"top-level origin" on environments seems incorrect; consider "top-level site"

[domenic]

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

[annevk]

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]

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]

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:

• Double check that per https://dontcallmedom.github.io/webdex/t.html#top-level%20origin%40%40environment%40dfn all the references are indeed for windows, not other environments
• Delete the old definition
• Introduce a new definition, Window's top-level origin (or maybe Document's top-level origin, to mirror Document's origin?)
• Update all usage sites in HTML. This involves transformations like "environment's top-level origin" -> "environment's relevant global object's top-level origin", or "global's relevant settings object's top-level origin" -> "global's top-level origin".
• File issues on the other specs in WebDex. (But no need to PR them yourself unless you're feeling particularly energetic.)