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.
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.
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"
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
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.
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)
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
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. legacy/trac#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
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
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
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.)
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
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?
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)
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 legacy/trac#27257 (moved) already but lost track of it it seems...
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.
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 5e83d0a7 and 479630e1) and tor-browser-68.2.0esr-9.5-1 (commits b9e148eb and 1762a2a4).
Trac: Keywords: GeorgKoppen201910, TorBrowserTeam201910R deleted, GeorgKoppen201911, TorBrowserTeam201911 added Status: needs_review to new
devtools.webide.autoinstallADBHelper (which you set to false) was removed in F64 and replaced by devtools.webide.autoinstallADBExtension (which you don't set and is at default true) - https://bugzilla.mozilla.org/show_bug.cgi?id=1491315
Yes, privacy.use_utc_timezone and privacy.suppressModifierKeyEvents came indeed from old Tor Browser patches (legacy/trac#16622 (moved) and legacy/trac#17009 (moved) 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 legacy/trac#19890 (moved), so we are good.
Trac: Status: assigned to needs_review Keywords: TorBrowserTeam202001 deleted, TorBrowserTeam202001R added Points: 0.5 to 1
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
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
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.
Trac: Status: needs_information to closed Resolution: N/Ato fixed