> And I can't think of any convenient way to do it other than WebUSB.
Simple. Deliver a native application with your device sensor that the user has to install (maybe it could even be automatically installed through PnP). This application would provide a webserver on localhost which exposes the lighting information to interested websites. And in contrast to the WebUSB thing it would mediate the access to the USB device (lots of browser windows and processes can get the information instead of only a single one) and it would guarantee that only the relevant information is forwarded and not arbitrary data on an USB channel.
Installing native applications are not always easy and straight forward especially in a commercial environment or an environment with multiple operating systems. For an enterprise they rarely want to push out new applications to every user because it's a pain to support. But tell them to go to a new web app? Easy.
I'm a big fan of native apps over web app. But web apps have a huge practically that's hard to ignore.
I'm very aware of that, as I have worked for a big corporation with such policies for normal users. However I believe that for them browsers which directly access real hardware will seem like an even bigger nightmare than users installing applications.
And you still have the question on how the web app comes to the user: Through a dedicated intranet site? Makes sense if more than one user requires it, but the effort seems similar as packaging a native application and rolling it out automatically through the ITs deployment system. If only very few users (maybe only a single one) requires that hardware both approaches have a high overhead and supporting the device will be most likely rejected.
Getting this web app directly from a third party site will be mostly out of question for the companies you are talking about. Besides the security implications then we also talk about reliability problems ("I can't use my USB device because internet is down...")
> browsers which directly access real hardware will seem like an even bigger nightmare than users installing applications.
If you look at the spec it doesn't directly access hardware and it even acknowledges doing so could be a big security issue. You interface with an abstraction that sits above the hardware that won't give you direct access but, instead, access to a subset of options that pass through the abstraction.
> Through a dedicated intranet site? Makes sense if more than one user requires it, but the effort seems similar as packaging a native application and rolling it out automatically through the ITs deployment system.
I'm not sure how you can compare the rollout of a native application to all user computers versus publishing within an intranet. They are not even in the same league in terms of deployment. Intranet is far, far easier. The native application has to be pushed out, installed and verified. A web app simply has to have its link emailed to users. Hell you could even push out a bookmark over many IT management systems (which is far easier than dealing with pushing out an application).
Simple. Deliver a native application with your device sensor that the user has to install (maybe it could even be automatically installed through PnP). This application would provide a webserver on localhost which exposes the lighting information to interested websites. And in contrast to the WebUSB thing it would mediate the access to the USB device (lots of browser windows and processes can get the information instead of only a single one) and it would guarantee that only the relevant information is forwarded and not arbitrary data on an USB channel.