Bug 1356381 (AntiFingerprintingMeasurement)

[META] Add Telemetry and Perform Experiments to measure breakage/impact of Anti-Fingerprinting Patches

NEW
Unassigned

Status

()

Core
DOM
P3
normal
a year ago
3 months ago

People

(Reporter: tjr, Unassigned)

Tracking

(Depends on: 6 bugs, {meta})

52 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [domsecurity-meta] [tor] [fingerprinting])

(Reporter)

Description

a year ago
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.
(Reporter)

Updated

a year ago
Depends on: 1356383
(Reporter)

Updated

a year ago
Depends on: 1356384
Keywords: meta
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

a year 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)
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)
We might add a pref "javascript.options.privacy.resistFingerprinting" in bug 1217238.
The patch is still waiting to be reviewed.
(Reporter)

Updated

a year ago
Depends on: 1359124
(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)
(Reporter)

Updated

a year ago
Depends on: 1360242
(Reporter)

Updated

a year ago
Depends on: 1266495
Comment hidden (typo)
(Reporter)

Updated

a year ago
Depends on: 1362184
(Reporter)

Updated

a year ago
Depends on: 1362186
(Reporter)

Updated

a year ago
Depends on: 1362187
(Reporter)

Updated

a year ago
Depends on: 1362188
(Reporter)

Comment 7

a year 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
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
(Reporter)

Updated

a year ago
See Also: → bug 728952

Comment 9

10 months 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

10 months 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)
Marking all [meta] bugs as P3.
Priority: -- → P3
(Reporter)

Updated

10 months ago
Depends on: 1388743
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

9 months 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

9 months 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)
You need to log in before you can comment on or make changes to this bug.