Open Bug 1649876 Opened 4 years ago Updated 7 months ago

Migrate FPI users to dFPI

Categories

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

Product:
Core
Component:
Privacy: Anti-Tracking
Type:
enhancement

Tracking

()

People

(Reporter: englehardt, Unassigned)

References

(Blocks 1 open bug)

Details

dFPI seeks to make FPI more web compatible by allowing us to relax isolation under certain conditions. Over the past couple months we've rapidly expanded the set of APIs covered by dFPI such that most of the APIs partitioned by FPI are also partitioned by dFPI.

We've decided to disable dFPI when FPI is active (see Bug 1631676). This complicates the UI (see Bug 1635984), mainly because FPI is not implemented/exposed as alternate cookie policy, and thus isn't mutually exclusive with dFPI.

I propose that we work towards migrating Firefox FPI users to dFPI in several steps:

  1. Add a UI notice to users that FPI is incompatible with dFPI and give users an option to switch (Bug 1637344).
  2. Deprecate and remove privacy.firstPartyIsolate from the WebExtension API. As of Firefox 78 extensions can set network.cookie.cookieBehavior to 5 via the websites.cookieConfig WebExtension API. This cookie behavior enables dFPI and tracker cookie blocking. Note that the WebExtension API will throw an error if an extension tries to activate privacy.firstPartyIsolate when the cookie behavior is set to 5.
  3. Work with the Tor Browser folks to figure out whether they'd be comfortable migrating to dFPI. Before this is an option we'll likely need to burn down more of Bug 1590107, fix Bug 1556816, and provide a way to disable storage access exceptions. We may also need to provide a cookie behavior pref that only enables partitioning and not tracker cookie blocking since Tor Browser doesn't consume any blocklists.
  4. Deprecate and remove the privacy.firstparty.isolate pref. Migrate Firefox FPI users to dFPI, and Tor Browser to a set of prefs that set the heuristics + isolation to their desired level.

Speaking with my https://addons.mozilla.org/en-US/firefox/addon/first-party-isolation/ developer hat on:

I'd be open to have my extension use a cookie policy of 5 and stop using the firstPartyIsolate pref if that's the only way forward, however here are my questions:

  • Do we have a list of differences between dFPI and FPI?
  • would it be possible to make FPI and dFPI mutually exclusive by porting the existing FPI pref into another cookie policy of "6"?

In the meantime, I'm looking to add a workaround that sets the policy to 4 and keep using the firstPartyIsolate pref, so I'm not changing expected behavior for existing users.

Do you have a timeframe for when you'd like to do this? Tor Browser will be shipping ESR 78 for some amount of time, but I don't know if they hope to migrate to the Release Channel before the subsequent ESR, so it might give us time to do this over some releases.

Personally, from a Tor POV but not the Tor POV, I think switching to a dFPI implementation would be fine as long as there were switches to make it behave the same way that FPI behaves today.

I am however hesitant about migrating current Firefox FPI users to a weakened form of dFPI. I would be more comfortable if we (a) silently migrated them to the dFPI implementation that behaved the same way as FPI and (b) offered them an option to migrate to dFPI with a link to a SUMO article that explained the differences.

(In reply to Frederik Braun [:freddy] from comment #1)

  • Do we have a list of differences between dFPI and FPI?

Not anything public yet unfortunately. You can see a list of the APIs currently covered by dFPI in the Mozilla-only google doc here: https://docs.google.com/document/d/17tqT0CZFdoF4LwDhibG6MBEXqGgZY9hibV0iiW1Ymw4/edit (For the non-Mozilla folks following along: we plan to have a public list live somewhere on MDN in the near future).

  • would it be possible to make FPI and dFPI mutually exclusive by porting the existing FPI pref into another cookie policy of "6"?

Possibly, but since a long-term goal of unifying the two seems achievable I don't think it's worth the effort.

In the meantime, I'm looking to add a workaround that sets the policy to 4 and keep using the firstPartyIsolate pref, so I'm not changing expected behavior for existing users.

That makes sense. I believe you can do that via websites.cookieConfig.

(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #2)

Do you have a timeframe for when you'd like to do this? Tor Browser will be shipping ESR 78 for some amount of time, but I don't know if they hope to migrate to the Release Channel before the subsequent ESR, so it might give us time to do this over some releases.

Not yet. It depends how long it will take to burn down the rest of the things listed in Bug 1590107 that are already covered by FPI. We expect much of that work to be finished in Q3 this year, so we should have a better idea well before the next ESR.

Personally, from a Tor POV but not the Tor POV, I think switching to a dFPI implementation would be fine as long as there were switches to make it behave the same way that FPI behaves today.

Got it. I think that's doable without too much extra effort. We will just need to add prefs to disable automatic storage access permissions and the like.

One major difference that I suspect will be okay is that we don't partition first-party state in dFPI. The partitionKey (dFPI's equivalent of firstPartyDomain) is left blank for first-party resources. That means enabling dFPI doesn't clear state for all first-party storage / we don't need to worry about migration. Do you know if double keying first-party storage was an intentional decision for FPI? Is there an added benefit.

I am however hesitant about migrating current Firefox FPI users to a weakened form of dFPI. I would be more comfortable if we (a) silently migrated them to the dFPI implementation that behaved the same way as FPI and (b) offered them an option to migrate to dFPI with a link to a SUMO article that explained the differences.

I'd also like to hold off on migrating users until dFPI and FPI are approximately equal in terms of coverage (i.e., at least cover the same APIs, even if we take a different approach to partitioning a few of them). Once we have a better idea of the exact differences between the two we can decide whether to go directly to dFPI or to dFPI + extra prefs that turn some webcompat stuff off.

Thank you for the detailed response, Steven. I'll make a patch to the add-on, to ensure it remains functional as expected.
I'll happily make my add-on se dFPI when it's ready for testing without significant differences in coverage (which you said hopefully Q3).
Do I correctly understand that you intend for dFPI to become default-enabled in the long run? I suppose that's going to depend on testing.

(In reply to Frederik Braun [:freddy] from comment #4)

Do I correctly understand that you intend for dFPI to become default-enabled in the long run? I suppose that's going to depend on testing.

That's the plan! And yes, in what form we can do that depends on the webcompat hit from dFPI. I'll note however that we're treating the partitioning of network state separately from the partitioning of cookies and other JS-accessible APIs (e.g., localStorage). Network state partitioning won't have a webcompat hit so we may let it ride the trains earlier that the rest of dFPI's partitioning. The partitioning of that state is controlled by the pref privacy.partition.network_state.

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

One major difference that I suspect will be okay is that we don't partition first-party state in dFPI. The partitionKey (dFPI's equivalent of firstPartyDomain) is left blank for first-party resources. That means enabling dFPI doesn't clear state for all first-party storage / we don't need to worry about migration. Do you know if double keying first-party storage was an intentional decision for FPI? Is there an added benefit.

I don't know why it was built this way to begin with. Tim might... For Tor Browser this won't matter. For Firefox, it would wipe out the FPI users cookie jar and log them out of everything; so I think we would need to do some migration for FF users in that case.

Tim: would you mind to comment on the question in Comment 6?

Flags: needinfo?(tihuang)

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

One major difference that I suspect will be okay is that we don't partition first-party state in dFPI. The partitionKey (dFPI's equivalent of firstPartyDomain) is left blank for first-party resources. That means enabling dFPI doesn't clear state for all first-party storage / we don't need to worry about migration. Do you know if double keying first-party storage was an intentional decision for FPI? Is there an added benefit.

Just as a side-note: Looking forward to that being solved more cleanly.
This is confusing for users and the major issue reported with the FPI extension.
When I receive duplicates and try to point them to https://github.com/mozfreddyb/webext-firstpartyisolation/issues/8

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

Tim: would you mind to comment on the question in Comment 6?

I think why we don't key the first-party domain is because the third-party storage might be unblocked/unpartitioned through either Storage API or heuristics. So the third-party can access the unblocked/unpartitioned storage which was stored by the first-party.

And yes, the concern that Tom raised is true. I think migration is needed and it should be not too hard to implement. We can migrate the first-party storage to unkeyed storage by removing the first party domain. And we can target all first-party storage by checking whether the origin of the storage is the same as the first-party domain.

Flags: needinfo?(tihuang)

Sorry, I misunderstood the question, I was thinking it's about the dFPI.

IIUC, the reason why we keyed the first-party for FPI is that we want to follow the original behavior of what Tor has built before the originAttributes. Tor used the first-party domain to isolate every connection in the same tab, including the first-party itself. To follow this, we chose to keyed the first-party as well.

Severity: -- → N/A
Priority: -- → P3

Took me a while to get back to it, but I just released version 1.4.0 of the first-party-isolation extension (really just a tiny browseraction button over the pref), which should address the cookiePolicy issue.
Currently, it just disables dFPI, which I believe can be a bit of an issue for future adoption.
Happy to work with folks in privacy engineering. I could imagine repurposing the extension to enable/disable dFPI once FPI has been unimplemented as a webext setting, but open to other suggestions.

Pushed four days ago:

https://hg.mozilla.org/releases/mozilla-release/rev/10a638a8c0d0644fca190c3c54957139ab9e0063

Bug 1686296 - Enable dFPI in strict mode for all channels. r=timhuang

Does this need to remain open, then? :)
Happy to adjust things on the extension's end once we consider dFPI on par with FPI.
We didn't think so when the bug was filed last year - did things change?

Flags: needinfo?(senglehardt)

(In reply to Frederik Braun [:freddy] from comment #13)

Does this need to remain open, then? :)
Happy to adjust things on the extension's end once we consider dFPI on par with FPI.
We didn't think so when the bug was filed last year - did things change?

Not yet; we're exposing dFPI in Strict mode, but standard mode users still won't have it.

Flags: needinfo?(senglehardt)

Also this bug isn't about making dFPI the default for FF users; it's about migrating people who have enabled FPI over to some form of dFPI so we can simplify the code.

See Also: → 1397624
You need to log in before you can comment on or make changes to this bug.