Long-running portals with first-party storage access

[jakearchibald]

By default, a portal'd page will not have access to its first-party storage until it's activated. However, there are a couple of situations where a page can have storage access, but then later end up in a portal:

• Portal is activated, and user presses back (assuming we're going to automatically move the page back into the portal)
• Portal is activated and it adopts the previous page.

All discussions with privacy so far seem to suggest this is not ok, unless I'm missing something that exempts it in this case. Sooooo, what should we do?

---

The best answer I have so far is to allow these pages to be portaled, but place restrictions on them similar to bfcache. This would mean they're effectively frozen, unable to run JS. Given that bfcache already does this (except for providing a visual), it seems ok?

I'm not sure what we do about pages that cannot be bfcached. Also, if we the top-level window is resized, we'll also want to update the rendering of the portaled page. Can we do that with a frozen page?

[domenic]

Could you clarify what you mean by "first party"? It sounds like it is different than "same origin", which is usually how I would define the term?

[jakearchibald]

Sorry, I've been using "first-party" to mean it has access to its main storage bucket, as if it were a top-level tab. I guess I should be saying "first-party storage"? Or is there a better term.

I've updated the OP and title to try and make it clearer.