Consider changing the key of FPI to site (i.e., include the URL scheme)
Categories
(Core :: DOM: Security, task, P3)
Tracking
()
People
(Reporter: annevk, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [domsecurity-backlog1])
Otherwise an insecure top-level A can influence the state of a secure third-party B that can then influence the state of a secure top-level A.
There are likely other attack vectors I'm not considering.
|
||
Updated•4 years ago
|
|
||
Comment 1•4 years ago
|
||
I believe Tor is in support of this.
|
|
||
Comment 2•4 years ago
•
|
||
I think I missed the patches in Bug 1637516 but it looks like if you flip privacy.firstparty.isolate.use_site - then for FPI we include scheme in the key (but not subdomains.) Is that correct? And that's in 78 ESR?
It would be safe for Tor to flip that to include scheme and test breakage, right?
|
||
Comment 3•4 years ago
|
||
(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #2)
I think I missed the patches in Bug 1637516 but it looks like if you flip
privacy.firstparty.isolate.use_site- then for FPI we include scheme in the key (but not subdomains.) Is that correct? And that's in 78 ESR?It would be safe for Tor to flip that to include scheme and test breakage, right?
Correct, I think you're right.
|
||
Comment 4•4 years ago
|
||
(In reply to Gary Chen [:xeonchen] from comment #3)
(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #2)
I think I missed the patches in Bug 1637516 but it looks like if you flip
privacy.firstparty.isolate.use_site- then for FPI we include scheme in the key (but not subdomains.) Is that correct? And that's in 78 ESR?It would be safe for Tor to flip that to include scheme and test breakage, right?
Correct, I think you're right.
Thanks! The concern expressed in Bug 1637516 about data migration seems relevant for FPI, as well (unfortunately). While Tor Browser's default configuration is private browsing-only mode, there is significant evidence that many users modify that configuration and save state on disk for persisting sessions. Do you have any suggestions for how we can (gracefully?) migrate user data in this scenario? This non-standard configuration isn't exactly supported, but isolating by site will have a large impact on the users and I don't want to intentionally break that usage.
Two options I see are:
- only respect
StaticPrefs::privacy_firstparty_isolate_use_site()in private browsing mode - Construct and cache both versions of "First Party Domain" in the OA and redefine OA equality such that either FPD version (site or base domain) may be equal for satisfying OA equality.
Option 1 seems much easier than option 2. However, with option 2, we could add some more logic for gradually migrating users from isolation based on the base domain to isolation based on site.
|
|
||
Comment 5•4 years ago
|
||
Can we just migrate the data? It would prevent people from flipping the pref off and keep their cookies; but if the browser starts up, the pref is on, and we find cookies of the old FPI form, migrate them to the new form defaulting the scheme to https?
|
||
Comment 6•4 years ago
|
||
(In reply to Matthew Finkel [:sysrqb] from comment #4)
- only respect
StaticPrefs::privacy_firstparty_isolate_use_site()in private browsing mode
FWIW, I'm not in favor of option 1. Many Firefox users use FPI in normal mode and we should make the change as universal as possible
|
|
||
Comment 7•4 years ago
|
||
I'll vote for comment 5. Migration using https as default sounds like a good idea.
|
|
||
Comment 8•4 years ago
|
||
Performing the migration at start up and using https and -1/default port does seem like the easiest and safest solution. Migrating the data as it is used would result in less breakage (because we know the correct scheme and port at that point), but the implementation would be more complex.
|
||
Comment 9•3 years ago
|
||
Linking bugs for visibility - bug 1637516 introduced privacy.firstparty.isolate.use_site but it's false by default with zero unit tests for the true value.
|
|
||
Comment 10•3 years ago
|
||
As a note about this, when I set up a new browser, I set this pref on and have been using it for a few weeks and haven't encountered anything that seems unusual.
|
|
||
Comment 11•3 years ago
|
||
How likely is it for this bug to be resolved (or WONTFIXed)? I see a patch at bug 1714065 that introduces a (common) helper to parse the partitionKey value. Similar logic can also be used for the firstPartyDomain when privacy.firstparty.isolate.use_site is true.
At https://bugzilla.mozilla.org/show_bug.cgi?id=1669716#c14 I see the following comment about FPI:
I don't forsee FPI become the default over dFPI. But someday I do hope that all of the FPI code goes away, and the FPI behavior (that of being strict with no compromises) is implemented by the dFPI code as some sort of extra, hidden dFPI mode. I don't know when - if ever - that will happen.
So at this point I'm not really sure to what extent I need to account for the possibility of FPI using (scheme,host,port) instead of just host. If FPI won't ever use host, then that would offer a more straightforward way (with less ambiguity of supporting FPI and dFPI in bug 1669716.
|
|
||
Comment 12•3 years ago
|
||
The experience for FPI users would be really bad if we enabled this without migrating data; so to resolve this we would need to do that.
Folding FPI into the dFPI implementation makes me a bit nervous, but primarily because I (and I think also Tor) don't/doesn't understand any of the subtleties of the dFPI codebase. I can't say how difficult that fold would be either.
Both of these tasks don't really have anyone who is able to work on them now.
I think it's likely that the status quo will be maintained for awhile, and that any impetus to change FPI's behavior can include the requirement to update your code as well. My only request is that the API is sufficiently stable with use_site is enabled. It doesn't need to work, but please don't crash or put things into an undefined state?
Description
•