In Bug 1329996 we are bringing in a lot of anti-fingerprinting patches, hidden behind prefs. In Bug 1308340 we are discussing adding a checkbox that would turn on all/many anti-fingerprinting prefs. In that bug, the question is posed: "If we offer fingerprinting protection, why wouldn't we turn it on by default?" The purpose of this meta-bug is to track all the things we want to measure to figure out how much web content is broken by enabling individual anti-fingerprinting changes or disabling fingerprintable features.
FYI I'm planning to study breakage for privacy.resistFingerprinting = true: https://github.com/mozilla/shield-study-privacy https://github.com/mozilla/shield-study-privacy/blob/master/lib/study.js :tjr - can you add a list of the anti-fingerprinting prefs and their effects? We may be able to include 1 or some in the study. glind: Are shield studies still limited to opt-in cohorts? Or can we quickly recruit users into many variations of a study?
So we (probably) want all the anti-fingerprinting prefs we care about to get turned on when privacy.resistFingerprinting = true. I think we haven't been completely diligent about making that the case though, mostly because that pref had been sitting stagnant waiting for UX approval and this bug (which I was planning on running a study pref-by-pref so doing them all together is way faster). So to see this Shield Study going forward is awesome (but also means we need to go get our ducks in a row!) For example I think Bug 1217238 should be enabled by anti-fingerprinting, but isn't yet. But Bug 418986 is one we were planning to start with, and is controlled by privacy.resistFingerprinting. Are you worried about us cleaning up our work over in https://wiki.mozilla.org/Security/Fingerprinting to get as many things controlled by the single pref as possible? Also, there are a host of things we would want to disable for fingerprinting purposes that are already controlled by individual prefs: the gamepad api, WebGL min Capability mode, etc. (Stuff like this: https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-45.7.0esr-7.0-1#n109 ) Do tying these things into the pref (or changing them alongside the pref) make you nervous? Also, in general, what's the window here for fixing up our pref story? Shield moves separately from FF, but our changes to whats affected by the pref can probably be uplifted aggressively since we're not changing anything that affects default configs.
Flags: needinfo?(tom) → needinfo?(lcrouch)
Unless there's a significant cost (probably code complexity?), we probably want as much fine control as we can get to start. Then we could actually use a shield study to determine *which* anti-fingerprinting features should be "lumped together" under the single privacy.resistFingerprinting pref. That would make all of us less nervous about which anti-fingerprinting prefs should be controlled by the single pref. We may even learn if we can set resistFingerprinting to true by default! E.g., we study breakage reports and retention between: 1. disabling the gamepad API 2. WebGL min capability 3. low-res js apis 4. obscure window.screen 5. etc. When we know the group of features that cause little/no breakage nor loss of retention, we put that group of features into the privacy.resistFingerprinting control. If the breakage is nil and retention is the same, we may even be able to default it to true!
(listening, thinking) Currently, studies are still opt-in. ETA for fixing that should be REAL SOON NOW. Shield is landed, and I will get an ETA for opt-out.
Nice comprehensive list. For the ones that are already preferences, Firefox 54 (or 55) may gain a quick and easy ability to test them: https://github.com/Osmose/normandy/blob/6f504237198386f7676aaaf0bbf25285b7dbc2fd/docs/user/actions/preference-experiment.rst
(In reply to Tom Ritter [:tjr] from comment #7) > ========================================= > ** Simpler Ones ** > > - Suppress MediaError.message when privacy.resistFingerprinting = true > > No Mozilla bug yet (?): > https://gitweb.torproject.org/tor-browser.git/patch/?id=58d186d FYI: This is Bug 1354633
(In reply to Tom Ritter [:tjr] from comment #7) > ========================================= > ** Simpler Ones ** > > - Network Information API > > We have telemetry for this (Bug 1360242) now how about we try disabling it: > pref("dom.network.enabled",false); > dom.network.enabled was removed in Bug 960426 (FF25) It was replaced by dom.netinfo.enabled in Bug 960426 (FF31)
Marking all [meta] bugs as P3.
Priority: -- → P3
FWIW, if you have access to STMO you can check out a dashboard for a shield study that measured breakage for the current release implementation of privacy.resistFingerprinting, compared to some other prefs. https://sql.telemetry.mozilla.org/dashboard/shield-study-improve-privacy-settings
(In reply to Luke Crouch [:groovecoder] from comment #12) > FWIW, if you have access to STMO you can check out a dashboard for a shield > study that measured breakage for the current release implementation of > privacy.resistFingerprinting, compared to some other prefs. > https://sql.telemetry.mozilla.org/dashboard/shield-study-improve-privacy- > settings This is excellent! Thanks, Luke!
(In reply to Tom Ritter [:tjr] from comment #7) > Okay so here is a list of things I'd like to include, or at least consider > including, in the study: > > - Add Telemetry For / Disable IndexedDB : Bug 1362184 > > pref("dom.indexedDB.enabled", false); Ruh roh .. not with Extensions (https://wiki.mozilla.org/Add-ons/Terminology#Glossary). uMatrix and uBlock Origin  require indexedDB, and many more since legacy support for prefs is dropped.  https://github.com/gorhill/uMatrix/commit/406f6473b67b5741e4bf367c0a629efd98b3a228  https://github.com/gorhill/uBlock/releases/tag/1.14.0 If you also look here: https://github.com/ghacksuserjs/ghacks-user.js/issues/226 - you will see disabling indexedDB causes console errors in FF itself (I also think it is affecting the startupcache, because after 2 years of having this disabled, when I turned it on, all hell broke loose! - I did snapshots before and after and ran diffs). Can extension and internal IDB can be separated from web content? IDK? In my 2+ years of no indexedDB I missed nothing - but it does break some sites functionality. Here: https://www.wilderssecurity.com/threads/firefox-and-indexeddb.395113/ : is a possible workaround: allow sites to THINK they have indexedDB, but then deny write permissions (see first comment)
You need to log in before you can comment on or make changes to this bug.