Refactoring environment origin, top-level site, etc into policy container

[wanderview]

At TPAC there was a discussion about moving various authority information from the environment into a policy container owned by the environment. This would ensure the information is copied around correctly.

I started looking into this, but there are a couple issues I see with doing this:

1. The policy container is currently on environment settings object and not on environment. This is a problem since we need the authority information on environments in order to construct a StorageKey during navigations in order to pick a service worker.
2. It seems an environment settings object for a window doesn't even own the policy container. Instead it references the document's policy container.

Also, I'm wondering if policy containers are truly copied or just a reference is passed around. I haven't verified which yet. But if a reference is passed around it becomes difficult to modify values. For example, a cross-origin iframe should inherit the top-level site but will have a different origin value. But maybe the containers are copied and not referenced.

@annevk Any thoughts on these issues and what a good path forward would be?

[annevk]

For cross-origin cases there is no inheritance so we'd have to copy (or set up something new) regardless. Policy container helps with certain same origin cases (such as about:blank and history).

Creating the policy container earlier on seems feasible (and having environment own it until a document comes alive), but we probably don't want to move ownership from document to environment settings object entirely as I suspect that initial about:blank and a subsequent same-origin document don't share a container.

@antosart did the policy container work and can hopefully help out here.

[wanderview]

I'm looking at moving origin to policy container, but I have another question. Right now the origin for a windows environment settings object delegates to the window's associated document's origin. So I presume I need to move document's origin into policy container. Correct?

Current document's policy container is defined in html spec, but document's origin is defined in DOM spec. Is there a recommendation on how to adjust things here? Can DOM spec reference the policy container defined in html? I'm not familiar with the dependencies or associated restrictions between html-vs-dom.

Thanks.

[annevk]

I was thinking that maybe we can move origin to HTML, but that does not immediately work as it's also cloned and such. Perhaps that is no longer necessary though if we keep track of it on the global as I don't think document's origin is directly exposed.

Interdependencies between DOM and HTML are okay though, but if we can avoid them or at least plan for a way out that's always better.

[wanderview]

Hmm, another complication will be that adding origin, top-level site, etc to policy container will mean it is no longer able to be created with reasonable defaults. We can use an opaque origin as a default, but that would change behavior. So we will have to ensure that wherever a policy container is created these values are now available.

Edit: This is difficult because policy containers are created as defaults of other objects and so on.

[wanderview]

Hmm, another complication may be that document.origin is altered when document.domain is set? I'm unsure of the implications of that on moving origin to policy container.

[wanderview]

I've tried to start a PR in #8447, but I don't know where to set the policy container origin for new documents. I could just reference document.origin, but is that going away? And policy container origin would not get updated along with it for document.domain.

[annevk]

Unless you take steps to copy an origin, you'll reference it, so any modifications to it should be reflected. This is what happens for instance with an about:blank <iframe>. It'll have a reference to the origin of its parent document and setting document.domain in either document will affect both documents as they share an origin.

As such I think this should be doable, including incrementally where we keep document's origin around, but we definitely want to be careful.

[wanderview]

I realized we might have a problem with document.domain changes leaking into the storage key incorrectly. See: whatwg/storage#150