Thanks for filing this intent. I agree with your analysis that it's not directly web-exposed, and as such, I don't think LGTMs are required (but still appreciate the intent as required context for rSA and rSAF). We'll see if other API owners disagree.
On Mon, Mar 20, 2023 at 10:31 PM Johann Hofmann <johann...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4jfJ3tEbyWMX6RgJMFhhNe5t5aScd9kNerYMC8THe1-Sg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAL5BFfVrFVLJ%3DUQ7H-4K2E7%2BcZev-hCWZSkfy1CZJ%3DeP%2B4qexg%40mail.gmail.com.
