Whoops. I thought the related issues would get autolinked somehow. Here are the URLs for those

https://bugs.chromium.org/p/chromium/issues/detail?id=468480
https://bugs.chromium.org/p/chromium/issues/detail?id=451165

Able to reproduce the issue on Windows 10, Mac 10.12.6 and Ubuntu 14.04 with chrome stable #	60.0.3112.90 , Canary #62.0.3174.2 and also on earlier version #45.0.2454.101. This is a non-regression issue hence marking it as untriaged.

Observed by loosing focus to "https://u2fdemo.appspot.com/" page, U2F flow is not working as expected.

Attaching the screen-cast for reference.

Deleted: 750294.mp4 699 KB

	750294.mp4 699 KB View Download

This is a cryptotoken extension issue, not webauthn. I'll reach out to the cryptotoken team to either confirm the behavior or see if it's been fixed since this was reported.

Internal bug: b/73229946

This is WAI for register operations.

From the internal bug: "The rationale is, a user has no way to validate the origin of the site requesting a U2F registration. All the user can see is a blinky light, and it could be coming from any origin, including a tab that's not visible. A register request is special, because it sets a kind of super cookie on the user: a valid U2F registration can track that user across profiles and machines, and survives cookie wipes, complete reimaging, and so on. As a result, it's a privacy sensitive operation.

The intent is to ensure that the user is reasonably confident about the site she is interacting with when the U2F register request begins. The mechanism currently implemented is based on focus: if the site is the active one when the request begins, it's allowed to begin. If the same site is active when the request completes, the site is allowed to receive the registration data. (You can navigate away and back between the two points, but the same site has to be active at the start and end of the request.)"

More can be found at https://docs.google.com/document/d/1ks0dQ4lRf7z27AgXGabq5NupVU4HfP87ywnkSiaI4e0 (googler-only)

I thought you might come to that conclusion. From the OP though

> Browser extensions (Eg. password managers) can interrupt the U2F flow if they present a prompt or do anything to cause the window to lose focus. If the user switches tabs, it makes sense to cancel the U2F flow, but if the window just loses focus maybe it shouldn't be canceled?

Any thoughts on preventing extensions from messing things up by triggering dialogs?

Hiya mastahyeti,

Your case of triggering dialogs doesn't cause issues as long as the dialog is closed before the user confirms the registration request. Is this causing an actual issue for your users, or is it something you discovered while testing?

Anyway, more thoughts:

Dialogs are a little funny. They to me seem like they could take away from a user's positive identification of the origin she's interacting with. From an internal doc I wrote about this years ago (that I really should make public, let me work on that out of band to this bug):

"We wish to ensure that users give informed consent to use their security keys on every distinct origin. For this consent, we must guarantee that the user must not be easily confused about the origin to which she is granting access."

We toyed around with a few different mechanisms, including, for a short time, requiring an additional in-browser confirmation, kind of like the location and notifications permissions dialogs. If we had those, I could imagine relaxing the dialog and tab restrictions we have today.

The downside to requiring an in-browser confirmation is that the user has to provide double-confirmation of every register request. This penalty felt pretty high for something that is almost always a very good thing for the user.

Ben, I would also be very curious to hear more about the extension-triggered prompts you have in mind, as we are thinking about introducing a native tab-modal dialog for WebAuthN operations, and it would be a shame if two bubbles were shown at the same time in real life scenarios.

I had a number of users of the Soft U2F authenticator report that the 1Password extension caused the tab to lose focus and break the registration flow.

https://github.com/github/SoftU2F/issues/18
https://github.com/github/SoftU2F/issues/40

In developing SoftU2F, I had to jump through some hoops to return focus to Chrome when the user interacts with the macOS notification:

https://git.io/vA3tE