<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 20, 2017 at 1:38 PM, Greg KH <span dir="ltr"><<a href="mailto:gregkh@linuxfoundation.org" target="_blank">gregkh@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jan 20, 2017 at 01:18:12PM +0100, Lars Knudsen wrote:<br>
>     > The full device should be fine if it has a WebUSB interface (even in a<br>
>     > composite scenario)<br>
><br>
>     Really?  You want to allow someone "raw" access to a composite device<br>
>     just because of one specific interface?<br>
><br>
>  <br>
> Ideally, I would only allow the browsers running in user space and only the<br>
> WebUSB interface.<br>
> - but would that even be possible on Linux? (now/future).<br>
<br>
</span>I don't know how the browser ends up talking to the USB device in the<br>
first place.  Does it use libusb?  usbfs directly?  Something else?<br>
It all depends on how it is accessing the device for what is needed to<br>
properly set the permissions on it.<br>
<span class=""><br>
> We should remember that devices with a WebUSB interface included were *made*<br>
> for user access (what else would be the point?).<br>
<br>
</span>I agree, but you never know what type of crazy composite device people<br>
will create with this interface type.<br>
<span class=""><br>
> Also: We *do* need a 'blanket' solution for these as manufactures can't always<br>
> wait for the next time all planets align<br>
> and e.g. Ubuntu chooses to upgrade the rules.  Just fyi, last time I was in<br>
> similar discussions in the smae lists, it took<br>
> some years for it to land in Ubuntu:  <a href="https://medium.com/@larsgk/" rel="noreferrer" target="_blank">https://medium.com/@larsgk/</a><br>
> web-enabling-legacy-devices-<wbr>dc3ecb9400ed#.7l1hztlmi<br>
<br>
</span>Nothing I can do about crazy/stupid distros that never want to update<br>
anything, all we can do is provide the solution and hope they wake up<br>
and take it.  Or users will end up moving to a distro that does provide<br>
the correct continuous update model (i.e. Fedora, openSUSE, Arch, etc.)<br></blockquote><div><br></div><div>Actually - there could be a way that would make the process more 'evergreen' </div><div>- you may have already considered it but it came to me in a dream last night,  </div><div>which I found quite magical (he he):</div><div><br></div><div>1. someone plugs in hardware with an unknown VID/PID but CDC capabilities</div><div>2. modemmanager does it's magic probing and finds "this is not a modem"</div><div>3. the VID/PID(& more if needed) + findings is sent to a cloud db ...</div><div>4. if the VID/PID(& more) gets enough votes to be modem/non-modem/other?, it will be registered as such</div><div><br></div><div>every now and then, the DB is spread to e.g. CDN or the like to be picked up by all installations...</div><div><br></div><div>next time someone plugs in the same hardware, it will allready be known</div><div><br></div><div>(this process could probably be expanded to other hardware/udev/etc)</div><div><br></div><div>This way, there is no 'waiting until crazy/stupid distros update' and one could compare the process to how e.g.</div><div>the system time is updated from a time server.</div><div><br></div><div>thoughts?</div><div><br></div><div>br</div><div>Lars</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
thanks,<br>
<br>
greg k-h<br>
</blockquote></div><br></div></div>