Skip to content
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.

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

Introduce request infrastructure for storage access #214

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

cfredric
Copy link
Contributor

@cfredric cfredric commented Mar 10, 2025

This splits out the underlying infrastructure changes introduced in #213 so that #213 can just introduce the behavior change, and this PR can add the infrastructure needed to formally define the current behavior (in Chrome and Firefox; Safari TBD).

I also incorporated @annevk's request that request/eligible for storage-access be a tri-state enum, rather than a boolean.

This PR relies on the environment/ancestry enum, similar to other cookie layering work (e.g.).


Preview | Diff

1. If |request|'s [=request/client=] is null, return "<code>[=storage access eligibility/unset=]</code>".
1. If |request|'s [=request/client=]'s [=environment/ancestry=] is not "<code>cross-site</code>", return "<code>[=storage access eligibility/unset=]</code>"
1. If |request|'s [=request/client=]'s [=environment/has storage access=] is false, return "<code>[=storage access eligibility/ineligible=]</code>".
1. If |request|'s [=url/origin=] is not [=/same site=] with |request|'s [=request/url=]'s [=url/origin=], return "<code>[=storage access eligibility/ineligible=]</code>".
Copy link
Member

Choose a reason for hiding this comment

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

Hmm I'm not sure I understand what purpose this step serves now, would you mind elaborating it for my benefit? :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This checks that the request's initiator is same-site with the URL that we're considering sending cookies to. If they're cross-site, we shouldn't include cookies, because doing so would allow an attacker to manipulate an iframe into CSRF-ing itself, IIUC.

Note that this is one of the two things that change to be 'same-origin' in 6b6ccef, since the rest of the web platform uses origin as the security boundary, rather than site.

Copy link
Member

Choose a reason for hiding this comment

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

Right, okay, and SAH would override eligibility if supplied by the request then?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, see step 8 of https://privacycg.github.io/storage-access-headers/#http-storage-access-retry-fetch.

I tweaked the field name (eligible to storage-access -> storage access eligibility) when I modified its type (bool -> tri-state enum) in this PR, but the SAH spec can be updated to use the new name once this PR lands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants