1815307 - Refactor the ShouldRFP functions (again) to support per-feature control

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, enhancement)

Description

[Tom Ritter [:tjr]]

As we are nearing completion of the fine-grained RFP control cutover, we also want to re-architect how RFP controls all of the various things that RFP controls. Specifically, we want to add the ability to have a middle level of fingerprinting resistance, less strict than Tor's, and with less breakage (we don't have a good name for this now, so we're going to refer to it as RFP-Lite). We're going to do some experiments with this mode to test for web breakage, but we don't have plans to expose it as a configurable toggle for users right now.

To support the ability to move things out of this mode (or into it) and to run experiments, we'll actually be able to control the features in this mode with a preference, similar to ETP (but not exactly like that).

1. In nsRFPService.h/cpp create an enum that will (eventually) contain an entry for every feature controlled by RFP. It will be an incrementing integer (not a bitfield) with numerals assigned when the enum value is created and never re-used.
2. In nsRFPService.h/cpp create a method that - given an enum value - returns true or false for whether we should enable fingerprinting resistance for the value. This function does not take into account fine-grained context information - it only takes into account whether we are in RFP-Mode or RFP-Lite mode (or no-RFP-mode, but we shouldn't ever reach this function if that is the case.)
   1. I think the default implementation for this will be a constant array defined in the source code, but I'm just guessing this will be the fastest at runtime.
3. Create a preference that can hold overrides for RFP-Lite. When the preference changes, an observer in nsRFPService will update a runtime table that we will consult before the hard-coded table.
   1. The overrides will only be for RFP-Lite, they will not work if you have the general RFP preference on. If someone really wants to have an RFP mode that enables everything except <foo>, they can do this by enabling everything for RFP-Lite, but it will be verbose. That is okay.
4. I envision this preference being a string of the form "+5,-6,+9" to indicate that the features 5 and 9 (which were default-disabled) get enabled for RFP-Lite, and the feature 6 (default-enabled) gets disabled.
5. All of the ShouldResistFingerprinting functions in nsContentUtils will get an optional enum value at the end, where the default value is ::Unknown. Eventually we'll prevent you from omitting the argument, but this will be the transition method.
6. We will cut over all the ShouldRFP callsites - a component at a time ideally so the enum values we add are clustered together logically - adding enum values where-ever it makes sense to distinguish separate behaviors. I'm not sure at this point how liberal we want to be with assigning new enums for different things. Probably only one enum for e.g. all the navigator overrides, but maybe a separate enum for navigator overrides on workers? We should be cognizent of the fact that users will set these values and changing their behavior later would probably be worse than being overly-verbose in the beginning.
7. We'll add our new check (I'll call it the feature check) in the ShouldRFP functions in nsContentUtils either before or after the fine-grained checks (I'll call them the context checks) depending on which check is faster. I expect the feature check is going to be faster, but we can test.
8. We'll add a new RFP-Lite preference probably.

Comment 1

[Thorin [:thorin]]

The overrides will only be for RFP-Lite, they will not work if you have the general RFP preference on

good

This is with my Firefox hat on, Tor Browser can lock prefs etc so they are fine. I don't like the idea of a pref for the features. A lite mode doesn't protect in any meaningful way if users can fiddle with it, not in a crowd (advanced scripts) or when made front facing or part of PB mode, and especially without randomized canvas for naive scripts. Ignorant users will use/abuse it and think they're protected. I'd prefer hardcoding it like Brave does for standard vs aggressive shields. IMO, lite should have randomized canvas (for naive scripts). Perhaps you can enforce canvas in the pref at runtime? IDK where we're at with randomized canvas long term but it's the only thing that currently makes the difference in FP protection in Firefox (because we have no crowd).

We can still reduce breakage/compat, such as devicePixelRatio = 2 to stop blur issues, make HTTP header userAgent spoof TB only behind a flag. Improve usability with larger newwin sizes (already a pref: use a better aspect ratio for today's desktops/laptops), etc.

Maybe lite mode can have some different solutions for some metrics but still be protected: brave does this and it makes sense in places. The pref is binary for each feature on/off, so how would you work that in to be future proof?

tom, I don't get the reasoning behind allowing users to toggle any of the entire feature set. Why not just have privacy.resistFingerprinting be an integer : 0=off, 1=lite, 2=everything

Comment 2

[Tom Ritter [:tjr]]

Attachment: Bug 1815307: Group RFP methods into logical sections r?timhuang

Comment 3

[Tom Ritter [:tjr]]

Attachment: Bug 1815307: Lay the groundwork for the IsRFPEnabledFor function r?timhuang

Depends on D170888

Comment 4

[Tom Ritter [:tjr]]

Attachment: Bug 1815307: Reconfigure the headers so types will be accessible in the right place without conflicts r?timhuang

Depends on D170889

Comment 5

[Tom Ritter [:tjr]]

Attachment: Bug 1815307: Make all ShouldRFP functions take a RTPTarget r?timhuang

The default value for the target is Unknown, so all callsites
keep working.

We also add a Target value used for Document precomputation. This
value is enabled in RFP Lite mode, and allows us to precompute
ShouldRFP and cache it for faster computations later. (The later
computations will still check the Target, but won't need to do the
other expensive checks.)

Depends on D170890

Comment 6

[Tom Ritter [:tjr]]

Attachment: Bug 1815307: Change wording in media error test r?timhuang

Depends on D170891

Comment 7

[Tom Ritter [:tjr]]

Attachment: Bug 1815307: Cut over Touch Events to the RFP-per-target architecture r?timhuang

Depends on D170892

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/337dfbf6a1f9
Group RFP methods into logical sections r=timhuang
https://hg.mozilla.org/integration/autoland/rev/83d79fcbded5
Lay the groundwork for the IsRFPEnabledFor function r=timhuang
https://hg.mozilla.org/integration/autoland/rev/7f4b594cf468
Reconfigure the headers so types will be accessible in the right place without conflicts r=timhuang
https://hg.mozilla.org/integration/autoland/rev/371d1d626984
Make all ShouldRFP functions take a RTPTarget r=timhuang
https://hg.mozilla.org/integration/autoland/rev/a22d49909ffa
Change wording in media error test r=timhuang
https://hg.mozilla.org/integration/autoland/rev/df49c162e4ad
Cut over Touch Events to the RFP-per-target architecture r=timhuang
https://hg.mozilla.org/integration/autoland/rev/18c8ae091952
apply code formatting via Lando

Comment 9

[Cristina Horotan [:chorotan]]

Backed out 7 changesets (bug 1815307) for causing mochitest failures at test_bug1729861.html

Backout: https://hg.mozilla.org/integration/autoland/rev/cb52c727e207edf1ee99b99986413f02b218c4af

Failure push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=18c8ae0919521155190e597feccfe05a1d5e17c4&selectedTaskRun=b4EXrqsHTXqUw2FnhqNTNw.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=409146901&repo=autoland&lineNumber=4830

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4bf25baa467c
Group RFP methods into logical sections r=timhuang
https://hg.mozilla.org/integration/autoland/rev/bb935b219495
Lay the groundwork for the IsRFPEnabledFor function r=timhuang
https://hg.mozilla.org/integration/autoland/rev/48086381500b
Reconfigure the headers so types will be accessible in the right place without conflicts r=timhuang
https://hg.mozilla.org/integration/autoland/rev/d8f2a5765d40
Make all ShouldRFP functions take a RTPTarget r=timhuang
https://hg.mozilla.org/integration/autoland/rev/cc164f9e33dd
Change wording in media error test r=timhuang
https://hg.mozilla.org/integration/autoland/rev/7de181e66ddf
Cut over Touch Events to the RFP-per-target architecture r=timhuang

Comment 11

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/4bf25baa467c
https://hg.mozilla.org/mozilla-central/rev/bb935b219495
https://hg.mozilla.org/mozilla-central/rev/48086381500b
https://hg.mozilla.org/mozilla-central/rev/d8f2a5765d40
https://hg.mozilla.org/mozilla-central/rev/cc164f9e33dd
https://hg.mozilla.org/mozilla-central/rev/7de181e66ddf

Comment 12

[Tom Ritter [:tjr]]

Let's move the alias to 1824390