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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
