Contact emails cfred...@chromium.org, shuu...@chromium.org, kaustub...@chromium.org, johann...@chromium.org
Explainer https://github.com/WICG/first-party-sets Specification https://wicg.github.io/first-party-sets Design docs First-Party Sets: Initial prototype description <https://docs.google.com/document/d/1Lbvn3Wt664AhWA-UytjGEi7UcRMhrR4trUWEi2ieUkE/edit#heading=h.t7ybo54eelkd> First-Party Sets Prototype Design Doc <https://docs.google.com/document/d/16m5IfppdmmL-Zwk9zW8tJD4iHTVGJOLRP7g-QwBwX5c/edit?usp=sharing> Summary First-Party Sets (“FPS”) provides a framework for developers to declare relationships among sites, to enable limited cross-site cookie access for specific, user-facing purposes. This is facilitated through the use of the Storage Access API <https://github.com/privacycg/storage-access> and requestStorageAccessFor <https://github.com/privacycg/requestStorageAccessForOrigin/> API. The First-Party Sets proposal that we intend to ship significantly differs from its originally proposed design, as we have incorporated feedback from various stakeholders. An overview of what changed and why can be found here <https://developer.chrome.com/docs/privacy-sandbox/first-party-sets-evolution/> . It’s important to note that because of its integration with the Storage Access API and requestStorageAccessFor, FPS is not a feature that is directly web-exposed. We still consider its overall impact on the web platform to be big enough to follow the blink launch process. We have submitted adjacent Intents to Ship both requestStorageAccess and requestStorageAccessFor. Blink component Privacy <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy> TAG review https://github.com/w3ctag/design-reviews/issues/342 TAG review status Pending Risks Interoperability and Compatibility This is not a breaking change. To use it, sites will need to opt in to using First-Party Sets. There is no change to existing behavior for sites not opting in to First-Party Sets. Gecko: Negative (https://github.com/mozilla/standards-positions/issues/350) WebKit: Negative (https://github.com/WebKit/standards-positions/issues/93) Web developers: Positive. FPS has been extensively discussed during its incubation in the Privacy CG and the WICG. Throughout this discussion we've consistently seen great interest and participation by web developers. - https://developer.chrome.com/docs/privacy-sandbox/first-party-sets-evolution/#working-with-the-ecosystem - https://lists.w3.org/Archives/Public/public-privacycg/2022Jun/0031.html Other signals: Edge: Positive. Microsoft has been “generally supportive of the effort” <https://github.com/privacycg/meetings/blob/main/2020/telcons/12-10-minutes.md> since 2020 and had a co-editor on the spec for a while. Edge, in conversations, has confirmed their intent to support FPS after it ships in Chrome. Through the component updater the FPS list should be available to Edge. We will work with the Edge team to make sure that they can potentially host their own version of the (same) list and to ensure cooperation on managing the list. Ergonomics Use of the Storage Access API requires sites to run JavaScript before they can access their cookies. No performance concerns. Activation Site owners will need to register their first-party sets in a public process, categorizing their usage in subsets and passing a number of technical checks, such as verifying ownership with a /.well-known/ file. The submission guidelines and checks are described in full detail on https://github.com/GoogleChrome/first-party-sets/blob/main/FPS-Submission_Guidelines.md This feature is meant to allow developers to preserve critical use cases (e.g., shared infrastructure across ccTLDs, service domains) when Chrome deprecates third-party cookies. As such, it will provide only limited utility right now, but give developers an important head start in testing and preparing their sites for the upcoming deprecation. FPS will require usage of the Storage Access API and/or requestStorageAccessFor API to have a web-observable effect. This improves cross-browser compatibility (for Storage Access API) but might come with some migration cost for developers that were previously relying on passive cookie access without JavaScript calls. Security None WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? No Debuggability We show a DevTools warning when third-party cookies are blocked and the top-level site is in the same First-Party Set as the embedded site. Further developer tooling will likely be needed to support the eventual deprecation of third-party cookies. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? No. This will be supported on Windows, Mac, Linux, Chrome OS, and Android, but will not initially be supported on Android WebView. The First-Party Set information is consumed only by Chrome's implementation of the Storage Access API, which is not implemented in Android WebView. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? No WPTs, as this isn't directly exposed to web content. Both rSA and rSAFor (through which this is exposed) have WPTs. Flag name FirstPartySets Requires code in //chrome? True Launch bug https://bugs.chromium.org/p/chromium/issues/detail?id=1175191 Estimated milestones Shipping in M113. Anticipated spec changes We don't expect backwards-incompatible changes to the general mechanics and web platform integration of FPS. We may improve the policy and technical checks of the submission process. To help with this, submitters should expect that sets will be subject to expiration and / or renewal requirements. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5640066519007232 Links to previous Intent discussions Intent to prototype: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/0EMGi-xbI-8/m/FgSjq6TtBwAJ Intent to Experiment: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/XkWbQKrBzMg This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4jfJ3tEbyWMX6RgJMFhhNe5t5aScd9kNerYMC8THe1-Sg%40mail.gmail.com.
