Deleting the user profile "fixes" the issue for me.

(sorry, cannot edit the previous comment)
If I delete the profile, navigator.usb is back; however as soon as I close Chrome and reopen it, navigator.usb is gone again!

As you may be already aware members of the security research community have identified a vulnerability in some models of U2F token that allows them to be exploited via a phishing attack using WebUSB. Out of an abundance of caution we have disabled WebUSB in Chrome to protect users while we roll out an update which includes the ability to block access to these vulnerable devices specifically.

We apologize for the inconvenience and thank you for your patience as we work through this issue.

To manually re-enable WebUSB you may add the flag "--enable-features=WebUSB" to the Chrome command line. To do this on Windows, right click on the "Google Chrome" application shortcut, select Properties and add the string " --enable-features=WebUSB" to the end of the line in the box labeled "Target".

On Chromium 64.0.3282.186 (520840) everything seems to work as expected. Is there anything that I can test on Chrome to track down this bug?

Thank you for your answer. Just for curiosity, how did you disable WebUSB?
I tried Chrome 63 and it looks disabled too. Do you have a remote kill switch?
Moreover, when did you disable WebUSB? Is there a public blog post / announcement about that?

Yes, the base::Feature class provides a remote kill switch through the variations framework in addition to command line control. This is normally used for staged rollouts of features or A/B testing. As Chromium does not check in with our update servers it is not affected by the configuration we deploy.

Is there somewhere we can sign up for notifications when released features get turned off by default remotely?

Just looking for ways to stay ahead of this next time 

For now, should we recommend developers using WebUSB (at workshops, in companies, etc.) to use Chromium?  Also, I see that OS-Android is mentioned - but in practice, is this an issue there?

As mentioned above, is there an announcement page and when can we expect stable to have the feature back?

We built our hardware token (TREZOR model T) as a WebUSB device. Frankly, I did not expect Google will globally disable this feature once the first problem appears in one of the hardware implementations. To be honest, I did not know there is a remote kill switch at all.

Can you please document which features can be turned off remotely? What is the exact mechanism and when is the expected date you plan to turn on the WebUSB feature again?

We have disabled WebUSB in the current Chrome stable release while we wait for our hardening patches to land. This patch allows us to disable access to specific vulnerable devices by VID/PID instead of disabling the entire feature as was done here. This patch has been cherry-picked to the Chrome 65 branch which will begin rolling out to the stable release channel over the next few days.

See https://www.chromium.org/developers/calendar for the latest estimated Chrome release dates.

As a workaround you can either apply the command line flag above to re-enable the feature or update your device to beta-channel and get Chrome 65 immediately.

Just adding - this seems to be the blacklist of the USB devices

https://github.com/chromium/chromium/blob/master/chrome/browser/usb/usb_blocklist.cc

The UsbBlocklist::PopulateWithServerProvidedValues() function parses the value provided by the variation server which allows us to add entries to the list without pushing a complete update to Chrome. The server will push those entries until released builds of Chrome catch up.

Thank you for the info!

I only hope that in the future, all u2f devices won't be banned outright, because our device (Trezor T) is also a u2f device (with the u2f interface being HID, so not accessible to webusb).

(As I noted on webusb draft github, I think the more long term solution would be to add at least optional domain whitelist, but that is beyond the scope of this discussion.)

While I definitely appreciate the proactive approach to user security, silently disabling a 'shipped' API has caused significant frustration to myself and others I'm working with, today. Some sort of indication that this API was deliberately disabled would've saved me hours of troubleshooting.

I admittedly don't know the technical details of the kill-switch, but something that comes to mind is replacing the navigator.usb methods with mocks that just throw an error indicating they've been disabled, or even replacing the entire navigator.usb object with a simple message, would've made my life much easier.

This incident has given us a lot to think about in terms of how we communicate the state of these flags to developers.

Unshipping an API without going through the full Blink intent process is an exception but that does not mean we couldn't build mechanisms to do it more transparently.

Just wanted to add a thanks to Reilly for responding quickly to our inquiries early this morning when things went awry. Currently we are back online with our Desktop clients and beta-channel Chromebooks, and have a workable timeline for those Chromebooks that are constrained to stable channel. Luckily for us Spring Break and the fact that our product itself is still in beta plays in our favor.

I like the idea of having a chrome-dev mailing list dedicated these sorts of "breaking changes".

Thanks again Reilly and team for your commitment to, and vision for WebUSB.

Yes, as another developer who lost a lot of hours yesterday  until I discovered this thread. Chrome are kind enough to notify developers of pending deprecations months in advance, so I don't think it would have hurt anybody to have shown a small console message message explaining the issue when, for example, navigator.usb was entered. That at least would have been common courtesy.

Chrome 65 is slowly rolling out to users (desktop and mobile only, Chrome OS is as usual following a little behind). If you want to check if a build is available for your platform visit chrome://chrome to check for updates.

 Issue 819190  has been merged into this issue.