Storage access activation reusability #22
+72
−1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change amends the explainer to support activation "stickiness" which tells the user agent to make the activation reusable for the URLs specified in the header, for the lifetime of the document.
cfredric
requested changes
Dec 19, 2024
Co-authored-by: Chris Fredrickson <[email protected]>
Co-authored-by: Chris Fredrickson <[email protected]>
Co-authored-by: Chris Fredrickson <[email protected]>
cfredric
reviewed
Jan 13, 2025
| @@ -179,6 +205,19 @@ The principal way that the Storage Access API addresses these security concerns | |||
|
|
|||
| This proposal uses a new forbidden name for the `Sec-Fetch-Storage-Access` header to prevent programmatic modification of the header value. This is primarily for reasons of coherence, rather than security, but there is a security reason to make this choice. If a script could modify the value of the header, it could lie to a server about the state of the `storage-access` permission in the requesting context and indicate that the state is `active`, even if the requesting context has not opted in to using the permission grant. This could mislead the server into inferring that the request context is more trusted/safe than it actually is (e.g., perhaps the requesting context has intentionally _not_ opted into accessing its cross-site cookies because it cannot conclude it's safe to do so). This could lead the server to make different decisions than it would have if it had received the correct header value (`none` or `inactive`). Thus the value of this header ought to be trustworthy, so it ought to be up to the user agent to set it. | |||
|
|
|||
| ### `reuse-for` | |||
|
|
|||
| A `retry` header with `reuse-for` enables the embedding document to send subsequent requests to the server with unpartitioned cookies without going through the _`retry`_ flow again. Developers who enable the reuse of storage access activation should be aware of the associated risks, such as cross-site request forgery (CSRF) and [cross-site leaks](https://xsleaks.dev/), and only allowlist URLs which expect credentialed cross-site requests and handle them safely. | |||
There was a problem hiding this comment.
Suggested change
| A `retry` header with `reuse-for` enables the embedding document to send subsequent requests to the server with unpartitioned cookies without going through the _`retry`_ flow again. Developers who enable the reuse of storage access activation should be aware of the associated risks, such as cross-site request forgery (CSRF) and [cross-site leaks](https://xsleaks.dev/), and only allowlist URLs which expect credentialed cross-site requests and handle them safely. | |
| A `retry` header with `reuse-for` enables the embedded document to send subsequent requests to the server with unpartitioned cookies without going through the _`retry`_ flow again. Developers who enable the reuse of storage access activation should be aware of the associated risks, such as cross-site request forgery (CSRF) and [cross-site leaks](https://xsleaks.dev/), and only allowlist URLs which expect credentialed cross-site requests and handle them safely. |
Do you mean "embedded" here? I read "embedding document" as referring to the top-level document (or something other than the innermost iframe, anyway). (Same comment for "embedding" below.)
There was a problem hiding this comment.
"embed" is probably not a good word here because with retry headers it's really the embedding document that's sending the request (e.g. to get an image that's embedded in the document) but I see how it can be confusing. Should I just remove "embedding" entirely to avoid confusion?
There was a problem hiding this comment.
Maybe "current document", like you suggested elsewhere?
Co-authored-by: Chris Fredrickson <[email protected]>
Co-authored-by: Chris Fredrickson <[email protected]>
Co-authored-by: Chris Fredrickson <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change extends the
Activate-Storage-Accessheader with an optionalreuse-forparameter, which tells the user agent to make the activation reusable for the URLs specified in the header, for the lifetime of the document.