Thanks Yoav! One minor note to the group that we successfully renamed the repository and so the explainer and spec can now be found at https://github.com/privacycg/requestStorageAccessFor and https://privacycg.github.io/requestStorageAccessFor/, respectively. (apologies to those who hit a 404 on the spec link)
On Wed, Mar 29, 2023 at 11:39 AM Yoav Weiss <[email protected]> wrote: > LGTM1 > > I appreciate the reliance on this API on FPS as an internal concept > (equivalent to the reliance of other browsers on entities.json) to > significantly reduce its user friction as well as the risk that other > vendors are concerned with (e.g. reputation concerns). > > I think we've made significant strides towards eventual interoperability > with this, without compromising on the use cases we care about, and without > unnecessarily burdening users with privacy labour. > > On Mon, Mar 20, 2023 at 10:35 PM Johann Hofmann <[email protected]> > wrote: > >> Contact emails >> >> [email protected], [email protected], [email protected] >> >> Explainer >> >> https://github.com/privacycg/requestStorageAccessForOrigin >> >> (note that we recently updated the name to remove “origin”, but not yet >> the repository name) >> >> Specification >> >> https://privacycg.github.io/requestStorageAccessForOrigin >> >> Summary >> >> An extension to the Storage Access API that allows a top-level site to >> request access to unpartitioned ("first-party") cookies on behalf of >> embedded sites. Browsers will have discretion to grant or deny access, with >> mechanisms like First-Party Set membership as a potential signal. This >> allows for use of the Storage Access API by top-level sites. >> >> For now, we intend to ship requestStorageAccessFor without user-facing >> prompts, instead relying on information from First-Party Sets to determine >> which sites should be granted storage access. >> >> Blink component >> >> Blink>StorageAccessAPI >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI> >> >> TAG review >> >> https://github.com/w3ctag/design-reviews/issues/808 >> >> TAG review status >> >> Pending >> >> Risks >> >> Interoperability and Compatibility >> >> Gecko: No signal ( >> https://github.com/mozilla/standards-positions/issues/736) >> >> WebKit: No signal ( >> https://github.com/WebKit/standards-positions/issues/125) >> >> This has been discussed with other browser vendors outside of the >> standards-positions repositories. These browsers ship this functionality as >> a version that is only accessible to internal code (as an >> anti-cross-site-cookie-breakage measure), but haven’t exposed it to >> developers, primarily out of prompt relevance concerns. There have been >> mixed reactions to our proposal, with the primary feedback being on >> reputation >> concerns with potential prompts >> <https://github.com/privacycg/requestStorageAccessForOrigin/issues/29>, >> and a desire to maintain the security benefits from cross-site cookie >> blocking to an even larger extent >> <https://github.com/privacycg/requestStorageAccessForOrigin/issues/30>. >> We intend to work on these concerns in collaboration with other browsers >> (if possible). >> >> Edge: No public signal. However, we’ve discussed this with Edge and they >> are supportive of this additional API surface and will work on enabling it >> (i.e. providing the prompts or FPS mechanisms to gate it) on Edge as well. >> >> Web developers: >> >> Positive. There has been developer >> <https://github.com/privacycg/storage-access/issues/107#issuecomment-1330491548> >> feedback <https://github.com/privacycg/storage-access/issues/53> on SAA >> asking for this or similar functionality, as well as communication with >> partners that are trying out the API to utilize FPS. >> >> Ergonomics >> >> Like requestStorageAccess, this API requires additional work from the >> developer compared to the old state of "passive" cross-site cookie access. >> This is an inherent, intentional property of the design. >> >> For security reasons, this feature requires developers to use either CORS >> headers (for non-iframe subresources) or requestStorageAccess in iframes to >> be able to access cross-site cookies after a requestStorageAccessFor call. >> >> >> 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 >> >> 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. >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> Yes, https://wpt.fyi/results/top-level-storage-access-api. Note that >> while tests are passing locally in Chrome, they’re not yet showing up on >> wpt.fyi because the feature wasn’t included in the experimental web >> platform features flag. >> >> Flag name >> >> StorageAccessAPIForOriginExtension >> >> Requires code in //chrome? >> >> True, as we’re adding a new permission and integrating with FPS. As >> mentioned in the FPS I2S, Chromium-based browsers should be able to consume >> the list through component updater. >> >> Estimated milestones >> >> Shipping in M113. >> >> >> Anticipated spec changes >> >> Some details of this API are still being discussed in the Privacy CG >> <https://github.com/privacycg/requestStorageAccessForOrigin/issues> and >> there may be backwards-incompatible changes in the future. As mentioned >> above, the primary feedback has been on reputation concerns with >> potential prompts >> <https://github.com/privacycg/requestStorageAccessForOrigin/issues/29>, >> and a desire to maintain the security benefits from cross-site cookie >> blocking to an even larger extent >> <https://github.com/privacycg/requestStorageAccessForOrigin/issues/30>. >> >> We are confident in shipping the API in its current state to better >> understand and iterate on real-world developer needs, and accept the >> responsibility of supporting potential future breaking API changes. Since >> use of the API in Chrome is currently restricted to First-Party Sets, we >> think it allows us to leverage targeted developer outreach to minimize >> compatibility impact. >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5122534152863744 >> >> Links to previous Intent discussions >> >> Intent to prototype: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGg35awh2_aqmFtWgOdo40vYVnWf%2BkEv3o7jxZ8DLbWq0eC3eQ%40mail.gmail.com >> >> >> 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_OO4g87zWDtnn00w1%2BVD%2BYwr9oP0TjOfemX97VrBe96kby3A%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4g87zWDtnn00w1%2BVD%2BYwr9oP0TjOfemX97VrBe96kby3A%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/CAD_OO4gsMixxu7f6pGGtEQ-8cUcYw35fJMZqN%3DmphF2MdkSAkg%40mail.gmail.com.
