How to block storage access pre-activation?

[domenic]

For the reasons discussed in https://github.com/jeremyroman/alternate-loading-modes/blob/gh-pages/browsing-context.md, we need to block access to storage pre activation. There are at least two potential strategies for this:

1. Block all storage access, as if the user were on an opaque origin. Bucket hooks whatwg/storage#18 (comment) discusses some of the spec mechanisms we'd use.

2. Delay storage access, where possible. That is, synchronous storage access like localStorage and document.cookie would still need to be blocked. However, any asynchronous calls, like indexedDB.open(), could just have their promise or callback refuse to settle until activation.

3. A variant of (2), where we don't just delay that particular call, but we freeze the entire document upon any such call. This could make it less likely for other tasks on the event loop to get confused by the hanging promise.

Additionally, all of these have a variant where we treat cookies differently from other types of storage. For cookies, we could give access to a partitioned cookie store pre-activation, and then merge it with the unpartitioned cookie store post-activation. This is possible for cookies, and not for other types of storage, because cookies have a very simple data model for which it's possible to write a reasonable merge algorithm.

[domenic]

This is possible for cookies, and not for other types of storage, because cookies have a very simple data model for which it's possible to write a reasonable merge algorithm.

@kinu I wrote this based on your comment in #5 (comment), but would you be able to expand on this point? For example, it seems like you'd still have conflicts with two same-name, different-value cookies. As another point, I wonder what the difference is between localStorage and cookies in this regard?

[kinu]

Thanks! Reg: the cookies cases: you're right that there still can be cases where conflicts happen. I was thinking about a bit more specific cases where the page has had no cookies, then partitioned == empty (== unpartitioned), and it feels there's less reason to let them fail.

There have been also some prior thoughts for starting with empty cookies and merging back changes based on timestamps on prerendering, i.e. https://www.chromium.org/developers/design-documents/cookies-and-prerender (option b and c)

It's a good point that document.cookies and localStorage have the very similar properties (they also have sync APIs). I'll think a bit more about this, but maybe they don't need to be distinguished.

[jeremyroman]

The idea of having localStorage throw but indexedDB hang is kind of weird and asymmetrical, so I suspect they should behave the same for consistency's sake. But maybe that's less of a big deal in practice.

[domenic]

We've had some more discussion of this issue in an external document, which analyzed it holistically with other pre-activation restrictions.

We feel like we have solid strategies for asynchronous storage APIs, BroadcastChannel, SharedWorker, and web locks.

What remains are:

• Synchronous storage APIs, namely localStorage, sessionStorage (?), and document.cookie
  • We have several proposals in that document, none of which we're 100% happy with.
  • On the Chromium implementation side, there is some desire to handle cookies differently from the other two in the near-term, but I believe we have agreement that in the long term they should converge.
• Service workers
  • @mfalken has two idea sketches for how to handle them, one more strict and the other more lenient

[nhiroki]

Let me check my understanding. Based on the explanation in the external document, it's ok to grant both the sync and async storage APIs in prerendered pages as long as it is same-origin prerendering, right?

The current Chromium implementation and wpt_internal tests obey this assumption. If it's correct, I'll start upstreaming the tests.

[domenic]

Yes, that understanding is correct. No restrictions on same-origin prerendering.