Intent to Implement: WebUSB API

[λ Ken Rockot]

Contact emails rei...@chromium.org,roc...@chromium.org Spec Editor's draft: http://reillyeon.github.io/webusb/ Summary The web platform API to support programming USB devices.

This gives developers the ability to enumerate devices, claim device interfaces, and initiate low-level I/O in the form of bulk, interrupt, isochronous, and control transfers. Motivation To give hardware vendors the ability to develop and deliver hardware drivers on the open web platform.

Compatibility Risk Firefox: No public signals Internet Explorer: No public signals Safari: No public signals Web developers: No signals

There have been past public discussions about a WebUSB API for other browsers, but there has been no perceivable progress on any of those fronts. We intend to initiate a public discussion around this proposal and reach a consensus among any interested vendors.

Describe the degree of compatibility risk you believe this change poses We believe the compatibility risk in adding this to Blink is relatively low. USB is an established hardware protocol with a well-defined scope of operations, and there are currently no other web platform features or proposals in active development which aim to provide overlapping functionality.

Ongoing technical constraints None. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Initially we will target all platforms except Android/WebView because at the moment there are relatively few practical use cases for Android devices acting as USB hosts. We do intend to support Android and WebView eventually.

OWP launch tracking bug https://crbug.com/492204 Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/5651917954875392 Requesting approval to ship? No. Runtime flag only, at the moment.

[PhistucK]

Can such an API crash the entire system? If so, what do you intend to do to prevent that?

☆PhistucK

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

[λ Ken Rockot]

On Tue, May 26, 2015 at 9:34 AM, PhistucK <phis...@gmail.com> wrote:

Can such an API crash the entire system? If so, what do you intend to do to prevent that?

Only insofar as any other API can crash the entire system. The implementation runs entirely in user space.

[Rick Byers]

I believe this is an important capability for the platform, thanks for pushing on it!  For example, in input it's infuriating that we're the gate keepers for exposing new input technologies to the web.  I really want to enable innovation in input to happen on the web platform without being gated on the browser developer / standards organization.  I assume this would provide a path, for example, for a web application to support input via a leap motion device.

The biggest challenge I think is the security/privacy implications.  Eg. presumably unrestricted access to my USB flash drive and USB webcam are something we need to carefully control.  Can you point to any thinking around the permissions model?

Thanks,

   Rick

[David Tapuska]

Can this be used as a channel between two isolated processes? Is it possible for intentionally insert a USB device into a persons PC without them knowing that advertises a USB device as allowed from the * origin; and all it does is transfer data from that process to another to accomplish something malicious?

Are there any privacy concerns here? Specifically around the serial number being able to be read and user tracking? Sure it is white-listed domains but perhaps some vendor gives you a discount if you connect this "USB device" to your computer (kind of like the insurance company car discounts).

[Reilly]

On Tuesday, May 26, 2015 at 10:57:55 AM UTC-7, David Tapuska wrote:

Can this be used as a channel between two isolated processes? Is it possible for intentionally insert a USB device into a persons PC without them knowing that advertises a USB device as allowed from the * origin; and all it does is transfer data from that process to another to accomplish something malicious?

Yes, but other APIs, such as web messaging, can already be used to carry data across origins. This can also be mitigated by requiring that an origin gain explicit permission before it can access a device (even though it is whitelisted).

 

Are there any privacy concerns here? Specifically around the serial number being able to be read and user tracking? Sure it is white-listed domains but perhaps some vendor gives you a discount if you connect this "USB device" to your computer (kind of like the insurance company car discounts).

The privacy concern is one of the reasons for whitelisting. Requiring the user to connect a device to their system seems similar to requiring that they log in. For example, a page in incognito mode requesting to connect to a device would require user permission to be regranted.

 

On Tue, May 26, 2015 at 12:51 PM, 'λ Ken Rockot' via blink-dev <blin...@chromium.org> wrote:

On Tue, May 26, 2015 at 9:34 AM, PhistucK <phis...@gmail.com> wrote:

Can such an API crash the entire system? If so, what do you intend to do to prevent that?

Only insofar as any other API can crash the entire system. The implementation runs entirely in user space.

 

☆PhistucK

On Tue, May 26, 2015 at 7:31 PM, 'λ Ken Rockot' via blink-dev <blin...@chromium.org> wrote:

Contact emails rei...@chromium.org,rockot@chromium.org Spec Editor's draft: http://reillyeon.github.io/webusb/ Summary The web platform API to support programming USB devices.

This gives developers the ability to enumerate devices, claim device interfaces, and initiate low-level I/O in the form of bulk, interrupt, isochronous, and control transfers. Motivation To give hardware vendors the ability to develop and deliver hardware drivers on the open web platform.

Compatibility Risk Firefox: No public signals Internet Explorer: No public signals Safari: No public signals Web developers: No signals

There have been past public discussions about a WebUSB API for other browsers, but there has been no perceivable progress on any of those fronts. We intend to initiate a public discussion around this proposal and reach a consensus among any interested vendors.

Describe the degree of compatibility risk you believe this change poses We believe the compatibility risk in adding this to Blink is relatively low. USB is an established hardware protocol with a well-defined scope of operations, and there are currently no other web platform features or proposals in active development which aim to provide overlapping functionality.

Ongoing technical constraints None. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Initially we will target all platforms except Android/WebView because at the moment there are relatively few practical use cases for Android devices acting as USB hosts. We do intend to support Android and WebView eventually.

OWP launch tracking bug https://crbug.com/492204 Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/5651917954875392 Requesting approval to ship? No. Runtime flag only, at the moment.

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

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

[Mark Pilgrim]

On Tuesday, May 26, 2015 at 2:28:58 PM UTC-4, Reilly wrote:

The privacy concern is one of the reasons for whitelisting. Requiring the user to connect a device to their system seems similar to requiring that they log in. For example, a page in incognito mode requesting to connect to a device would require user permission to be regranted.

Cool, so we've reinvented dongles.

[Elliott Sprehn]

This spec has NoInterfaceObject on nearly every interface which doesn't look correct. Please define constructors for all the simple types and remove it from the others.

[Jochen Eisinger]

+Adrienne Porter Felt did this get security reviewed yet?

[Jeffrey Yasskin]

Note that [[NoInterfaceObject]] doesn't mean "no platform-accessible
constructors" or even "no interface object", it means "no .constructor
property and not exposed on Window":
http://heycam.github.io/webidl/#interface-prototype-object. What's the
benefit of adding properties to Window for each interface in the spec?

[Domenic Denicola]

That's not quite correct. It means no interface object: http://heycam.github.io/webidl/#NoInterfaceObject

> it indicates that an interface object will not exist for the interface in the ECMAScript binding.

I don't think that's how it's implemented in Blink, but that's how it's specced.

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

[Jeffrey Yasskin]

On Tue, May 26, 2015 at 11:55 AM, Domenic Denicola <d...@domenic.me> wrote:
> That's not quite correct. It means no interface object: http://heycam.github.io/webidl/#NoInterfaceObject
>
>> it indicates that an interface object will not exist for the interface in the ECMAScript binding.

And yet "There must exist an interface prototype object for every
non-callback interface defined, regardless of whether the interface
was declared with the [NoInterfaceObject] extended attribute." from
http://heycam.github.io/webidl/#interface-prototype-object. Mine has a
MUST, while yours is just descriptive. Maybe an "interface object"
isn't the same as an "interface prototype object", but then I have to
ask what an "interface object" is.

[λ Ken Rockot]

I suppose it allows someone else to reinvent dongles? Maybe the login analogy unintentionally alluded to that, but it's not really one of the target use cases we're focusing on.

[Adrienne Porter Felt]

It's been discussed in passing but we haven't started an actual review. Now is a good time to start. Reilly/Ken, can you please e-mail chrome-secu...@google.com with your docs to get that started?

[λ Ken Rockot]

On Tue, May 26, 2015 at 11:38 AM, Elliott Sprehn <esp...@chromium.org> wrote:

This spec has NoInterfaceObject on nearly every interface which doesn't look correct. Please define constructors for all the simple types and remove it from the others.

I don't understand why it's incorrect to use NoInterfaceObject on these types, but that's probably because I still don't understand the semantics of NoInterfaceObject, even given the discussion and links posted here. These interfaces are all for objects which can only meaningfully be constructed by the platform embedder. Is that irrelevant?

[Boris Zbarsky]

On 5/26/15 3:00 PM, Jeffrey Yasskin wrote:
> Maybe an "interface object" isn't the same as an "interface prototype object"

It's not.

> but then I have to ask what an "interface object" is.

Let me try to illustrate by example: Node.prototype is the "interface
prototype object" for the "Node" interface. The "interface object" for
that interface is Node.

If the interface has a constructor, the "interface object" has a
[[Construct]] (well, [[Call]], but that's likely to change) that does
whatever the specification says to do for that constructor. This is
why, for example "new Event" works: window.Event is the interface object
for the "Event" interface and has a [[Construct]] that does the right
things.

As Domenic notes, [NoInterfaceObject] means that the interface object
does not exist. This is noted in
http://heycam.github.io/webidl/#NoInterfaceObject as descriptive text
and more explicit in http://heycam.github.io/webidl/#es-interfaces which
talks about when the interface object _does_ exist: when the interface
is a non-callback interface not declared with [NoInterfaceObject] or
when it's a callback interface with constants.

So [NoInterfaceObject] does in fact mean "no platform-accessible
constructors" (unless [NamedConstructor] is used) and "no interface object".

> What's the benefit of adding properties to Window for each interface
> in the spec?

Two things come to mind offhand:

1) It allows instanceof tests.

2) It allows getting hold of the prototype to extend it without having
to get your hands on an actual instance.

-Boris

[Ken Rockot]

On Tue, May 26, 2015 at 12:17 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> What's the benefit of adding properties to Window for each interface
> in the spec?

Two things come to mind offhand:

1) It allows instanceof tests.

2) It allows getting hold of the prototype to extend it without having to get your hands on an actual instance.

-Boris

I think I see. So it sounds like the absence of NoInterfaceObject does not imply "must have a platform-accessible constructor" (e.g., new USBDevice() could still throw a TypeError) Correct? The benefits of having an interface object make sense, so we'll update the IDL.

[Boris Zbarsky]

On 5/26/15 3:26 PM, Ken Rockot wrote:
> So it sounds like the /absence /of NoInterfaceObject does
> /not/ imply "must have a platform-accessible constructor" (e.g., new

> USBDevice() could still throw a TypeError) Correct?

Correct. In fact, it will do so unless you explicitly define a
constructor for the interface.

-Boris

[Jeffrey Yasskin]

On Tue, May 26, 2015 at 12:17 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 5/26/15 3:00 PM, Jeffrey Yasskin wrote:
>>
>> Maybe an "interface object" isn't the same as an "interface prototype
>> object"
>
>
> It's not.
>
>> but then I have to ask what an "interface object" is.
>
>
> Let me try to illustrate by example: Node.prototype is the "interface
> prototype object" for the "Node" interface. The "interface object" for that
> interface is Node.

Ah, thanks for correcting me.

> As Domenic notes, [NoInterfaceObject] means that the interface object does
> not exist. This is noted in
> http://heycam.github.io/webidl/#NoInterfaceObject as descriptive text and
> more explicit in http://heycam.github.io/webidl/#es-interfaces which talks
> about when the interface object _does_ exist: when the interface is a
> non-callback interface not declared with [NoInterfaceObject] or when it's a
> callback interface with constants.

This is nitpicky, but http://heycam.github.io/webidl/#es-interfaces
talks about a *property* existing whose value is the interface object.
It's consistent for the interface object to exist but not be exposed
to user code.

It's only Domenic's citation
(http://heycam.github.io/webidl/#NoInterfaceObject) that insists on
something that can't be implemented in Javascript, but I believe
violating that is unobservable, so implementations can do it anyway.

> So [NoInterfaceObject] does in fact mean "no platform-accessible
> constructors" (unless [NamedConstructor] is used) and "no interface object".

Sorry, in my head "platform-accessible" means that the implementation
of the platform can access the constructor, not that the constructor
is exposed to users of the platform. I believe you read it as "the
platform makes a constructor accessible"

>> What's the benefit of adding properties to Window for each interface
>> in the spec?
>
> Two things come to mind offhand:
>
> 1) It allows instanceof tests.
>
> 2) It allows getting hold of the prototype to extend it without having to
> get your hands on an actual instance.

Yep, so for each interface that Elliott wants to expose, wouldn't it
make sense to see whether these properties make sense? They might, but
they also imply taking another name from the global namespace, so it's
not totally obvious that tradeoff always goes the same way.

Thanks,
Jeffrey

[Boris Zbarsky]

On 5/26/15 4:53 PM, Jeffrey Yasskin wrote:
> This is nitpicky, but http://heycam.github.io/webidl/#es-interfaces
> talks about a *property* existing whose value is the interface object.

Sure. In particular, the normative requirements are that if
[NoInterfaceObject] then per
http://heycam.github.io/webidl/#es-interfaces there is no corresponding
property on the global and per
http://heycam.github.io/webidl/#interface-prototype-object there is no
.constructor property on the relevant interface prototype object.

> It's consistent for the interface object to exist but not be exposed
> to user code.

Well, if it exists but there's no way to detect that, then that's
black-box equivalent to it not existing, so sure.

> It's only Domenic's citation
> (http://heycam.github.io/webidl/#NoInterfaceObject) that insists on
> something that can't be implemented in Javascript

In what sense can it not be implemented in JavaScript any more than
anything else in the web platform?

A [NoInterfaceObject] interface is just like using Object.create() to
create the prototype object, without setting its .constructor to
anything at all.

> but I believe
> violating that is unobservable, so implementations can do it anyway.

Implementations can always do anything that's unobservable, yes.

>> So [NoInterfaceObject] does in fact mean "no platform-accessible
>> constructors" (unless [NamedConstructor] is used) and "no interface object".
>
> Sorry, in my head "platform-accessible" means that the implementation
> of the platform can access the constructor, not that the constructor
> is exposed to users of the platform. I believe you read it as "the
> platform makes a constructor accessible"

Yes, indeed. The implementation of the platform can obviously do
whatever it wants. ;)

>> Two things come to mind offhand:
>>
>> 1) It allows instanceof tests.
>>
>> 2) It allows getting hold of the prototype to extend it without having to
>> get your hands on an actual instance.
>
> Yep, so for each interface that Elliott wants to expose, wouldn't it
> make sense to see whether these properties make sense?

Sure, but #2 generally makes sense for pretty much everything in my
experience.

-Boris

[Ojan Vafai]

+1. I agree it's unfortunate that we keep polluting the global scope, but I think it's a necessary evil until we have a reasonable solution involving modules/imports.

In my view, the idea situation would be that you need to import WebUSB to be able to use it and that the import would let you declare a namespace (or something) to avoid polluting the global scope. I haven't been following the state of JS modules to see if they could actually help address this problem though.

[Jeffrey Yasskin]

On Tue, May 26, 2015 at 2:06 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 5/26/15 4:53 PM, Jeffrey Yasskin wrote:
>>
>> This is nitpicky, but http://heycam.github.io/webidl/#es-interfaces
>> talks about a *property* existing whose value is the interface object.
>
>
> Sure. In particular, the normative requirements are that if
> [NoInterfaceObject] then per http://heycam.github.io/webidl/#es-interfaces
> there is no corresponding property on the global and per
> http://heycam.github.io/webidl/#interface-prototype-object there is no
> .constructor property on the relevant interface prototype object.

Yep, I think we agree.

>>> Two things come to mind offhand:
>>>
>>> 1) It allows instanceof tests.
>>>
>>> 2) It allows getting hold of the prototype to extend it without having to
>>> get your hands on an actual instance.
>>
>>
>> Yep, so for each interface that Elliott wants to expose, wouldn't it
>> make sense to see whether these properties make sense?
>
>
> Sure, but #2 generally makes sense for pretty much everything in my
> experience.

Thanks for acknowledging the tradeoff. This makes a lot more sense
than previous reasons I'd been given for avoiding
[[NoInterfaceObject]].

[Nikolay Soserov]

Economic Survey of nepal 2015-16 - English 412 página Para obtener acceso ilimitado y la ...