Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
In short, no. I believe not implementing the facet algorithm is a feature. I recommend migrating to Web Authentication as soon as practical. I will also point to a post on blink-dev from Adam Langely calling for websites targeting Chrome to migrate to WebAuthn: https://groups.google.com/a/chromium.org/d/msg/Blink-dev/SdceviqfKJo/zIMMWWoLBgAJ J.C. On Wed, May 22, 2019 at 7:05 AM sraman--- via dev-platform < dev-platform@lists.mozilla.org> wrote: > Hi all, > > Thank you for enabling U2F! But Duo Security's implementation of U2F is > dependent on the Trusted Facet functionality, as we need to reliably > enroll/authenticate a U2F credential across subdomains. Until the trusted > facet functionality is implemented I don't believe we can enable our users > to use U2F in Firefox, even though we have a lot of really passionate U2F > users. > > Are there any thoughts about investing some time into enabling this > functionality, or considering it on your roadmap? > ___ > 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
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
Hi all, Thank you for enabling U2F! But Duo Security's implementation of U2F is dependent on the Trusted Facet functionality, as we need to reliably enroll/authenticate a U2F credential across subdomains. Until the trusted facet functionality is implemented I don't believe we can enable our users to use U2F in Firefox, even though we have a lot of really passionate U2F users. Are there any thoughts about investing some time into enabling this functionality, or considering it on your roadmap? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
Thanks for being flexible here in the face of adversity, big fan of running trains even if it seems icky in the short term. On Wed, Mar 27, 2019 at 1:00 PM JC Jones wrote: > On Tuesday, March 26, 2019 at 12:50:21 PM UTC-7, Alex Gaynor wrote: > > 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. > > I'm sorry to be unclear. I'm intending to include the register support as > well. > > I have filed Bug 1539541 [0] to do this work: > > Enable the security.webauth.u2f by default, to ride the trains > > Remove the aOp == U2FOperation::Sign check from EvaluateAppID in > WebAuthnUtil.cpp, permitting the Google override to work for Register as > well as Sign. > > Further discussion is still welcome, either here or on the bug. > > > [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1539541 > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 Don't miss out! CDT's Tech Prom is April 10, 2019, at The Anthem. Please join us: https://cdt.org/annual-dinner/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
On Tuesday, March 26, 2019 at 12:50:21 PM UTC-7, Alex Gaynor wrote: > 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. I'm sorry to be unclear. I'm intending to include the register support as well. I have filed Bug 1539541 [0] to do this work: Enable the security.webauth.u2f by default, to ride the trains Remove the aOp == U2FOperation::Sign check from EvaluateAppID in WebAuthnUtil.cpp, permitting the Google override to work for Register as well as Sign. Further discussion is still welcome, either here or on the bug. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1539541 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
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 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 > wrote: > > > On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones 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
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
On Tue, Mar 26, 2019 at 3:46 PM J.C. Jones 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 > wrote: > > > On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones 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
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
(Sorry for the delay in replying, had a long-weekend of PTO there) On Thu, Mar 21, 2019 at 7:08 AM Henri Sivonen wrote: > On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones 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? [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
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
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 wrote: > On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones 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
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones 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
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
On Thursday, March 14, 2019 at 7:22:21 PM UTC-4, acze...@google.com wrote: > Hi there, > > Chiming in from Google. This has nothing to do with our level of motivation > (which is high btw). This has to do with OEM burned-in images on Android > devices that have already shipped and the lifecycle of these devices out in > the field. Without going into too many details, in order to not lock users > out of their devices, we cannot switch u2f register to webauthn create() > until there is sufficient churn in Android devices. You can expect webauthn > get() to come much much sooner, as that is not impacted. > > Again, this is only happening because of how the code that adds accounts is > burned into certain devices. There are not any other websites, that I'm > aware of, that are in a similar unfortunate situation. Hi Alexei, Thanks for the info, can you provide some more detail? 1) Is it impossible to update the devices in question or is the OEM just not shipping updates? 2) What workarounds are available on Google's side to resolve this issue without including this ugly hack in Firefox, and why haven't they been deployed? 3) Why are we just finding about this now, in 2019, long after all of the bits for WebAuthn have shipped? It's not like WebAuthn was a surprise on the roadmap, we have been steadily moving towards it for many years now in an ecosystem that Google created. Jonathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
Hi there, Chiming in from Google. This has nothing to do with our level of motivation (which is high btw). This has to do with OEM burned-in images on Android devices that have already shipped and the lifecycle of these devices out in the field. Without going into too many details, in order to not lock users out of their devices, we cannot switch u2f register to webauthn create() until there is sufficient churn in Android devices. You can expect webauthn get() to come much much sooner, as that is not impacted. Again, this is only happening because of how the code that adds accounts is burned into certain devices. There are not any other websites, that I'm aware of, that are in a similar unfortunate situation. And so I'm hoping (and strongly believe) that this move would not encourage more usages of u2f (over webauthn). Thanks, -Alexei On Thursday, March 14, 2019 at 2:48:39 PM UTC-7, Robert O'Callahan wrote: > On Fri, Mar 15, 2019 at 10:35 AM devsnek > wrote: > > > If this is how you feel, encourage Google to fix the problem. This isn't > > Firefox's fault, Firefox is doing the right thing by supporting > > standardized APIs instead of "whatever Google uses". It's incredibly > > frustrating and demoralizing to see web standards being undermined in this > > way. > > > > Mozilla people know this and I'm sure they've made every effort to > "encourage" Google. It's up to you, and whoever else you can organize, to > exert whatever additional pressure you can on Google (on this and similar > issues). > > Rob > -- > Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot > mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil > fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta > dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew > hcihw, gninnigeb eht morf saw hcihw taht. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
On Fri, Mar 15, 2019 at 10:35 AM devsnek wrote: > If this is how you feel, encourage Google to fix the problem. This isn't > Firefox's fault, Firefox is doing the right thing by supporting > standardized APIs instead of "whatever Google uses". It's incredibly > frustrating and demoralizing to see web standards being undermined in this > way. > Mozilla people know this and I'm sure they've made every effort to "encourage" Google. It's up to you, and whoever else you can organize, to exert whatever additional pressure you can on Google (on this and similar issues). Rob -- Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew hcihw, gninnigeb eht morf saw hcihw taht. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
On Thursday, 14 March 2019 13:12:24 UTC-5, JC Jones wrote: > 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. If this is how you feel, encourage Google to fix the problem. This isn't Firefox's fault, Firefox is doing the right thing by supporting standardized APIs instead of "whatever Google uses". It's incredibly frustrating and demoralizing to see web standards being undermined in this way. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
On Thu, Mar 14, 2019 at 11:25 AM Alex Gaynor wrote: > one overriding concern: phishing, particularly moderately-sophisticated > phishing which can handle forms of 2FA such as TOTP, SMS, or push, is a > scourge. TOTP was never much defense against phishing, just password compromise (shoulder surfing, site breaches). In the late 90's AOL support techs were regularly phished for their RSA-fob tokens by people trying to get into AOLs systems. WebAuthn is solving a very real and very old problem. -Dan Veditz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
There are a lot of good reasons to oppose this: - This is a very frustrating _expansion_ of non-standard APIs, more than a year after we shipped the W3C standard API - It'll put pressure on other browsers, which were only implementing webauthn, to also support u2f.js - It'll prolong the period of having multiple APIs, which I think contributes to a lot of confusion about the ecosystem - Once we have the whitelist, there will doubtlessly be other websites who ask to be placed on it, giving them an excuse to not migrate to webauthn Having said all of those -- which are real and true -- there's one overriding concern: phishing, particularly moderately-sophisticated phishing which can handle forms of 2FA such as TOTP, SMS, or push, is a scourge. It is brutally effective, and far too cheap to scale. If this is the price we need to pay to give our users the protections of security keys, it's worth it. Further, support by default in more browsers will hopefully be a good thing for ecosystem wide security key adoption. I desperately hope some combination of Google Accounts, Android, and Chrome have a strategy for migrating Google Accounts to webauthn before all these older Androids cycle out. But in the meantime, I don't think it's fair that that block our users from phishing resilient authenticators. Thanks for putting this together JS. Alex On Thu, Mar 14, 2019 at 2:12 PM J.C. Jones wrote: > Web Authentication (WebAuthn) is our best technical response to > phishing, which is why we’ve championed it as a technology. All major > browsers either support it already, or have their support in-progress, > yet adoption by websites has been slow. The deprecated Javascript API > that WebAuthn replaces, the FIDO U2F API [0], is mostly confined to > Chromium-based browsers. > > > # tl;dr # > > To make security keys work with Google Accounts in the near future, I > propose enabling our FIDO U2F API for google.com domains, controlled > by a whitelist preference. Waiting on Google Accounts to fully support > Web Authentication will probably take too long, since it’s Android > deployments which are holding them up. > > > # Background # > > More than a year ago, I proposed here an interim solution to permit > Google Accounts to use existing FIDO U2F API credentials in Firefox > [1] which was implemented in Bug 1436078. We agreed then to implement > a hard-coded permission for Google Accounts when utilizing FIDO U2F > API credential support, whether that was via Web Authentication’s > backward compatibility extension, or via Firefox’s FIDO U2F API > support hidden behind the “security.webauth.u2f” preference. > > We’ve recently learned that Google Accounts has slipped their schedule > for using Web Authentication to register new credentials. This delay > is attributed to security key support on Android being, for most > devices, non-upgradable. WebAuthn is backwards-compatible with > credentials produced by the FIDO U2F API. However, WebAuthn-produced > credentials cannot be used with the FIDO U2F API. Because of that, > credentials created using WebAuthn will never be usable on the > majority of FIDO U2F-only Android devices currently in circulation. > > Due to this issue, there has been an unclear timeline communicated to > me for when Google Accounts will support registering security keys > using Web Authentication. > > > # Proposal # > > 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” to either “enabled > by default” or “enabled for specific domains by default.” I am > proposing the latter. > > > ## Thorny issues in enabling our FIDO U2F API implementation ## > > This is not as simple a decision as it might appear. Certainly we want > to encourage adoption of Web Authentication rather than the FIDO U2F > API. There have already been sad cases of well-known web properties > implementing the deprecated standard after we shipped WebAuthn [2]. > There’s also the matter that we haven’t built-out the whole of the > FIDO U2F API. > > Firefox’s implementation of the FIDO U2F API is deliberately incomplete: > > 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. But the specification is > the specification. > > Second, we do not perform the “Trusted Facet List” portions of the > “Determining if a Caller's FacetID is Authorized for an AppID” > algorithm [4] from the specification (we stop at step 3). It seems: > under-specified [5]; of dubious security/privacy advantage [6]; and > it’s rarely necessary [7]. > > I don’t intend to invest the engineering time to fix the above issues > (neither coding nor spec-wrangling). The anti-phishing future is Web > Authentication, and we should only care about
