[Related Website Sets] Remove Related Website Sets guide#44361
[Related Website Sets] Remove Related Website Sets guide#44361bershanskiy wants to merge 1 commit into
Conversation
github-actions
Bot
added
Content:WebAPI
|
This is interesting because the feature is deprecated along with much of the rest of the privacy sandbox (https://privacysandbox.google.com/blog/update-on-plans-for-privacy-sandbox-technologies) but because this is a guide page, it doesn't automatically get the deprecation notice (the corresponding API does: https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccessFor , because it has BCD, which works to convey deprecation). That's a bit of a maintenance problem because eventually we'll be able to remove all these privacy sandbox feature pages, but it's harder to track guide pages (so we can remember to remove them). If it were me I would delete this guide page and instead link to https://privacysandbox.google.com/cookies/related-website-sets-integration when we need to (i.e. from from pages like https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccessFor). I would also delete https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using#requesting_storage_access_from_the_top-level_site_on_behalf_of_embedded_resources. |
Should I just update this PR to delete this guide page? |
I agree with @wbamberg's suggested approach here. So the things to do are:
|
github-actions
Bot
added
Content:Other
| ## 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): |
There was a problem hiding this comment.
Chris suggested removing this entirely. I think that is a good idea.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| - 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). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
|
||
| > [!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 [Storage Access API](/en-US/docs/Web/API/Storage_Access_API) for an example of the "Standards positions" section and what it should contain, as well as the landing page banner. |
There was a problem hiding this comment.
This doesn't work, because it is the deleted link/doc that has the standards position info. Either we find a different example, delete this, or we pull the standards position into here from that doc. I would prefer we pull it in because I don't think there is another great concrete example - I could be wrong though.
There was a problem hiding this comment.
There are many examples, but most of them focus on deprecated Privacy Sandbox APIs. The only non-deprecated reasonable detailed position is in files/en-us/web/api/shared_storage_api/index.md.
There was a problem hiding this comment.
That works for me https://developer.mozilla.org/en-US/docs/Web/API/Shared_Storage_API
bershanskiy
force-pushed
the
rws
branch
3 times, most recently
from
9dc8a26 to
549ae28
Compare
Add links to official Chrome document, where appropriate.
bershanskiy
changed the title
bershanskiy
requested review from
hamishwillee and
pepelsbey
and removed request for
a team
5 participants
Description
Update warning with deprecation notice.
Motivation
Save developers' time.
Additional details
RWS stopped accepting new submissions and archived their repository in 2025:
GoogleChrome/related-website-sets@75210e7
Related issues and pull requests