Given the above, LGTM2 On Wed, Apr 5, 2023 at 5:57 PM Alex Russell <[email protected]> wrote:
> Per today's OWNERS meeting, Daniel raised the point that we need a place > to approve/dispose the overall FPS direction rather than the smaller point > features, so for that reason I'm going to LGTM1 this here (contra Yoav's > previous message). > > Best, > > Alex > > On Friday, March 31, 2023 at 8:31:10 AM UTC-7 Chris Harrelson wrote: > >> 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/02233b55-3d98-438a-a4be-abb06e180ea3n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02233b55-3d98-438a-a4be-abb06e180ea3n%40chromium.org?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/CAL5BFfUaOvSStxP9bJMChARXmurPdqh6NWuTyDWU9ohJJDtiZg%40mail.gmail.com.
