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

Mention per-frame rSA interaction #7

Merged
merged 2 commits into from
Jan 10, 2023
Merged

Mention per-frame rSA interaction #7

merged 2 commits into from
Jan 10, 2023

Conversation

mreichhoff
Copy link
Collaborator

Also clarify CORS use-credentials.

Also clarify CORS use-credentials.
@mreichhoff
Copy link
Collaborator Author

@johannhof @krgovind

(cc @nickgaw @helenyc @cfredric)

I thought we might want to mention how per-frame fits in, and in particular the potential to use it as an embeddee opt-in signal while still improving utility (by relaxing the iframe user interaction requirement).

Copy link
Member

@johannhof johannhof left a comment

Choose a reason for hiding this comment

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

Thanks!

README.md Outdated Show resolved Hide resolved
* `SameSite=None` cookies granted via requestStorageAccessForOrigin on subresources should only be attached on CORS-enabled requests. For example, an `<img>` without a [`crossorigin` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/crossorigin) would not have `SameSite=None` cookies attached, even with a valid grant. This ensures the server is aware of the caller and can react accordingly. Note that CORS is not possible on navigations; this requirement is not intended to protect `<iframe>` elements, which have other mechanisms for forbidding embedding (e.g., `x-frame-options` or `CSP`).
* For nested resource loads, [a variant of the site for cookies algorithm](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-10#section-5.2.1) could be used to avoid unrelated iframes from using a grant, potentially with a permission policy opt-out, as suggested in [a recent security analysis](https://github.com/privacycg/storage-access/issues/113).
* Another alternative would be requiring explicit per-frame opt-in via normal `requestStorageAccess` call; see below.
* `SameSite=None` cookies granted via `requestStorageAccessForOrigin` on subresources should only be attached on CORS-enabled requests. For example, an `<img>` without a [`crossorigin` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/crossorigin) set to `use-credentials` would not have `SameSite=None` cookies attached, even with a valid grant. This ensures the server is aware of the caller and can react accordingly; because the response must have the appropriate header to be read by the embedder, this ensures the embeddee has opted in. Note that CORS is not possible on navigations; this requirement is not intended to protect `<iframe>` elements.
Copy link
Member

Choose a reason for hiding this comment

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

I think this was technically mentioned in the issue and document, but it's fine listing it here :)

@mreichhoff mreichhoff merged commit 0525f5a into main Jan 10, 2023
@mreichhoff mreichhoff deleted the explainer-update branch January 19, 2023 21:08
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