consider setting StorageKey on environment explicitly

[wanderview]

Currently various attributes are stored on the environment and environment settings object and then a StorageKey is computed from those values. This works today when StorageKey only consists of origin. It also will be relatively easy to add the top-level site to StorageKey.

In chromium, though, we have a couple of additional values in StorageKey. We include the ancestor-chain-bit and a possible nonce for anonymous iframes. The current properties on environment don't allow us to compute these values.

So, we could add ACB and nonce to the environment so we can compute the StorageKey. That feels a bit awkward, though, for things like the nonce. Its literally "storage key nonce" and not a nonce for anything else.

Should we instead consider setting a StorageKey on environment when its created?

Sometimes this will be computed and sometimes it will be inherited from the context initiating the creation of the environment. This would seem a more natural way to propagate things like nonce to me.

Also, this approach would seem to more naturally make it easier to extend StorageKey in the future. There are less places to fix since we don't have to deconstruct the StorageKey to assign each thing as a separate property on environment just to reconstruct it again later.

[annevk]

I think that's reasonable. I think what we want long term is to have a field on environment called authority (or hey, principal), that encompasses origin, the top-level site, and other pertinent authority aspects. I think that would make the new web security model a lot clearer. (And then we can define things such as "same authority" and in developer relations we can talk about the transition from the same-origin policy to the same-authority policy.)

Perhaps a step in that direction would be that we define StorageKey as such, but for now we also keep the separate origin getter on environment and then we can adjust all the call sites.

cc @bvandersloot-mozilla

[wanderview]

Ok, I'll look into what it will take to move StorageKey to environment.

[wanderview]

It appears we will need to modify the following places where environments or environment settings objects are created:

• Process a navigate fetch
• Set up a worker environment settings object
• Run Service Worker
• Set up a worklet environment settings object

[wanderview]

Also it appears an environment is created in create a new browsing context; e.g. when creating an about:blank iframe, etc.

[wanderview]

Also:

https://html.spec.whatwg.org/#navigating-across-documents:set-up-a-window-environment-settings-object

[wanderview]

From PR and chat, it appears @annevk would prefer we not do this. Instead he'd like to keep the attributes exploded out, but perhaps stored in some kind of new struct.

[annevk]

That is what I meant above with "defining StorageKey as such", yeah.

I suspect what I didn't push back against enough initially was the idea in OP that these storage key extensions are somehow exclusive to storage keys, as per Google's proposal they're not.