chrome.usb available to Extensions

[Benjamin Kalman]

Hi everybody,

I have here a CL to make chrome.usb available to Extensions: https://codereview.chromium.org/1017253002

It was approved a long time ago by security but we never got around to actually submitting it. Rather than going through my own API proposal process - something I am unqualified for when it comes to USB - I'll solicit feedback here.

The relevant background is just that, a long time ago, we were blocked on having descriptive names for USB devices. Now - we have that, so it's ok.

A lighter version of this would be to expose just the picker UI, but for simplicity's sake my preference is to open up the whole thing.

Cheers,

Ben.

[Ken Rockot]

My only feedback is hooray, this sounds awesome! OK maybe that's not my only feedback:

It would be nice if there were UI to indicate where my devices were being used, but I think may be a specific instance of the more general desire to know what extensions are active in a given tab.

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[Justin Schuh]

Since I may not have been totally paying attention, I just want to make sure the Enamel team was cool with the UI for this. That was the only gate, IIRC.

[Benjamin Kalman]

The UI is/was an install warning listing the devices - these have readable names, which was blocking extension support for a while. That, and me not getting around to switching it on. Reilly more recently added a chooser UI for arbitrary devices, which we'd presumably also expose.

[Elisabeth Morant]

Do you have a screenshot of the UI you could share?

[Mustafa Emre Acer]

Why not start with the chooser instead of opening the API broadly? As I recall one of the main reasons the chooser was implemented was so that we could open the API to extensions. Gating on install permission sounds a bit at odds with user consent for content scripts project?

[Benjamin Kalman]

Sure. I've attached screenshots of the only app I know off the top of my head that needs USB devices. "Before expand" is the normal permissions dialogue, the relevant permission being "access any of these USB devices". Unfortunately, it's the Dev Editor, which needs.... every USB device, so it's diabolical.

On Thu, Mar 19, 2015 at 9:36 AM, Elisabeth Morant <e...@chromium.org> wrote:

[Joel Weinberger]

(This is a repeat of a prior email sent from the correct email account)

Sorry, but why on earth does it need *every* USB device? And moreover, if the user chooses to only give it access to one USB device, how would it know that it's *not* everything?

I guess I'm pretty dubious of adding an install permission in this situation, but this is Mustafa's call.

[Benjamin Kalman]

Mustafa - I guess the ideal safe situation here is only allowing up-front device requests, then a chooser UI for arbitrary devices. I do think that if I install the "security key" extension that I shouldn't then need to choose it the first time I plug in.

I'm not sure if getDevices lists all devices (with the appropriate permission) or whether it only includes the devices that you have access to. If the latter then we could tweak the API a bit I suppose.

On Thu, Mar 19, 2015 at 10:29 AM, Joel Weinberger <j...@google.com> wrote:

Sorry, but why on earth does it need *every* USB device? And moreover, if the user chooses to only give it access to one USB device, how would it know that it's *not* everything?

I guess I'm pretty dubious of adding an install permission in this situation, but this is Mustafa's call.

--Joel

On Thu, Mar 19, 2015 at 10:27 AM Benjamin Kalman <kal...@chromium.org> wrote:

[Benjamin Kalman]

On Thu, Mar 19, 2015 at 10:35 AM, Benjamin Kalman <kal...@chromium.org> wrote:

I do think that if I install the "security key" extension that I shouldn't then need to choose it the first time I plug in

And for Joel's sake, to be clear, I mean that the install warning needs to say "Access to the Security Key Thing device" not "Access to your USB devices".

[Reilly Grant]

CDE is a bad example at the moment because it should be using the USB chooser API but isn't yet. If it were then it actually wouldn't have any install time permissions because I recently got rid of the message if you have the "usb" permission but no "usbDevices" permissions, which CDE has many of.

A good example of an app that requests access to a specific devices is this demo:

https://chrome.google.com/webstore/detail/kcpjgiicabigbjejdjnkflkdkjknkdch

[Joel Weinberger]

But if the extension requests a whitelist of 1000 devices, isn't that effectively "all devices"? Why not just require off the bat that extensions fail gracefully if the user denies access to a particular device?

[Reilly Grant]

I am not sure that optional permissions work properly for the "usbDevices" permission. In theory there are two mechanisms to request access to a device: 1) calling chrome.usb.getUserSelectedDevices which prompts the user with a filtered list of currently connected devices and 2) requesting the device via an optional permission which prompts the user with the device name we know from our internal list of USB vendor and product IDs whether or not the device is currently connected.

[Benjamin Kalman]

On Thu, Mar 19, 2015 at 10:43 AM, Joel Weinberger <j...@chromium.org> wrote:

But if the extension requests a whitelist of 1000 devices, isn't that effectively "all devices

I don't think so, in a similar enough way that a list of 1000 hosts is not all-hosts. I would also hope that a list of 1000 devices is overwhelming vs "your USB devices" is easily missed.

However, I for extensions we could consider an arbitrarily limit on the number of devices, I suppose. Anything more and as Reilly says they should use the chooser UI.

[Benjamin Kalman]

As I mentioned, you install the gnubby app, you want gnubby to work. You install the myrobot app, you want the myrobot app to work. A chooser here is an unnecessary point of failure and friction (not to say I don't like choosers - I really do).

My strawman proposal earlier was to limit these to some smaller number than 1,000. Let's say 10. There will always be a legitimate use case for wanting 11, but that's a reasonable price to pay I suppose.

Though, do note that the version of this API without these proposed restrictions is what we already have with apps. I don't see a compelling reason in this case to hold onto this fragmentation. The threat model of bad-thing-wants-to-do-bad-thing is the same for apps and extensions.

On Thu, Mar 19, 2015 at 3:25 PM, Chris Palmer <pal...@google.com> wrote:

Requesting access to the Alexa Top 1,000 hosts would indeed basically be all-hosts.

And we know from experience (Android)  that people are fatigued, not alarmed, by permission lists 1,000 items long.

Use a chooser: simple, safe, universal.

[Justin Schuh]

So, I kinda disagree and really think all the use cases strongly call for choosers.

On Fri, Mar 20, 2015 at 3:47 PM, Benjamin Kalman <kal...@chromium.org> wrote:

As I mentioned, you install the gnubby app, you want gnubby to work. You install the myrobot app, you want the myrobot app to work. A chooser here is an unnecessary point of failure and friction (not to say I don't like choosers - I really do).

If we're stripping away the install time prompt and the chooser supports filtering on e.g. device IDs and classes, then it's effectively the same amount of friction. However, with a scoped chooser the friction is occurs at the first point of use. That seems to me far better to me than either prompting on install or silently allowing some number of devices through.

My strawman proposal earlier was to limit these to some smaller number than 1,000. Let's say 10. There will always be a legitimate use case for wanting 11, but that's a reasonable price to pay I suppose.

Though, do note that the version of this API without these proposed restrictions is what we already have with apps. I don't see a compelling reason in this case to hold onto this fragmentation. The threat model of bad-thing-wants-to-do-bad-thing is the same for apps and extensions.

Actually, that's not true. Extensions have a much larger ambient attack surface and inherit far greater ambient credentials. So, they really are far more risky than apps under the current model. With v3 we can mitigate that to a point where I think we'll all be much more comfortable combining them, but we're not there yet.

[Benjamin Kalman]

I'm not proposing to strip away the install prompt, just the ability to request all-devices. Similar to how we're stripping away the ability to request all-hosts but leaving the ability to request individual hosts - with limitations presumably, but we haven't gotten there yet.

I'm happy enough just exposing the chooser, though. Reilly, how hard would this be (i.e. does it involve more than a few checks for is-app around the place)?

Btw much of what I've been saying presumes that we have good way to classify/name devices, which I've been informed isn't necessarily true.

[Reilly Grant]

(Reposted to everyone.)

There's currently no "all devices" permission. Just "no devices" and "a list of devices." In either case additional devices can be requested at run time using the device picker. The list of devices displayed in the install prompt names them using a database that map numeric IDs to strings. We currently allow an app to request a device for which there is no entry in the database and display a more generic message but I've considered removing this and ignoring such permissions instead.

At run time the device picker can name devices better because it has access to not only the internal database but also the strings that can be read from the device. It still falls back to ugly generic names but it's generally a better experience.

We could easily allow only the "usb" permission (which allows the chooser) and not the "usbDevices" permission (which lists particular devices) for extensions.

[Adrià Vilanova Martínez]

Hi!

Is the chrome.usb API going to be available for extensions in the near future? I'm developing an extension which will read a smart card, so access to the USB api would allow me to use the chrome.certificateProvider API to provide the certificates of the smart card.

Cheers :)

[Reilly Grant]

You can work around this limitation by writing to components: 1) an app that communicates with the smart card reader and 2) an extension that uses the chrome.certificateProvider API and communicates with the app via chrome.runtime.postMessage(). The advantage of this architecture is that the app allows the hardware resource (the smart card) to be shared among a number of different apps and extensions that may want to use it.

[T Steiner]

Since google is discontinuing apps next year ( http://www.omgchrome.com/not-joke-google-killing-chrome-apps/ ) this will no longer work. Is there any news on whether the USB api will be opened to extensions or if chrome is just no longer supporting interface to USB devices without some 3rd party software. Any information would be appreciated, thanks!

[Sungguk Lim]

The alternative of chrome.usb API is webUSB(https://wicg.github.io/webusb/). which is available on dev channel.

2016년 9월 25일 일요일 오전 4시 46분 45초 UTC+9, T Steiner 님의 말:

[Rahul Chaturvedi]

There are no plans for supporting USB in extensions. Access to USB doesn't really belong in extensions - it was typically something an app would want to do.

Chrome apps on other platforms are being replaced by WebApps, which do have access to USB, Bluetooth and other peripherals.

[T Steiner]

Thanks for the responses. I have looked into WebUSB but here are some issues:

1) Chrome App support ends very soon and WebUSB is only supported in the Dev version of Chrome, there is no announced date when it will be available in the production version (customers are not going to want to install a special version of Chrome just to use your app). 

2) I understand that for many things IoT is the way to go and WebUSB makes sense. However, for security related applications where you don't want to send the data over the internet even if it is encrypted, this does not make sense. For example, you want to load information to a USB device such as passwords or encryption keys, the user can enter this information into a Chrome App which sends it directly to the USB device via USB HID, the attack surface is pretty limited. The same example with WebUSB introduces many new issues to solve like how do I know that my USB device is only communicating with the authorized site, what if a MITM attack occurs on a user system that sends them to a cloned site, what if the site I connect to is storing my data without my consent. 

Two examples of security products that currently use Chrome apps like this are Trezor and OnlyKey

One additional question, is it possible to use WebUSB via an extension? I.e. host the server portion of the WebUSB in the extension and USB device communicates to the local WebUSB server.

Again thanks for you time and information. 

[Reilly Grant]

On Tue, Sep 27, 2016 at 11:37 PM T Steiner <twst...@gmail.com> wrote:

Thanks for the responses. I have looked into WebUSB but here are some issues:

1) Chrome App support ends very soon and WebUSB is only supported in the Dev version of Chrome, there is no announced date when it will be available in the production version (customers are not going to want to install a special version of Chrome just to use your app). 

WebUSB is supported in Chrome 54 as an Origin Trial. Chrome 54 will be stable around Oct 18th, 2016 according to the release calendar (an estimate of course). This particular trial will run through Chrome 56. Customers do not have to do anything special.

 

2) I understand that for many things IoT is the way to go and WebUSB makes sense. However, for security related applications where you don't want to send the data over the internet even if it is encrypted, this does not make sense. For example, you want to load information to a USB device such as passwords or encryption keys, the user can enter this information into a Chrome App which sends it directly to the USB device via USB HID, the attack surface is pretty limited. The same example with WebUSB introduces many new issues to solve like how do I know that my USB device is only communicating with the authorized site, what if a MITM attack occurs on a user system that sends them to a cloned site, what if the site I connect to is storing my data without my consent. 

This is a really interesting question but first some clarifications: an MITM attack is not a concern for WebUSB because API access is only allowed from sites loaded over HTTPS. WebUSB also requires the origin of the site to match one of the ones enumerated from the device so yes, the device knows that it is communicating with an authorized site.

This does not, however, protect against the possibility of the site being compromised. Here Chrome Apps have an advantage. While a Chrome App developer's account could be compromised and used to push a malicious version of the app Chrome Apps by default have no network access. They must explicitly request the ability to make HTTP requests or raw socket connections. A compromised app with the ability to phone home would trigger a permission change prompt that would hopefully raise user suspicions. However, since what we're really talking about here is a combination of a Chrome Extension and Chrome App where the Chrome Extension communicates with arbitrary web pages (to fill in passwords, for example) then compromising both would allow for a path to exfiltrate data from the device as long as the user can be convinced to visit a cooperating compromised site.

 

Two examples of security products that currently use Chrome apps like this are Trezor and OnlyKey

One additional question, is it possible to use WebUSB via an extension? I.e. host the server portion of the WebUSB in the extension and USB device communicates to the local WebUSB server.

Using WebUSB from an extension (which really means in this context, applying a different security policy to calls to WebUSB APIs from an extension than from a web site) is basically the same question as whether we allow chrome.usb from an extension.

[T Steiner]

Thanks for the info on when WebUSB will be supported, I am good with this answer.

For #2 below though I think there may be some additional considerations in regards to security. Questions inline below:

On Wednesday, September 28, 2016 at 6:02:31 AM UTC-4, Reilly Grant wrote:

On Tue, Sep 27, 2016 at 11:37 PM T Steiner <twst...@gmail.com> wrote:

Thanks for the responses. I have looked into WebUSB but here are some issues:

1) Chrome App support ends very soon and WebUSB is only supported in the Dev version of Chrome, there is no announced date when it will be available in the production version (customers are not going to want to install a special version of Chrome just to use your app). 

WebUSB is supported in Chrome 54 as an Origin Trial. Chrome 54 will be stable around Oct 18th, 2016 according to the release calendar (an estimate of course). This particular trial will run through Chrome 56. Customers do not have to do anything special. 

 

2) I understand that for many things IoT is the way to go and WebUSB makes sense. However, for security related applications where you don't want to send the data over the internet even if it is encrypted, this does not make sense. For example, you want to load information to a USB device such as passwords or encryption keys, the user can enter this information into a Chrome App which sends it directly to the USB device via USB HID, the attack surface is pretty limited. The same example with WebUSB introduces many new issues to solve like how do I know that my USB device is only communicating with the authorized site, what if a MITM attack occurs on a user system that sends them to a cloned site, what if the site I connect to is storing my data without my consent. 

This is a really interesting question but first some clarifications: an MITM attack is not a concern for WebUSB because API access is only allowed from sites loaded over HTTPS. WebUSB also requires the origin of the site to match one of the ones enumerated from the device so yes, the device knows that it is communicating with an authorized site.

While HTTPS does mitigate a lot of MITM attacks there are still via attacks. Consider a user alice is connected at a coffee shop, a hacker uses a tool like sslsplit to intercept alice's request to https://mywebusb.com and instead sends her to a fake site. Alice is not very tech savvy and ignores the red line through the https on the site and proceeds anyway. Since the origin of the site matches and her USB device does not do any cryptographic signature verification it trusts the fake site and allows USB commands. One of those commands from the malicious site overwrites her firmware with malicious firmware that overclocks the USB device processor causing it to catch fire and burn down the coffee shop. 

Obviously a bit overdramatic here just wanted to highlight what could happen :)

 

This does not, however, protect against the possibility of the site being compromised. Here Chrome Apps have an advantage. While a Chrome App developer's account could be compromised and used to push a malicious version of the app Chrome Apps by default have no network access. They must explicitly request the ability to make HTTP requests or raw socket connections. A compromised app with the ability to phone home would trigger a permission change prompt that would hopefully raise user suspicions. However, since what we're really talking about here is a combination of a Chrome Extension and Chrome App where the Chrome Extension communicates with arbitrary web pages (to fill in passwords, for example) then compromising both would allow for a path to exfiltrate data from the device as long as the user can be convinced to visit a cooperating compromised site.

I think comparing a user's developer account being compromised with a website being hacked is quite far from apples to apples. A user can protect a developer account making it nearly impossible to compromise (2 factor auth etc) while a website is something that most businesses (those who know security at least) expect will at some point be compromised. Websites are publicly accessible and all it takes is one 0day vulnerability and it is game over. 

So looking at a risk matrix (impact/probability) the risk of a website vs. a chrome app being compromised is far greater. Because while the impact of both are the same the probability of a website being hacked is very high. 

The impact of both would be at the highest level, lets say you have 100,000 USB devices that communicate with your website daily. The website is hacked and now feeding malicious USB commands to your users. Take the over dramatic example above, now you have 100,000 coffee shops burned down. 

 

 

Two examples of security products that currently use Chrome apps like this are Trezor and OnlyKey

One additional question, is it possible to use WebUSB via an extension? I.e. host the server portion of the WebUSB in the extension and USB device communicates to the local WebUSB server.

Using WebUSB from an extension (which really means in this context, applying a different security policy to calls to WebUSB APIs from an extension than from a web site) is basically the same question as whether we allow chrome.usb from an extension.

True, but given the example of risk above if I could do this I could significantly decrease the risk of compromise because I would have no web site to hack. Also I would not be susceptible to the first attack mentioned because no HTTPS traffic is leaving a user's system. This is really the requirement I need to meet. Setting up a HTTPS server inside of the extension is not out of the questions as long as it is possible. Do you think it would be possible?

[Rafael Salomao]

How can I access USB/Bluetooth and etc from an WebApps? Can you share any link?

[Vincent Scheib]

Access USB Devices on the Web

Interact with Bluetooth devices on the Web

Stack Overflow is the best place to ask questions (there is a tag for each).

[Vincent Scheib]

Bluetooth is available on Android M+ devices, ChromeOS, and macOS. 

USB is available on Android, ChromeOS, macOS, Linux, and Windows in Chrome 61 which is in Beta now and stable early September.

[Rafael Salomao]

Great! 

What is the roadmap for Bluetooth on Windows and Linux?

[Vincent Scheib]

Windows was partially implemented earlier, completion is planned, but not started, in 2017.

No Linux development planned at this time.

https://www.chromium.org/teams/device-team/device-okrs

[Peter Connor]

So now that WebUSB has blocked communication with interfaces for smart card readers, is there no possible way to talk to a smart card reader anymore? Chrome Apps have been discontinued and as far as I am aware extensions still has no access to the chrome.usb API?

Any info would be much appreciated.

Thanks. 

[Reilly Grant]

The supported path for Smart Cards (on Chrome OS) is documented here: https://support.google.com/chrome/a/answer/7014689?hl=en 

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Reilly Grant]

Direct communication with Smart Card readers is not supported outside Chrome OS.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

On Tue, Oct 2, 2018 at 1:15 AM Peter Connor <pdco...@hotmail.co.uk> wrote:

Thanks for the link, what about for people not running Chrome OS?