Open samuelgoto opened 2 months 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).
@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).
We went through a concrete use case with Shopify and how they think about the space.
@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.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).
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 tomode=active
,mode=passive
can be adopted gradually.Importantly,
mode=passive
andmode=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" ofmode=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?