How is sessionStorage impacted by storage partitioning?

[Octophi]

I was reading the Chrome blog post from last year on storage partitioning and I was curious what impact this has on sessionStorage. For localStorage it seems clear that using a double key will prevent certain scenarios that were possible before. However, since sessionStorage is already only available on a per-tab basis and is keyed by origin, I was curious how behavior would change if at all when storage is partitioned for it to use top-level site as well as the origin as keys. Am I wrong in thinking that the fact that it's restricted per tab already virtually guarantees what top-level site it comes from?

EDIT: I see that sessionStorage persists if we go to a different top-level site and then back to our original site. Is that going to be the main scenario that might be affected, ie if we visit top-level site a.com which frames example.com, then go to b.com which frames example.com, then back to a.com?

[miketaylr]

Hi @Octophi - yes, we are planning on partitioning sessionStorage as well, in the same way as localStorage (and other APIs).

Can you explain more about your use case? It sounds similar to the known issue of Firebase Authentication (example.com redirects to example.firebaseapp.com, some auth dance happens and a token in stored in sessionStorage, then the tab is redirected back to example.com, which opens a frame to example.firebaseapp.com and it postMessages the auth token up) - but slightly different.