preferences cleanup

added TorBrowserTeam202001 component::applications/tor browser ff68-esr owner::gk points::1 priority::medium reporter::rzb resolution::fixed reviewer::acat severity::normal status::closed tbb-pref type::defect labels

Trac:
Owner: N/A to tbb-team
Component: - Select a component to Applications/Tor Browser
Keywords: N/A deleted, ff60-esr added

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,");

dead pref? removed in FF55: https://bugzilla.mozilla.org/1241390

Confirmed.

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

Confirmed.

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

last remnants removed in FF60 (https://bugzilla.mozilla.org/1355166)

Confirmed.

Trac:
Keywords: N/A deleted, TorBrowserTeam201808R added
Status: new to needs_review

Whoa! Arthur! Unexpected! What about obsolete #21916 (moved), #16443 (moved), #13575 (moved)? 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);

Trac:
Username: reportUrl

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

Trac:
Username: rzb

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!

Trac:
Status: needs_review to new

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.

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

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

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]

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)

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.

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! :)

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?

Trac:
Username: rzb

Trac:
Keywords: TorBrowserTeam201808R deleted, TorBrowserTeam201808 added

Moving our tickets to September 2018

Trac:
Keywords: TorBrowserTeam201808 deleted, TorBrowserTeam201809 added

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 (moved).

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 (moved) as a duplicate of this ticket (it's in the list below)
close #32028 (moved) as a duplicate of this ticket (everything there is in this list)
this ticket: change keyword to ff68-esr etc

Urgent?

FF28: intl.charset.default - https://bugzilla.mozilla.org/910192
- you need to fix this asap in #20025 (moved) with intl.charset.fallback.override
FF46: browser.pocket.api, browser.pocket.enabled, browser.pocket.site - https://bugzilla.mozilla.org/1215694
- if needed, replace with extensions.pocket* which are currently not covered

Deprecated

FF24: plugin.expose_full_path - https://bugzilla.mozilla.org/883671
FF31: dom.network.enabled - https://bugzilla.mozilla.org/960426
- replaced by dom.netinfo.enabled which is already covered
FF43: media.audio_data.enabled - https://bugzilla.mozilla.org/1206091
FF45: devtools.appmanager.enabled - https://bugzilla.mozilla.org/1216590
FF46: datareporting.healthreport.service.enabled - https://bugzilla.mozilla.org/1234526
FF47: datareporting.healthreport.about.reportUrlUnified - https://bugzilla.mozilla.org/1236580
FF50: browser.safebrowsing.enabled - https://bugzilla.mozilla.org/1025965
- the two main switches are already covered: browser.safebrowsing.malware.enabled, browser.safebrowsing.phishing.enabled
FF52: media.gmp-eme-adobe.visible - https://bugzilla.mozilla.org/buglist.cgi?bug_id=1329538,1337121
FF52: media.gmp-eme-adobe.enable - https://bugzilla.mozilla.org/buglist.cgi?bug_id=1329538,1337121
FF53: security.tls.unrestricted_rc4_fallback - https://bugzilla.mozilla.org/1130670
FF54: media.eme.apiVisible - https://bugzilla.mozilla.org/1242321
FF55: dom.enable_user_timing - https://bugzilla.mozilla.org/1344669
FF59: datareporting.healthreport.about.reportUrl - https://bugzilla.mozilla.org/1352497
FF60: extensions.hotfix.id - https://bugzilla.mozilla.org/1356331
FF60: browser.newtabpage.preload - https://bugzilla.mozilla.org/show_bug.cgi?id=1355166
FF61: network.jar.block-remote-files - https://bugzilla.mozilla.org/1427726
FF63: browser.search.countryCode - https://bugzilla.mozilla.org/1462015
FF67: dom.event.highrestimestamp.enabled - https://bugzilla.mozilla.org/1485264

Not in DXR

FF54?: browser.download.manager.scanWhenDone - https://bugzilla.mozilla.org/851471 (best I can find)
- https://hg.mozilla.org/mozilla-central/rev/baf05f61bc14
FF55?: browser.download.manager.retention
- https://hg.mozilla.org/mozilla-central/rev/ccfe5420876a232a834afe88597228d832afb089

RFP Redundant

NOTE: RFP overrides these and FFS no-one should disable RFP
dom.maxHardwareConcurrency - https://bugzilla.mozilla.org/1360039
- or at least set as value 2 to match RFP
ui.use_standins_for_native_colors - https://bugzilla.mozilla.org/1485266
browser.zoom.siteSpecific - https://bugzilla.mozilla.org/1369357
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 :)
privacy.use_utc_timezone - https://bugzilla.mozilla.org/1330890
- is this an old Tor Browser only pref? is there old code to rip out?
- RFP already spoofs as UTC

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

NOTE: we need to make a decision/double-check here on these
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
media.webspeech.synth.enabled - https://bugzilla.mozilla.org/1333641
- same thing: disabling vs spoofing
- needs double checking: but the new FP is universal AFAIK
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
dom.gamepad.enabled - https://bugzilla.mozilla.org/1337161
- RFP hides gamepad from content
- not sure if the FP changes and is universal
device.sensors.enabled - https://bugzilla.mozilla.org/1369319
- RFP already disables the device censor
- not sure if the FP changes but it should be universal
privacy.suppressModifierKeyEvents- https://bugzilla.mozilla.org/buglist.cgi?bug_id=1222285,1433592,1438795
- is this an old Tor Browser only pref?
- RFP already spoofs keyboard events and suppress keyboard modifier events (SHIFT and both ALT keys)

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

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.)

media.webspeech.synth.enabled - https://bugzilla.mozilla.org/1333641

same thing: disabling vs spoofing

needs double checking: but the new FP is universal AFAIK

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.)

dom.gamepad.enabled - https://bugzilla.mozilla.org/1337161

RFP hides gamepad from content

not sure if the FP changes and is universal

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

Great list.

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-https://ghacksuserjs.github.io/TorZillaPrint/js/headers.js

Two buckets. So up to Georg I guess.

preferences cleanup

Child items 0

Activity