Add storage key to environment. (whatwg/storage#142)

[wanderview]

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chrome: …
  • Firefox: …
  • Safari: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …

(See WHATWG Working Mode: Changes for more details.)

---

/browsing-the-web.html ( diff )
/infrastructure.html ( diff )
/webappapis.html ( diff )
/workers.html ( diff )
/worklets.html ( diff )

[wanderview]

See also: whatwg/storage#143

[annevk]

So this is a bit different from what I was expecting. What I was expecting is that we create an authority struct on environments upon which we store the various authority-related keys. And then the various algorithms can make use of that in the way that suits them. And over time we migrate keys that are currently stored elsewhere there (or turn them into getters).

As in, we need the top-level document site for both networking and storage, should they each be dealing with it individually?

[wanderview]

I'm not sure I completely understand what you see as the final vision. Do you see an authority struct that contains a storagekey or do you see an authority struct that contains each individual attribute that could then be used to compute a storage key later? If its the latter, I don't really see how that is any different than the situation today.

To this question:

As in, we need the top-level document site for both networking and storage, should they each be dealing with it individually?

It seems networking could get top-level site out of the storagekey? (Once its defined there, etc.)

[annevk]

My thinking is that authority would be a struct containing the individual fields and that HTML would own the logic of how you derive a key from that and perform comparisons. Similar to how HTML owns the logic around origins today.

I think that for networking we eventually also want the "has cross-origin ancestors" bit and at least according to https://wicg.github.io/anonymous-iframe/#spec-network-partition-key it needs the "partition nonce" as well. The main differentiating factor I can see between storage and networking authority is "origin". (I suspect that's where the misunderstanding started as in whatwg/storage#142 you outline these as being specific to the storage key, but I don't think that's correct and I'm also not sure it fits with the long term threat model.)

Based on that, perhaps another way of slicing this is that we omit "origin" from this struct and name it "partition authority" or some such. But I'm not sure it's better that some callers have to add two authority fields together versus some callers having to ignore one of them. Ignoring one of them seems like a better approach? (And for cookies we might end up having to ignore the "has cross-origin ancestors" bit, too.)

[wanderview]

So are you talking about moving StorageKey from storage spec to html spec?

I guess I was hoping to limit this refactor to what was necessary to unblock writing PRs for adding top-level site, ancestor chain bit, and anonymous iframe nonce. I think I have a handle on what is necessary for that.

What you are talking about seems quite a bit broader in scope and I'm not sure I understand all the nuances of how it would interact with different features (like networking, etc).

Any chance you would be ok with an incremental improvement here instead of jumping to your final design. I just don't have a clear enough picture of what you want there to really do the work and I'm unsure of all the implications.