search

w3c-fedid / active-mode

A proposal to extend FedCM to handle logged out users gracefully
2 stars 0 forks source link

Can we make `mode=passive` interoperate across browsers? #6

Open samuelgoto opened 2 months ago

samuelgoto commented 2 months ago

@bvandersloot-mozilla brought up in the FedID CG meeting that he wasn't sure whether/how Firefox would support the mode=passive, and wasn't sure if it would be possible to make browsers interoperate.

IIUC, part of the challenge for Firefox (and @bvandersloot-mozilla, please correct me where I'm wrong) is that mode=passive does not require user activation, and can be requested on page load, leading to UX that can be more intrusive than one would like.

This may be related to: https://github.com/w3c/webauthn/issues/1293

Chrome, on the other hand, so far has supported mode=passive because (a) we are finding clear demand from developers and (b) we firmly believe that we can sufficiently mitigate intrusiveness.

Let me go over (b) first.

First, at the moment, the browser reserves the right to ignore the mode=passive request: for example, in Chrome, if the browser believes the request isn't going to be helpful to users, the request gets into a "cooldown" state and ignored.

Second, we think there are two big improvements we can make: (i) much quieter UXs, like the one below and (ii) machine learning classifiers to improve matching the volume of the dialog with the user's intent (Chrome currently only considers whether the user has "dismissed manually" the dialog in the past X mins).

Screenshot 2024-09-17 at 11 59 00

While we are confident about (b), it is important to note that we are getting out of our way because we firmly believe in (a).

mode=passive gives developers a deployment structure that augments their website, rather than requiring replacing their systems or (worse) requiring user behavioral changes. We think that's key to FedCM's adoption, because, as opposed to mode=active, mode=passive can be adopted gradually.

Importantly, mode=passive and mode=active is something that each browser can pick and choose their preferences, and we can make those preferences interoperate for developers.

For example, Firefox could default to ignore every mode=passive request, whereas Chrome could ignore "some" of mode=passive, and developers would have a consistent expectation of API, while still allowing each browser to have control over intrusion.

@bvandersloot-mozilla, would that work?

bvandersloot-mozilla commented 1 month ago

As I said in the last call, planning for an entire use-case of the API to not work in one browser is planning for incompatibility.

Let's see if there is any forward progress on this at Tim's breakout session Wednesday (Harmonizing Identity-Related Web Platform API).

samuelgoto commented 1 month ago

@bvandersloot-mozilla and I chatted a bit today at TPAC on this and here are some personal mental notes I took (@bvandersloot-mozilla feel free to correct me where I misunderstood).

  1. We confirmed that it is possible to ask for WebAuthn without user activation, but it is notable that it has very different incentives compared to FedCM: a website doesn't win anything by spamming itself with a WebAuthn prompt, because it doesn't learn anything fundamentally new, as opposed to FedCM where you'd typically (but not necessarily) learn email addresses.
  2. @bvandersloot-mozilla raised the important distinction between signing-up and signing-in, and that the latter seemed more useful to have without user activation than the former.

We went through a concrete use case with Shopify and how they think about the space.