demo · v142

Phishing Defence Comparator

FedCM's old dialog only showed the top-level site. A user signing into a payment widget embedded on news.com would see "sign in to news.com" — even though the actual relying party was a payment iframe. Chrome 142 surfaces the iframe origin too. Pick a real-world scenario and watch the difference between the old dialog and the new one.

pick a scenario

legit News article embeds payments.stripe.com as a tip jar. User clicks "tip" → FedCM sign-in.
evil Compromised ad slot loads stripe-payments.evil.example in an iframe. Same look, different origin.
evil Legit news.com is XSS'd — attacker injects an iframe to auth.fake-idp.example that mimics a real IdP.
subtle Forum embeds a comment widget (disqus.com). Honest embed, but the user thought they were signing into the forum directly.
first-party News.com embeds its own static subdomain (static.news.com) — a same-org embed, not a third party. The dialog should NOT spotlight it as foreign.
Chrome < 142 — top frame only
G
Sign in to news.com
with accounts.google.com
user reads top URL only
Chrome 142 — iframe origin shown
G
Sign in to news.com
requested by payments.stripe.com
with accounts.google.com
user sees the actual relying-party origin
user can spot phish?
—
user can spot phish (v142)?
—

relevant markup

// inside the embedded iframe (the relying party)
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: "https://accounts.idp.example/fedcm.json",
      clientId: "0a1b2c"
    }]
  }
});
// The dialog now shows BOTH the top-level site (the embedder) and
// the iframe origin (this script's origin). Users see "requested by
// payments.stripe.com" even though the address bar still reads news.com.

see also