search

explainers-by-googlers / storage-access-for-fedcm

This proposal reconciles the FedCM and Storage Access APIs by making a prior FedCM grant a valid reason to automatically approve a storage access request.
Creative Commons Attribution 4.0 International
3 stars 0 forks source link

Incorporate Prevent Silent Access into this proposal #1

Closed johannhof closed 3 months ago

johannhof commented 7 months ago

As @bvandersloot points out in https://github.com/fedidcg/CrossSiteCookieAccessCredential/issues/8, we should not auto-grant storage access if prevent silent access is activated for the top-level (RP) origin.

johannhof commented 7 months ago

cc @cfredric @yi-gu

cfredric commented 7 months ago

This requirement looks like it's already mentioned in the explainer (though it doesn't go into detail).

johannhof commented 7 months ago

Ah, yes... It actually says in https://github.com/explainers-by-googlers/storage-access-for-fedcm?tab=readme-ov-file#saa-autogrants

So, overhearing from @yi-gu, it sounds like this mechanism doesn't actually control auto-reauthentication on FedCM because it's controlled by the IdP itself (through .preventSilentAccess()) and thus not really a privacy thing but a developer ergonomics / expected behavior kind of question.

I do want to be consistent with when FedCM gives out access to identifiers, so I'd be more inclined to align with its prevent silent access behavior.

yi-gu commented 7 months ago

Per spec, PreventSilentAccess is suggested when a user is signing out (of the RP) such that upon user's next visit, the credential (password, identity etc.) stored in the browser should not be handed over to the RP automatically without user mediation (e.g. prompt).

From FedCM's perspective, post PreventSilentAccess,

  1. we'd show some UI upon user's next visit to ask for user's explicit permission before moving on when mediation: optional is used in the API. i.e. there would be no auto re-authentication
  2. we do NOT update the connected account set to remove the RP/IdP connection because that's what the Disconnect API does

For this proposal, it does not involve "handing over stored credential to API caller" because from privacy's perspective it only checks if the user has allowed communication between the RP and IdP. Since the connected account set is not affected by PreventSilentAccess, the signal should be the same.

It's worth noting that another key factor of this proposal is "RP must opt in for IdP to have storage access with FedCM grant". This is currently enforced by RP specifying proper Permissions Policy for the IdP iframe to use FedCM API. So we could discuss whether calling "PreventSilentAccess" is a signal that the RP is opting out. My personal opinions are:

  1. The API name "prevent silent access" may suggest "opt-out". That said, per spec and developer guide, this API was mainly focused on preventing "auto sign-in" via password or FedCM and by the time the developers deployed this API on their website (especially for Password use case) years ago, they didn't actually have the intention to "opt out".
  2. If an RP really wants to opt out of storage access auto granting by FedCM upon user signing out of the RP, they should opt out with a FedCM specific API. e.g. they could use the FedCM Disconnect API to update the connected account set such that future rSA calls would not be auto granted.
johannhof commented 7 months ago

@yi-gu does this mean that mediation: silent fails after preventSilentAccess is called or that it succeeds? I think I'd like to follow mediation: silent behavior in this proposal.

johannhof commented 5 months ago

@yi-gu @cfredric anything else we needed to do here?

yi-gu commented 5 months ago

@yi-gu does this mean that mediation: silent fails after preventSilentAccess is called or that it succeeds? I think I'd like to follow mediation: silent behavior in this proposal.

Sorry that I missed this questions!

You are right that mediation: silent fails after preventSilentAccess (as you can tell from their names :)). That being said, I'm still not convinced that we should use that as a signal to disable auto-grant. The question I'd like to clarify is "whose silent access we are trying to prevent".

@bvandersloot-mozilla mentioned that "If a site goes out of its way to call navigator.credentials.preventSilentAccess(), then we shouldn't be using things from the credential store without a dialog." I agree with the statement for the previous usage of the credential store. e.g. if a user stored their password/passkeys, then they shouldn't be auto signed in post preventSilentAccess; if a user signed in via FedCM, similarly they shouldn't be auto re-authenticated without a dialog. Because in these use cases, it's the website that's requesting "silent access".

In the storage access auto-grant use case, it's the 3P iframe (likely an IdP) that's requesting "silent access". From privacy's perspective, there's no IdP tracking concern by allowing auto-grant post preventSilentAccess until the Disconnect API is invoked which would update the connected account set and cut off the IdP-RP connection in the browser.

WDYT?

bvandersloot-mozilla commented 5 months ago

In the storage access auto-grant use case, it's the 3P iframe (likely an IdP) that's requesting "silent access". From privacy's perspective, there's no IdP tracking concern by allowing auto-grant post preventSilentAccess until the Disconnect API is invoked which would update the connected account set and cut off the IdP-RP connection in the browser.

I disagree. In a 3pc-less world, a frame is part of the top level document from a privacy perspective.

FedCM actually respects the preventSilentAccess signal. In steps 5-7 of Create an Identity Credential, the browser aborts mediation: "silent" requests when preventSilentAccess has been called last. If you can't get the token silently via FedCM, we definitely don't want to weaken the privacy state by giving up 3pc.

Practical example: a user that registers an account with an IDP, then decides later to log out and switch to a passkey by just making a new account. FedCM can't auto-reauthenticate. Should the IDP be able to silently use 3pc in the background forever?

yi-gu commented 5 months ago

Practical example: a user that registers an account with an IDP, then decides later to log out and switch to a passkey by just making a new account. FedCM can't auto-reauthenticate.

True. It's worth noting that until the connect account set is updated (either via disconnect or clearing cookies), the user is considered as a "returning user" by the browser. From FedCM privacy threat model's perspective, we put high trust on the IdP because the RP/IdP connection has been established. Could you please elaborate a bit on "we definitely don't want to weaken the privacy state"? As Johann mentioned above, we are under the impression that this is not a privacy thing but rather a developer ergonomics kind of question.

One concrete example of us putting high trust on the IdP for returning accounts is the User Info API which is to display the personalized sign-in buttons. Since it shouldn't be disabled with preventSilentAccess (otherwise it would be useless), the IdP could use that API to encode information to return to their own iframe without user mediation. After all, this is post the initial user permission so we don't believe that there's any privacy implication here as long as the connected account set stays the same.

bvandersloot-mozilla commented 5 months ago

Could you please elaborate a bit on "we definitely don't want to weaken the privacy state"?

Sure! With FedCM as-is, the RP cannot gain data from the IDP without a user-prompt after preventSilentAccess is called. We should maintain that property when expanding to cookie access.

As Johann mentioned above, we are under the impression that this is not a privacy thing but rather a developer ergonomics kind of question.

I bring up privacy because improving developer ergonomics should not weaken the privacy properties.

One concrete example of us putting high trust on the IdP for returning accounts is the User Info API which is to display the personalized sign-in buttons. Since it shouldn't be disabled with preventSilentAccess (otherwise it would be useless), the IdP could use that API to encode information to return to their own iframe without user mediation. After all, this is post the initial user permission so we don't believe that there's any privacy implication here as long as the connected account set stays the same.

I didn't realize that was the case! I had forgotten about this! I suppose that makes my argument invalid, but raises questions about the privacy properties of that feature.

yi-gu commented 5 months ago

I bring up privacy because improving developer ergonomics should not weaken the privacy properties.

Totally agree on this principle!

I suppose that makes my argument invalid, but raises questions about the privacy properties of that feature.

Yeah I think that's what we should align on. i.e. post the initial FedCM permission which has connected the RP and IdP, whether improving developer ergonomics (e.g. allowing auto-grant post preventSilentAccess, or the User Info API itself) actually weakens any privacy property.

johannhof commented 3 months ago

Talked to @bvandersloot-mozilla and @cfredric about this again, to figure out how to move forward here:

It sounds like there are two different ways of looking at the privacy implications of calling preventSilentAccess (presumably as a result of the RP logging the user out): We could disconnect IdP and RP entirely (like not expose the credential by default anymore) or keep the connection active since there has been a prior grant and from a threat-model perspective the RP or an embedded IdP could have kept a user identifier around post-signout (this is probably the justification for getUserInfo surviving a preventSilentAccess call).

Our preference for the initial MVP of the SAA autogrant would be to go the slightly more conservative route and match what FedCM does for exposing the token, i.e. respect preventSilentAccess and not auto-grant SAA after it was set. This way, we can discuss the implications of "leaking" information after the bit is set in FedID CG and possibly either adjust the behavior of the autogrant (which would be harder to do in reverse from a web compat standpoint) or change the behavior of getUserInfo.

This is, by the way, also what we had prototyped in Chrome as part of our Origin Trial.

I'll close this issue and will file a new one on FedCM to pick the discussion back up.