Closed Bug 1640135 Opened 5 years ago Closed 4 years ago

Consider using separate attribute to store first-party domain for dFPI

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla79
Tracking Status
firefox79 --- fixed

People

(Reporter: xeonchen, Assigned: xeonchen)

References

(Blocks 1 open bug)

Details

Attachments

(5 files)

mFirstPartyDomain was introduced by first-party isolation (FPI), and dynamic first-party isolation (dFPI) reuses this attribute. This may be problematic especially when both mode are enabled (see bug 1631676).

Adding another attribute for dFPI seems reasonable and is quite cheap, we should probably consider doing this.

I think we already settled that FPI and dFPI should be mutually exclusive, right? I.e., if you enable one, the other is disabled.

Then in bug 1637516 we'd like to move the keying from top-level registrable domain to site. If we did that on top of mFirstPartyDomain it would contain a different value based on which of FPI or dFPI is enabled. That probably works, but starts getting confusing. (Migrating FPI to site is being considered as well, but is much more complicated as it already shipped.)

Also, dFPI will be impacted by follow-up projects to Fission eventually where there is a desire to hide values from processes the process would not otherwise have access to, i.e., the top-level site (when its referrer policy is "no-referrer"). We don't have to tackle that now, but that would also impact this key and not having it impact FPI in addition would probably make that easier.

Then in discussions we've considered adding even more keying for non-storage state, though that would likely require another attribute whichever way we go.

Summary: Consider use separate attribute to store first-party domain for dFPI → Consider using separate attribute to store first-party domain for dFPI
Severity: -- → N/A
Priority: -- → P1
Assignee: nobody → xeonchen
Status: NEW → ASSIGNED

Depends on D77914

Depends on D77915

Depends on D77916

Depends on D77917

See Also: → 1667440
Regressions: 1669716
Regressions: 1710232
Blocks: 1710232
No longer regressions: 1710232
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: