Skip to content

Add top-level site and cross site ancestry to storage key #182

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kyraseevers wants to merge 10 commits into
base: main
Choose a base branch
from
+22 −5
Open

Add top-level site and cross site ancestry to storage key #182

Changes from 7 commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
262d10d
Add top-level site and cross site ancestry to storage key
Jun 20, 2025
72237a2
Adding old language involving tuple back in
Jun 20, 2025
fc339da
Simplify the "obtain a site" language
kyraseevers Jun 27, 2025
a4db459
Simplify return tuple language
kyraseevers Jun 27, 2025
8bdb828
Removing trailing whitespace and adding for=url to origin
Jun 27, 2025
18f3bb4
Remove url namespace for origin
Jun 27, 2025
a5134b4
Fixing cross-site ancestry references
Jun 30, 2025
ceeca13
Updating same-site namespace and cross-site ancestry comparator
Jul 2, 2025
5904cd8
Updating language since acb is no longer on the environment
Jul 28, 2025
dfc0a6c
Reflecting changes to environment's naming
Jul 30, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 22 additions & 5 deletions storage.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ urlPrefix: https://tc39.github.io/ecma262/; spec: ECMASCRIPT
</pre>

<pre class=link-defaults>
spec:html; type:dfn; for:site; text:same site
spec:infra; type:dfn; text:implementation-defined
spec:infra; type:dfn; text:user agent
</pre>
Expand Down Expand Up @@ -207,10 +208,9 @@ anticipated that some APIs will be applicable to both <a>storage types</a> going
<h3 id=storage-keys>Storage keys</h3>

<p>A <dfn export>storage key</dfn> is a <a>tuple</a> consisting of an
<dfn for="storage key">origin</dfn> (an <a for=/>origin</a>). [[!HTML]]

<p class=XXX>This is expected to change; see
<a href="https://privacycg.github.io/storage-partitioning/">Client-Side Storage Partitioning</a>.
<dfn for="storage key">origin</dfn> (an <a for=/>origin</a>), a
<dfn for="storage key">top-level site</dfn> (a <a for=/>site</a>), and a
<dfn for="storage key">cross-site ancestry</dfn> (a boolean). [[!HTML]]
Copy link
Member

@annevk annevk Jul 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's rename this to "has cross-site ancestor" to align with what HTML ended up with.


<div algorithm>
<p>To <dfn export>obtain a storage key</dfn>, given an <a for=/>environment</a>
Expand Down Expand Up @@ -239,7 +239,18 @@ anticipated that some APIs will be applicable to both <a>storage types</a> going
<a>environment settings object</a>; otherwise <var>environment</var>'s
<a for=environment>creation URL</a>'s <a for=url>origin</a>.

<li><p>Return a <a>tuple</a> consisting of <var>origin</var>.
<li><p>Let <var>topLevelOrigin</var> be <var>environment</var>'s
<a for=environment>top-level origin</a>.

<li><p>If <var>topLevelOrigin</var> is null, then set it to <var>origin</var>.

<li><p>Let <var>topLevelSite</var> be the result of <a>obtaining a site</a> given
<var>topLevelOrigin</var>.

<li><p>Let <var>crossSiteAncestry</var> be <var>environment</var>'s
<a for=environment>cross-site ancestry</a>.
Copy link
Member

@annevk annevk Jul 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@domenic @bvandersloot-mozilla now that has cross-site ancestor is no longer on environment, how is this going to work here?

Copy link
Member

@domenic domenic Jul 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Um. I think it just never came up in whatwg/html#11133, when I convinced @bvandersloot-mozilla to switch to ESO, that we were hoping to use this for storage keys.

I noticed that we already have a branch in https://storage.spec.whatwg.org/#obtain-a-storage-key-for-non-storage-purposes which treats ESOs specially. Would that work here? Probably not. It would give the wrong answer during the phase when only an environment exists, but not an ESO, such as when navigation has started but not yet gotten as far as creating a Window object. I could see that phase as needing to look at the storage key, e.g., for service worker lookups.

So... unless there's something that's missing, I think I really screwed up here, and we should go back to @bvandersloot-mozilla's original approach. It is much more complex, but it seems to be necessary, if we're planning to use this during the liminal pre-ESO time.

Copy link
Member

@annevk annevk Jul 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's been a long time since I looked at all this, but I think pre-ESO is important for service worker allocation.


<li><p>Return (<var>origin</var>, <var>topLevelSite</var>, <var>crossSiteAncestry</var>).
</ol>
</div>

Expand All @@ -251,6 +262,12 @@ anticipated that some APIs will be applicable to both <a>storage types</a> going
<li><p>If <var>A</var>'s <a for="storage key">origin</a> is not <a>same origin</a> with
<var>B</var>'s <a for="storage key">origin</a>, then return false.

<li><p>If <var>A</var>'s <a for="storage key">top-level site</a> is not <a>same site</a>
with <var>B</var>'s <a for="storage key">top-level site</a>, then return false.

<li><p>If <var>A</var>'s <a for="storage key">cross-site ancestry</a> is not equal to
<var>B</var>'s <a for="storage key">cross-site ancestry</a>, then return false.

<li><p>Return true.
</ol>
</div>
Expand Down
Loading