Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Fri, Jan 20, 2017 at 1:38 PM, Greg KH <gre...@linuxfoundation.org> wrote:

> On Fri, Jan 20, 2017 at 01:18:12PM +0100, Lars Knudsen wrote:
> > > The full device should be fine if it has a WebUSB interface (even
> in a
> > > composite scenario)
> >
> > Really?  You want to allow someone "raw" access to a composite device
> > just because of one specific interface?
> >
> >
> > Ideally, I would only allow the browsers running in user space and only
> the
> > WebUSB interface.
> > - but would that even be possible on Linux? (now/future).
>
> I don't know how the browser ends up talking to the USB device in the
> first place.  Does it use libusb?  usbfs directly?  Something else?
> It all depends on how it is accessing the device for what is needed to
> properly set the permissions on it.
>
> > We should remember that devices with a WebUSB interface included were
> *made*
> > for user access (what else would be the point?).
>
> I agree, but you never know what type of crazy composite device people
> will create with this interface type.
>
> > Also: We *do* need a 'blanket' solution for these as manufactures can't
> always
> > wait for the next time all planets align
> > and e.g. Ubuntu chooses to upgrade the rules.  Just fyi, last time I was
> in
> > similar discussions in the smae lists, it took
> > some years for it to land in Ubuntu:  https://medium.com/@larsgk/
> > web-enabling-legacy-devices-dc3ecb9400ed#.7l1hztlmi
>
> Nothing I can do about crazy/stupid distros that never want to update
> anything, all we can do is provide the solution and hope they wake up
> and take it.  Or users will end up moving to a distro that does provide
> the correct continuous update model (i.e. Fedora, openSUSE, Arch, etc.)
>

Actually - there could be a way that would make the process more
'evergreen'
- you may have already considered it but it came to me in a dream last
night,
which I found quite magical (he he):

1. someone plugs in hardware with an unknown VID/PID but CDC capabilities
2. modemmanager does it's magic probing and finds "this is not a modem"
3. the VID/PID(& more if needed) + findings is sent to a cloud db ...
4. if the VID/PID(& more) gets enough votes to be modem/non-modem/other?,
it will be registered as such

every now and then, the DB is spread to e.g. CDN or the like to be picked
up by all installations...

next time someone plugs in the same hardware, it will allready be known

(this process could probably be expanded to other hardware/udev/etc)

This way, there is no 'waiting until crazy/stupid distros update' and one
could compare the process to how e.g.
the system time is updated from a time server.

thoughts?

br
Lars



> thanks,
>
> greg k-h
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Fri, Jan 20, 2017 at 12:05 PM, Greg KH <gre...@linuxfoundation.org>
wrote:

> On Fri, Jan 20, 2017 at 11:43:24AM +0100, Lars Knudsen wrote:
> >
> >
> > On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie <
> simon.mcvit...@collabora.co.uk
> > > wrote:
> >
> >     On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> > > 2. make sure that webusb devices will be somehow accessible to be
> used by
> > a
> > > browser running with user permissions (current temp solution
> listed here:
> > > adding user to plugdev, adding 0664 permissions to device: https://
> > > developers.google.com/web/updates/2016/03/access-usb-
> devices-on-the-web )
> >
> > > (udev/systemd task).
> >
> > Since I didn't see a response to this: this sounds like a job for
> uaccess.
> > Most things that happened via the plugdev group (on
> Debian/derivatives)
> > 5 or 10 years ago should happen via uaccess now.
> >
> > TAG+="uaccess" in a udev rule results in an ACL being set so that
> > a currently-active logind session on the same seat can read and write
> > the device node.
> >
> >
> > OK thanks!
> >
> >  - so if we can make a rule that consistently detects USB devices with a
> WebUSB
> > interface defined, we should get this in as a standard rule.
>
> Sure, feel free to write the helper binary that will do this.
>
Cool, I am still wondering if we could do it with a script.  Do you have an
example of a binary for udev?
(I am assuming it's a source for a plugin to be shipped with and callable
by udev?)


>
> > Is it possible to give access on an interface level - or would it always
> have
> > to be the full device?
>
> How would you provide userspace access to only one USB interface on
> Linux?
>
The full device should be fine if it has a WebUSB interface (even in a
composite scenario)

br
Lars

>
> thanks,
>
> greg k-h
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie <
simon.mcvit...@collabora.co.uk> wrote:

> On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> > 2. make sure that webusb devices will be somehow accessible to be used
> by a
> > browser running with user permissions (current temp solution listed here:
> > adding user to plugdev, adding 0664 permissions to device: https://
> > developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
> )
> > (udev/systemd task).
>
> Since I didn't see a response to this: this sounds like a job for uaccess.
> Most things that happened via the plugdev group (on Debian/derivatives)
> 5 or 10 years ago should happen via uaccess now.
>
> TAG+="uaccess" in a udev rule results in an ACL being set so that
> a currently-active logind session on the same seat can read and write
> the device node.
>

OK thanks!

 - so if we can make a rule that consistently detects USB devices with a
WebUSB interface defined, we should get this in as a standard rule.

Is it possible to give access on an interface level - or would it always
have to be the full device?

br
Lars


> S
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

If it can be invoked via DBus - what is the harm to only do the scan for
the greylisted (in this case webusb) modems when the user actually wants to
search for a modem (like a printer) - and leave the poor devices alone
otherwise?  In headless systems, it will not be the same problem as they
will most probably be custom made anyway.

On Wed, Jan 11, 2017 at 3:32 PM, Dan Williams <d...@redhat.com> wrote:

> On Wed, 2017-01-11 at 14:21 +0100, Christer Weinigel wrote:
> > On 2017-01-10 19:55, Lars Knudsen wrote:
> > > On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams <d...@redhat.com
> > > <mailto:d...@redhat.com>> wrote:
> > > And we're quite happy to keep blacklisting specific VID/PID
> > > combos we
> > > know are not modems. Another possible solution is to greylist
> > > devices
> > > that happen to have webusb descriptors, such that they won't
> > > get auto-
> > > probed, but could be probed on-demand via D-Bus.  But I'd
> > > rather that
> > > happen via udev rules than MM trying to walk USB device
> > > attributes and
> > > parsing webusb descriptors.
> > >
> > > Actually, that sounds like a very good compromise.  I remember my
> > > own
> > > struggles 3-4 years ago when I had to get a device working properly
> > > on
> > > ChromeOS and Ubuntu, where the firmware had to handle that the
> > > first ~16
> > > seconds it would *sometimes* get sent strange AT commands (the
> > > probing)
> > > all while the system thought it could already start speaking with
> > > the
> > > device over e.g. chrome.serial.  Eventually you (modemmanager) were
> > > kind
> > > enough to get our VID/PID listed and ChromeOS was quick to pick it
> > > up
> > > (~5-6 months to get in stable) and ubuntu so kind to upgrade to the
> > > version of modemmanager including our blacklisting approx 2.5 years
> > > later (sigh) ;)
> >
> > Weird question: should modem manager really autoprobe _every_ serial
> > device nowdays?  99% of the devices I connect to my laptop are not
> > modems.  They are serial ports on development platforms, RS485
> > interfaces, Arduinos with a FTDI, CP210x or CH341 USB-UART bridge,
> > and
> > so on.  Modems with a physical serial port are almost nonexistent
> > today.
> >  For me it's a pain in the back to have to update the blacklist of
> > things modem manger shouldn't touch.
>
> MM does already whitelist platform serial devices (eg, i8250 UART) and
> already greylists USB<->serial adapters like FTDI and CP210x.
>
> Unfortunately, you'd be surprised how many modems actually *do* get
> hooked up with USB<->serial converters like FTDI and CP210x.  Modem
> manufacturers often build these chips into devices so the modem looks
> like USB but uses a generic VID/PID and a generic driver (FTDI).
>
> If you have updates to the blacklist, we'd happily take them.
>
> > Wouldn't it be better to whitelist known ḿodems and have modem
> > manager
> > ignore everything else?  Devices which are so new that modem manager
> > don't know about them can be configured manually.
>
> I ran a list of explicit modem VID/PID pairs in kernel drivers (like
> option, qmi_wwan, sierra, hso, etc) 2 years ago and there were >1000
> known WWAN modems.
>
> That >1000 does *not* count attribute-matched devices like CDC ACM
> devices, CDC WDM/ether, generic serial bridge modems (FTDI/CP210x), or
> USB interface class/subclass/protocol matching which many Huawei
> devices now use instead.  Whitelisting is simply not really an option,
> unfortunately, as too many new modem devices actually do come out every
> year.  Thankfully, many these days are MBIM (thanks to Windows 8+) or
> QMI, but the embedded world still does a lot of serially-bridged
> devices.
>
> Dan
>
> > At least to me that seems like a much more sane default.
> >
> >   /Christer
> > ___
> > ModemManager-devel mailing list
> > modemmanager-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams <d...@redhat.com> wrote:

> On Tue, 2017-01-10 at 18:33 +0100, Greg KH wrote:
> > On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote:
> > >
> > >
> > > On Jan 10, 2017 18:19, "Greg KH" <g...@kroah.com> wrote:
> > >
> > > On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> > > > I figured that made most sense :)
> > > >
> > > > Still, it would be good if we could have a rule to not grab
> > > the CDC
> > > interface
> > > > part if the device includes WebUSB functionality.
> > >
> > > What exactly do you mean by "grab"?
> > >
> > > MM probing :)
> >
> > Probe should be fine, right?  Are you really thinking that MM needs
> > to
> > go "oh look, a cdc device, let's go look at all of the raw interfaces
> > to
> > ensure it really isn't a webusb device as well before I touch it!"
> >
> > That way lies madness...
> >
> > What's wrong with touching it?  The kernel already did, why would
> > userspace care?
>
> And we're quite happy to keep blacklisting specific VID/PID combos we
> know are not modems. Another possible solution is to greylist devices
> that happen to have webusb descriptors, such that they won't get auto-
> probed, but could be probed on-demand via D-Bus.  But I'd rather that
> happen via udev rules than MM trying to walk USB device attributes and
> parsing webusb descriptors.
>

Actually, that sounds like a very good compromise.  I remember my own
struggles 3-4 years ago when I had to get a device working properly on
ChromeOS and Ubuntu, where the firmware had to handle that the first ~16
seconds it would *sometimes* get sent strange AT commands (the probing) all
while the system thought it could already start speaking with the device
over e.g. chrome.serial.  Eventually you (modemmanager) were kind enough to
get our VID/PID listed and ChromeOS was quick to pick it up (~5-6 months to
get in stable) and ubuntu so kind to upgrade to the version of modemmanager
including our blacklisting approx 2.5 years later (sigh) ;)

If greylisting prevents auto-probing, I think it would be very valuable for
devices with a WebUSB header because those will in most cases (as I see
them used) be industrial things (like my current medical company employer)
or IoT devices.  And waiting ~16 seconds for a fallback to USB Serial where
WebUSB is not available (or for other reasons not chosen), can be a real
pain.

I agree that a solid udev rule would be a good way forward (I'll look into
greylisting and see if I can come up with something that covers) and maybe
this could also be the place to do the user space access (or not - I'll try
to come back with something.

thanks for all the input.  Maybe Kenneth, Reilly or some working on USB
related things in Intel have something to add?


>
> Dan
>
> > > > The likelihood of a modem+WebUSB combo is so small that it
> > > must fall
> > > > in the category where potential rare exotic devices combining
> > > it must
> > > > be whitelisted and the rest be left alone.
> > >
> > > I think you misunderstand just how crazy firmware authors can
> > > be.  I'm
> > > sure we will see those types of devices in the wild.
> > >
> > > ...But realistically how many? Bothering 99.9% to support the
> > > special case
> > > seems less logical than just finding the 0.1% and whitelisting it
> > > (if needed)
> >
> > That's the joy of writing an operating system for all devices on the
> > planet, those 0.1% can be a lot of devices :)
> >
> > Anyway, I don't think there's much to do here just yet, let's wait
> > and
> > see just how bad these webusb devices end up looking like...
> >
> > thanks,
> >
> > greg k-h
> > ___
> > ModemManager-devel mailing list
> > modemmanager-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 10, 2017 18:19, "Greg KH" <g...@kroah.com> wrote:

On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> I figured that made most sense :)
>
> Still, it would be good if we could have a rule to not grab the CDC
interface
> part if the device includes WebUSB functionality.

What exactly do you mean by "grab"?

MM probing :)


> The likelihood of a modem+WebUSB combo is so small that it must fall
> in the category where potential rare exotic devices combining it must
> be whitelisted and the rest be left alone.

I think you misunderstand just how crazy firmware authors can be.  I'm
sure we will see those types of devices in the wild.

...But realistically how many? Bothering 99.9% to support the special case
seems less logical than just finding the 0.1% and whitelisting it (if
needed)


> Also (probably more a generic udev/systemd patch) always give user (or at
least
> browser - if that differentiation is possible) access to WebUSB devices.

That's a bit harder as it requires userspace to parse the headers and
"know" to allow access to the device.  I suggest a udev helper program
for it.

good luck,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

I figured that made most sense :)

Still, it would be good if we could have a rule to not grab the CDC
interface part if the device includes WebUSB functionality. The likelihood
of a modem+WebUSB combo is so small that it must fall in the category where
potential rare exotic devices combining it must be whitelisted and the rest
be left alone.

Also (probably more a generic udev/systemd patch) always give user (or at
least browser - if that differentiation is possible) access to WebUSB
devices.

Btw: Afaik, Chromebooks are still using modemmanager, where not even
experts have easy access to creating udev rules

Br
Lars

Br
Lars

On Jan 10, 2017 17:34, "Dan Williams" <d...@redhat.com> wrote:

On Tue, 2017-01-10 at 01:01 +0100, Lars Knudsen wrote:
> On Tue, Jan 10, 2017 at 12:47 AM, Lars Knudsen <lar...@gmail.com>
> wrote:
>
> > A small update:  When the modemmanager finishes probing (~16 secs
> > after
> > connection) data seems to stop flowing in from the WebUSB bulk
> > endpoint
> > also.  It is, however, possible to reconnect and get data again -
> > so I need
> > to see if there should be anything in the mbed firmware causing
> > that
> > behavior or there is some sort of silent reset of
> > interfaces/endpoints
> > happening on the linux side when probing is done.
> >
>
> Had to separate the CDC and WebUSB serial control signals completely
> in the
> firmware driver. - now survives

Yes, if you expose two USB interfaces that can be bound by two
different drivers, then you must expect they could be used
independently.  Not only by MM, but by anything.

Most devices that expose multiple ttys (eg, modems) treat the ttys as
completely separate at the link layer (serial signals) but commands
issued on separate ttys obviously affect internal firmware state
concurrently.

Dan

> >
> > On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen <lar...@gmail.com>
> > wrote:
> >
> > > I finally managed to make a configuration that *seems* to work
> > > and I
> > > realize that I may have had something else blocking the WebUSB
> > > interface
> > > (2) while modemmanager was communicating with the CDC_ACM
> > > interface (1).
> > >
> > > I made a clean arbitrary VID/PID and get what seems to be a
> > > functioning
> > > WebUSB (now) while modemmanager sends "AT...AT..." to the CDC
> > > interface -
> > > so while I thought the modemmanager grabbed my WebUSB interface
> > > part, it
> > > must have been because of a faulty combination on my side - my
> > > apologies.
> > > WebUSB actually *does* seem to give immediate "bulk" access to a
> > > device
> > > otherwise claimed by modemmanager - a very nice option to have
> > > and sorry
> > > for the confusion I had that modemmanager grabbed more interfaces
> > > than it
> > > should have.
> > >
> > > Still, the original request still stands and please tell me if
> > > it's a
> > > viable path:
> > >
> > > 1.  If a device has a WebUSB descriptor, it's most probably *not*
> > > a modem
> > > - and should in stead be considered a device that in this rare
> > > case needs
> > > to be whitelisted (as modem), while defaulting to not being
> > > it.  This is to
> > > ease the usage from non-browsers to the same hardware, which can
> > > then
> > > happen immediately and not be required to fail and wait over the
> > > modemmanager probing period (30 sec?) - related to modemmanager
> > > 2. If a device has a WebUSB descriptor, at least the interface
> > > linked to
> > > WebUSB should be made accessible in user land by default so no
> > > average user
> > > has to figure out how to do udev rules - related to udev/systemd
> > >
> > > my headers that seem to work now for the case above:
> > >
> > > Bus 002 Device 089: ID 1209:d010 InterBiometrics
> > > Device Descriptor:
> > >   bLength18
> > >   bDescriptorType 1
> > >   bcdUSB   2.10
> > >   bDeviceClass0 (Defined at Interface level)
> > >   bDeviceSubClass 0
> > >   bDeviceProtocol 0
> > >   bMaxPacketSize064
> > >   idVendor   0x1209 InterBiometrics
> > >   idProduct  0xd010
> > >   bcdDevice0.01
> > >   iManufacturer   1 empriKit
> > >   iProduct2 empriKit|MOTION
> > >   iSerial 3 00.01
> &

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 10, 2017 07:51, "Greg KH"  wrote:

On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant wrote:
> On 2017-01-09 9:55 am, Greg KH wrote:
> > On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote:
> > > Greg KH  writes:
> > > > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde
Christiansen wrote:
> > > >> Web USB can only grab devices which has special Web USB headers.
It can not
> > > >> grab any USB device.
> > > >>
> > > >> https://wicg.github.io/webusb/#webusb-descriptors
> > > >
> > > > Ah, fun :(
> > > >
> > > > So, we can add a quirk into the kernel cdc-acm driver to never bind
to a
> > > > device that has the wusb platform capability descriptor,
> > >
> > > I fail to see why a quirk should be necessary. New device classes are
> > > expected to use new class/subclass codes distintly different from
> > > anything handled by existing class drivers.
> >
> > One would hope, but it seems like they want to piggy-back on the cdc-acm
> > spec.  But I could be totally wrong here, does anyone have the actual
> > descriptor dump of a device anywhere?
>
> We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
> always have its interfaces marked vendor-specific. Below is an example of
a
> device which implements both a CDC-ACM interface and a WebUSB interface.

Ick, why would you want both interfaces on a device?  Are you going to
allow firmware to talk to both endpoints at the same time?  Why?

Why not just make it a "one interface" type of device?

I work for a medical company, where we are using long lived software and
hardware. Having the option of supporting both WebUSB and USB serial will
allow us to move to pure web and still support legacy platforms.

If we - in stead - were to only have WebUSB or standard CDC, we would force
an impossible break.

Having modemmanager estimating that "this WebUSB device is *probably* not a
modem" and furthermore allowing user access to that device (udev/systems)
would be a huge help in the direction of true PnP for users and
manufacturers.

Yesterday night I finally got WebUSB and MM running in parallel (so..Sorta
halfway there on Linux at least):
https://twitter.com/denladeside/status/818717316443676672


thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Tue, Jan 10, 2017 at 12:47 AM, Lars Knudsen <lar...@gmail.com> wrote:

> A small update:  When the modemmanager finishes probing (~16 secs after
> connection) data seems to stop flowing in from the WebUSB bulk endpoint
> also.  It is, however, possible to reconnect and get data again - so I need
> to see if there should be anything in the mbed firmware causing that
> behavior or there is some sort of silent reset of interfaces/endpoints
> happening on the linux side when probing is done.
>
Had to separate the CDC and WebUSB serial control signals completely in the
firmware driver. - now survives

>
> On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen <lar...@gmail.com> wrote:
>
>> I finally managed to make a configuration that *seems* to work and I
>> realize that I may have had something else blocking the WebUSB interface
>> (2) while modemmanager was communicating with the CDC_ACM interface (1).
>>
>> I made a clean arbitrary VID/PID and get what seems to be a functioning
>> WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface -
>> so while I thought the modemmanager grabbed my WebUSB interface part, it
>> must have been because of a faulty combination on my side - my apologies.
>> WebUSB actually *does* seem to give immediate "bulk" access to a device
>> otherwise claimed by modemmanager - a very nice option to have and sorry
>> for the confusion I had that modemmanager grabbed more interfaces than it
>> should have.
>>
>> Still, the original request still stands and please tell me if it's a
>> viable path:
>>
>> 1.  If a device has a WebUSB descriptor, it's most probably *not* a modem
>> - and should in stead be considered a device that in this rare case needs
>> to be whitelisted (as modem), while defaulting to not being it.  This is to
>> ease the usage from non-browsers to the same hardware, which can then
>> happen immediately and not be required to fail and wait over the
>> modemmanager probing period (30 sec?) - related to modemmanager
>> 2. If a device has a WebUSB descriptor, at least the interface linked to
>> WebUSB should be made accessible in user land by default so no average user
>> has to figure out how to do udev rules - related to udev/systemd
>>
>> my headers that seem to work now for the case above:
>>
>> Bus 002 Device 089: ID 1209:d010 InterBiometrics
>> Device Descriptor:
>>   bLength18
>>   bDescriptorType 1
>>   bcdUSB   2.10
>>   bDeviceClass0 (Defined at Interface level)
>>   bDeviceSubClass 0
>>   bDeviceProtocol 0
>>   bMaxPacketSize064
>>   idVendor   0x1209 InterBiometrics
>>   idProduct  0xd010
>>   bcdDevice0.01
>>   iManufacturer   1 empriKit
>>   iProduct2 empriKit|MOTION
>>   iSerial 3 00.01
>>   bNumConfigurations  1
>>   Configuration Descriptor:
>> bLength 9
>> bDescriptorType 2
>> wTotalLength   90
>> bNumInterfaces  3
>> bConfigurationValue 1
>> iConfiguration  0
>> bmAttributes 0xc0
>>   Self Powered
>> MaxPower  100mA
>> Interface Descriptor:
>>   bLength 9
>>   bDescriptorType 4
>>   bInterfaceNumber0
>>   bAlternateSetting   0
>>   bNumEndpoints   1
>>   bInterfaceClass 2 Communications
>>   bInterfaceSubClass  2 Abstract (modem)
>>   bInterfaceProtocol  1 AT-commands (v.25ter)
>>   iInterface  0
>>   CDC Header:
>> bcdCDC   1.10
>>   CDC Call Management:
>> bmCapabilities   0x03
>>   call management
>>   use DataInterface
>> bDataInterface  1
>>   CDC ACM:
>> bmCapabilities   0x02
>>   line coding and serial state
>>   CDC Union:
>> bMasterInterface0
>> bSlaveInterface 1
>>   Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x81  EP 1 IN
>> bmAttributes3
>>   Transfer TypeInterrupt
>>   Synch Type   None
>>   Usage Type   Data
>> wMaxPacketSize 0x0010  1x 16 bytes
>> bInterval  16
>&

Re: [systemd-devel] WebUSB

[Lars Knudsen]

A small update:  When the modemmanager finishes probing (~16 secs after
connection) data seems to stop flowing in from the WebUSB bulk endpoint
also.  It is, however, possible to reconnect and get data again - so I need
to see if there should be anything in the mbed firmware causing that
behavior or there is some sort of silent reset of interfaces/endpoints
happening on the linux side when probing is done.

On Tue, Jan 10, 2017 at 12:11 AM, Lars Knudsen <lar...@gmail.com> wrote:

> I finally managed to make a configuration that *seems* to work and I
> realize that I may have had something else blocking the WebUSB interface
> (2) while modemmanager was communicating with the CDC_ACM interface (1).
>
> I made a clean arbitrary VID/PID and get what seems to be a functioning
> WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface -
> so while I thought the modemmanager grabbed my WebUSB interface part, it
> must have been because of a faulty combination on my side - my apologies.
> WebUSB actually *does* seem to give immediate "bulk" access to a device
> otherwise claimed by modemmanager - a very nice option to have and sorry
> for the confusion I had that modemmanager grabbed more interfaces than it
> should have.
>
> Still, the original request still stands and please tell me if it's a
> viable path:
>
> 1.  If a device has a WebUSB descriptor, it's most probably *not* a modem
> - and should in stead be considered a device that in this rare case needs
> to be whitelisted (as modem), while defaulting to not being it.  This is to
> ease the usage from non-browsers to the same hardware, which can then
> happen immediately and not be required to fail and wait over the
> modemmanager probing period (30 sec?) - related to modemmanager
> 2. If a device has a WebUSB descriptor, at least the interface linked to
> WebUSB should be made accessible in user land by default so no average user
> has to figure out how to do udev rules - related to udev/systemd
>
> my headers that seem to work now for the case above:
>
> Bus 002 Device 089: ID 1209:d010 InterBiometrics
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.10
>   bDeviceClass0 (Defined at Interface level)
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize064
>   idVendor   0x1209 InterBiometrics
>   idProduct  0xd010
>   bcdDevice0.01
>   iManufacturer   1 empriKit
>   iProduct2 empriKit|MOTION
>   iSerial 3 00.01
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   90
> bNumInterfaces  3
> bConfigurationValue 1
> iConfiguration  0
> bmAttributes 0xc0
>   Self Powered
> MaxPower  100mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   1
>   bInterfaceClass 2 Communications
>   bInterfaceSubClass  2 Abstract (modem)
>   bInterfaceProtocol  1 AT-commands (v.25ter)
>   iInterface  0
>   CDC Header:
> bcdCDC   1.10
>   CDC Call Management:
> bmCapabilities   0x03
>   call management
>   use DataInterface
> bDataInterface  1
>   CDC ACM:
> bmCapabilities   0x02
>   line coding and serial state
>   CDC Union:
> bMasterInterface0
> bSlaveInterface 1
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0010  1x 16 bytes
> bInterval  16
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber1
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass10 CDC Data
>   bInterfaceSubClass  0 Unused
>   bInterfaceProtocol  0
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82  EP 2 IN
> bmAttributes2
>   

Re: [systemd-devel] WebUSB

[Lars Knudsen]

I finally managed to make a configuration that *seems* to work and I
realize that I may have had something else blocking the WebUSB interface
(2) while modemmanager was communicating with the CDC_ACM interface (1).

I made a clean arbitrary VID/PID and get what seems to be a functioning
WebUSB (now) while modemmanager sends "AT...AT..." to the CDC interface -
so while I thought the modemmanager grabbed my WebUSB interface part, it
must have been because of a faulty combination on my side - my apologies.
WebUSB actually *does* seem to give immediate "bulk" access to a device
otherwise claimed by modemmanager - a very nice option to have and sorry
for the confusion I had that modemmanager grabbed more interfaces than it
should have.

Still, the original request still stands and please tell me if it's a
viable path:

1.  If a device has a WebUSB descriptor, it's most probably *not* a modem -
and should in stead be considered a device that in this rare case needs to
be whitelisted (as modem), while defaulting to not being it.  This is to
ease the usage from non-browsers to the same hardware, which can then
happen immediately and not be required to fail and wait over the
modemmanager probing period (30 sec?) - related to modemmanager
2. If a device has a WebUSB descriptor, at least the interface linked to
WebUSB should be made accessible in user land by default so no average user
has to figure out how to do udev rules - related to udev/systemd

my headers that seem to work now for the case above:

Bus 002 Device 089: ID 1209:d010 InterBiometrics
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x1209 InterBiometrics
  idProduct  0xd010
  bcdDevice0.01
  iManufacturer   1 empriKit
  iProduct2 empriKit|MOTION
  iSerial 3 00.01
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   90
bNumInterfaces  3
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xc0
  Self Powered
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass  2 Abstract (modem)
  bInterfaceProtocol  1 AT-commands (v.25ter)
  iInterface  0
  CDC Header:
bcdCDC   1.10
  CDC Call Management:
bmCapabilities   0x03
  call management
  use DataInterface
bDataInterface  1
  CDC ACM:
bmCapabilities   0x02
  line coding and serial state
  CDC Union:
bMasterInterface0
bSlaveInterface 1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval  16
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Mon, Jan 9, 2017 at 7:43 PM, Bjørn Mork <bj...@mork.no> wrote:

> Lars Knudsen <lar...@gmail.com> writes:
>
> > configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK) would:
> >
> > 1) not be considered a modem (it would not make sense to do a modem
> > including webusb headers - in the same device mode at least)
> > 2) provide standard /dev/ttyUSBx serial functionality on the standard CDC
> > endpoints (e.g. interface 1 above)
> > 3) provide full user access to the WebUSB CDC/BULK interface (2 above)
> >
> > What I was asking before is for an example header/configuration
> descriptors
> > where MM would *not* pick up the CDC interface but the system still
> > creating a /dev/ttyUSBx device (or ttyACMx - which it's called when MM is
> > installed) - without creating blacklisting rules specifically for e.g.
> > *that* VID/PID combo.
> > When I was experimenting the last few days - this did not seem
> possible.  I
> > had to completely wipe any indication of this device being CDC before MM
> > stopped claiming it.  Surely, MM should not pick it up if the device
> > indicates it doesn't have call functionality?
>
> This is hard to decipher.
>
> I tend to interprete "a CDC interface" as a "Communications Class
> Interface" as defined by "Universal Serial Bus Class Definitions for
> Communications Devices".  But this makes no sense in the context you are
> using it, so I guess I am misunderstanding?
>
> I don't think any current kernel driver will create /dev/ttyUSBx devices
> for any type of CDC function, so that makes no sense either.
>
> /dev/ttyACMx devices are created by the CDC ACM driver, and has nothing
> to do with MM being installed or not.
>
Thanks for clearing that upi - I was wondering why on some devices we have
without MM, the USB serial devices are called /dev/ttyUSBx until MM is
installed (but maybe it pulls cdc_acm?)

>
> In short: I don't understand anything of the above. I believe the
> requested descriptor samples would clear up some of this.  As would some
> references to the CDC spec if you are going to continue using parts of
> if to describe the device.
>

Ok - one example would be taking e.g. the USBCDC descriptors from mbed:

https://developer.mbed.org/users/mbed_official/code/USBDevice/file/4f589e246b9e/USBSerial/USBCDC.cpp

and adding a bulk WebUSB interface or the ones from Zephyr/Intel:

https://github.com/nagineni/zephyr-webusb/blob/master/samples/usb/webusb/src/webusb_serial.c

(where the webusb interface is added)

I'd like if we by default:

1. assume it's not a modem (I still can't think of any practical examples
where WebUSB descriptors [that requires online] would be added in a modem
[to get online?]) - this would be
2. could have user space access to the endpoints (at least the WebUSB
endpoints - the desired behavior could probably be to have the system
create a serial device on the CDC port andlet the firmware tie the two up
functionality wise, Reilly?) - this is probably udev/systemd

does this make more sense?

br
Lars


>
> Bjørn
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

For all practical reasons and looking ahead, I truly believe that there
will be no reason to have a WebUSB header in any of the few coming modem
devices (what are the stats on new USB CDC modems for these years in
general? - still enough to justify a "blanket claim as modem"?) as having a
functioning/practical webusb header requires an existing internet
connection letting you access the hardware from a trusted URL.

In any case - even if some few would decide to try the combo - the far
majority would not and the same logic (the user can just make a udev
rule...Not sure how to explain my wife how ;)) to whitelist those would be
the logical approach.

Even if it is decided that MM should still try to claim the CDC interface
(which I think would be very wrong as a default in this case), the
remaining WebUSB, custom class (yet CDC style), Bulk interface should be
left untouched and available to user space browsers.

Btw on the Mac, they seem to have fixed it nicely by creating two logical
tty devices and not claiming anything before the user tries to access
either the modem one or pure data one (same physical interface - different
protocol "on demand").

On Jan 9, 2017 19:40, "Dan Williams" <d...@redhat.com> wrote:

> On Mon, 2017-01-09 at 19:22 +0100, Lars Knudsen wrote:
> > On Jan 9, 2017 18:56, "Bjørn Mork" <bj...@mork.no> wrote:
> >
> > > Lars Knudsen <lar...@gmail.com> writes:
> > >
> > > > It seemed like if just one interface in the description list was
> > > > somehow
> > > > compliant with modem manager, the full device seemed claimed.
> > > >
> > > > I may have missed something in my headers while experimenting.
> > > > Can you
> > >
> > > give
> > > > an example of a header structure that will not be assumed to be a
> > > > modem
> > >
> > > by
> > > > MM while still accessible as a proper CDC serial device - without
> > > > blacklisting anything?
> > >
> > > I am slowly starting to wonder if the concern is about composite
> > > devices
> > > where you want a subset of the functions to be used in one context
> > > (MM)
> > > and another subset to be used in another context (WebUSB)?  Is this
> > > correct?
> > >
> >
> > Well, ideally, any WebUSB device that exposes a CDC interface (e.g.
> > configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK)
> > would:
> >
> > 1) not be considered a modem (it would not make sense to do a modem
> > including webusb headers - in the same device mode at least)
> > 2) provide standard /dev/ttyUSBx serial functionality on the standard
> > CDC
> > endpoints (e.g. interface 1 above)
> > 3) provide full user access to the WebUSB CDC/BULK interface (2
> > above)
>
> So I read the spec quickly but clearly not well enough.
>
> Is the separate WebUSB interface parallel to the others in
> functionality?  eg, it's just another conduit for the same information
> as the other interfaces?  Or is it some other completely separate
> protocol?
>
> Let's take two-tty CDC-ACM, one cdc-ether modem normally controlled
> with AT commands, like a Nokia 21M-02.  It exposes 8 interfaces; 3 ttys
> and one ethernet device:
>
> 0 - cdc-acm commc
> 1 - cdc-acm data
> 2 - cdc-acm commc
> 3 - cdc-acm data
> 4 - cdc-acm commc
> 5 - cdc-acm data
> 6 - cdc-ether commc
> 7 - cdc-ether data
>
> Now if that supported webusb, would you have:
>
> 8 - webusb
>
> If that is true, then what is supposed to happen with this modem when
> you plug it in?  Just because it has a WebUSB descriptor, should it be
> automatically "claimed" by a running browser or such, and be
> unavailable to the rest of the system?  Would all the ttys and ethernet
> devs be re-permissioned to the browser user?
>
> Or, could you expand on "it wouldn't make sense" to do a modem with
> WebUSB descriptors?  Why not?
>
> > What I was asking before is for an example header/configuration
> > descriptors
> > where MM would *not* pick up the CDC interface but the system still
> > creating a /dev/ttyUSBx device (or ttyACMx - which it's called when
> > MM is
> > installed) - without creating blacklisting rules specifically for
> > e.g.
> > *that* VID/PID combo.
>
> It depends. If MM is running and MM has been configured to probe
> devices (which can be easily changed with udev rules) then MM will
> probe and claim any device that it determines is a modem, including
> devices that expose ttys that respond to queries like AT+GCAP
> indicating they support WWAN standa

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 9, 2017 18:56, "Bjørn Mork" <bj...@mork.no> wrote:

> Lars Knudsen <lar...@gmail.com> writes:
>
> > It seemed like if just one interface in the description list was somehow
> > compliant with modem manager, the full device seemed claimed.
> >
> > I may have missed something in my headers while experimenting. Can you
> give
> > an example of a header structure that will not be assumed to be a modem
> by
> > MM while still accessible as a proper CDC serial device - without
> > blacklisting anything?
>
> I am slowly starting to wonder if the concern is about composite devices
> where you want a subset of the functions to be used in one context (MM)
> and another subset to be used in another context (WebUSB)?  Is this
> correct?
>

Well, ideally, any WebUSB device that exposes a CDC interface (e.g.
configured with [0]CDC INT, [1]CDC BULK and [2]WebUSB CDC/BULK) would:

1) not be considered a modem (it would not make sense to do a modem
including webusb headers - in the same device mode at least)
2) provide standard /dev/ttyUSBx serial functionality on the standard CDC
endpoints (e.g. interface 1 above)
3) provide full user access to the WebUSB CDC/BULK interface (2 above)

What I was asking before is for an example header/configuration descriptors
where MM would *not* pick up the CDC interface but the system still
creating a /dev/ttyUSBx device (or ttyACMx - which it's called when MM is
installed) - without creating blacklisting rules specifically for e.g.
*that* VID/PID combo.
When I was experimenting the last few days - this did not seem possible.  I
had to completely wipe any indication of this device being CDC before MM
stopped claiming it.  Surely, MM should not pick it up if the device
indicates it doesn't have call functionality?


>
> If so, then I believe you won't be able handle that in a single
> configuration.  If you mix all functions in a single configuration then
> you are correct that MM will take control of the device based on the
> functions it (or the kernel) supports.
>
> Split the function subsets in different configurations and make the OS
> and/or userspace select the active one if you need to support these
> different use cases.  Anything else is going to be an endless mess of
> workarounds and quirk lists all over the place.
>
>
> Bjørn
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

It seemed like if just one interface in the description list was somehow
compliant with modem manager, the full device seemed claimed.

I may have missed something in my headers while experimenting. Can you give
an example of a header structure that will not be assumed to be a modem by
MM while still accessible as a proper CDC serial device - without
blacklisting anything?

BR
Lars

On Jan 9, 2017 18:13, "Bjørn Mork"  wrote:

Greg KH  writes:
> On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen
wrote:
>> Web USB can only grab devices which has special Web USB headers. It can
not
>> grab any USB device.
>>
>> https://wicg.github.io/webusb/#webusb-descriptors
>
> Ah, fun :(
>
> So, we can add a quirk into the kernel cdc-acm driver to never bind to a
> device that has the wusb platform capability descriptor,

I fail to see why a quirk should be necessary. New device classes are
expected to use new class/subclass codes distintly different from
anything handled by existing class drivers.


Bjørn
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Mon, Jan 9, 2017 at 11:39 AM, Greg KH  wrote:

> On Mon, Jan 09, 2017 at 11:29:24AM +0100, Aleksander Morgado wrote:
> > On Mon, Jan 9, 2017 at 11:07 AM, Greg KH  wrote:
> > > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen
> wrote:
> > >> Web USB can only grab devices which has special Web USB headers. It
> can not
> > >> grab any USB device.
> > >>
> > >> https://wicg.github.io/webusb/#webusb-descriptors
> > >
> > > Ah, fun :(
> > >
> > > So, we can add a quirk into the kernel cdc-acm driver to never bind to
> a
> > > device that has the wusb platform capability descriptor, which will
> > > prevent you from having to disconnect the driver from the device (and
> > > the permissions issues involved in that.)
> > >
> > > Would that help out?
> > >
> > > And just do the same thing in modem manager, never grab a device with
> > > this descriptor, and let the browser/webusb handle the control of the
> > > device if it so desires.
> >
> > Not sure anything would be required in ModemManager if the kernel
> > already skips the binding to cdc-acm; i.e. ModemManager won't do
> > anything unless the TTY is exposed.
>
> Great, that was easy then!
>
> So, who is going to send in the kernel patch for this? :)
>

To be sure we don't miss anything, let's give the folks in California a
chance to give their input.

In any case, WebUSB looks very cool and looks like a starting point for
finally getting an easy way (a bit like BLE vs Bluetooth) for average users
connecting USB devices in a secure and cross-platform compliant way to the
web.

br
Lars


>
> thanks,
>
> greg k-h
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

I have som more input - but really need Reilly's comments on this:

As hardware manufacturers most often want to make it possible for users to
use their hardware in a WebUSB setting as well as in a "normal" app mode,
we will most likely see composite devices that could have the following
interfaces defined:

1. INT IF (for std CDC)
2. BULK CDC (non-webusb - e.g. for normal serial port bindings)
3. WebUSB CDC/bulk

In this case - ideally - the system should be allowed to grab 1 and 2 (but
most probably not modemmanager - as it's very unlikely that a modem will be
a webusb device.. as webusb devices assume internet) but leave 3 untouched
(unclaimed) for WebUSB bulk communication.  This means that the udev rules
need to be made on an interface level and not "blanket cover" the whole
device.

Beware that I might not be 100% correct on these assumptions and really
need some input on the intentions from Reilly or others with more knowledge
in the area (let's give California time to wake up :))

br
Lars


On Mon, Jan 9, 2017 at 11:29 AM, Aleksander Morgado <
aleksan...@aleksander.es> wrote:

> On Mon, Jan 9, 2017 at 11:07 AM, Greg KH  wrote:
> > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen
> wrote:
> >> Web USB can only grab devices which has special Web USB headers. It can
> not
> >> grab any USB device.
> >>
> >> https://wicg.github.io/webusb/#webusb-descriptors
> >
> > Ah, fun :(
> >
> > So, we can add a quirk into the kernel cdc-acm driver to never bind to a
> > device that has the wusb platform capability descriptor, which will
> > prevent you from having to disconnect the driver from the device (and
> > the permissions issues involved in that.)
> >
> > Would that help out?
> >
> > And just do the same thing in modem manager, never grab a device with
> > this descriptor, and let the browser/webusb handle the control of the
> > device if it so desires.
>
> Not sure anything would be required in ModemManager if the kernel
> already skips the binding to cdc-acm; i.e. ModemManager won't do
> anything unless the TTY is exposed.
>
> --
> Aleksander
> https://aleksander.es
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Lars Knudsen]

On Jan 9, 2017 10:53, "Mantas Mikulėnas" <graw...@gmail.com> wrote:

On Mon, Jan 9, 2017 at 11:20 AM, Lars Knudsen <lar...@gmail.com> wrote:

Hi,

I am currently looking into how we can make using WebUSB devices less
painful for users on Linux.

The main purpose of WebUSB (as far as I can see) is to enable certain CDC
(in particular - but not limited to) devices communicate directly with
browsers visiting certain trusted sites (listed inside a binary object
store - sent on initial handshake).

The spec is here: https://wicg.github.io/webusb/ (already running fine in
chrome stable)
Examples:
https://www.youtube.com/watch?v=Z1Nk2hH2wFE
https://www.youtube.com/watch?v=o7wGt9RfHVA
https://twitter.com/denladeside/status/817451203076427783

I'm guessing the solution will consist of 2 parts:

1. make sure no WebUSB device is picked up by modemmanager (modemmanager
task)

2. make sure that webusb devices will be somehow accessible to be used by a
browser running with user permissions (current temp solution listed here:
adding user to plugdev, adding 0664 permissions to device:
https://developers.google.com/web/updates/2016/03/access-
usb-devices-on-the-web )  (udev/systemd task).

For 2. we need to either making all webusb devices accessible or find some
other way the browsers can - in a generic way - gain access.  In all cases,
it's important that no USB interfaces has been pre-claimed by the system
(e.g. by cdc_acm) or it should be possible for the browser to throw off the
claims.


I'm not sure how ModemManager could possibly avoid claiming a device based
on a website visit that will happen *sometime in the future*, if ever.

It is in the USB descriptors. Should be easy to do a clean detection. It is
not likely anyone would ever make a modem with webusb descriptors.


As for permissions, uaccess might work if the device types are known (see
e.g. the Yubikey udev rules), but... somehow, it sounds like webapps will
end up being more privileged than local software, a bit odd.

-- 
Mantas Mikulėnas <graw...@gmail.com>
-- 

Mantas Mikulėnas <graw...@gmail.com>
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] WebUSB

[Lars Knudsen]

Hi,

I am currently looking into how we can make using WebUSB devices less
painful for users on Linux.

The main purpose of WebUSB (as far as I can see) is to enable certain CDC
(in particular - but not limited to) devices communicate directly with
browsers visiting certain trusted sites (listed inside a binary object
store - sent on initial handshake).

The spec is here: https://wicg.github.io/webusb/ (already running fine in
chrome stable)
Examples:
https://www.youtube.com/watch?v=Z1Nk2hH2wFE
https://www.youtube.com/watch?v=o7wGt9RfHVA
https://twitter.com/denladeside/status/817451203076427783

I'm guessing the solution will consist of 2 parts:

1. make sure no WebUSB device is picked up by modemmanager (modemmanager
task)

2. make sure that webusb devices will be somehow accessible to be used by a
browser running with user permissions (current temp solution listed here:
adding user to plugdev, adding 0664 permissions to device:
https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
)  (udev/systemd task).

For 2. we need to either making all webusb devices accessible or find some
other way the browsers can - in a generic way - gain access.  In all cases,
it's important that no USB interfaces has been pre-claimed by the system
(e.g. by cdc_acm) or it should be possible for the browser to throw off the
claims.

thoughts?

br
Lars
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel