Opened 3 months ago
Last modified 2 months ago
#27268 new defect
preferences cleanup
| Reported by: | rzb | Owned by: | tbb-team |
|---|---|---|---|
| Priority: | Medium | Milestone: | |
| Component: | Applications/Tor Browser | Version: | |
| Severity: | Normal | Keywords: | ff60-esr, TorBrowserTeam201809 |
| Cc: | Actual Points: | ||
| Parent ID: | Points: | ||
| Reviewer: | 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,");
- dead pref? removed in FF55: https://bugzilla.mozilla.org/1241390
pref("browser.newtabpage.directory.source", "data:text/plain,");
pref("browser.newtabpage.enhanced", false);
pref("browser.newtabpage.introShown", true);
- all 3 were removed in FF60: https://bugzilla.mozilla.org/buglist.cgi?bug_id=1370930,1433133
pref("browser.newtabpage.remote", false);
- last remnants removed in FF60 (https://bugzilla.mozilla.org/1355166)
Child Tickets
| Ticket | Status | Owner | Summary | Component |
|---|---|---|---|---|
| #28370 | new | tbb-team | stop setting obsolete media.eme.apiVisible pref | Applications/Tor Browser |
Change History (16)
comment:1 Changed 3 months ago by
| Component: | - Select a component → Applications/Tor Browser |
|---|---|
| Keywords: | ff60-esr added |
| Owner: | set to tbb-team |
comment:2 Changed 3 months ago by
| Keywords: | TorBrowserTeam201808R added |
|---|---|
| Status: | new → needs_review |
comment:3 Changed 3 months ago by
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 3 months ago by
here are some more
pref("browser.pocket.enabled", false);
pref("browser.pocket.api", "");
pref("browser.pocket.site", "");
- all 3 replaced by extensions.pocket.* in FF46: https://bugzilla.mozilla.org/1215694
pref("extensions.hotfix.id", "");
- removed in FF60: https://bugzilla.mozilla.org/1356331
pref("datareporting.healthreport.about.reportUrl", "data:text/plain,");
- removed in FF59: https://bugzilla.mozilla.org/1352497
pref("datareporting.healthreport.about.reportUrlUnified", "data:text/plain,");
- removed in FF47: https://bugzilla.mozilla.org/1236580
pref("datareporting.healthreport.service.enabled", false);
- removed in FF46: https://bugzilla.mozilla.org/1234526
pref("devtools.webide.autoinstallFxdtAdapters", false);
- removed in FF57: https://bugzilla.mozilla.org/1393497
pref("dom.network.enabled",false);
- removed in FF31 and replaced by dom.netinfo.enabled: https://bugzilla.mozilla.org/960426
- dom.netinfo.enabled is covered by privacy.resistFingerprinting since FF56 (bug 1372072)
pref("security.tls.unrestricted_rc4_fallback", false);
- removed in FF53: https://bugzilla.mozilla.org/1130670
comment:5 Changed 3 months ago by
| 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 follow-up: 7 Changed 3 months ago by
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 follow-up: 9 Changed 3 months ago by
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 3 months ago by
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 Changed 3 months ago by
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 follow-up: 11 Changed 3 months ago by
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 Changed 3 months ago by
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 3 months ago by
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 3 months ago by
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);
- removed in FF45: https://bugzilla.mozilla.org/1216590
- integrated into WebIDE. Covered by devtools.webide.enabled=false ?
pref("browser.safebrowsing.enabled", false);
- removed in FF50: https://bugzilla.mozilla.org/1025965
- renamed to browser.safebrowsing.phishing.enabled
pref("media.gmp-eme-adobe.visible", false);
pref("media.gmp-eme-adobe.enabled", false);
- removed in FF52 and/or FF53: https://bugzilla.mozilla.org/buglist.cgi?bug_id=1329538,1337121,1329543
pref("media.eme.apiVisible", false);
- removed in FF54: https://bugzilla.mozilla.org/1242321
- revert this patch?
pref("browser.reader.detectedFirstArticle", true);
- removed in FF55: https://bugzilla.mozilla.org/1352501
- https://dxr.mozilla.org/mozilla-esr60/search?q=detectedFirstArticle
pref("dom.enable_user_timing", false);
- removed in FF55: https://bugzilla.mozilla.org/1344669
- revert this patch?
comment:14 Changed 3 months ago by
| Keywords: | TorBrowserTeam201808 added; TorBrowserTeam201808R removed |
|---|
comment:15 Changed 2 months ago by
| Keywords: | TorBrowserTeam201809 added; TorBrowserTeam201808 removed |
|---|
Moving our tickets to September 2018
comment:16 Changed 2 months ago by
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.
Replying to rzb:
Thank you for finding these, rzb!
Here is my patch for review: https://github.com/arthuredelstein/tor-browser/commit/27268
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.
Removed in https://bugzil.la/883671
The code now uses the "false" behavior always. (It never exposes a full path.)
Yes, this pref was removed in https://bugzil.la/1286530. I confirmed that navigator.mozTCPSocket is only exposed in chrome contexts.
Yes, this was removed in https://bugzil.la/1274633
Confirmed.
Confirmed.
Confirmed.
Confirmed.