WebUSB

[Robert O'Callahan]

On Wed, Dec 2, 2015 at 10:00 AM, Eric Rescorla <e...@rtfm.com> wrote:

> On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan <rob...@ocallahan.org>
> wrote:
>
> I'd really like to see WebUSB with USB device IDs are bound to specific
>> origins (through a registry for legacy devices and through the USB protocol
>> extensions defined in that spec) so that vendors can host apps that access
>> their devices --- and so that vendor pages in an <iframe> can define and
>> vend "safe" APIs to any third-party application.
>>
>
> This seems to be roughly the API contemplated by the WebUSB spec.
> To be honest, I'm not very excited about that design. Having a system
> where the only people who can talk to USB device X are the manufacturers
> and the browser is just a conduit for that interaction doesn't really seem
> that
> great for the Open Web.
>

There are three possible approaches I can see to expose USB devices to
third-party applications:
1) What I suggested: Whitelist vendor origins for access to their devices
and have vendor-hosted pages ("Web drivers"?) expose "safe" API to
third-party applications.
2) Design a permissions API that one way or another lets users authorize
access to USB devices by third-party applications.
3) Wrap USB devices in Web-exposed believed-to-be-safe standardized APIs
built into browsers.

I see pros and cons to all three. I don't think #3 is sustainable over the
long term for more than a minority of device types, though I'm sure we'll
do it for some specific cases. It inevitably leads to bloated browsers,
interop issues, and the Web platform lagging behind native.

I think we should definitely support #1. Trusting device vendor code with
access to their devices is no worse than loading their device driver, in
most respects. Once we support such whitelisting device vendors can expose
their own APIs to third party applications even with no further effort from
us.

I see that #2 could have some value for the open Web by allowing authors to
bypass whatever API restrictions device vendors impose (including not
exposing an API at all). But in practice, just like it's normal for people
to use vendor-supplied device drivers, I think we should expect and
encourage vendor-provided Web APIs, so I'd prioritize #1 over #2. Plus the
design choices for #2 are all suboptimal.

I agree it's a bit scary to let device vendors extend the Web platform
willy-nilly; they'll make mistakes, overexpose sensitive functionality to
the Web, and make selfish API decisions. But I don't think we have any
choice if the Web is to be a first-class platform. We can mitigate the
worst of the damage, e.g. by blacklisting known-vulnerable Web drivers. Of
course nothing prevents device vendors from agreeing on API standards among
themselves, and maybe we can find ways to incentivize that.

Rob
--
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf
toD
selthor stor edna siewaoeodm or v sstvr esBa kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea
lurpr
.a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn

[Jonas Sicking]

On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> 1) What I suggested: Whitelist vendor origins for access to their devices
> and have vendor-hosted pages ("Web drivers"?) expose "safe" API to
> third-party applications.
> 2) Design a permissions API that one way or another lets users authorize
> access to USB devices by third-party applications.
> 3) Wrap USB devices in Web-exposed believed-to-be-safe standardized APIs
> built into browsers.

There's also

4) Design a new USB-protocol which enables USB devices to indicate
that they are "web safe" and which lets the USB device know which
website is talking to it. Then let the user authorize a website to use
a given device.

This is similar to what we did with TCP (through WebSocket), UDP
(WebRTC) and HTTP (through CORS).

Except that we'd also have to let the user authorize devices, similar
to 2. But at least we could design the new protocol such that we can
give the user enough information to make an informed decision.

Obviously this has the dramatic downside that it leaves all existing
USB devices behind and doesn't provide a solution for them. But that's
similar to what we did for TCP/UDP/HTTP.

/ Jonas

[Robert O'Callahan]

On Thu, Dec 3, 2015 at 11:48 PM, Jonas Sicking <jo...@sicking.cc> wrote:

> On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan <rob...@ocallahan.org>
> wrote:
> > 1) What I suggested: Whitelist vendor origins for access to their devices
> > and have vendor-hosted pages ("Web drivers"?) expose "safe" API to
> > third-party applications.
> > 2) Design a permissions API that one way or another lets users authorize
> > access to USB devices by third-party applications.
> > 3) Wrap USB devices in Web-exposed believed-to-be-safe standardized APIs
> > built into browsers.
>
> There's also
>
> 4) Design a new USB-protocol which enables USB devices to indicate
> that they are "web safe" and which lets the USB device know which
> website is talking to it. Then let the user authorize a website to use
> a given device.
>
> This is similar to what we did with TCP (through WebSocket), UDP
> (WebRTC) and HTTP (through CORS).

Yes, that's another possibility.

However, for USB the "Web driver" approach seems better than that, to me.
It makes it easy to update the vendor library to fix security bugs and
update the API. If the Web API is baked into the device firmware that's a
lot harder.

[Martin Thomson]

On Fri, Dec 4, 2015 at 8:04 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> However, for USB the "Web driver" approach seems better than that, to me.
> It makes it easy to update the vendor library to fix security bugs and
> update the API. If the Web API is baked into the device firmware that's a
> lot harder.

The only concession needed in option 4 would be some way of indicating
what was safe to use, which might be conditioned on origin.
Management of that might even be mediated by the browser rather than
the firmware. In a sense, this is a more general form of option 1 if
the vendor's origin is whitelisted.

[Eric Rescorla]

On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan <rob...@ocallahan.org>
wrote:

> On Wed, Dec 2, 2015 at 10:00 AM, Eric Rescorla <e...@rtfm.com> wrote:

>
>> On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan <rob...@ocallahan.org>
>> wrote:
>>
>> I'd really like to see WebUSB with USB device IDs are bound to specific
>>> origins (through a registry for legacy devices and through the USB protocol
>>> extensions defined in that spec) so that vendors can host apps that access
>>> their devices --- and so that vendor pages in an <iframe> can define and
>>> vend "safe" APIs to any third-party application.
>>>
>>
>> This seems to be roughly the API contemplated by the WebUSB spec.
>> To be honest, I'm not very excited about that design. Having a system
>> where the only people who can talk to USB device X are the manufacturers
>> and the browser is just a conduit for that interaction doesn't really
>> seem that
>> great for the Open Web.
>>
>
> There are three possible approaches I can see to expose USB devices to
> third-party applications:

> 1) What I suggested: Whitelist vendor origins for access to their devices
> and have vendor-hosted pages ("Web drivers"?) expose "safe" API to
> third-party applications.
> 2) Design a permissions API that one way or another lets users authorize
> access to USB devices by third-party applications.
> 3) Wrap USB devices in Web-exposed believed-to-be-safe standardized APIs
> built into browsers.
>

I can think of at least one more:
(4) Have the APIs hidden behind access controls that need to be enabled by
an extension
(but a trivial one). Perhaps you think this is #2.

I see pros and cons to all three. I don't think #3 is sustainable over the
> long term for more than a minority of device types, though I'm sure we'll
> do it for some specific cases. It inevitably leads to bloated browsers,
> interop issues, and the Web platform lagging behind native.
>

I agree with this. It's also not clear that such a safe system can be built.

I think we should definitely support #1. Trusting device vendor code with
> access to their devices is no worse than loading their device driver, in
> most respects. Once we support such whitelisting device vendors can expose
> their own APIs to third party applications even with no further effort from
> us.
>

Color me unconvinced. One of the major difficulties with consumer
electronics devices
that are nominally connectable to your computer is that the vendors do a
bad job
of making it possible for third party vendors to talk to them. Sometimes
this is done
intentionally in the name of lock-in and sometimes it's done
unintentionally through
laziness, but in either case it's bad. However, at least in those cases,
the third party
vendor can at least in principle produce some compatible downloadable driver
for the device, and its not much harder to install that than to install the
OEM driver.

I don't think it's good for the Web for browser to be in the business of
enforcing vendor
lock-in by radically increasing the gap between the access the vendor has
to the
device and the access third parties do.

I see that #2 could have some value for the open Web by allowing authors to
> bypass whatever API restrictions device vendors impose (including not
> exposing an API at all). But in practice, just like it's normal for people
> to use vendor-supplied device drivers, I think we should expect and
> encourage vendor-provided Web APIs, so I'd prioritize #1 over #2. Plus the
> design choices for #2 are all suboptimal.
>

I don't agree with this assessment of the tradeoffs for the reasons listed
above.

-Ekr

[Robert O'Callahan]

On Fri, Dec 4, 2015 at 1:56 PM, Eric Rescorla <e...@rtfm.com> wrote:

> On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan <rob...@ocallahan.org>
> wrote:
>
>> There are three possible approaches I can see to expose USB devices to
>> third-party applications:
>> 1) What I suggested: Whitelist vendor origins for access to their devices
>> and have vendor-hosted pages ("Web drivers"?) expose "safe" API to
>> third-party applications.
>> 2) Design a permissions API that one way or another lets users authorize
>> access to USB devices by third-party applications.
>> 3) Wrap USB devices in Web-exposed believed-to-be-safe standardized APIs
>> built into browsers.
>>
>
> I can think of at least one more:
> (4) Have the APIs hidden behind access controls that need to be enabled by
> an extension
> (but a trivial one). Perhaps you think this is #2.
>

Yeah it seems like a version of #2.

I think we should definitely support #1. Trusting device vendor code with
>> access to their devices is no worse than loading their device driver, in
>> most respects. Once we support such whitelisting device vendors can expose
>> their own APIs to third party applications even with no further effort from
>> us.
>>
>
>
> Color me unconvinced. One of the major difficulties with consumer
> electronics devices
> that are nominally connectable to your computer is that the vendors do a
> bad job
> of making it possible for third party vendors to talk to them. Sometimes
> this is done
> intentionally in the name of lock-in and sometimes it's done
> unintentionally through
> laziness, but in either case it's bad. However, at least in those cases,
> the third party
> vendor can at least in principle produce some compatible downloadable
> driver
> for the device, and its not much harder to install that than to install
> the OEM driver.
>
> I don't think it's good for the Web for browser to be in the business of
> enforcing vendor
> lock-in by radically increasing the gap between the access the vendor has
> to the
> device and the access third parties do.
>

I see your point, I just don't think it's as important as you do.

[Eric Rescorla]

r

On Fri, Dec 4, 2015 at 2:25 PM, Robert O'Callahan <rob...@ocallahan.org>

Sure. Conversely, I don't find myself convinced by your position.

Would be happy to talk about this live if you think that's useful.

-Ekr

[Robert O'Callahan]

On Fri, Dec 4, 2015 at 2:43 PM, Eric Rescorla <e...@rtfm.com> wrote:

>
> Sure. Conversely, I don't find myself convinced by your position.
>
> Would be happy to talk about this live if you think that's useful.
>

Probably not ... these are judgement calls that are difficult to resolve.

[Patrick McManus]

On Fri, Dec 4, 2015 at 10:56 PM, Eric Rescorla <e...@rtfm.com> wrote:

>
>
> Color me unconvinced. One of the major difficulties with consumer
> electronics devices
> that are nominally connectable to your computer is that the vendors do a
> bad job
> of making it possible for third party vendors to talk to them. Sometimes
> this is done
> intentionally in the name of lock-in and sometimes it's done
> unintentionally through
> laziness, but in either case it's bad.

and often lazy takes the form of abandonware - one of the successes of open
source has been in filling in that kind of gap. the open web should be able
to do it too.
<https://lists.mozilla.org/listinfo/dev-platform>

[rei...@chromium.org]

On Thursday, December 3, 2015 at 11:49:32 PM UTC-8, Jonas Sicking wrote:

What I've proposed is a combination of #1 and #4. USB devices can be decomposed into a number of "functions" and each of these can be declared as accessible from a set of origins or none at all. This declaration can either be communicated to the user agent by the device itself (using a command set included in the specification) or published somewhere (to support existing devices).

I chose to make this policy declarative instead of simply telling the device what origin is connected to it because:

a) It supports existing hardware through the use of a public registry.
b) It lowers the burden on the device firmware to properly understand origins and track which ones are using different hardware features. As has been pointed out in this thread it is easier to fix a bug in a software library (which will be reloaded next time the device is used) than to patch firmware. Also remember that these commands need to be implemented on chips costing only a few cents with very limited program and data memory. Even the proposed command set, which only returns fixed values, is a non-trivial barrier.

[Tim Guan-tin Chien]

On Fri, Dec 4, 2015 at 7:01 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
>
> On Fri, Dec 4, 2015 at 2:43 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
> >
> > Sure. Conversely, I don't find myself convinced by your position.
> >
> > Would be happy to talk about this live if you think that's useful.
> >
>
> Probably not ... these are judgement calls that are difficult to resolve.
>
> Rob

Rob,

IMHO there will be some detail to settle for (1) since that implies
hardware vendor has to host a driver for the device to work,
_forever_.

We could get around it by amending (1) into having vendor shipping a
JS library as driver, which fold it into (4) (if I understand it
correctly). But then we would lost the benefit of getting vendors to
supply security update timely and block bad API calls from apps.

I am leaning toward Ekr's opinion in this case. The way hardware
vendors divide their works also prevent the actual chip vendor (OEM)
from providing end user support (by at least host a driver).

Thanks,


Tim

[Robert O'Callahan]

On Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla <e...@rtfm.com> wrote:

> (4) Have the APIs hidden behind access controls that need to be enabled by
> an extension
> (but a trivial one). Perhaps you think this is #2.
>

I realized I don't understand exactly what this means.

I assume "extension" means a privileged browser extension whose install is
gated on user opt-in. Who creates and maintains this extension? How is it
distributed and updated? Does it work cross-browser? Once it's installed,
what is its effect?

[Martin Thomson]

On Thu, Dec 10, 2015 at 5:17 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>> (4) Have the APIs hidden behind access controls that need to be enabled by
>> an extension
>> (but a trivial one). Perhaps you think this is #2.
>>
>
> I realized I don't understand exactly what this means.

The basic idea is similar to what we are currently doing for
screensharing. Maintain a whitelist of sites that can access USB (or
origin+device pairs). The extension/addon just adds a set of things to
this whitelist. And yes, because this is installed in the same way
that the worst of our addons is installed, we gain the same (limited)
protections that we get from the addons, including the ability to
block the addon if it turns out to be bad.

For the record: I think is an awful solution, but it might work here.

[Tim Guan-tin Chien]

[Eric Rescorla]

On Thu, Dec 10, 2015 at 1:36 AM, Martin Thomson <m...@mozilla.com> wrote:

> On Thu, Dec 10, 2015 at 5:17 PM, Robert O'Callahan <rob...@ocallahan.org>
> wrote:
> > On Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla <e...@rtfm.com> wrote:
> >
> >> (4) Have the APIs hidden behind access controls that need to be enabled
> by
> >> an extension
> >> (but a trivial one). Perhaps you think this is #2.
> >>
> >
> > I realized I don't understand exactly what this means.
>
>
> The basic idea is similar to what we are currently doing for
> screensharing. Maintain a whitelist of sites that can access USB (or
> origin+device pairs). The extension/addon just adds a set of things to
> this whitelist. And yes, because this is installed in the same way
> that the worst of our addons is installed, we gain the same (limited)
> protections that we get from the addons, including the ability to
> block the addon if it turns out to be bad.
>

Yes, as Martin says. The usual reasoning here is "if I could get you to
install an add-on like this, it's game over anyway"

For the record: I think is an awful solution, but it might work here.
>

I too think it's an awful solution, just less awful than being in the
business
of enforcing vendor lockin for these devices.

-Ekr

[Robert O'Callahan]

What if we allow such addons but also whitelist the vendor origin reported
by the device?

[Eric Rescorla]

On Mon, Dec 14, 2015 at 8:02 PM, Robert O'Callahan <rob...@ocallahan.org>

This is certainly something one could consider, but it it seems like it
confers a major
advantage on the vendor vis-a-vis everyone else. If we're going to have an
add-on
mechanism, I don't see why vendors can't use it too.

-Ekr

[Robert O'Callahan]

On Mon, Dec 14, 2015 at 11:09 PM, Eric Rescorla <e...@rtfm.com> wrote:

> This is certainly something one could consider, but it it seems like it
> confers a major
> advantage on the vendor vis-a-vis everyone else. If we're going to have an
> add-on
> mechanism, I don't see why vendors can't use it too.
>

I think there's value in being able to plug in a device and have it just
work on the Web without any extra steps.

Yes, it gives the vendor some privilege, but given the user has chosen to
buy the vendor's device, I think that's fair. Judgement call again.

[Eric Rescorla]

On Mon, Dec 14, 2015 at 8:15 PM, Robert O'Callahan <rob...@ocallahan.org>
wrote:

> On Mon, Dec 14, 2015 at 11:09 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>> This is certainly something one could consider, but it it seems like it
>> confers a major
>> advantage on the vendor vis-a-vis everyone else. If we're going to have
>> an add-on
>> mechanism, I don't see why vendors can't use it too.
>>
>
> I think there's value in being able to plug in a device and have it just
> work on the Web without any extra steps.
>
> Yes, it gives the vendor some privilege, but given the user has chosen to
> buy the vendor's device, I think that's fair. Judgement call again.
>

I certainly agree that this would be better than not allowing third parties
to access devices
at all. I would be more enthusiastic about it if:

(1) There was a simple, standardized, way to write this kind of add-on.
(2) We didn't disclose the origin to the WebUSB device (unlike, say, FIDO)
so that it couldn't discriminate.

-Ekr