v142 · miscellaneous

FedCM—Support showing third-party iframe origins in the UI

Currently, FedCM always shows the toplevel site in its UI. This works well when the iframe is conceptually first-party (e.g. foo.com may have an iframe foostatic.com, which is not meaningful to the user). But if the iframe is actually third-party, it would be better to make it possible to show the iframe origin in the UI so that the user better underst

concepts

  1. Third-party iframe origin

    Edit top-level site, iframe, and IdP — see the FedCM consent dialog before Chrome 142 (top frame only) next to the Chrome 142 dialog (the iframe origin shows too).

  2. Embed Allow Matrix

    Per-IDP × per-iframe-origin policy matrix that maps to Permissions-Policy: identity-credentials-get. Toggle cells, watch the FedCM dialog update or the iframe get blocked outright.

  3. Phishing Defence Comparator

    Five real-world embed scenarios — legit Stripe widget, typo-squat iframe injected via a bad ad, XSS plus fake IdP, honest third-party comment widget, same-org subdomain — side-by-side in the old dialog vs the Chrome 142 dialog. See which attacks each version lets the user catch.

  4. Origin Disclosure Builder

    A mock browser FedCM chooser rendered in the page — four radio modes (show both / top-level only / iframe only / hidden) drive what the dialog shows. A risk-score meter rises when the iframe origin is hidden from the user; editable origin names make the mismatch tangible.

  5. Permissions-Policy inheritance cascade

    The key rule authors miss: if the top-frame policy denies identity-credentials-get, no child iframe can re-enable it — even with an explicit allow attribute. Toggle the top-frame policy and each iframe's allow attribute to see the cascade and generate the exact header and attribute syntax.

why it shipped

See https://github.com/w3c-fedid/FedCM/issues/725 for more discussion on the motivation

references