1635984 - Define and implement Nightly UI experience for FPI users when dFPI is disabled

Status: RESOLVED FIXED

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

Description

[Steven Englehardt [:englehardt]]

In Bug 1628486 we'd like to enable dFPI in Nightly. We know some Nightly users currently have privacy.firstparty.isolate set to true, whether directly or via an extension. We know that enabling both dFPI and FPI for those users may introduce bugs, so we've decided to disable dFPI when FPI is enabled (see Bug 1631676).

Unfortunately privacy.firstparty.isolate isn't tied into any of our ETP UI, so we need to decide what experience we would like to give users with FPI enabled. For users that don't currently have FPI enabled we'd like to update the cookie policy of ETP Standard and Strict to be network.cookie.cookieBehavior=5 (dFPI). Users with FPI enabled will stay on network.cookie.cookieBehavior=4.

One approach here -- suggested by Gary -- is to conditionally change the default prefs for the UI based on privacy.firstparty.isolate. If FPI is on, then Standard and Strict use cookieBehavior=4 and otherwise use cookieBehavior=5. (I believe that Gary has a patch to do this already). An FPI user that selects Custom in the ETP preferences could still manually choose cookieBehavior=5 from the Cookies dropdown, so we'll likely want to remove that as an option as well. I think this is the right approach for short-term testing in Nightly.

Gary's patches in Bug 1631676 should handle the case where an FPI user tries to set cookieBehavior=5 manually in about:config, and Baku has suggested we should throw an error if an extension tries to set both FPI and dFPI (I'll follow up offline to make sure we do that).

Silently hiding dFPI from users with FPI enabled isn't a good long-term solution. Long-term we should:

1. consider whether we want to continue to support FPI users -- if not, we should consider removing the webExtensions integration
2. migrate all FPI users to Custom
3. warn FPI users in about:preferences#privacy that privacy.firstparty.isolate is incompatible with Standard/Strict and don't allow them to choose it.
4. if we decide we want to continue to support FPI long-term we can consider adding it as an option to the Cookie dropdown (so it's mutually exclusive with dFPI). If we decide we don't, we can also make the cookie dropdown inaccessible and encourage those users to disable privacy.firstparty.isolate.

Comment 1

[Tom Ritter [:tjr]]

(This is a hypothetical question:) How 'd' is dFPI? Are the dynamic decisions made by the browser based on an allowlist? Conservative Heuristic? A very permissive anything-that-appears-to-break heuristic?

Would the dynamic-ness of dFPI ever have a knob on it? Could a user potentially say "No, don't use a heuristic, prompt me?" in the future?

FPI is just dFPI with the knob turned all the way to the right. If that knob were to be configurable or exposed in any capacity... then perhaps the long-term solution is to correctly unify dFPI and FPI, drop the FPI pref, and rely on the knob.....

Comment 2

[Gary Chen [:xeonchen]]

Attachment: Bug 1635984 - use effective cookie behavior in preferences page;

Comment 3

[Steven Englehardt [:englehardt]]

(In reply to Tom Ritter [:tjr] (OOTO until 5/1?) from comment #1)

(This is a hypothetical question:) How 'd' is dFPI? Are the dynamic decisions made by the browser based on an allowlist? Conservative Heuristic? A very permissive anything-that-appears-to-break heuristic?

Would the dynamic-ness of dFPI ever have a knob on it? Could a user potentially say "No, don't use a heuristic, prompt me?" in the future?

FPI is just dFPI with the knob turned all the way to the right. If that knob were to be configurable or exposed in any capacity... then perhaps the long-term solution is to correctly unify dFPI and FPI, drop the FPI pref, and rely on the knob.....

dFPI doesn't currently cover all of the storage locations covered by FPI -- so it's not exactly the same and FPI currently provides strictly more isolation. That's because dFPI only covers things covered by the StoragePrincipal.

The "dynamic" part is somewhat permissive -- we provide access under the same conditions that we do for cookie blocking: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy#Storage_access_grants (plus one additional heuristic defined in Bug 1616585). I suspect these are things FPI users wouldn't want (and certainly not Tor users).

We plan to have StoragePrincipal eventually cover most things covered by FPI (though some things may be treated differently), and could introduce an "FPI mode" that completely disables the dynamic aspect. So I think it's a good long-term goal to unify them.

Comment 4

[Gary Chen [:xeonchen]]

(In reply to Steven Englehardt [:englehardt] from comment #0)

One approach here -- suggested by Gary -- is to conditionally change the default prefs for the UI based on privacy.firstparty.isolate. If FPI is on, then Standard and Strict use cookieBehavior=4 and otherwise use cookieBehavior=5. (I believe that Gary has a patch to do this already). An FPI user that selects Custom in the ETP preferences could still manually choose cookieBehavior=5 from the Cookies dropdown, so we'll likely want to remove that as an option as well. I think this is the right approach for short-term testing in Nightly.

We probably don't need to change the default prefs, because it doesn't matter cookieBehavior is 4 or 5 when FPI is on: it always act as 4.
So without touching the default prefs, we can still see the prefs matching the pre-defined prefs in Standard/Strict because it's actually 5 saved.

What we need is:

1. make sure Standard/Strict section displays correct behavior (partition or not) based on the altered/effective pref.
2. make dFPI option hidden in Custom when FPI is on.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/65266126fcb8
use effective cookie behavior in preferences page; r=ewright

Comment 6

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/65266126fcb8