Hacker Newsnew | past | comments | ask | show | jobs | submit | ultimatt42's commentslogin

> depending on your OS, an "Arduino.exe" can't even access USB devices without an additional signed driver and/or further administrative privileges

Which OS are you thinking of? WebUSB doesn't need any additional drivers, so if the browser can do it I assume any app can do it.


No, Logitech mice and keyboards generally use Logitech's proprietary HID++ protocol which is built on top of standard HID. WebUSB considers HID a "protected interface class" and blocks access to USB HID interfaces. USB HID devices are protected because they include devices like keyboards which handle sensitive user data, such as passwords.

https://wicg.github.io/webusb/#has-a-protected-interface-cla...

WebHID also restricts access to mice and keyboards, but it uses information available at the HID protocol level to selectively block access to sensitive capabilities while leaving other capabilities unblocked. So, you can't implement an input logger but you can configure LEDs and other device behavior.

In general, WebUSB isn't useful for devices that already have some system-level support. If there's a driver, it will have already claimed the USB interface and needs to release it before the browser can access it. Even if the HID interface class were not protected, you still wouldn't be able to claim it because the USB HID interface is already claimed by the system's generic HID driver. The generic HID driver exposes a non-exclusive "raw" HID interface to applications. WebHID uses this non-exclusive interface which is why it doesn't have the same limitation as WebUSB.


FWIW Mozilla updated their position on Web Serial API to "neutral" and clarified that they might be okay with enabling the API with an add-on.

https://mozilla.github.io/standards-positions/#webserial

Allowing serial but not HID would be really strange. With HID you get standard identifiers that let you filter out devices that are too dangerous for the web. With serial you get nothing. Even if you know a device is dangerous, there's no way to protect users from it.


The site has to request permission to access a device, then the user has to select the device from a permission dialog to grant access.


Good; that's way better than being able to reflash your PS4 controllers with a drive-by.


That's the wrong comparison. We used to only have dedicated POS systems, now we have the option to run POS software on a general purpose computing device. The question is why should that POS software be a native app instead of a web app?


Who says oil can't be produced? I mean, it doesn't make sense to use it as a fuel source since you'd have to put in at least as much energy as you'd be getting back out, but you can still produce it.


There are plenty of standalone apps for videoconferencing. I don't think there's any need to package it with a whiteboard app unless you can come up with an innovative way to integrate the video with the whiteboard (indexing video frames to scribbles, maybe?)

In my experience, having a video feed is pretty much worthless for productivity; if anything, it's distracting. Much more useful is having voice chat and the ability to share files seamlessly. Again, these are needs that can be adequately fulfilled by Google Docs, Google Talk, Skype, etc, so there's no reason to reinvent the wheel.


This is exactly the approach we're going for. We're a distributed team and have been since the start, and over the past two years we've used a variety of weird and wonderful tools to enhance the communication between us.

While video conferencing is nice, we've never found it really adds that much value to our conversations unless we're show & telling. Screen sharing can be useful but it doesn't lend itself well to a fluid two-way conversation (only one person can control a computer/cursor/keyboard at once), and it's generally not instantly available - if we're already talking on the telephone we have to switch tools entirely, and if we're talking to someone outside our team it's pretty much pot luck as to whether they'll already have access to the same services we do.

We wanted something with zero setup. No registration, no downloads/installs, no login.. Maybe when HTML5 is implemented uniformly across all major browsers we can drop the requirement for any 3rd party software at all.

It's an add-on to your existing workflow, rather than a workflow of its own.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: