Opened 21 months ago

Closed 4 months ago

Last modified 4 months ago

#27268 closed defect (fixed)

preferences cleanup

Reported by: rzb Owned by: gk
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff68-esr, TorBrowserTeam202001, tbb-pref
Cc: tbb-team Actual Points:
Parent ID: Points: 1
Reviewer: acat Sponsor:

Description

pref("plugins.hide_infobar_for_missing_plugin", true);

  • dead pref? hxxps://dxr.mozilla.org/mozilla-esr60/search?q=hide_infobar_for_missing_plugin -> 0 results found

pref("plugins.hideMissingPluginsNotification", true);

  • dead pref? hxxps://dxr.mozilla.org/mozilla-esr60/search?q=hideMissingPluginsNotification -> 0 results found

pref("plugin.expose_full_path", false);

  • dead pref? hxxps://dxr.mozilla.org/mozilla-esr60/search?q=expose_full_path -> 0 results found

unless you have custom code that re-implements this I don't think the pref does anything anymore:
pref("dom.mozTCPSocket.enabled", false);

  • hxxps://dxr.mozilla.org/mozilla-esr60/search?q=mozTCPSocket

pref("browser.usedOnWindows10", true);

  • dead pref? hxxps://hg.mozilla.org/mozilla-central/rev/5dd17564f294 -> also uplifted to FF50
  • hxxps://dxr.mozilla.org/mozilla-esr60/search?q=usedOnWindows10 -> 2 remnants for .introURL but nothing for "browser.usedOnWindows10"

pref("browser.selfsupport.enabled", false);
pref("browser.selfsupport.url", "");

  • both removed in FF55 -> ​https://bugzilla.mozilla.org/1361578
  • hxxps://dxr.mozilla.org/mozilla-esr60/search?q=browser.selfsupport -> 0 results
  • hxxps://dxr.mozilla.org/mozilla-esr60/search?q=selfsupport -> 8 results but nothing that looks related to these 2 prefs

pref("browser.newtabpage.directory.ping", "data:text/plain,");

pref("browser.newtabpage.directory.source", "data:text/plain,");
pref("browser.newtabpage.enhanced", false);
pref("browser.newtabpage.introShown", true);

pref("browser.newtabpage.remote", false);

Child Tickets

TicketStatusOwnerSummaryComponent
#28370closedtbb-teamstop setting obsolete media.eme.apiVisible prefApplications/Tor Browser

Change History (43)

comment:1 Changed 21 months ago by gk

Component: - Select a component → Applications/Tor Browser
Keywords: ff60-esr added
Owner: set to tbb-team

comment:2 in reply to:  description Changed 21 months ago by arthuredelstein

Keywords: TorBrowserTeam201808R added
Status: new → needs_review

Replying to rzb:

Thank you for finding these, rzb!

Here is my patch for review: ​https://github.com/arthuredelstein/tor-browser/commit/27268

pref("plugins.hide_infobar_for_missing_plugin", true);

  • dead pref? hxxps://dxr.mozilla.org/mozilla-esr60/search?q=hide_infobar_for_missing_plugin -> 0 results found

pref("plugins.hideMissingPluginsNotification", true);

  • dead pref? hxxps://dxr.mozilla.org/mozilla-esr60/search?q=hideMissingPluginsNotification -> 0 results found

Yes, I confirmed that "plugins.hideMissingPluginsNotification" and "plugins.notifyMissingFlash" were removed in ​https://bugzil.la/836415. And "plugins.hide_infobar_for_missing_plugin" was migrated to "plugins.hide_infobar_for_blocked_plugin" in ​https://bugzil.la/870112 and then removed in ​https://bugzil.la/1027049

The plugin finder service was removed, so these notifications no longer happen.

pref("plugin.expose_full_path", false);

  • dead pref? hxxps://dxr.mozilla.org/mozilla-esr60/search?q=expose_full_path -> 0 results found

Removed in ​https://bugzil.la/883671

The code now uses the "false" behavior always. (It never exposes a full path.)

unless you have custom code that re-implements this I don't think the pref does anything anymore:
pref("dom.mozTCPSocket.enabled", false);

  • hxxps://dxr.mozilla.org/mozilla-esr60/search?q=mozTCPSocket

Yes, this pref was removed in ​https://bugzil.la/1286530. I confirmed that navigator.mozTCPSocket is only exposed in chrome contexts.

pref("browser.usedOnWindows10", true);

  • dead pref? hxxps://hg.mozilla.org/mozilla-central/rev/5dd17564f294 -> also uplifted to FF50
  • hxxps://dxr.mozilla.org/mozilla-esr60/search?q=usedOnWindows10 -> 2 remnants for .introURL but nothing for "browser.usedOnWindows10"

Yes, this was removed in ​https://bugzil.la/1274633

pref("browser.selfsupport.enabled", false);
pref("browser.selfsupport.url", "");

  • both removed in FF55 -> ​https://bugzilla.mozilla.org/1361578
  • hxxps://dxr.mozilla.org/mozilla-esr60/search?q=browser.selfsupport -> 0 results
  • hxxps://dxr.mozilla.org/mozilla-esr60/search?q=selfsupport -> 8 results but nothing that looks related to these 2 prefs

Confirmed.

pref("browser.newtabpage.directory.ping", "data:text/plain,");

Confirmed.

pref("browser.newtabpage.directory.source", "data:text/plain,");
pref("browser.newtabpage.enhanced", false);
pref("browser.newtabpage.introShown", true);

Confirmed.

pref("browser.newtabpage.remote", false);

Confirmed.

comment:3 Changed 21 months ago by reportUrl

Whoa! Arthur! Unexpected!
What about obsolete #21916, #16443, #13575?
Also removed:
pref("datareporting.healthreport.about.reportUrl", "data:text/plain,");
pref("datareporting.healthreport.about.reportUrlUnified", "data:text/plain,");
pref("browser.newtabpage.preload", false); Bug 16316 - Avoid potential confusion over tiles for now.
pref("extensions.hotfix.id", ""); Bug 16837: Disable hotfix updates as they may cause compat issues
pref("browser.download.manager.retention", 1);

comment:4 Changed 21 months ago by rzb

here are some more

pref("browser.pocket.enabled", false);
pref("browser.pocket.api", "");
pref("browser.pocket.site", "");

pref("extensions.hotfix.id", "");

pref("datareporting.healthreport.about.reportUrl", "data:text/plain,");

pref("datareporting.healthreport.about.reportUrlUnified", "data:text/plain,");

pref("datareporting.healthreport.service.enabled", false);

pref("devtools.webide.autoinstallFxdtAdapters", false);

pref("dom.network.enabled",false);

pref("security.tls.unrestricted_rc4_fallback", false);

comment:5 Changed 21 months ago by gk

Status: needs_review → new

Thanks. I cherry-picked the patch Arthur made to tor-browser-60.1.0esr-8.0-1 (commit ad4624a470a0791ebe836c1b83df88b54f361286).

We should remove plugin.expose_full_path from browser_tor_TB4.js as well. Which I did in commit 7f61bed1a7dd5c6af77f80419fcf0979c78ec2b4.

Thanks rzb!

comment:6 Changed 21 months ago by gk

A user on the blog mentioned a bunch of resistfingerprinting related prefs we still set and which should be covered by that defense already (see: ​https://blog.torproject.org/comment/276556#comment-276556):

the following prefs should be left at their Firefox default values if privacy.resistFingerprinting is enabled:

dom.maxHardwareConcurrency,dom.enable_resource_timing,dom.enable_performance,device.sensors.enabled,browser.zoom.siteSpecific,dom.gamepad.enabled,dom.netinfo.enabled,media.webspeech.synth.enabled,media.video_stats.enabled,dom.w3c_touch_events.enabled,media.ondevicechange.enabled,webgl.enable-debug-renderer-info.

However, 000-tor-browser.js still changes them, except dom.netinfo.enabled (setting the obsolete dom.network.enabled pref instead), media.ondevicechange.enabled, and webgl.enable-debug-renderer-info.

comment:7 in reply to:  6 ; Changed 21 months ago by Thorin

Replying to gk:

A user on the blog mentioned a bunch of resistfingerprinting related prefs ...

I created an account just so I could talk to you guys :). THIS is not an issue in terms of changing TBB's fingerprint, because TBB can enforce/lock prefs and set their own default values. It is only for FF users, because any pref different from default that alters the FF FP is not good. When RFP becomes front facing in FF, very few users would tinker under the hood with about:config, so the vast majority would be at defaults

​https://github.com/ghacksuserjs/ghacks-user.js/issues/222 - here is a look at some of the earlier RFP patches and how they can alter the FP (any subsequent "clashes" are maintained in the user.js itself, under section 4600). e.g

  • media.video_stats.enabled=false disables the API, but RFP returns dynamically spoofed values
  • dom.netinfo.enabled=false returns "unknown: but RFP returns "undefined"

---
I emailed Arthur over 24 hrs ago, but he must have misread me. I wanted to point you guys to this -> ​https://github.com/ghacksuserjs/ghacks-user.js/issues/123

Any pref we have enforced or flipped in the user.js over the years (and we only deal with security/privacy/anti-FP etc prefs), when it is deprecated, ends up in this sticky. We capture all diffs between FF releases and the issue linked above provides hyperlinks to eacha nd every bugzilla as source for the pref's removal/renaming etc. It's also grouped by FF release, so you can just have at it and check everything from 59 back. Just wanted to save you some time.

---
I don't want to go OT, but HWA being turned on is an issue. We have a PoC that uses timing to get history leaks, and HWA=off is the only thing that makes it fail. Which is why I am waiting to see what YOU guys do with the all the perf/timing prefs (please don't follow my lead, or it will be the tail wagging the dog). See ​https://github.com/ghacksuserjs/ghacks-user.js/issues/491

Arthur: Tom Ritter was given the info on the timing attack PoC

comment:8 Changed 21 months ago by Thorin

so you can just have at it and check everything from 59 back

sorry, correction, from FF60 and earlier. The version number is the release in which it was deprecated,so you'll want to include 60

comment:9 in reply to:  7 Changed 21 months ago by gk

Replying to Thorin:

Replying to gk:

A user on the blog mentioned a bunch of resistfingerprinting related prefs ...

[snip]

I don't want to go OT, but HWA being turned on is an issue. We have a PoC that uses timing to get history leaks, and HWA=off is the only thing that makes it fail.

I am mostly confused about your comment but if there is an issue with Hardware acceleration turned on for an unmodified Tor Browser, please open a ticket detailing what the problem is so we can think about fixing it.

[snip]

comment:10 Changed 21 months ago by Thorin

but if there is an issue with Hardware acceleration turned on for an unmodified Tor Browser

Sorry, forgot that TBB does not enable history (right?), so in this case re our PoC, it is not an issue

I am mostly confused about your comment

If you didn't mean just the HWA part, then IDK what else to say. If it's about flipped prefs vs RFP patches altering the FP, then see this comment: https://trac.torproject.org/projects/tor/ticket/27257#comment:5 . As for deprecated prefs as per his ticket topic, that should be self-explanatory (a source of 90+ most-likely-related TBB prefs that are deprecated with sources)

comment:11 in reply to:  10 Changed 21 months ago by gk

Replying to Thorin:

but if there is an issue with Hardware acceleration turned on for an unmodified Tor Browser

Sorry, forgot that TBB does not enable history (right?), so in this case re our PoC, it is not an issue

Good. FWIW that is not related to HWA. I've observed this behavior years a ago, see: comment:8:ticket:11333. The PoC in ​https://bugzilla.mozilla.org/show_bug.cgi?id=884270 should still work.

I am mostly confused about your comment

If you didn't mean just the HWA part, then IDK what else to say. If it's about flipped prefs vs RFP patches altering the FP, then see this comment: https://trac.torproject.org/projects/tor/ticket/27257#comment:5 . As for deprecated prefs as per his ticket topic, that should be self-explanatory (a source of 90+ most-likely-related TBB prefs that are deprecated with sources)

That comment makes sense. Yes, we need to look at the resistfingerprinting prefs closer during the clean-up. In general, there should not be any need for deviation on our side as we were involved with patch upstreaming. If there is then we should think harder about the process because the goal is not to upstream patches for feature X and then still carrying on patches for X on our side.

comment:12 Changed 21 months ago by Thorin

OT, FYI: HWA=off mitigates the history leak in our PoC ( it seems disabling HW acceleration slows it down to a point where the attack is no longer really practical) - it's just a side affect, that was all. It is more related to ​https://bugzilla.mozilla.org/show_bug.cgi?id=1477773, but the PoC does not care about layout.css.visited_links_enabled=false. I do not know what the bugzilla is (if any) as I do not have access to "access denied" bugs - but its clearly not a TBB issue if you disable history :) And Tom Ritter / Mozilla are aware of it

sorry for unloading this OT at yer! :)

comment:13 Changed 21 months ago by rzb

and a few more ...

pref("intl.charset.default", "windows-1252");

  • can't find the bugzilla but it was apparently removed in FF28
  • may want to check if there's a replacement

pref("media.audio_data.enabled", false);

  • can't find the bugzilla but it was apparently removed in FF43
  • may want to check if there's a replacement

pref("devtools.appmanager.enabled", false);

pref("browser.safebrowsing.enabled", false);

pref("media.gmp-eme-adobe.visible", false);
pref("media.gmp-eme-adobe.enabled", false);

pref("media.eme.apiVisible", false);

pref("browser.reader.detectedFirstArticle", true);

pref("dom.enable_user_timing", false);

comment:14 Changed 21 months ago by gk

Keywords: TorBrowserTeam201808 added; TorBrowserTeam201808R removed

comment:15 Changed 21 months ago by gk

Keywords: TorBrowserTeam201809 added; TorBrowserTeam201808 removed

Moving our tickets to September 2018

comment:16 Changed 21 months ago by gk

While we are at it, we should clean up the general user agent settings prefs as they are not used anymore and confuse users, see e.g. #26146.

comment:17 Changed 8 months ago by Thorin

Here's an updated list for cleaning up for ESR68, including some missing bugzillas etc. I may have missed a couple of things, but this is a start. There are maybe some more RFP redundant items from my ghacks user.js section 4600

[1] ​https://github.com/ghacksuserjs/ghacks-user.js/blob/master/user.js#L1489
[2] ​https://github.com/ghacksuserjs/ghacks-user.js/issues/123 [my deprecated items and sources list]

Housekeeping

  • close #28370 as a duplicate of this ticket (it's in the list below)
  • close #32028 as a duplicate of this ticket (everything there is in this list)
  • this ticket: change keyword to ff68-esr etc

Urgent?

Deprecated

Not in DXR

RFP Redundant

RFP Redundant Part 2

  • NOTE: RFP overrides these, some are deprecated AFAICT (e.g vendor), current values are out of sync with ESR68, and maintaining it is extra work
    • general.appname.override
    • general.appversion.override
    • general.oscpu.override
    • general.platform.override
    • general.productSub.override
    • general.buildID.override
    • general.useragent.vendor
    • general.useragent.vendorSub

RFP Redundant Part 3: probably changes fingerprint, maybe entropy

Not sure

  • browser.startup.homepage_override.buildID
    • FF (not RFP) always returns the navigator.buildID as 201810010000001, productSub and UA still use 20100101
    • ​https://bugzilla.mozilla.org/583181
    • so not sure what value you want here, I only included it because it's bundled with all the other general.override prefs. I think it should be at the top with the other startup prefs
Last edited 8 months ago by Thorin (previous) (diff)

comment:18 in reply to:  17 ; Changed 8 months ago by tom

Replying to Thorin:

RFP Redundant

  • dom.enable_resource_timing & dom.enable_performance
    • check with tom, 100% sure this is covered by tom's RFP reduceTimerPrecision prefs
    • not sure if RFP overrides these: i.e disabling the API vs rounding it: for all I know you might be causing perf issues: ask tom :)

With RFP set, all of these timestamps will be clamped/jittered. Additionally, RFP has the behavior of setting dom.enable_performance to false (so you don't need to set that pref.)

However RFP does not have the same behavior for dom.enable_resource_timing - so you may want to disable that explicitly.

RFP Redundant Part 2

  • NOTE: RFP overrides these, some are deprecated AFAICT (e.g vendor), current values are out of sync with ESR68, and maintaining it is extra work
    • general.appname.override
    • general.appversion.override
    • general.oscpu.override
    • general.platform.override
    • general.productSub.override
    • general.buildID.override
    • general.useragent.vendor
    • general.useragent.vendorSub

Yeah all of these should be deleted from tor's js file. With RFP enabled they do nothing.

RFP Redundant Part 3: probably changes fingerprint, maybe entropy

  • dom.netinfo.enabled - ​https://bugzilla.mozilla.org/1372072
    • this pref disables the API: you get an error or "undefined"
    • the pref is only default true on mobile: RFP returns "unknown"
    • so removing the pref would create two buckets: mobile vs desktop

RFP ought to return one value for all situations, right? (I have no verified.)

I don't remember what RFP does to this one.

  • media.video_stats.enabled - ​https://bugzilla.mozilla.org/1369309
    • same thing: disabling vs spoof
    • needs double checking: some RFP values are the same, some are bucketized so may create more entropy: check with tom

RFP should give the same results for all users. The value is dependent on the playback time of the video however. (e.g. you'll get a different answer for 1 second vs 10 seconds into the video.)

Setting this pref to false removes the objects from the DOM; setting RFP just always reports "No gamepads."

Great list.

comment:19 in reply to:  18 Changed 8 months ago by Thorin

Replying to tom:

RFP Redundant Part 3: probably changes fingerprint, maybe entropy

  • dom.netinfo.enabled - ​https://bugzilla.mozilla.org/1372072
    • this pref disables the API: you get an error or "undefined"
    • the pref is only default true on mobile: RFP returns "unknown"
    • so removing the pref would create two buckets: mobile vs desktop

RFP ought to return one value for all situations, right? (I have no verified.)

You can test on ​https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#headers

The way it works is

  • if the API is disabled (default desktop), you cannot read navigator.connection.type -> therefore: error -> (instead I fall back to navigator.connection -> "undefined"
  • if the API is enabled (default mobile), then you can read navigator.connection.type and that's when RFP kicks in and returns unknown

code: view-source:https://ghacksuserjs.github.io/TorZillaPrint/js/headers.js

Two buckets. So up to Georg I guess.

Last edited 8 months ago by Thorin (previous) (diff)

comment:20 Changed 8 months ago by gk

Keywords: ff68-esr TorBrowserTeam201910R GeorgKoppen201910 added; ff60-esr TorBrowserTeam201809 removed
Status: new → needs_review

Great work! I'll start with a patch for the first three sections. What should we set intl.charset.fallback.override to in your opinion?

For the prefs not in DXR here is a little tip that has helped me a lot in the past to track those issues down:

1) Figure out in which file the prefs were used, ideally files which still exist in your git checkout
2) Do a git log -p path_to_file
3) Search in the git log for the prefs. This should give you the commit where they got removed.

So, ​https://bugzilla.mozilla.org/show_bug.cgi?id=1254558 is the bug where they got removed.

bug_27268 (​https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_27268) has the first batch of prefs fixups for review (two commits). There is a Torbutton patch, too, in bug_27268 (​https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_27268&id=a2eac79bab7c2afa17cd45109a5669cf528215c0): Note, I removed security.pki.sha1_enforcement_level as well even though the pref is still in action. But we set it to a lower value than Mozilla ships today which we should not do.

We should figure out as well whether there is a new hotfix mechanism that still needs to get disabled.

Oh, and I'll adapt the commit message for the preference commit accordingly next time I rebase the branch.

comment:21 in reply to:  20 ; Changed 8 months ago by Thorin

Replying to gk:

Great work! I'll start with a patch for the first three sections. What should we set intl.charset.fallback.override to in your opinion?

IMO this shouldn't be done here: but rather be tied to privacy.spoof_english: see https://trac.torproject.org/projects/tor/ticket/20025#comment:5 .. the solution part

Set intl.charset.fallback.override = windows-1252 when privacy.spoof_english = 2, and reset it when privacy.spoof_english !== 2. Do this upstream

---

bug_27268 (​https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_27268) has the first batch of prefs fixups for review (two commits). There is a Torbutton patch, too, in bug_27268 (​https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_27268&id=a2eac79bab7c2afa17cd45109a5669cf528215c0): Note, I removed security.pki.sha1_enforcement_level as well even though the pref is still in action. But we set it to a lower value than Mozilla ships today which we should not do.

Urgent, Deprecated + Not-in-DXR (first three sections) check: I don't see the following being removed

  • intl.charset.default
  • media.gmp-eme-adobe.visible
  • media.gmp-eme-adobe.enable
  • browser.download.manager.scanWhenDone
  • browser.download.manager.retention

And I don't see a dom.netinfo.enabled in the tor button code

comment:22 in reply to:  21 ; Changed 8 months ago by gk

Replying to Thorin:

Replying to gk:

Great work! I'll start with a patch for the first three sections. What should we set intl.charset.fallback.override to in your opinion?

IMO this shouldn't be done here: but rather be tied to privacy.spoof_english: see https://trac.torproject.org/projects/tor/ticket/20025#comment:5 .. the solution part

Set intl.charset.fallback.override = windows-1252 when privacy.spoof_english = 2, and reset it when privacy.spoof_english !== 2. Do this upstream

I see.

bug_27268 (​https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_27268) has the first batch of prefs fixups for review (two commits). There is a Torbutton patch, too, in bug_27268 (​https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_27268&id=a2eac79bab7c2afa17cd45109a5669cf528215c0): Note, I removed security.pki.sha1_enforcement_level as well even though the pref is still in action. But we set it to a lower value than Mozilla ships today which we should not do.

Urgent, Deprecated + Not-in-DXR (first three sections) check: I don't see the following being removed

  • intl.charset.default
  • media.gmp-eme-adobe.visible
  • media.gmp-eme-adobe.enable
  • browser.download.manager.scanWhenDone
  • browser.download.manager.retention

Huh, you are right. bug_27268_v2 (​https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_27268_v2) should fix that. The eme prefs were removed earlier on on our latest branch.

And I don't see a dom.netinfo.enabled in the tor button code

Hrm. I am not sure yet what we should do. While we don't defend against os fingerprinting leaving the netinfo state the way it is seems a bit lame. I guess we should disable it everywhere?

comment:23 in reply to:  22 ; Changed 8 months ago by Thorin

Replying to gk:

And I don't see a dom.netinfo.enabled in the tor button code

Hrm. I am not sure yet what we should do. While we don't defend against os fingerprinting leaving the netinfo state the way it is seems a bit lame. I guess we should disable it everywhere?

I agree. Lets not give away free entropy... make the bastards work for it. Ideally, upstream we should make RFP measures more robust and anti-tamperable (e.g. from about:config tweakers)

comment:24 in reply to:  23 Changed 8 months ago by gk

Replying to Thorin:

Replying to gk:

And I don't see a dom.netinfo.enabled in the tor button code

Hrm. I am not sure yet what we should do. While we don't defend against os fingerprinting leaving the netinfo state the way it is seems a bit lame. I guess we should disable it everywhere?

I agree. Lets not give away free entropy... make the bastards work for it. Ideally, upstream we should make RFP measures more robust and anti-tamperable (e.g. from about:config tweakers)

Actually, we had the discussion about what to do in #27257 already but lost track of it it seems...

comment:25 in reply to:  20 ; Changed 7 months ago by mcs

Replying to gk:

bug_27268 (​https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_27268) has the first batch of prefs fixups for review (two commits). There is a Torbutton patch, too, in bug_27268 (​https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_27268&id=a2eac79bab7c2afa17cd45109a5669cf528215c0): Note, I removed security.pki.sha1_enforcement_level as well even though the pref is still in action. But we set it to a lower value than Mozilla ships today which we should not do.

r=mcs
These patches look good to me, although I did not re-do all of the deep detective work that other people have already done for this ticket. I tried to do a sanity check for each removed pref though.

We should figure out as well whether there is a new hotfix mechanism that still needs to get disabled.

Do we need a new ticket for that task?

comment:26 in reply to:  25 Changed 7 months ago by gk

Keywords: TorBrowserTeam201911 GeorgKoppen201911 added; TorBrowserTeam201910R GeorgKoppen201910 removed
Status: needs_review → new

Replying to mcs:

Replying to gk:

bug_27268 (​https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_27268) has the first batch of prefs fixups for review (two commits). There is a Torbutton patch, too, in bug_27268 (​https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_27268&id=a2eac79bab7c2afa17cd45109a5669cf528215c0): Note, I removed security.pki.sha1_enforcement_level as well even though the pref is still in action. But we set it to a lower value than Mozilla ships today which we should not do.

r=mcs
These patches look good to me, although I did not re-do all of the deep detective work that other people have already done for this ticket. I tried to do a sanity check for each removed pref though.

We should figure out as well whether there is a new hotfix mechanism that still needs to get disabled.

Do we need a new ticket for that task?

Could be. I need to look closer and will pick this whole ticket up in November again. So setting this to new and amending the keywords to not lose track here.

I've picked the Torbutton commit and applied it to master (commit 73a43f2f4d846b2870757d7aa18a1b33643ba2b5) and maint-9.0 (commit 09e3050265303eff776ba540861c533d5cab2254).

The browser related commits landed on tor-browser-68.2.0esr-9.0-1 (commits 5e83d0a74e4d5ccaef5275e3cc0bfe36e77e9315 and 479630e18d3c184846f94e2e1e53f6d4df1c5cb) and tor-browser-68.2.0esr-9.5-1 (commits b9e148eb996515e18ce47cd42f18b6dd967c1cbd and 1762a2a4ba9eb9eca76f9d522f456dd262a99f84).

comment:27 Changed 7 months ago by gk

Points: → 0.5

comment:28 Changed 6 months ago by pili

Owner: changed from tbb-team to gk
Status: new → assigned

assigning tickets to gk

comment:29 Changed 6 months ago by brade

Cc: tbb-team added

comment:30 Changed 6 months ago by gk

Keywords: GeorgKoppen201911 removed

Work bugs are tracked by assignment from now on.

comment:31 Changed 6 months ago by Thorin

​https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-68.2.0esr-9.5-1#n208

comment:32 Changed 6 months ago by pili

Keywords: TorBrowserTeam201912 added; TorBrowserTeam201911 removed

Moving tickets to December

comment:33 Changed 5 months ago by sysrqb

Keywords: TorBrowserTeam202001 added; TorBrowserTeam201912 removed

comment:34 Changed 5 months ago by gk

Keywords: TorBrowserTeam202001R added; TorBrowserTeam202001 removed
Points: 0.5 → 1
Status: assigned → needs_review

Okay, I think I've addressed all the remaining removals in bug_27268_v4 (​https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_27268_v4) (including setting dom.netinfo.enabled to false).

Yes, privacy.use_utc_timezone and privacy.suppressModifierKeyEvents came indeed from old Tor Browser patches (#16622 and #17009 respectively) that got upstreamed meanwhile.

As to the hotfix mechanism: that's now part of the ​Go Faster mechanism using system addons. We disable that in #19890, so we are good.

comment:35 Changed 5 months ago by Thorin

Cool :) Looking at ​https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_27268_v4&id=469729e01aae49cbd4a571fb07fe240baa23f576

from the list in comment 18

RFP redundant (4 of 6)
-pref("dom.maxHardwareConcurrency", 1);
-pref("ui.use_standins_for_native_colors", true);
-pref("browser.zoom.siteSpecific", false);
-pref("dom.enable_performance", false);

RFP redundant part 2 (8 out of 8)
-pref("general.appname.override", "Netscape");
-pref("general.appversion.override", "5.0 (Windows)");
-pref("general.oscpu.override", "Windows NT 6.1");
-pref("general.platform.override", "Win32");
-pref("general.productSub.override", "20100101");
-pref("general.buildID.override", "20100101");
-pref("general.useragent.vendor", "");
-pref("general.useragent.vendorSub", "");

RFP redundant part 3 (5 of 6)
+pref("dom.netinfo.enabled", false);
-pref("media.webspeech.synth.enabled", false);
-pref("media.video_stats.enabled", false);
-pref("dom.gamepad.enabled", false); // bugs.torproject.org/13023
-pref("device.sensors.enabled", false);

New (3 of 3)
-pref("devtools.webide.autoinstallADBHelper", false);
-pref("devtools.webide.autoinstallFxdtAdapters", false);
+pref("devtools.webide.autoinstallADBExtension", false);

That all looks good. What's not addressed (or I don't understand): these are still being applied, but don't do anything: RFP already covers them

  • dom.enable_resource_timing
  • privacy.use_utc_timezone
  • privacy.suppressModifierKeyEvents

I do not see any code upstream for the two privacy. prefs. And the resource timing is redundant (from part 1 in comment 18)

comment:36 in reply to:  35 ; Changed 5 months ago by gk

Replying to Thorin:

[snip]

That all looks good. What's not addressed (or I don't understand): these are still being applied, but don't do anything: RFP already covers them

  • dom.enable_resource_timing

I actually read tjr's comment as an advice to actually make sure we disable that, which is why I did not touch that pref. Quoting from comment 18:

However RFP does not have the same behavior for dom.enable_resource_timing - so you may want to disable that explicitly.
  • privacy.use_utc_timezone
  • privacy.suppressModifierKeyEvents

I do not see any code upstream for the two privacy. prefs.

Dang. Yes, that's been my bad. I was researching the prefs (and made a respective comment in my last comment about the results) but I forgot to actually remove them. Fixed in bug_27268_v5 (​https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_27268_v5).

comment:37 in reply to:  36 Changed 5 months ago by Thorin

v5 looks good

Replying to gk:

  • dom.enable_resource_timing

I actually read tjr's comment as an advice to actually make sure we disable that, which is why I did not touch that pref. Quoting from comment 18:

However RFP does not have the same behavior for dom.enable_resource_timing - so you may want to disable that explicitly.

OK. AFAIK it doesn't make a difference but tom would know better than most

As long as it can't "hurt" RFP then I guess it's a moot point

comment:38 Changed 4 months ago by pili

Reviewer: → acat

comment:39 Changed 4 months ago by acat

The changes in ​https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_27268_v5 look good to me, too.

comment:40 in reply to:  39 ; Changed 4 months ago by boklm

Keywords: TorBrowserTeam202001 added; TorBrowserTeam202001R removed
Status: needs_review → needs_information

Replying to acat:

The changes in ​https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_27268_v5 look good to me, too.

I cherry-picked the two patches on branch tor-browser-68.4.1esr-9.5-1 as commits da7e8b35800a41249b5c2a847c4f931c4bf6582a and 77970cdee3ba6c294a7acfe9d9b5a2ae9511e579.

Is there still more preferences cleanup needed, or can we close this ticket?

comment:41 in reply to:  40 ; Changed 4 months ago by Thorin

Replying to boklm:

Is there still more preferences cleanup needed, or can we close this ticket?

AFAIK, we're done here. Everything listed has been addressed, and I couldn't find anything else in the TB pref list that is irrelevant. We can start a new ticket for esr-78 when needed

comment:42 in reply to:  41 Changed 4 months ago by boklm

Resolution: → fixed
Status: needs_information → closed

Replying to Thorin:

Replying to boklm:

Is there still more preferences cleanup needed, or can we close this ticket?

AFAIK, we're done here. Everything listed has been addressed, and I couldn't find anything else in the TB pref list that is irrelevant. We can start a new ticket for esr-78 when needed

Thanks. Closing this ticket then.

comment:43 Changed 4 months ago by gk

Keywords: tbb-pref added
Note: See TracTickets for help on using tickets.