On Tue, Mar 26, 2019 at 3:46 PM J.C. Jones <j...@mozilla.com> wrote: > (Sorry for the delay in replying, had a long-weekend of PTO there) > > On Thu, Mar 21, 2019 at 7:08 AM Henri Sivonen <hsivo...@mozilla.com> > wrote: > > > On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones <j...@mozilla.com> wrote: > > > It appears that if we want full security key support for Google > > > Accounts in Firefox in the near term, we need to graduate our FIDO U2F > > > API support from “experimental and behind a pref” > > > > I think it's problematic to describe something as "experimental" if > > it's not on path to getting enabled. > > [...] > > > So I think it's especially important to move *somewhere* from the > > "experimental and behind a pref" state: Either to interop with Chrome > > to the extent required by actual sites (regardless of what's de jure > > standard) or to clear removal so that the feature doesn't look like > > sites should just wait for it to get enabled and that the sites expect > > the user to flip a pref. > > > > To be clear, our FIDO U2F API support is behind a pref since it's 1) > deprecated in favor of the superior WebAuthn standard, and 2) our > implementation is bare-bones. I think these points have merit, but not > enough to justify waiting as long as we have, let alone longer. > > > > As a user, I'd prefer the "interop with Chrome" option. > > > > Okay. > > > > > to either “enabled by default” or “enabled for specific > > > domains by default.” I am proposing the latter. > > > > Why not the former? Won't the latter still make other sites wait in > > the hope that if they don't change, they'll get onto the list > > eventually anyway? > > > > It's certainly easier to simply pref-flip the feature on by default. I'm > not opposed to that, though it leaves Safari as the lone browser that will > be dragging the ecosystem to move to WebAuthn. > > > First, we only implemented the optional Javascript version of the API, > > > not the required MessagePort implementation [3]. This is mostly > > > semantics, because everyone actually uses the JS API via a > > > Google-supplied polyfill called u2f-api.js. > > > > Do I understand correctly that the part that is actually needed for > > interop is implemented? > > > > Basically, yes. (See the caveats in the original message) > > > > > > > As I’ve tried to establish, I’ve had reasons to resist shipping the > > > FIDO U2F API in Firefox, and I believe those reasons to be valid. > > > However, a multi-year delay for the largest security key-enabled web > > > property is, I think, unreasonable to push upon our users. We should > > > do what’s necessary to enable full security key support on Google > > > Accounts as quickly as is practical. > > > > This concern seems to apply to other services as well. > > > > > > What user-relevant problem is solved by having to add domains to a > > list compared to making the feature available to all domains? > > > > Last week's abrupt loss of support on Github [0] is a good case in point. > > Does anyone here disagree with simply flipping the preference on by default > to ride the trains in 68? > > Simply flipping the pref, and not including register support seems a bit unfortunate, as it'll leave some websites in a works-sometimes state. While some larger sites have UIs and help articles explaining that Firefox works for login but not reigstering a key, many will not. If it's possible to include register support in what rides the train, that seems preferable.
It's probably worth flagging that there'll still be some sites which do not work even with this, since we have a different implementation strategy than Chrome, and so some feature detection efforts break. Cheers, Alex > > [0] > > https://www.reddit.com/r/firefox/comments/b39eac/github_no_longer_allows_using_security_keys/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
