Open Bug 1628783 Opened 5 years ago Updated 1 year ago

Make FPI affect keying of docgroup

Categories

(Core :: DOM: Security, defect, P5)

defect

Tracking

()

People

(Reporter: annevk, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [domsecurity-backlog1])

I think currently docgroup is keyed on eTLD+1. This should really be scheme + eTLD+1 (i.e., https://html.spec.whatwg.org/#site).

If websites opt-in, we are planning on changing the keying from site to origin. See bug 1601594. (I suspect it would be best for any fix here to build on that, but ultimately defer to Tom Tung on that.)

I also believe that currently, FPI does not affect docgroup keying. Since the goal of FPI is that when A embeds B1 and B1 popups B2, B1 and B2 are as isolated from each other as A and B1 are (assuming that the Bs are same-site and A is cross-site from the Bs), B1 and B2 ought to be in different docgroups (i.e., agents).

The observable effect of this would be that B1 and B2 can have shared memory (that uses docgroup as a key), despite FPI trying to forbid that in spirit.

(This takes us further from suggestions in bug 1321158, but I think that ought to be INVALID/WONTFIX.)

Priority: -- → P3
Whiteboard: [domsecurity-backlog1]
Blocks: 1436186

(In reply to Anne (:annevk) from comment #0)

The observable effect of this would be that B1 and B2 can have shared memory (that uses docgroup as a key), despite FPI trying to forbid that in spirit.

To be explicit and make sure I understand - this observable effect is what is presently happening; and fixing this by involving FPI in the docgroup keying would ensure they cannot have shared memory. Right?

Flags: needinfo?(annevk)

I strongly suspect so, but haven't written a test. There would be other ways to mitigate that, FWIW, so I'd rather focus on the more theoretical rationale that this is something keyed by origin/site and FPI ought to impact such state.

Flags: needinfo?(annevk)

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Severity: normal → S3

This does not block dFPI since popups have a special status there and their problems are tracked by bug 1556816 and bug 1657250 already. This would still make sense for a strict version of FPI.

No longer blocks: DynamicFirstPartyIsolation
Severity: S3 → N/A
Priority: P3 → P5
Severity: N/A → S4
You need to log in before you can comment on or make changes to this bug.