When testing how the two features layer together I found Bug 1630796, and I only tested four storage locations in that bug. Communication channels may also have some unexpected interactions, and we may introduce bugs in the future.

It seems safest to disable dfpi when fpi is enabled. We can revisit this decision if we end up providing further protections in dfpi than we offer in fpi, but as it stands fpi is a strictly stronger set of protections (since it never allows cross-site access).

Tom, Matthew: does this seem preferable to you?

Because FPI should never allow relaxation of protections, I would expect DFPI to behave as if it were disabled when FPI is enabled.

Perhaps this bug is about the implementation details? e.g. instead of checking if FPI is enabled in the "should we relax protections" function that happens as part of DFPI, we should instead check in the "Is DFPI enabled?" function?

In which case.... sure. That seems like the more conservative choice and less prone to bugs that could subtly affect Tor.

When FPI is enabled, will document principal different from its storage principal?
If they are the same, what are the consequences if we don't disable dFPI?

@tjr: yes, that's my thought. It seems safest to completely avoid enabling dfpi when fpi is active.

@gary: consider Bug 1630796. That weirdness was partially introduced by Bug 1630763.

It's fine it we do this silently when we enable in Nightly, but we'll probably want to think through the implications for FPI users if we keep that policy when shipping to release.

Some issues:

• Let's say this is the default in Strict or Standard ETP, then users with FPI enabled can't select those modes. They'll be forced into Custom
• How will the "Cookies" dropdown work for FPI users? Will the DFPI selector be blocked our for them?

It might be worth adding Telemetry to figure out how many users currently have the firstparty.isolate pref set to true.

Depends on D74049

https://hg.mozilla.org/mozilla-central/rev/c1ee5647da8f

Comment on attachment 9146303 [details]
Bug 1631676 - Part 3: use effective cookie behavior in preferences page;

Revision D74128 was moved to bug 1635984. Setting attachment 9146303 [details] to obsolete.

Comment on attachment 9145822 [details]
Bug 1631676 - collect usage of pref privacy.firstparty.isolate;

Beta/Release Uplift Approval Request

• User impact if declined: This patch adds a telemetry probe to collect user preference setting, we need uplift to collect accurate user number.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's telemetry only, and has been landed to nightly a few days.
• String changes made/needed:

Comment on attachment 9145822 [details]
Bug 1631676 - collect usage of pref privacy.firstparty.isolate;

Low risk telemetry probe, uplift approved for 77 beta 8.

https://hg.mozilla.org/releases/mozilla-beta/rev/40da86b4f0e0

https://hg.mozilla.org/mozilla-central/rev/fc0fe3b5516a
https://hg.mozilla.org/mozilla-central/rev/ab798364a53b
https://hg.mozilla.org/mozilla-central/rev/a9d6489a6a67

https://hg.mozilla.org/mozilla-central/rev/fdef23410b2e

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

It's fine it we do this silently when we enable in Nightly, but we'll probably want to think through the implications for FPI users if we keep that policy when shipping to release.

Some issues:

• Let's say this is the default in Strict or Standard ETP, then users with FPI enabled can't select those modes. They'll be forced into Custom
• How will the "Cookies" dropdown work for FPI users? Will the DFPI selector be blocked our for them?

It might be worth adding Telemetry to figure out how many users currently have the firstparty.isolate pref set to true.

I did some tests

78-Dev, 79-Nightly

• ETP: standard
• set FPI on and cookieBehavior to 5 (done from about:config, not a user.js)
• order of changing prefs doesn't matter
• check options UI
• ETP: custom: displays value 4
  • 78: there is no combo box item for value 5 normally anyway
  • 79: combo box item for value 5 is missing: it's normally there in nightly

In both cases, the cookieBehaviour pref stays at 5 in about:config. This is cosmetic right, just checking?

Cases:

• dFPI is enabled by default, and user decides to turn on FPI
• user is using FPI and default 4, FF update flips dFPI on by changing to 5
• in both cases the displayed ETP information is out of sync with the value stored in prefs: how does the user know what is going on and which one to believe?

(In reply to Simon Mainey from comment #24)

I did some tests

78-Dev, 79-Nightly

• ETP: standard
• set FPI on and cookieBehavior to 5 (done from about:config, not a user.js)
• order of changing prefs doesn't matter
• check options UI
• ETP: custom: displays value 4
  • 78: there is no combo box item for value 5 normally anyway
  • 79: combo box item for value 5 is missing: it's normally there in nightly

In both cases, the cookieBehaviour pref stays at 5 in about:config. This is cosmetic right, just checking?

We didn't touch the "real" value stored in about:config, we instead use the effective value of cookieBehavior, which is: fallback 5 to 4 when FPI is enabled.

Cases:

• dFPI is enabled by default, and user decides to turn on FPI
• user is using FPI and default 4, FF update flips dFPI on by changing to 5
• in both cases the displayed ETP information is out of sync with the value stored in prefs: how does the user know what is going on and which one to believe?

We have bug 1637344 to add some notice, maybe it will make the UI clearer?

(In reply to Gary Chen [:xeonchen] from comment #25)

We have bug 1637344 to add some notice, maybe it will make the UI clearer?

OMG, how did I not find that? My bad :)

(sorry for the noise)