Bugzilla

(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.

(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.