User:ArielGlenn/Related website sets

Related Website Sets (notes)

Notes with links for the Related Website Sets approach to mitigation of third party cookie/block tracking phaseout.

Benefits

It would allow the current wiki login mechanism across wikis and wiki families to continue to work normally for users of browsers that adopt this; ~~no code changes~~ no changes to the design of the login mechanism would be required. However, all third party cookie access would need to be accomplished via the Storage Access API [1], requiring client-side code to enable access to third party cookies. ^[1]

Browser vendor overview

Protocol owner: Google

Adopting browser vendors: Google, Microsoft (partially?)

Opposed browser vendors: Apple ^[2], Mozilla ^[3] and ^[4]

Browser adoption

Google Chrome 113+ -- After April 25, 2024 ^[5]

Microsoft Edge 121+ -- The functionality can be enabled; third party cookies permitted by default ^[6]

Specification

There is not an official specification yet, but there is a work in progress draft. ^[7]

Implementation procedure

Submit list of related domains to a github repo as a pull request according to the procedure described in the Related Webset Sets repo ^[8], and be sure it passes technical and other validity checks; then wait 2 weeks after the pull request is merged for installed copies of Chrome to pick it up ^[9]

Issues

According to the submission guidelines ^[10]:

Each domain must be a registrable domain (i.e., eTLD+1).

One domain should be designated as "set primary" (a "representative domain"). The rest, if they are not service domains, would be listed in an "associated" subset, only 5 of these are permitted. See also an earlier github issue ^[11] about this.

Variants of ccTLD may also be declared (example: wikipedia.gr) with no limit on the number of these.

Service domains may be declared in a "services" subset, with no limit on the number of these. However, these domains must not be crawlable, and must have a homepage that redirects to a different domain or results in 4xx (client error) or 5xx (server error). These too must be of the form eTLD+1.

We have rather more domains than five (or 6 if one is "primary"): wikipedia.org, wikidata.org, wikimedia.org, wikifunctions.org, wikivoyage.org, wiktionary.org, wikisource.org, wikibooks.org and so on. ~~None of these qualifies~~ I am uncertain if these can qualify as service domains.

Calls to requestStorageAccess() and requestStorageAccessFor(origin) will be auto-granted by the browser for the first 5 associated domains listed and auto-rejected for the remainder. If a service domain calls requestStorageAccessFor(origin), the call is automatically rejected.^[12]

References

[1] ttps://developers.google.com/privacy-sandbox/3pcd/storage-access-api#when_to_use_the_storage_access_api_over_other_apis

[2] ttps://github.com/WebKit/standards-positions/issues/93

[3] ttps://github.com/mozilla/standards-positions/issues/350

[4] ttps://github.com/privacycg/proposals/issues/17#issuecomment-641687052

[5] ttps://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md#important-notice-regarding-set-submissions

[6] ttps://learn.microsoft.com/en-us/deployedge/microsoft-edge-policies#relatedwebsitesetsenabled

[7] ttps://wicg.github.io/first-party-sets/

[8] ttps://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md

[9] ttps://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md#browser-behavior

[10] ttps://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md#subset-level-technical-validation

[11] ttps://github.com/WICG/first-party-sets/issues/179

[12] ttps://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md#browser-behavior

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]