Opened 4 weeks ago

Last modified 12 days 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,");

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

Change History (16)

comment:1 Changed 4 weeks ago by gk

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

comment:2 in reply to:  description Changed 4 weeks ago by arthuredelstein

Keywords: TorBrowserTeam201808R added
Status: newneeds_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 4 weeks 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 4 weeks 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 4 weeks ago by gk

Status: needs_reviewnew

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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks ago by gk

Keywords: TorBrowserTeam201808 added; TorBrowserTeam201808R removed

comment:15 Changed 2 weeks ago by gk

Keywords: TorBrowserTeam201809 added; TorBrowserTeam201808 removed

Moving our tickets to September 2018

comment:16 Changed 12 days 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.

Note: See TracTickets for help on using tickets.