Platform Capability Descriptor / Binary Object Store

[mon]

Hey there! I'm currently designing a USB keyboard based LUFA project, and all is going well. However, since Chrome is dropping support for Chrome web apps next year, my configuration app needs to move to a different setup.

WebUSB looks like a promising solution, but it requires some descriptor fiddling for access control, otherwise any website could play with your USB devices. This requires a Platform Capability Descriptor which is part of the Binary Object Store in the descriptor table - these are both new terms to me, but I think I understand how they work in the grand scheme of things.

I've done some searching and I can't seem to find anything in LUFA for creating these descriptor entries. No worries if this is the case, I can just use raw bytes and the right IDs for everything. But I figured I'd check I'm not missing something to make a pretty solution full of useful macros and named structs.

[Dean Camera]

Interesting! I haven't looked at the Chrome USB extensions before - I can see the use case, but something always makes me nervous about exposing local devices to internet browsers like that. Sounds like a good way to siphon off other's data or exploit weaknesses in the host's USB stack.

LUFA doesn't currently have any examples using, or definitions of, the WebUSB Platform Compatibility Descriptors - but if you make one, I'd love to include it for other's benefit. Making your own descriptor definition should be easy using their specification and the existing LUFA descriptor definitions as a template (see https://github.com/abcminiuser/lufa/blob/master/LUFA/Drivers/USB/Core/StdDescriptors.h). Basically, you'd just make your own struct with the appropriate entries, then fill it out in your project's Descriptors.c file and link it up to the stack via the USB_GetDescriptor callback (also in Descriptors.c).

Cheers!

- Dean

--
You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lufa-support...@googlegroups.com.
To post to this group, send email to lufa-s...@googlegroups.com.
Visit this group at https://groups.google.com/group/lufa-support.
For more options, visit https://groups.google.com/d/optout.

[mon]

The security seems fairly well thought out, actually - the descriptor explicitly specifies the domain names which are allowed to use a particular report, and the user requires an extra confirmation on top of that.

It might end up a bit more complex than just a descriptor - the Microsoft specific descriptor stuff comes through in a Feature Request. Haven't got it to work yet but I think I'm on the right track. Will definitely clean it up and make a pull request if I get it sorted.

Another pain point is the requirement to use USB 2.1 instead of just 2.0. When I change the USBSpecification to VERSION_BCD(2,1,0), the device fails to enumerate. Whatever stack the Arduino uses seems to get away with a version number change too, so I imagine I'm not responding to BOS requests correctly.

I'll keep you up to date!

[mon]

The problem with BOS descriptors is there's potentially 3 nested variable length arrays you need to account for - I've just been reminded that it is illegal to have an array of structs each containing a variable length array. In hindsight this is of course obvious. The final implementation for this will look similar to the Report datatype - an array of bytes with convenience macros to populate them.

[Paul Stoffregen]

WebUSB looks like a perfect storm for a future filled with bricked
products. Does anyone really believe manufacturers of specialty USB
devices are really going to properly and reliably maintain web service
infrastructure after their products' commonly short product life
cycles? The well known brands like Startech & Siig & Belkin don't
maintain even basic product archive pages for download of drivers and
manuals for their discontinued products.

[mon]

I agree with your concerns - it's far easier to archive a driver blob than a website which potentially grabs config dynamically through AJAX or similar.

However, for "hobby grade" projects like mine, it's a tremendous feature to have access to. Using the MS OS 2.0 descriptor for Windows I can get driverless configuration on all operating sytems. Because WebUSB simply exposes a standard endpoint, I can also develop native apps that can configure the device offline. Publishing source for both of these on Github (hopefully) extends the longevity of the device should I disappear.

[Nick Moore]

However, for "hobby grade" projects like mine, it's a tremendous feature to have access to. Using the MS OS 2.0 descriptor for Windows I can get driverless configuration on all operating sytems. Because WebUSB simply exposes a standard endpoint, I can also develop native apps that can configure the device offline. Publishing source for both of these on Github (hopefully) extends the longevity of the device should I disappear.

G'day Mon, did you ever have any luck with this?

-----Nick

[mon]

I have an ongoing pull request here: https://github.com/abcminiuser/lufa/pull/91

It works fine, but the onus is on me to clean it up before it will be accepted. I haven't really had the time to make things nicer, but feel free to use my fork if you'd like to use these features.

[Nick Moore]

Wow, thanks, I hadn't seen your PR.  I'll try and get my head around it ... This whole descriptor thing is seriously terrifying :-). 

 

It makes me wonder if it wouldn't be a better approach to have some other program take descriptors in a more suitable markup language and compile them  down to binary blobs in .h files.   I did find https://github.com/zonque/USBDescriptorKitchen

which isn't totally unlike that idea ...

[Benjamin Riggs]

I took a slightly different approach to WebUSB support: https://github.com/abcminiuser/lufa/pull/101 (This message prompted me to clean it up for a PR, so thanks!)

However, I haven't done any Windows integration, if that's what you're looking for.

Also, if you want to make a WebUSB device, it turns out Chrome no longer actually cares if you comply with the WebUSB spec. As of version 61, Chrome is more than happy to grab any USB device it can get ahold of.