Opened 16 months ago
Last modified 11 days ago
#27268 assigned defect
preferences cleanup
Reported by: | rzb | Owned by: | gk |
---|---|---|---|
Priority: | Medium | Milestone: | |
Component: | Applications/Tor Browser | Version: | |
Severity: | Normal | Keywords: | ff68-esr, TorBrowserTeam201912 |
Cc: | tbb-team | Actual Points: | |
Parent ID: | Points: | 0.5 | |
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 | closed | tbb-team | stop setting obsolete media.eme.apiVisible pref | Applications/Tor Browser |
Change History (32)
comment:1 Changed 16 months ago by
Component: | - Select a component → Applications/Tor Browser |
---|---|
Keywords: | ff60-esr added |
Owner: | set to tbb-team |
comment:2 Changed 16 months ago by
Keywords: | TorBrowserTeam201808R added |
---|---|
Status: | new → needs_review |
comment:3 Changed 16 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 16 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 16 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 16 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 16 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 16 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 16 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 16 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 16 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 16 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 16 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 16 months ago by
Keywords: | TorBrowserTeam201808 added; TorBrowserTeam201808R removed |
---|
comment:15 Changed 15 months ago by
Keywords: | TorBrowserTeam201809 added; TorBrowserTeam201808 removed |
---|
Moving our tickets to September 2018
comment:16 Changed 15 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.
comment:17 follow-up: 18 Changed 2 months ago by
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?
- FF28:
intl.charset.default
- https://bugzilla.mozilla.org/910192- you need to fix this asap in #20025 with
intl.charset.fallback.override
- you need to fix this asap in #20025 with
- 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
- if needed, replace with
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) - FF55?:
browser.download.manager.retention
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
- or at least set as value
ui.use_standins_for_native_colors
- https://bugzilla.mozilla.org/1485266browser.zoom.siteSpecific
- https://bugzilla.mozilla.org/1369357dom.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 use20100101
- 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
- FF (not RFP) always returns the navigator.buildID as
comment:18 follow-up: 19 Changed 2 months ago by
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.
comment:19 Changed 2 months ago by
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 tonavigator.connection
-> "undefined" - if the API is enabled (default mobile), then you can read
navigator.connection.type
and that's when RFP kicks in and returnsunknown
code: view-source:https://ghacksuserjs.github.io/TorZillaPrint/js/headers.js
Two buckets. So up to Georg I guess.
comment:20 follow-ups: 21 25 Changed 2 months ago by
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 follow-up: 22 Changed 2 months ago by
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
whenprivacy.spoof_english
=2
, and reset it whenprivacy.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, inbug_27268
(https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_27268&id=a2eac79bab7c2afa17cd45109a5669cf528215c0): Note, I removedsecurity.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 follow-up: 23 Changed 2 months ago by
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
whenprivacy.spoof_english
=2
, and reset it whenprivacy.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, inbug_27268
(https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_27268&id=a2eac79bab7c2afa17cd45109a5669cf528215c0): Note, I removedsecurity.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 follow-up: 24 Changed 2 months ago by
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 Changed 2 months ago by
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 follow-up: 26 Changed 6 weeks ago by
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, inbug_27268
(https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_27268&id=a2eac79bab7c2afa17cd45109a5669cf528215c0): Note, I removedsecurity.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 Changed 6 weeks ago by
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, inbug_27268
(https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_27268&id=a2eac79bab7c2afa17cd45109a5669cf528215c0): Note, I removedsecurity.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 6 weeks ago by
Points: | → 0.5 |
---|
comment:28 Changed 3 weeks ago by
Owner: | changed from tbb-team to gk |
---|---|
Status: | new → assigned |
assigning tickets to gk
comment:29 Changed 3 weeks ago by
Cc: | tbb-team added |
---|
comment:30 Changed 3 weeks ago by
Keywords: | GeorgKoppen201911 removed |
---|
Work bugs are tracked by assignment from now on.
comment:31 Changed 3 weeks ago by
devtools.webide.autoinstallADBHelper
(which you set to false) was removed in F64 and replaced bydevtools.webide.autoinstallADBExtension
(which you don't set and is at default true) - https://bugzilla.mozilla.org/show_bug.cgi?id=1491315devtools.webide.autoinstallFxdtAdapters
was deprecated in FF57 - https://bugzilla.mozilla.org/show_bug.cgi?id=1393497
comment:32 Changed 11 days ago by
Keywords: | TorBrowserTeam201912 added; TorBrowserTeam201911 removed |
---|
Moving tickets to December
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.