Hi all, Some naive questions to understand what's happened here.
Is https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api the API that will be added to Firefox? Is https://cs.chromium.org/chromium/src/chrome/browser/resources/cryptotoken/enroller.js the relevant bit of code in Chromium? Is https://github.com/grantila/u2f-api the mentioned Google-supplied polyfill called u2f-api.js? On Thu, Mar 21, 2019 at 3:08 PM 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. "Experimental and behind a pref" > sounds like it's on track to getting enabled, so simultaneously 1) > sites have a reason to believe they don't need to do anything for > Firefox, since for now users can flip a pref and the feature is coming > anyway and 2) still the feature doesn't actually work by default for > users, and, considering the penalty of using an experimental feature > where the experiment fails is getting locked out of an account for > this particular feature. > > 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. > > As a user, I'd prefer the "interop with Chrome" option. > > > 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? > > > 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? > > > 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. > > > I’ve proposed here making the FIDO U2F API whitelist a pref. I can’t > > say whether I would welcome adding more domains to it by default; I > > think we’re going to have to take them on a case-by-case basis. > > What user-relevant problem is solved by having to add domains to a > list compared to making the feature available to all domains? > > -- > Henri Sivonen > hsivo...@mozilla.com > _______________________________________________ > 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
