Contact emails cbiesin...@chromium.org
Explainer https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md Specification https://github.com/fedidcg/FedCM/pull/436 Summary This origin trial is intended to cover the IdP Sign-in Status API <https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md>, which is our proposal to address the last remaining privacy leak of FedCM before we feel comfortable enabling it without third party cookies: The Timing Attack Problem (issue <https://github.com/fedidcg/FedCM/issues/230#issue-1168333560>, presentation <https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM_%20Options%20for%20the%20Timing%20Attack%20Problem%20(8_16_2022).pdf> ). The Timing Attack Problem is an attack that a tracker can perform by using the FedCM API in such a way that allows them to track users invisibly. The attack works by correlating the time between credentialed and uncredentialed requests and abusing the API to prevent it from being observed by users. While we explored many variations and options (presentation <https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM_%20Options%20for%20the%20Timing%20Attack%20Problem%20(8_16_2022).pdf>), in this proposal, the IdP Sign-in Status API <https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md> allows an Identity Provider to signal to the browser when their users are logging in and logging out (in a top level frame). This signal allows the FedCM API to (a) avoid making any credential requests when the user is logged out of the IdP (and hence, fully mitigate timing correlations) an (b) provide a guarantee that every credentialed request it makes will have a user-visible outcome (e.g. an account chooser or a dialog to sign in to the IdP) given that the assumption is that the user is logged in. We believe this will make the Timing Attack economically impractical (e.g. it requires the user to (a) have logged-in to the attacker in a top level frame as well as to (b) be recognized as an IdP in the account chooser), and in doing so enables FedCM to operate when third party cookies are blocked. Blink component Blink>Identity>FedCM <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM> TAG review We have an open spec PR <https://github.com/fedidcg/FedCM/pull/436> that is currently under review, and in that process, Firefox suggested that we reframe the API in terms of the Login Status API <https://github.com/privacycg/is-logged-in> which Chrome/Firefox/Safari seem to be in directional agreement <https://github.com/privacycg/is-logged-in/issues/53>. We are planning to kick-off our TAG review once this settles a bit more into concrete spec terms while we are running the origin trial but before we send our I2S. TAG review status Pending Risks Interoperability and Compatibility Gecko: Under consideration (https://github.com/fedidcg/FedCM/pull/436). Firefox raised early on the Timing Attack Problem <https://github.com/fedidcg/FedCM/issues/230#issue-1168333560> and possible ways <https://github.com/fedidcg/FedCM/issues/230#issuecomment-1097224792> we can address it. The IdP Sign-in Status API is intended as a signal that the user agent can use to mitigate the Silent <https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM_%20Options%20for%20the%20Timing%20Attack%20Problem%20(8_16_2022).pdf> Timing Attacks which are executed through correlating the time between credentialed and uncredentialed requests without the user’s knowledge. The API sufficiently mitigates the problem for Chrome by showing a prompt (e.g. account chooser or dialog to sign in to the IdP) every time it makes a credentialed request within the FedCM API. We are working with Firefox to write the spec in such a way that different user agents can have the flexibility to make different trade-offs in terms of how often to prompt users. WebKit: No signal. Safari has so far shown overall support <https://lists.webkit.org/pipermail/webkit-dev/2022-March/032162.html> for FedCM, but haven't yet formed a position on this specific extension of FedCM. We are generally in agreement of the API shape using the Login Status API <https://github.com/privacycg/is-logged-in/issues/53>, but we haven't yet gotten signals from them on how FedCM, specifically, is going to be using this signal. We are planning to send a webkit standards position <https://github.com/WebKit/standards-positions> after we resolve this <https://github.com/privacycg/is-logged-in/issues/53> and before we I2S. Web developers: Positive We have been working with the FedID CG to develop this API and running experiments <https://developers.google.com/identity/gsi/web/guides/supported-browsers#third-party_cookies> with the Google Identity Services team. Other signals: Ergonomics This is an API that is designed to be used by identity providers, when their users login in to their websites. We exposed an HTTP header, since we heard from them that logins are often made through 302 redirects. There is also a JS API that is equivalent to the HTTP headers. WebView application risks FedCM is not currently supported on WebView <https://source.chromium.org/chromium/chromium/src/+/main:android_webview/lib/aw_main_delegate.cc;drc=1ead36c3a2d08a91935ce2aa22b35396cfc27b22;l=325>, so no change or risk to Android WebViews. Goals for experimentation The main goal for the experiment is to gather data on the user interfaces that we introduced with this API. We introduce, specifically, a dialog which allows users to open a pop-up window to login to their IdP whenever there is a mismatch between the signal we have in the IdP Sign-in Status API and what the IdP server returns that we’d like to feel confident about how it performs with users. We have run enough devtrials in preparation for this origin trial that we have learned enough about ergonomics for Identity Providers and Relying Parties. Ongoing technical constraints Debuggability The presence of the HTTP header can be checked in the network panel in devtools and the JS API calls can be debugged as usual. When we don’t send a network request due the user being logged out or if we detect a mismatch, we are planning to add a console message in bug <https://crbug.com/1453353>1453353 Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? No We are intending to start our origin trials on desktop-only and extend to mobile during the origin trial (possibly in M117). Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? Not currently: we are working on it (blocked by https://crbug.com/1451884). DevTrial instructions https://github.com/fedidcg/FedCM/blob/main/explorations/HOWTO-chrome.md#idp-sign-in-status-api Flag name FedCM - FedCM enabled with FedCM IDP sign-in status chrome://flags/#fedcm Requires code in //chrome? False Estimated milestones OriginTrial desktop last 119 OriginTrial desktop first 116 DevTrial on desktop 115 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5177628008382464 Links to previous Intent discussions -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XHJ-LMsCa-PMf1Ft51DCJK1dkzRrFZmRZuzL_Qe2WK2iA%40mail.gmail.com.
