Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
1 change: 1 addition & 0 deletions files/en-us/_redirects.txt
Original file line number Diff line number Diff line change
Expand Up @@ -10421,6 +10421,7 @@
/en-US/docs/Web/API/StorageQuota/queryInfo /en-US/docs/Web/API/StorageManager
/en-US/docs/Web/API/StorageQuota/requestPersistentQuota /en-US/docs/Web/API/StorageManager
/en-US/docs/Web/API/StorageQuota/supportedTypes /en-US/docs/Web/API/StorageManager
/en-US/docs/Web/API/Storage_Access_API/Related_website_sets /en-US/docs/Web/API/Storage_Access_API
/en-US/docs/Web/API/StyleSheet.disabled /en-US/docs/Web/API/StyleSheet/disabled
/en-US/docs/Web/API/StyleSheet.href /en-US/docs/Web/API/StyleSheet/href
/en-US/docs/Web/API/StyleSheet.media /en-US/docs/Web/API/StyleSheet/media
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -74,4 +74,4 @@ It is important to clarify the current standardization status of such features t
- Adding a "Standards positions" section to the same page as the above banner, as a sub-section of the standard "Specifications" section.

> [!NOTE]
> See [Related Website Sets](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets) for an example of the "Standards positions" section and what it should contain, as well as the landing page banner.
> See [Shared Storage API](/en-US/docs/Web/API/Shared_Storage_API) for an example of the "Standards positions" section and what it should contain, as well as the landing page banner.
2 changes: 1 addition & 1 deletion files/en-us/web/api/document/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -281,7 +281,7 @@ _This interface also inherits from the {{DOMxRef("Node")}} and {{DOMxRef("EventT
- {{DOMxRef("Document.requestStorageAccess()")}}
- : Allows a document loaded in a third-party context (i.e., embedded in an {{htmlelement("iframe")}}) to request access to unpartitioned cookies, in cases where user agents by default block access to unpartitioned cookies by sites loaded in a third-party context to improve privacy.
- {{DOMxRef("Document.requestStorageAccessFor()")}} {{deprecated_inline}} {{non-standard_inline}}
- : Allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets).
- : Allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](https://privacysandbox.google.com/cookies/related-website-sets-integration).
- {{domxref("Document.startViewTransition()")}}
- : Starts a new {{domxref("View Transition API", "view transition", "", "nocode")}} and returns a {{domxref("ViewTransition")}} object to represent it.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ browser-compat: api.Document.requestStorageAccessFor

{{APIRef("Storage Access API")}}{{deprecated_header}}{{non-standard_header}}

The **`requestStorageAccessFor()`** method of the {{domxref("Document")}} interface allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets). It returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied.
The **`requestStorageAccessFor()`** method of the {{domxref("Document")}} interface allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](https://privacysandbox.google.com/cookies/related-website-sets-integration). It returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied.

## Syntax

Expand Down Expand Up @@ -43,7 +43,7 @@ A {{jsxref("Promise")}} that fulfills with `undefined` if the access to third-pa
- The document is not the top-level document.
- The document has a `null` origin.
- The supplied `requestedOrigin` is [opaque](https://html.spec.whatwg.org/multipage/browsers.html#concept-origin-opaque).
- The top-level and embedded sites are not in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets).
- The top-level and embedded sites are not in the same [related website set](https://privacysandbox.google.com/cookies/related-website-sets-integration).
- The embedding {{htmlelement("iframe")}} is sandboxed, and the `allow-storage-access-by-user-activation` token is not set.
- Usage is blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/en-US/docs/Web/HTTP/Guides/Permissions_Policy).
- Usage is denied by the user agent's permission request to use the API.
Expand Down
6 changes: 3 additions & 3 deletions files/en-us/web/api/storage_access_api/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,7 @@ Third party content embedded in an {{htmlelement("iframe")}} that needs to acces
- Safari shows prompts for all embedded content that has not previously received storage access.
- Firefox only prompts users after an origin has requested storage access on more than a threshold number of sites.
- Chrome shows prompts for all embedded content that has not previously received storage access.
It will however automatically grant access and skip prompts if the embedded content and embedding site are part of the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets).
It will however automatically grant access and skip prompts if the embedded content and embedding site are part of the same [related website set](https://privacysandbox.google.com/cookies/related-website-sets-integration).

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Chris also proposed that you remove all mentions of "related website set" that you think you can, and only convert the remaining links to the privacy sandbox.

I'm not going to second guess this, but just want to make sure you thought about this case.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

At this time, this statement still holds true. Google Chrome developers pledged to gradually drive down RWS usage by disabling RWS functionality and reaching out to affected parties, but to the best of my knowledge, RWS requestStorageAccessFor() usage did not change much.


3. Permission is granted or denied based on whether the content meets all the security requirements — see [Security considerations](#security_considerations) for general requirements, and [Browser-specific variations](#browser-specific_variations) for some browser-specific security requirements.
The {{jsxref("Promise")}}-based nature of `requestStorageAccess()` allows you to run code to handle success and failure cases.
Expand Down Expand Up @@ -311,8 +311,8 @@ Documentation for Firefox's new storage access policy for blocking tracking cook
- : New name for {{domxref("Document.hasStorageAccess()")}}.
- {{domxref("Document.requestStorageAccess()")}}
- : Allows content loaded in a third-party context (i.e., embedded in an {{htmlelement("iframe")}}) to request access to third-party cookies and unpartitioned state; returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied.
- {{domxref("Document.requestStorageAccessFor()")}} {{experimental_inline}}
- : A proposed extension to the Storage Access API that allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets). Returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied.
- {{domxref("Document.requestStorageAccessFor()")}} {{deprecated_inline}}
- : A non-standard deprecated extension to the Storage Access API that allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](https://privacysandbox.google.com/cookies/related-website-sets-integration). Returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied.

> [!NOTE]
> User interaction propagates to the promise returned by these methods, allowing the callers to take actions requiring user interaction without requiring a second click. For example, a caller could open a pop-up window from the resolved promise without triggering Firefox's pop-up blocker.
Expand Down
163 changes: 0 additions & 163 deletions files/en-us/web/api/storage_access_api/related_website_sets/index.md

This file was deleted.

4 changes: 2 additions & 2 deletions files/en-us/web/api/storage_access_api/using/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -117,15 +117,15 @@ async function handleCookieAccess() {

### Related website sets

The Chrome-only [related website sets](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets) feature can be considered a progressive enhancement mechanism that works alongside the Storage Access API — supporting browsers grant default third-party cookie and unpartitioned state access between websites in the same set. This means not having to go through the usual user permission prompt workflow described above, meaning a more user-friendly experience for users of sites in the set.
The Chrome-only [related website sets](https://privacysandbox.google.com/cookies/related-website-sets-integration) feature can be considered a progressive enhancement mechanism that works alongside the Storage Access API — supporting browsers grant default third-party cookie and unpartitioned state access between websites in the same set. This means not having to go through the usual user permission prompt workflow described above, meaning a more user-friendly experience for users of sites in the set.

## Requesting storage access from the top-level site on behalf of embedded resources

The Storage Access API features above allow an embedded document to request its own third-party cookie access. There is an additional experimental method available, {{domxref("Document.requestStorageAccessFor()")}}, a proposed extension to the Storage Access API that allows top-level sites to request storage access on behalf of specific related origins.

The `requestStorageAccessFor()` method addresses challenges in adopting the Storage Access API on top-level sites that use cross-site images or scripts requiring cookies. It can enable third-party cookie access for cross-site resources directly embedded into the top-level site that are unable to request their own storage access, for example via {{htmlelement("img")}} or {{htmlelement("script")}} elements.

For `requestStorageAccessFor()` to work, both the calling top-level page and the embedded resource it is requesting storage access for need to be part of the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets).
For `requestStorageAccessFor()` to work, both the calling top-level page and the embedded resource it is requesting storage access for need to be part of the same [related website set](#related_website_sets).

Typical usage of `requestStorageAccessFor()` looks like this (this time written in regular promise-style rather than async/await):
Comment on lines 122 to 130

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Chris suggested removing this entirely. I think that is a good idea.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I would prefer removing the whole document, since only Google Chrome implements requestStorageAccessFor() and they maintain their own documentation for it. I wanted to postpone that to a separate PR.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I haven't done my due diligence on whether anything in that document is relevent to other browers. If it is, removing the document might be a bit more challenging than just removing the section.

Anyhow, I think if you intend to come back, this is a good intermediate fix.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

MDN commits to maintaining reference documentation for 2 years after a feature stops shipping in all browsers (reflected from https://github.com/mdn/browser-compat-data/tree/main/docs/data-guidelines#removal-of-irrelevant-features).

So unless we want to make an exception for privacy sandbox, we unfortunately can't delete the pages for requestStorageAccessFor(), or any of the other privacy sandbox reference pages, for a long time.

(I hope we could learn from this to be more cautious in documenting things that might not be ready to be part of the web platform.)

So my suggestion was just to remove the guide material, since it's probably acceptable to bend the rules in that case, especially since guide pages don't really participate in the machinery to deprecate features.

But I guess we could have a conversation about making an exception to the 2-year rule for privacy sandbox, if we can see that there's not much value in keeping the docs around.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I think that's a discussion you have with BCD team first. If they agree everything else can reasonably follow (or at least that's the way I work). For this PR though, I think this fix is reasonable.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Google's public messaging regarding Related Website Sets (or First Party Sets) can be a bit confusing and their publicly stated plans changed multiple times. To the best of my knowledge, the latest and most complete public statements are Intent to Deprecate and Remove: document.requestStorageAccessFor and Intent to Deprecate and Remove: Related Website Sets (RWS)
.

The first source states:

Any invocations of rSAFor outside of an RWS currently returns a promise that is rejected.

Here "rSAFor" is a shorthand for requestStorageAccessFor(), so it appears that the current MDN text is just paraphrasing that quote.

Also, the RWS registry no longer accepts any new registrations and currently contains only 71 sets.


Expand Down
Loading