Hi Philip: 1) Yes 2) I think so -- it's clearly had substantial refactoring in the process of moving to Web Authentication 3) I think that's the one, but most sites redistribute a much older version that used to be served by gstatic.com (I can't find it now) archived here: https://github.com/fido-alliance/google-u2f-ref-code/blob/master/u2f-gae-demo/war/js/u2f-api.js
On Fri, Mar 22, 2019 at 5:34 AM Philip Jägenstedt <foo...@chromium.org> wrote: > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
