-
Notifications
You must be signed in to change notification settings - Fork 23.2k
[Related Website Sets] Remove Related Website Sets guide #44361
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Chris suggested removing this entirely. I think that is a good idea.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would prefer removing the whole document, since only Google Chrome implements
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 (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.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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:
Here "rSAFor" is a shorthand for Also, the RWS registry no longer accepts any new registrations and currently contains only 71 sets. |
||
|
|
||
|
|
||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.