LGTM to experiment from M116 to M119 inclusive.
On 6/8/23 5:38 PM, Christian Biesinger wrote:
Contact emails
cbiesin...@chromium.org
Explainer
https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md
<https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md>
Specification
https://github.com/fedidcg/FedCM/pull/436
<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
<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: PositiveWe 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 <https://crbug.com/1451884>).
DevTrial instructions
https://github.com/fedidcg/FedCM/blob/main/explorations/HOWTO-chrome.md#idp-sign-in-status-api
<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
<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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XHJ-LMsCa-PMf1Ft51DCJK1dkzRrFZmRZuzL_Qe2WK2iA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/4562db6c-39e5-500a-af15-dd49bafa3387%40chromium.org.
