Open
Bug 1356381
(AntiFingerprintingMeasurement)
Opened 7 years ago
Updated 1 year ago
[META] Add Telemetry and Perform Experiments to measure breakage/impact of Anti-Fingerprinting Patches
Categories
(Core :: DOM: Core & HTML, enhancement, P3)
Tracking
()
NEW
People
(Reporter: tjr, Unassigned)
References
(Depends on 4 open bugs)
Details
(Keywords: meta, Whiteboard: [domsecurity-meta] [fingerprinting][fp-triaged])
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.
|
||
Comment 1•7 years ago
|
||
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?
Flags: needinfo?(tom)
Flags: needinfo?(glind)
|
Reporter | |
Comment 2•7 years ago
|
||
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)
|
|
||
Comment 3•7 years ago
|
||
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!
Flags: needinfo?(lcrouch)
|
||
Comment 4•7 years ago
|
||
We might add a pref "javascript.options.privacy.resistFingerprinting" in bug 1217238. The patch is still waiting to be reviewed.
(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.
Flags: needinfo?(glind)
| Comment hidden (typo) |
|
|
Reporter | |
Comment 7•7 years ago
|
||
Okay so here is a list of things I'd like to include, or at least consider including, in the study: ========================================= ** Already in ** - Window rounding, orientation, aspect rario, DPI, color depth, font smoothing on OSX (this is in privacy.resistsFingerprinting) See https://dxr.mozilla.org/mozilla-central/search?q=regexp%3A%5BrR%5DesistFingerprinting&redirect=false files like ScreenOrientation.cpp, SessionStore.jsm, nsGlobalWindow.cpp, nsScreen.cpp, MouseEvent.cpp, Touch.cpp, nsMediaFeatures.cpp, nsWindowWatcher.cpp, nsXULWindow.cpp - Mime Type and Plugin list (this is in privacy.resistsFingerprinting) Bug 418986 See https://dxr.mozilla.org/mozilla-central/search?q=regexp%3A%5BrR%5DesistFingerprinting&redirect=false nsMimeTypeArray.cpp and nsPluginArray.cpp ========================================= ** Big, Tougher Ones ** - SOMETHING about Canvas Data extraction. Bug 1041818 This is a big one. We know that canvas is used a lot (perhaps even 'mostly') for fingerprinting purposes. I'm not sure what we would measure here, but we should measure something. Perhaps we block canvas is the object is not visible on the screen? Perhaps we add a prompt (Bug 967895 but not really pushing for that)? Perhaps we add telemetry that tells us what percentage of canvas calls occur from some particular context (script loaded from third party domain, iframe, offscreen...) But we know Canvas is a big concern, so while it's difficult to figure out what to do I feel strongly we should try and do something. - No Third Party Cookies pref("network.cookie.cookieBehavior", 1); - Disable WebRTC pref("media.peerconnection.enabled", false); // Disable WebRTC interfaces pref("media.navigator.enabled", false); - Restrict Local Font Enumeration Bug 732096 This may be testable via the font.system.whitelist pref. We're going to need more information about this. - Disable external protocols except in <a> hrefs Bug 167475 This one is just so ancient it's going to take a lot of thinking through to develop. ========================================= ** Simpler Ones ** - Suppress MediaError.message when privacy.resistFingerprinting = true No Mozilla bug yet (?): https://gitweb.torproject.org/tor-browser.git/patch/?id=58d186d - Spoof timezone as UTC - Bug 1330890 - Add Telemetry for / Remove <isindex> - Bug 1266495 (and Bug 1330892) - Keyboard layout is leaked by Keyboard Event - Bug 1222285 - WebGL Minimal Mode Tor turns on WebBGL minimal mode and then actually relaxes it (Bug 1217290). We could test either our current, unrelaxed minimal mode, or Tor's relaxed version of it. Also: pref("webgl.disable-extensions", true); pref("webgl.disable-fail-if-major-performance-caveat", true); - Time Precision - Bug 1217238 - Add Telemetry for / Disable NTLM and Negotiate HTTP Auth Tor currently disables this, which was done in response to Mozilla security Bug 1046421. https://gitweb.torproject.org/tor-browser.git/patch/?id=53c5e00 https://hg.mozilla.org/mozilla-central/rev/bf5fd6a7021e Telemetry may be done already: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-05-03&keys=__none__!__none__!__none__&max_channel_version=nightly%252F55&measure=NTLM_MODULE_USED_2&min_channel_version=nightly%252F52&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-03-08&table=0&trim=1&use_submission_date=1 - Add Telemetry For / Disable IndexedDB : Bug 1362184 pref("dom.indexedDB.enabled", false); - Make certificate store memory only pref("security.nocertdb", true); - Disable pings pref("browser.send_pings", false); - Network Information API We have telemetry for this (Bug 1360242) now how about we try disabling it: pref("dom.network.enabled",false); - Override a bunch of specific buildId type stuff pref("general.appname.override", "Netscape"); pref("general.appversion.override", "5.0 (Windows)"); pref("general.oscpu.override", "Windows NT 6.1"); pref("general.platform.override", "Win32"); pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"); pref("general.productSub.override", "20100101"); pref("general.buildID.override", "20100101"); pref("browser.startup.homepage_override.buildID", "20100101"); pref("general.useragent.vendor", ""); pref("general.useragent.vendorSub", ""); - Override some charset locale stuff pref("intl.charset.default", "windows-1252"); pref("javascript.use_us_english_locale", true); pref("intl.accept_languages", "en-us, en"); // Set by Torbutton pref("intl.accept_charsets", "iso-8859-1,*,utf-8"); // Set by Torbutton pref("intl.charsetmenu.browser.cache", "UTF-8"); // Set by Torbutton -Add Telemetry for / Disable Gamepad API: Bug 1356383 and Bug 1337161 pref("dom.gamepad.enabled", false); // bugs.torproject.org/13023 - Add Telemetry For / Disable WebSpeech API Bug 1233846 and Bug 1356384 - Disable Video Statistics: Bug 654550 and Bug 1362186 pref("media.video_stats.enabled", false); - Add Telemetry for / Disable Sensors: Bug 1359124 pref("device.sensors.enabled", false); - Add Telemetry For / Disable User Timing APIs pref("dom.enable_resource_timing", false); // Bug 13024 pref("dom.enable_user_timing", false); // Bug 16336 pref("dom.event.highrestimestamp.enabled", true); - Change System Color Something pref("ui.use_standins_for_native_colors", true); // https://bugzilla.mozilla.org/232227 - Add Telemetry For / Disable MathML Bug 1362187 pref("mathml.disabled", false); - Add Telemetry For / Disable SVG pref("svg.in-content.enabled", false); - Spoof or Add Telemetry for navigator.hardwareConcurrency Bug 1360039 and Bug 1362188
|
|
||
Comment 8•7 years ago
|
||
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
|
||
Comment 9•7 years ago
|
||
(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
|
|
||
Comment 10•7 years ago
|
||
(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)
|
|
||
Comment 12•7 years ago
|
||
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
|
||
Comment 13•7 years ago
|
||
(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!
|
|
||
Comment 14•7 years ago
|
||
(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 [2] require indexedDB, and many more since legacy support for prefs is dropped. [1] https://github.com/gorhill/uMatrix/commit/406f6473b67b5741e4bf367c0a629efd98b3a228 [2] 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)
|
|
Reporter | |
Updated•6 years ago
|
No longer depends on: uplift_tor_fingerprinting
Whiteboard: [domsecurity-meta] [tor] [fingerprinting] → [domsecurity-meta] [fingerprinting][fp-triaged]
|
Assignee | |
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•