On Thursday, December 3, 2015 at 11:49:32 PM UTC-8, Jonas Sicking wrote:
> On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan <r...@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.
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.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
