-
esphome
ESPHome is a system to control your ESP8266/ESP32 by simple yet powerful configuration files and control them remotely through Home Automation systems.
ESPHome uses WebSerial[2] to flash microcontrollers via the browser, saving the user from having to install a whole development environment and whatnot to do the initial firmware upload.
Super slick from a user POV, just connect the device via USB cable and hit the flash button. I admit I was a bit skeptical to all this, but having just tried it I must admit it was very, very convenient.
[1]: https://esphome.io/
[2]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_...
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
file-system-access
Expose the file system on the user’s device, so Web apps can interoperate with the user’s native applications.
Regarding File System Access I notice that [1]:
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
[1]: https://wicg.github.io/file-system-access/
-
WebUSB is not finalised in any way. It’s a WICG draft (draft means not finalised, and WICG means explicitly unofficial), with only one shipping implementation in browsers. (There’s also an implementation for Node.js, but I think that’s considered irrelevant.) My recollection of the rough processes is that to become a Candidate Recommendation (which is the first stage you could reasonably argue “finalised spec” corresponds to) it would need at least a second shipping implementation, and to be adopted by a working group.
As it stands, there’s no short-term prospect of a second implementation: Mozilla’s current position is that WebUSB is harmful because it’s super dangerous and the risks can’t be adequately explained, and is a tracking hazard <https://mozilla.github.io/standards-positions/#webusb>, and WebKit have likewise consciously decided not to implement WebUSB for similar reasons (“due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns”) <https://webkit.org/tracking-prevention/#anti-fingerprinting>.
That multiple browsers use the same engine and implementation is irrelevant for standardisation—otherwise Chromium would be the very definition of the standards. To show this even more clearly, WebSQL was scuttled because everyone used SQLite and there was no satisfactory way of specifying what would be permitted.
-
They probably use WCID, which is a mechanism for devices to tell Windows that they are compatible with the generic WinUSB driver. Zadig is useful for older versions of windows, non-WCID devices, and when you want to override that auto-specified driver.
Here's more information from the author of Zadig: https://github.com/pbatard/libwdi/wiki/WCID-Devices
-
Limiting it to installed apps still has the problem of users blindly agreeing to something that is fundamentally super dangerous. I don’t believe installing PWAs currently exposes any new security surface, so this would be a significant change, and worse still a persistent hazard with probably no indication of what’s going on when it’s in use. I think there’s still potential in the general concept, but it’d take work and is certainly not ready yet in any browser.
Yes, certain classes are restricted from access via WebUSB for security, https://wicg.github.io/webusb/#protected-interface-classes. But as the note says, it’s about balance: that list is necessary for security, but not sufficient.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives