Hi Martin, On Fri, Mar 31, 2023 at 12:32 AM Martin Thomson <[email protected]> wrote:
> As long as FPS affects how the web operates in any way, it should be > subject to standardization and - I would expect - the same review as any > other feature. > With the plan Yoav is suggesting, the Blink API owners would still review it carefully, but in the context of the other intents that involve web-exposed behavior. In the end, which email we reply to is a technicality; either way, we'll review the entire feature set. On Wed, Mar 29, 2023 at 6:44 PM Yoav Weiss <[email protected]> wrote: > >> 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 <[email protected]> >> wrote: >> >>> Contact emails >>> >>> [email protected], [email protected], [email protected], >>> [email protected] >>> >>> 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 [email protected]. >>> 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 [email protected]. >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVrFVLJ%3DUQ7H-4K2E7%2BcZev-hCWZSkfy1CZJ%3DeP%2B4qexg%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLxc%3DWySgtAyOz07J6-Ot9%2BnHyVWDHS_VJHL3WdXA9r2SEAcw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLxc%3DWySgtAyOz07J6-Ot9%2BnHyVWDHS_VJHL3WdXA9r2SEAcw%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-ZHyoMMqq4f53V6POJc9y-dtPtHGzN%2B3gfxUtO3WRwCQ%40mail.gmail.com.
