Repository navigation
"top-level origin" on environments seems incorrect; consider "top-level site" #8014
Description
Back in #4966 we introduced "top-level origin" as a field of environments. The setup is roughly:
- For window environment settings objects: this is clearly well-defined, and is often used, e.g. for
showPicker()or COOP protections. - For dedicated workers or worklets: it is set to the top-level origin of its creator. It does not appear to be used for them, yet.
- For shared workers and service workers: it is set to an implementation-defined value, meant to represent the outcome of whatever we do with storage partitioning. It does not appear to be used for them, yet.
As storage partitioning gets more concrete, I think this setup is not going to work out. Since we plan to partition primarily on top-level site, it will be possible for any "shared" resource to have multiple top-level values that are important. That is, if a.example.com and b.example.com both embed example.org, which itself creates a shared worker or service worker, then both a.example.com and b.example.com are arguably the "top level origin" for that shared or service worker. And, because dedicated workers can be nested inside shared workers, the same problem occurs for them.
I think instead we should:
-
Move "top-level origin" to
Window, similar to Remove "responsible document" concept #7694, since there is only a single unambiguous top-level origin for windows. (I guess we could also do it for worklets, but so far it isn't needed.) This can be used by a variety of things, e.g. COOP checks. -
Create a "top-level site" field on environments, which we can populate unambiguously for shared, service, and dedicated workers.
/cc @wanderview @annevk
Activity
annevk commentedon Jun 15, 2022
I wonder how this works out with permissions, but I suppose that is also an existing problem that we largely sidestep by managing permissions outside of workers.
Overall your logic seems sound with respect to what we need to be doing here. Thanks for writing it up!
As I wrote in whatwg/storage#142 I hope we can slowly move towards defining these various fields together in a struct called "authority" (or equivalent). That makes it clearer what we need to forward to other places and consider as a whole. Perhaps container policy integration even makes sense.
cc @artines1 @bvandersloot-mozilla @antosart @ParisMeuleman
wanderview commentedon Jun 15, 2022
I'm happy to do the work to add top-level site to environment and make storage key use it. Its not clear to me how much work it would be to move top-level origin to window, though.
domenic commentedon Jun 15, 2022
I think it can be done separately. Maybe adding an XXX box for top-level origin in the same PR that adds top-level site, to explain the situation and link to this issue.
For the record moving top-level origin would consist of:
Add top-level site to environment. (whatwg#8014)
Add top-level site to environment. (whatwg#8014)