Re: [w3ctag/design-reviews] Incubation: FedCM: Support showing third-party iframe origins in the UI (Issue #1136)

cbiesinger left a comment (w3ctag/design-reviews#1136)

Was that written by AI? I have a hard time following it.

> We appreciate your detailed feedback on the proposal

We were hoping for *your* feedback on the proposal

> questioned what triggered its recent reconsideration

I have no idea what this means

> Example attack (Phishing Scenario): an evil site could exploit the specification to deceive users if the iframe URL is not shown. Consider the following:

This proposal allows *showing* the iframe URL

> An evil site (kitten.com) could feature a button for authentication on google.com. However, when the user clicks it, the site loads gogle.com (a domain owned by the evil site).

I can't follow this. Can you describe in more detail what the iframe origin is in this attack?

Are you suggesting that kitten.com embeds an iframe from gogle.com, and a dialog saying "Sign in to gogle.com with google.com. kitten.com embeds content from gogle.com" is a phishing risk (?)

Or alternatively, you are concerned about "Sign in to kitten.com with google.com" showing up (the status quo without the proposal) even though that token will get sent to gogle.com? But this attack requires kitten.com to cooperate with gogle.com, in which case it can skip the entire iframe and just ask the user to sign in to the toplevel frame directly.

> It doesn't matter whether the IdP is benign or malicious, or whether the authentication succeeds or fails, because gogle.com is already in the permission list of kitten.com, and the user has been presented with kitten.com on the iframe.

Sorry, why does it not matter if the authentication fails? What is the bad thing that will happen?

> If the iframe had displayed all three URLs (gogle.com,kitten.com,idp.com), the user could have noticed the discrepancy.

I assume you mean the fedcm dialog when you say "iframe". This proposal *allows* showing the iframe. I still don't follow the attack vector that requires the toplevel to conspire with the iframe because in that case the toplevel can skip the iframe entirely.

> Incognito Mode Behaviour

That seems entirely unrelated to the specific change, but in general, FedCM will only use the cookies that were set in incognito mode. That is, FedCM does work in incognito, but only if the user signed in to the IDP within incognito mode.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1136#issuecomment-3438371410
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1136/3438371410@github.com>