Intent to Experiment: FedCM as a trust signal for the Storage Access API

[Chris Fredrickson]

Contact emails

joha...@chromium.org, cfre...@chromium.org, yi...@chromium.org

Explainer

https://github.com/explainers-by-googlers/storage-access-for-fedcm

Specification

None (TBD)

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.

Blink component

Blink>StorageAccessAPI

TAG review

None

TAG review status

N/A

Risks

Interoperability and Compatibility

None

Gecko: No public signals, positive initial signals. We will request a formal position.

WebKit: No signal. We will request a formal position.

Web developers: Positive

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?

N/A, not shipping on Android WebView.

Goals for experimentation

Evaluate the implementation, and the usability of the feature to ensure it adequately solves the problem.

Ongoing technical constraints

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No. It will not be supported in Android WebView.

Is this feature fully tested by web-platform-tests?

No. The implementation is primarily in permissions code in //chrome, which cannot be tested in WPTs since WPTs use a fake permission manager in Chromium.

Flag name on chrome://flags

#fedcm-with-storage-access-api

Finch feature name

FedCmWithStorageAccessAPI

Non-finch justification

None

Requires code in //chrome?

True

Estimated milestones

M126 through M127 (inclusive).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5116478702747648

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4iogs7O60r0YcVnDB5aCvs9WUYjWFcuHqcFi5bXLRBOig%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

LGTM to experiment from 126 to 127 inclusive.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9a75fe74-ca55-4ddc-93d7-120adfdee49en%40chromium.org.

[Chris Fredrickson]

FYI, we're going to extend this OT another 2 milestones, to 129 inclusive. (Existing OT tokens will still work, they won't expire IIUC.)

[Mike Taylor]

Hey Chris,

Per the process, you'll need to formally request an extension, rather than treat this as an FYI.

(Also, I just double checked and https://developer.chrome.com/origintrials/#/register_trial/4008766618313162753 is only available until M127. Note there's a 2 month "grace period" where it will continue to work for users on 126 or 127 that haven't upgraded to M128 or higher - but it should not work in 128 or 129.)

thanks,
Mike

[Chris Fredrickson]

Hi Mike,

My apologies, I misunderstood the process here. I hereby formally request an extension for this OT, through M129 :)

Re: the OT dashboard, I've already requested an OT extension through the chromestatus entry; I believe the OT dashboard will be updated to reflect that once the OT team approves that request.

Chris

[Mike Taylor]

On 7/24/24 8:06 PM, Chris Fredrickson wrote:

My apologies, I misunderstood the process here. I hereby formally request an extension for this OT, through M129 :)

Thanks, I formally LGTM the request to M129 inclusive. :)

Re: the OT dashboard, I've already requested an OT extension through the chromestatus entry; I believe the OT dashboard will be updated to reflect that once the OT team approves that request.

Great - I think the OT team typically chases down LGTMs - so you should be set now.

[Chris Fredrickson]

Hello again - we'd like to request another OT extension, through M130 inclusive. As a demonstration of progress, we have:

• Opened a spec PR
• Requested formal position signals from Firefox and WebKit
• Written WPTs
• Requested TAG review

[Chris Harrelson]

Hi Chris,

Sounds like good progress, thanks. Could you also tell us the reasons you need to continue experimenting?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b4effd10-8b45-478a-8d73-ba0a766688efn%40chromium.org.

[Chris Fredrickson]

It's not exactly for experimentation, technically. My understanding is that we need to have a verdict from the TAG review before we send an I2S, but I don't think it's realistic to expect one before M130 branch cut (9/16/23). (I also need to go through I2S pre-review and launch bug approval before I can actually enable this feature by default, which will take some time.)

I'm trying to avoid creating a gap between the OT and when the feature ships in Chrome, since that would be a bad experience for OT participants. (I have seen the technical note about "gapless" OTs, but I'm not 100% clear on what that means, since it seems to imply that OT extension requests are irrelevant from a technical perspective.)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mike Taylor]

Hey Chris,

A few thoughts:

We do not block shipping features if TAG is slow with their responses. But that said, I see the TAG review was requested just 20 hours ago - we do like to give them a reasonable amount of time to respond (this is usually on the order of a few weeks, maybe longer if there's an active dialog happening) before approving an I2S. If you were to send an I2S today, that would probably be the case[1].

We also don't like using OTs/experiments as "soft launches". The first two points of the "contract" that a site agrees to when registering for an OT are:

1. "I understand that this feature is experimental and may at any point become unavailable, and may never be enabled beyond this experiment, and even if Chrome decides to enable the feature after this trial, it will be unavailable for some time."
2.  "I understand that this feature may change throughout the course of the trial."

Other API OWNERs may disagree with me (and that's OK), but I'm not personally inclined to approve an extension here in order to prevent a small gap in availability until an I2S is sent and approved (in short order, it sounds like).

later,
Mike

[1] FWIW, I've noticed that TAG has recently reduced their latency in responding to and engaging with reviews, which is great to see.

[Rick Byers]

On Wed, Sep 11, 2024 at 3:04 PM Mike Taylor <mike...@chromium.org> wrote:

Hey Chris,

A few thoughts:

We do not block shipping features if TAG is slow with their responses. But that said, I see the TAG review was requested just 20 hours ago - we do like to give them a reasonable amount of time to respond (this is usually on the order of a few weeks, maybe longer if there's an active dialog happening) before approving an I2S. If you were to send an I2S today, that would probably be the case[1].

We also don't like using OTs/experiments as "soft launches". The first two points of the "contract" that a site agrees to when registering for an OT are:

1. "I understand that this feature is experimental and may at any point become unavailable, and may never be enabled beyond this experiment, and even if Chrome decides to enable the feature after this trial, it will be unavailable for some time."
2.  "I understand that this feature may change throughout the course of the trial."

Other API OWNERs may disagree with me (and that's OK), but I'm not personally inclined to approve an extension here in order to prevent a small gap in availability until an I2S is sent and approved (in short order, it sounds like).

I'm involved with FedCM and have a different perspective in trying to represent a partner's interests here so I'll recuse myself as an API owner on this one.

As I understand it, we have a major partner who is currently experimenting with SAA autogrant with a small fraction of their traffic. They are evaluating some properties of the design with that experiment which may influence future versions of our design. While we are expecting to I2S before they conclude their experiment, it would be harmful to their experimentation if we caused a gap in it - causing a delay in their own work for at least a month, or possibly even resetting their work more than that. Does that all match your understanding Chris? When you said "It's not exactly for experimentation", did you mean that we (Chrome / Privacy Sandbox) are now confident in our design and are preparing to ship even though we have a partner who is still experimenting themselves and not yet ready to go to 100% of their traffic?

Also note this OT was approved for 2 milestones and renewed once for 2. If Chris had just requested the max of 6 milestones at the start (or max of 3 for the first renewal), we wouldn't even need any extension approval for the 5 milestones we ultimately expect the trial to run I believe. To what extent do we think this should have a bearing on how API owners reason about extensions?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b4effd10-8b45-478a-8d73-ba0a766688efn%40chromium.org.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b229db03-df87-4751-9436-6f719f0c4789%40chromium.org.

[Chris Fredrickson]

Thanks for your response Mike; I do appreciate that OTs shouldn't be used as soft launches, and it's nice to hear that TAG reviews technically aren't blocking.

Rick, thanks for providing that context. You are absolutely correct; that partner is still running an experiment and may have feedback for us, so we'd like to not interrupt their study. (My earlier email was definitely incorrect, I was thinking too hard about things I need to do for the I2S.) Re: shipping, yes; we're preparing to ship a conservative behavior, but would still like to support the partner as they'recollecting metrics to evaluate that behavior.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b4effd10-8b45-478a-8d73-ba0a766688efn%40chromium.org.

--
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+unsubscribe@chromium.org.

[Mike Taylor]

Thanks Chris and Rick for the clarifications. I'm happy to approve an extension given that partners are actively experimenting.

LGTM to extend to M130 or 131 inclusive - whichever is more useful (either way, you're still within the default 6 milestone limit for experiments).