Yes, we ran an OT with 15+ registrants. The feedback we got was positive - that this feature allowed for better UX via a context-specific FedCM prompt, rather than the generic Storage Access API prompt.
One piece of feedback we got on the API was a question on whether `navigator.credentials.preventSilentAccess()` should or should not "disable" access via the Storage Access API. That said, they didn't have a strong opinion either way at the moment. We've added metrics <https://crsrc.org/c/chrome/browser/storage_access_api/storage_access_grant_permission_context.cc;drc=dab95e5948233f94cf75134d6acc08db2af4e62c;l=252> to see if this question needs to be revisited in the future, but for now would like to ship the conservative approach <https://github.com/explainers-by-googlers/storage-access-for-fedcm/issues/1#issuecomment-2318722185>. (Note that we could backward-compatibly relax this decision in the future, if needed.) Re: reviewing the spec PR, it'd be nice to review/merge the PR, I'll work with the editors as soon as they have bandwidth to review. In the meantime, I'd like to provide to users the well-let path that supports the use cases identified in the explainer sooner rather than later, to give sites as much time as possible to adopt new features before 3P cookies become less available in Chrome. On Monday, October 7, 2024 at 12:40:26 AM UTC-4 Domenic Denicola wrote: > From what I understand this had an Origin Trial. Did you get any results > you are able to share from the trial? > > On Thu, Oct 3, 2024 at 2:48 AM Chris Fredrickson <cfred...@chromium.org> > wrote: > >> Contact emails >> >> johann...@chromium.org, cfred...@chromium.org, y...@chromium.org >> >> Explainer >> >> https://github.com/explainers-by-googlers/storage-access-for-fedcm >> >> Specification >> >> https://github.com/privacycg/storage-access/pull/206 >> > > It isn't required, but is there a chance this PR could get at least > reviewed, and ideally merged, before we ship? I realize that the Mozilla > standards position only became positive last week, but with that in hand I > think merging should be possible, right? > > >> >> Summary >> >> Reconciles the FedCM and Storage Access APIs by making a prior FedCM >> grant a valid reason to automatically approve a storage access request. >> >> When a user grants permission for using their identity with a 3rd party >> Identity Provider (IdP) on a Relying Party (RP), many IdPs require >> third-party cookies to function correctly and securely. This proposal aims >> to satisfy that requirement in a private and secure manner by updating the >> Storage Access API (SAA) permission checks to not only accept the >> permission grant that is given by a storage access prompt, but also the >> permission grant that is given by a FedCM prompt. >> >> A key property of this mechanism is limiting the grant to cases >> explicitly allowed by the RP via the FedCM permissions policy, enforcing a >> per-frame control for the RP and preventing passive surveillance by the IdP >> beyond the capabilities that FedCM already grants, as outlined in the >> Privacy >> Considerations >> <https://github.com/privacycg/storage-access/blob/main/explainers/storage-access-for-fedcm.md#privacy-considerations> >> . >> >> >> 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/992 >> >> TAG review status >> >> Pending >> >> Chromium Trial Name >> >> FedCmWithStorageAccessAPI >> >> Origin Trial documentation link >> >> https://github.com/explainers-by-googlers/storage-access-for-fedcm >> >> WebFeature UseCounter name >> >> kFedCmWithStorageAccessAPI >> >> Risks >> >> Interoperability and Compatibility >> >> None >> >> >> Gecko: Positive ( >> https://github.com/mozilla/standards-positions/issues/1065) >> >> WebKit: No signal ( >> https://github.com/WebKit/standards-positions/issues/390) >> >> Web developers: Positive ( >> https://github.com/w3c-fedid/FedCM/issues/467#issuecomment-1735911894) >> >> Other signals: >> >> 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? >> >> None >> >> >> Debuggability >> >> This feature requires that the identity-credentials-get permissions >> policy is provided. >> >> - >> >> If the policy is not provided, document.requestStorageAccess() falls >> back to its normal control flow (i.e. checking for a user gesture, >> checking >> for RWS autogrant, checking for a previous top-level interaction, and >> finally showing a prompt). >> - >> >> If a policy is provided but misspelled, Chrome prints "Unrecognized >> feature: <feature name>." in the console. >> >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)? >> >> No >> >> FedCM and Storage Access API are not 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/fedcm/fedcm-storage-access-api-autogrant.tentative.https.sub.html?label=experimental&label=master&aligned >> >> (WPTs are currently failing on wpt.fyi due to an unrelated error that >> we're fixing.) >> >> Flag name on chrome://flags >> >> fedcm-with-storage-access-api >> >> Finch feature name >> >> FedCmWithStorageAccessAPI >> >> Requires code in //chrome? >> >> True >> >> Estimated milestones >> >> Origin trial desktop first >> >> 126 >> >> Origin trial desktop last >> >> 131 >> >> Origin trial extension 1 end milestone >> >> 129 >> >> Origin trial extension 2 end milestone >> >> 131 >> >> DevTrial on desktop >> >> 125 >> >> Origin trial Android first >> >> 126 >> >> Origin trial Android last >> >> 131 >> >> DevTrial on Android >> >> 125 >> >> >> Anticipated spec changes >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> >> None >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5116478702747648?gate=5070701733347328 >> >> Links to previous Intent discussions >> >> Intent to Prototype: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4iogs7O60r0YcVnDB5aCvs9WUYjWFcuHqcFi5bXLRBOig%40mail.gmail.com >> >> Intent to Experiment: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9a75fe74-ca55-4ddc-93d7-120adfdee49en%40chromium.org >> >> Intent to Extend Experiment 1: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/LwgSKPBivuM/m/0dRsXWhBAgAJ >> >> Intent to Extend Experiment 2: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/LwgSKPBivuM/m/0dRsXWhBAgAJ >> >> >> 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/5486dcaf-3ff6-4d97-a081-9626f97e2e03n%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5486dcaf-3ff6-4d97-a081-9626f97e2e03n%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1a09db7a-ddd6-4f0b-b023-70defe391831n%40chromium.org.
