+1 this will be very welcome for so many Google Accounts and orgs that use GSuite but love us some Firefox.
I did want to raise another issue... many activists, journalists, politicians, political campaign staff, election officials, are increasingly using Google's Advanced Protection Program (which mandates only u2f two-factor). This has meant a number of us have to have two browsers open as we literally cannot use those accounts in Firefox. I'm a bit worried about what will happen if Google APP enrollees have to re-enroll tokens instead of the seamless harcoded allowance... I'm just not sure what will happen. APP account recovery is purposefully Very Hard and slow by design and that could be some serious headaches for people we've been trying to move to "unphishable credentials". best and huge fan, Joe On Tue, Jan 30, 2018 at 1:20 PM, J.C. Jones <j...@mozilla.com> wrote: > My understanding is that the gstatic migration will take effect as soon as > Google deploys Web Authentication. Re-enrolling devices will start some > unspecified time after that. > > They are concerned about Google Accounts that are accessed using a U2F > device very infrequently (once or twice per year) needing multiple > opportunities to re-enroll, hence asking for the long period. > > If we choose a shorter period, the worst-case is some of those long-tail > accounts would need to use Chrome to complete the login flow (presumably) > rather than Firefox or Tor Browser. That is probably okay. > > So perhaps February 2020 instead? > > On Tue, Jan 30, 2018 at 11:12 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > > > > > On Tue, Jan 30, 2018 at 8:49 AM, J.C. Jones <j...@mozilla.com> wrote: > > > >> Summary: Support already-enrolled U2F devices with Google Accounts for > Web > >> Authentication > >> > >> Web Authentication is on-track to ship in Firefox 60 [1], and contains > >> within it support for already-deployed USB-connected FIDO U2F devices, > and > >> we intend to ship with a spec extension feature implemented to support > >> devices that were already-enrolled using the older U2F Javascript API > [2]. > >> That feature depends on Firefox supporting the older API’s algorithm for > >> relaxing the same-origin policy [3] which is not completely implemented > in > >> Firefox [4]. > >> > >> It appears that many U2F JS API-compatible websites do not require the > >> cross-origin features currently unimplemented in Firefox, but notably > the > >> Google Accounts service does: For historical reasons (being the first > U2F > >> implementor) their FIDO App ID is “www.gstatic.com” [5] for logins to > “ > >> google.com” and its subdomains [6]. Interestingly, as the links to > >> Chromium’s source code in [5] and [6] show, Chrome chooses to hardcode > the > >> approval of this same-origin override rather than complete the > >> specification’s algorithm for this domain. > >> > >> As mentioned in the bug linked in [4], I have a variety of reservations > >> with the U2F Javascript API’s algorithm. I also recognize that Google > >> Accounts is the largest player in existing U2F device enrollments. The > >> purpose of the extension feature in [2] is to permit users who already > are > >> using U2F devices to be able to move seamlessly to Web Authentication -- > >> and hopefully also be able to use browsers other than Chrome to do it. > >> > >> After discussions with appropriate Googlers confirmed that the “ > >> www.gstatic.com” origin used in U2F is being retired as part of their > >> change-over to Web Authentication, I propose to hard-code support in > Gecko > >> to permit Google Accounts’ cross-origin U2F behavior, the same way as > >> Chrome has. I propose to do this for a period of 5 years, until 2023, > and > >> > > > > Five years seems very long to keep this around. 1-2 seems a lot more > > appropriate. When is the gstatic migration goingt o be complete? > > > > -Ekr > > > > > >> to file a bug to remove this code around that date. That would give even > >> periodically-used U2F-protected Google accounts ample opportunity to > >> re-enroll their U2F tokens with the new Web Authentication standard and > >> provide continuity-of-access. The code involved would be a small search > >> loop, similar to Chrome’s in [6]. > >> > >> If we choose not to do this, Google Accounts users who currently have > U2F > >> enabled will not be able to authenticate using Firefox until their > >> existing > >> U2F tokens are re-enrolled using Web Authentication -- meaning not only > >> will Google need to change to the Web Authentication API, they will also > >> have to prompt users to go back through the enrollment ceremony. This > >> process is likely to take several years. > >> > >> Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=webauthn > >> > >> Spec: https://www.w3.org/TR/webauthn/ > >> > >> Estimated target release: 60 > >> > >> Preference behind which this is implemented: > >> security.webauth.webauthn > >> > >> DevTools support: > >> N/A > >> > >> Support by other browser engines: > >> - Blink: In-progress > >> - Edge: In-progress > >> - Webkit: No public announcements > >> > >> Testing: > >> Mochitests in-tree; https://webauthn.io/; https://webauthn.bin.coffee/; > >> https://webauthndemo.appspot.com/; Web Platform Tests in-progress > >> > >> > >> Cheers, > >> J.C. Jones and Tim Taubert > >> > >> [1] > >> https://groups.google.com/d/msg/mozilla.dev.platform/tsevyqf > >> BHLE/lccldWNNBwAJ > >> > >> [2] https://w3c.github.io/webauthn/#sctn-appid-extension and > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1406471 > >> > >> [3] > >> https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/ > >> fido-appid-and-facets-v1.2-ps-20170411.html > >> > >> [4] > >> https://groups.google.com/d/msg/mozilla.dev.platform/UW6WMmo > >> DzEU/8h7DFOfsBQAJ > >> and https://bugzilla.mozilla.org/show_bug.cgi?id=1244959 > >> > >> [5] > >> https://chromium.googlesource.com/chromium/src.git/+/master/ > >> chrome/browser/extensions/api/cryptotoken_private/cryptotoke > >> n_private_api.cc#30 > >> > >> [6] > >> https://chromium.googlesource.com/chromium/src.git/+/master/ > >> chrome/browser/extensions/api/cryptotoken_private/cryptotoke > >> n_private_api.cc#161 > >> _______________________________________________ > >> 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 > -- 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
