11 ms·

WebUSB is dead

63 points by hatemben 7y ago

oceanghost 7y ago
About ten years ago, I wrote an IE/win7 plugin that broke the security model of IE to allow the browser to communicate with a USB device (in this case, a remote control). It was a nasty, nasty hack, and things like this shouldn't be allowed. Management insisted that our product have a web-interface because they had information that our competitor was going from desktop apps to web apps. Ironically, our competitor was never able to get its web interface working.
anderspitman 7y ago
I find the push to turn web browsers into VMs for running sandboxed JavaScript/WebAssembly applications fascinating. WebUSB, WebGPU, WebTransport, etc etc. I think it's really cool, and enables cool things, but I have 1 problem with it. I wish we separated the browser application from the VM application. ie, let us make simple, secure content with HTML and minimal CSS. For things like Wikipedia and even a lot of YouTube that's all you need. People can use an extremely simple (and private/secure!) program to access this kind of content. A text version of my personal site is browsable with cURL or even netcat[0]. Make the VM a separate program that people use for fancy web apps. [0]: https://anderspitman.net/19/#netcatable https://anderspitman.net/19/#netcatable
- ar-nelson 7y ago
  This is how the Web was originally designed, which is why we had Flash and Java applets. But it's hard to make those VMs secure, and yet somehow it's been easier to keep modern browsers reasonably secure as they keep adding features.
  - anderspitman 7y ago
    One problem is that browser vendors are using the complexity of modern browsers to create an oligopoly. When even Microsoft doesn't want to maintain their own browser, something is wrong. A simple browser that only implemented a subset of HTML and the good parts of CSS (ie flexbox) could be implemented easily by a small team.
    - api 7y ago
      The driver is the desire by web app builders to build more and more niftiness into web apps. The browser vendors and standards bodies are attempting to satisfy this desire and that's leading down a path that is having the effect of creating an oligopoly because a browser must become this enormous OS-inside-an-OS. I don't think it's a conspiracy. Most things that look like conspiracies are in fact unplanned outcomes that result from an unintentional alignment of multiple perverse incentives. A different way of saying the same is that most things that appear to be conspiracies are actually "emergent" behaviors in complex systems. A different example of something similar is real estate hyperinflation. I don't think somebody sat down and said "lets make housing impossible for any family making less than 5X the local median income to reasonably afford." What happened instead was that multiple decisions made for independent and unrelated reasons created an aligned set of perverse incentives that drove the price of housing nuts. There is no one cause or one responsible party.
      - redwall_hp 7y ago
        Flash reached a point where it was basically unmaintainable spaghetti, and not something that was going to be trivially reimplemented by a third party. Sadly, that's exactly what's happening to the Web now. Instead of being standards-first, and browsers implement it, we've basically shifted to descriptive standards that attempt to formalize what a corporate cabal unilaterally decides. And we're in inch away from a homogeny of browser engines...
        bawolff 7y ago
        Well multilaterally decide. Its a small group but firefox isnt totally irrelavent yet. And thats ok in my opinion. The IETF describes itself as "rough consensus and running code" and it seems to work well. I dont have a problem with the web following that model.
      - anderspitman 7y ago
        You're not wrong, but people have been pointing these issues out for years, and browser vendors are very aware of these opinions, and have taken no serious action I can see to realign their incentives. EDIT: But that can also be explained by incentives+emergent behavior. So at the end of the day, you're simply correct.
  - thu2111 7y ago
    There's no mystery to it. Look at Firefox. It's actually not more secure than old Java used to be. It has CVEs all the time. Chrome constantly patches security bugs too. The difference is they have much more aggressive automatic upgrade processes than Flash or Java did, so bugs remain usable for way less time. And Chrome did sandboxing. But Firefox doesn't/didn't. It got a free pass from the community because Mozilla is somehow seen as "not a corporation" and did a lot of drum beating about openess/webbyness/etc. So people gave it a break although the architecture wasn't really any different to something like Java applets and if anything was much worse.
- deleted 7y ago
  [deleted]
- JohnFen 7y ago
  I really wish this is the direction the web would go. This "browser as OS" stuff isn't something that I'm even a little OK with, and I'd love to have a browser that simply didn't have the support for any of it.
  - VoxPelli 7y ago
    Deactivate javascript: Done
    - progval 7y ago
      And then you can't see the article, because its CSS hides the text and Javascript un-hides it; and people call you an extremist.
      - VoxPelli 7y ago
        That's not a good way to handle it, harmful to the web :/
      - gpderetta 7y ago
        I wish there was a reader mode only browser. You would need to somehow extract navigational links though.
      - deleted 7y ago
        [deleted]
    - JohnFen 7y ago
      Yes, I do that already, but that doesn't remove the code in the browser. Also, I'd really love a JS interpreter that was restrictive enough that I could leave it on without exposing me to this stuff.
      - VoxPelli 7y ago
        Not just an interpreter – unless there's a standardized subset that one can look for as a web developer then one can't really adopt to it (through either graceful degradation or progressive enhancement). Same reason why eg. Noscript addons creates havoc at times. Web sites expects a certain baseline and when it's not there, they expect that javascript will be disabled altogether and <noscript>-tags to get executed, but just disabling some code prohibits that fallback, making it less usable than fully disabling js.
- untog 7y ago
  And it's entirely possible to do that today. Things like WebUSB require permission prompts, which you can say no to or disable entirely.
- roca 7y ago
  > let us make simple, secure content with HTML and minimal CSS. Browsers aren't stopping you or Wikipedia or Youtube from sticking to HTML and minimal CSS. Your problem isn't with browsers, it's with Web developers who don't share your priorities.
  - clSTophEjUdRanu 7y ago
    *it's users who don't share your priorities.
    - javajosh 7y ago
      *it's Capital that doesn't share your priorities.
    - roca 7y ago
      That too.
  - anderspitman 7y ago
    Yep, but there is a bit of a chicken/egg problem. If someone created a wicked-fast, private, secure browser that worked with a subset of HTML/CSS, people could start designing their sites in a way that's compatible with both that and modern browsers. It would actually be less work for the developer because you need to become familiar with a smaller number of tags and properties. Over time hopefully bigger sites would make themselves compatible, and eventually you get a killer app like Wikipedia on board and the rest is history. </pipedream>
    - roca 7y ago
      Sorry but this vision is totally unrealistic. You're right there's a chicken/egg problem: no-one's going to use that fantasy browser, because it can't browse the Web. We know this because faster experimental browsers exist, and essentially no-one uses them. Even browsers with tens or hundreds of millions of users struggle to get Web developer attention, even when they're almost completely compatible with the dominant browser and don't require fundamentally rearchitecting, and arguably crippling, one's Web site. Also, from a technical point of view, ripping out JS and DOM APIs does not magically mean you get a "wicked-fast, private, secure browser". It would be a lot more secure, but building a fast HTML/CSS rendering engine that still has to handle window resizing, zooming, incremental loading, editing and other interaction is still incredibly hard, in fact not hugely easier than supporting JS. (Source: I'm a former Mozilla distinguished engineer who worked on this stuff.) By far the easiest path to such a browser would be to take an existing engine and rip out stuff, and I don't think you're going to end up with something much faster. Disabling JS in a regular browser is going to give you most of the wins.
- svnpenn 7y ago
  You used to be able to do this: https://en.wikipedia.org/wiki/HTML_Application https://en.wikipedia.org/wiki/HTML_Application
  - at_a_remove 7y ago
    Don't laugh but I made one of these last year, just needed something dead simple.
    - svnpenn 7y ago
      For a more modern solution, you could use PHP or similar: https://cup.github.io/rosso/html-application https://cup.github.io/rosso/html-application
      - at_a_remove 7y ago
        No, I mean I made something that I didn't have to install anything for. PHP wasn't on the machine. But I could do .hta. Boom.
  - bawolff 7y ago
    And now we have electron. Everything old is new again.
- baroomba 7y ago
  HTML clients & standards have stagnated badly because we know javascript and heavy-handed CSS can work around any problems—even if those solutions are almost always bad (usually: highly janky, at least). Example: Table sorting. Hell, maybe table pagination, too. This is part of why developing HTML-based UI still seems so weird and shitty compared to native, even with the aid of Javascript. Those native SDKs provide way more support for common, basic use cases. Even within the narrow scope of rich document format & display, HTML without Javascript is crippled (see again: super-basic and common table functionality). Plus you'll get a hell of a lot better performance letting C/C++/Rust handle those kinds of basics, rather than trying to re-create them in CSS and Javascript. Another example: there's a clear, fairly common need for tiled dynamically-loading images, as in maps applications. That should be a tag, and... that's all. Just a tag. To get that whole thing. A couple properties to enable/disable things like zooming. Some sensible standard for how to request tiles by X/Y at a given total canvas size (so, just a convention for image URLs) so that just has to be implemented once per server-side language, and can easily be pre-generated and served from actual files. A way to drop other elements on the image at some X/Y value for pins or linking people's faces to wikipedia entries or whatever, kinda like old school imagemap elements. That's clearly useful even for document-centric usecases (aside from maps, consider, say, ultra-high-res images of painted church ceilings). The browser and HTML should include that. Search. Complete- or hint-as-you-type search fields should be a built-in element, with results from local or remote (some convention for the URL) markup-based sources. There's a ton of stuff like that which, in 2020, really ought not require Javascript. Lots of which are still basically rich-document UI elements that've been in demand for 15-25 years at this point, with the holes filled a thousand times over at great cost in person-hours by slow, janky, battery-eating JS and CSS. And that's not even considering overhauling HTML to better suit use in "applications", which could also be done and arguably should be done, since we've pretty much lost the battle to keep that from happening. I'd love more of the Web to be Javascript-light or -free, but modern HTML standards & clients aren't really up to the task. Mostly because (I think) Javascript has freed them from having to worry about it. "Table sorting by column? Well yes of course everyone wants that basically everywhere all the time, but let Javascript handle it".
  - anderspitman 7y ago
- ptx 7y ago
  That text protocol is pretty much what HTTP looked like originally[1]. If you just support an optional "GET " before the document path, you'll essentially have an implementation of HTTP 0.9. [1] https://www.w3.org/Protocols/HTTP/AsImplemented.html https://www.w3.org/Protocols/HTTP/AsImplemented.html
  - anderspitman 7y ago
    Yup. Once I got to the point I was considering adding support for range requests for streaming videos, I figured it would make more sense to implement a subset of HTTP. HTTP started as a pretty dang good protocol and I really hope we never full ditch HTTP/1.1 in favor of the newer binary versions. I'm all for progress, but simple things should remain simple.
- pjmlp 7y ago
  I agree, but at this stage the Chrome VM has won. Safari is still relevant due to iOS and iPad not macOS, and although I mostly use FF privatly, it is seldom a project acceptance requirement to also validate against it. Ironically it were the IE haters that kind of helped this to happen.
- sandoooo 7y ago
  So what you're saying is we should build a browser inside the browser sandbox?
- boring_twenties 7y ago
  Not exactly related but you might enjoy curling this website: https://wttr.in https://wttr.in
ksbakan 7y ago
Why does the site need a loading bar to display a text only post? It sucks that webusb is cjome only, but there are definitely at least a few projects using it.
- sowbug 7y ago
  It works on Edge.
  - loeg 7y ago
    Edge is either a dead end or Chrome now.
cjbprime 7y ago
It seems bad form to declare something is dead when you didn't work on it directly, and other people clearly are working on it as evidenced by the latest version of the spec being less than two months old. I don't know whether WebUSB is healthy or not -- but the OP clearly doesn't either.
nimish 7y ago
WebUSB sounds like a truly gaping security hole. Imagine exploiting USB drivers over the web (yes, even though USB doesn't require DMA support, the drivers operate on a very low level -- https://security.stackexchange.com/questions/118854/attacks-via-physical-access-to-usb-dma https://security.stackexchange.com/questions/118854/attacks-...). WebGPU is more useful but direct access to hardware that could have coherent memory access/DMA is just irresponsible. Chrome needs it for chromebooks. Not sure why it's needed for less constrained machines.
- VoxPelli 7y ago
  Did you read this? https://wicg.github.io/webusb/#security-and-privacy https://wicg.github.io/webusb/#security-and-privacy Maybe give feedback here? https://github.com/WICG/webusb/issues/ https://github.com/WICG/webusb/issues/
  - BoorishBears 7y ago
    I did literally last night (what a happy coincidence!) and it gave me a great laugh "We identified the biggest security problem with this, but to get adoption we're going to rely on prompts (which we all know users pay attention to)" Then the next section is: "We know how the previous shortcomings can be exploited to pwn the host too, hosts, don't let yourselves get pwn'd k thnx" What feedback is there to give, they know what's wrong, they just don't care.
    - VoxPelli 7y ago
      Longer related thread: https://github.com/w3ctag/design-reviews/issues/108 https://github.com/w3ctag/design-reviews/issues/108
      - BoorishBears 7y ago
        Isn't that a play by play of exactly what I described?
  - nimish 7y ago
VoxPelli 7y ago
Google themselves just made it possible to flash Android devices from within the browser, by using WebUSB: https://android-developers.googleblog.com/2020/01/flashing-android-open-source-project-builds.html?linkId=81318357 https://android-developers.googleblog.com/2020/01/flashing-a... I interpret the definition of "dead" here to be: No other implementation than the one in Chrome Rather than: No implementation or spec work at all
- tjoff 7y ago
  I sure consider anything only working in one browser to be dead. Now that might change as we soon will only have one browser.
  - VoxPelli 7y ago
    I would say it's "bad", but "dead" isn't the right term for me in that case
  - qubex 7y ago
    I think you’ve confused “so far has failed to take off” with “dead”.
untog 7y ago
The title here is pretty misleading. WebUSB certainly isn't dead, but it's true that Google are the only ones pushing it forward.
pedrovhb 7y ago
I just got an Ergodox-EZ (ergonomic split keyboard which takes some adapting to), and their helpful training tool [0] leverages WebUSB (which I didn't even know about before I started using it). It's useful because it can talk to the keyboard to find out what's the current layout and layer, and show you the relevant info and keys being pressed. From my point of view as a user: on one hand it kind of sucks because I use Firefox as my main browser, and launching Chrome/Chromium every time is a bit out of my usual path. On the other hand, I appreciate not having to install something on my computer just for this. It's nice for small apps that you won't be interacting with that often or for too long. [0] https://configure.ergodox-ez.com/train https://configure.ergodox-ez.com/train
- sayhello 7y ago
  And it's nice that the web app only has a narrow set of permissions. You could imagine the same for an unzipping app. It theory, an unzipping app doesn't need anything else than specific file system permissions, i.e. read for a specific set of bytes and write access to a specific filepath. https://github.com/GoogleChromeLabs/unarchiver https://github.com/GoogleChromeLabs/unarchiver I work on the Capabilities team on Chrome and I think it's pretty cool the web can do more, and provide safe experiences for users.
semireg 7y ago
This topic fascinates me because I've successfully built an app and business around an Electron app (no Linux, yet) that connects to USB devices on Mac and Windows. The app uses native node modules for USB (not chrome). I've been successful using these npm modules: "@nodert-win10-rs3/windows.devices.custom" and "enumerated" on Windows and "usb" on Mac. Interestingly, "usb" relies on libusb which isn't really an option for the common Windows user. A naive developer will read about WebUSB and think, "oh, Electron is Chrome, so this must be a good solution!" but remember that Electron apps consist of one node process (main) and multiple chrome processes (renderers, aka, BrowserWindow objects). In my experience, it is poor design to exclusively connect to USB hardware using a BrowserWindow. Instead, it's much better to use the main node process to handle all exclusive USB access, and then push state to renderers using IPC. So, once you go down this road you realize that WebUSB on Electron isn't viable. The idea seems good, but was dead on arrival for me. Your mileage may vary. Ten years ago I would never have identified as a hardware-focused software developer. Now it's become part of my professional identity. My speciality is Electron/USB. You can check out my USB-heavy Windows/Mac app at https://www.label.live https://www.label.live. I'm available for consulting if you have a need for custom desktop software that talks to hardware. I've solved dozens of incredibly difficult problems over the last few years. Super fun.
- anaisbetts 7y ago
  > Instead, it's much better to use the main node process to handle all exclusive USB access, and then push state to renderers using IPC. You should absolutely not do this - don't do anything in the main process at all; blocking it even a little bit makes your entire app janky and hang'y. If you want to connect to USB hardware in an isolated context, create a hidden renderer process (aka a BrowserWindow that you don't call `show` on), though tbh I would just use your existing BrowserWindow, I'm not sure why you immediately dismiss it as "poor design".
  - semireg 7y ago
    You’re assuming the USB read and writes block, but they are in fact async and work quite well for this purpose. My app is document-based so the user may have multiple label designs open. Because of this, USB is handled from a central location. That could be another renderer, but then you have to shuttle data from renderer to renderer (via main) which in and of itself becomes laborious.
shadowgovt 7y ago
Ah, that's inconvenient. A probably-viable (but also inconvenient) alternative is to code your own bridge: a server that talks the relevant USB protocol in the host OS and exposes an HTTP endpoint that a browser can connect to. More complicated than having the browser just be the bridge, and it introduces the significant risk of mis-implementing the security model and leaving your hardware open for remote-zombification though.
Ecco 7y ago
The title is completely misleading. It should read "I couldn't use WebUSB". And WebUSB is by no mean dead. Geez, it just got supported by Microsoft in the last version of Edge!
- schappim 7y ago
  Yeah, surprised Dang left it as is...
emddudley 7y ago
I write a lot of engineering and test software that interacts with hardware. Generally it communicates over serial or UDP. I package the software as an executable that gets installed on lab PCs. There is a lot of configuration management. An operator has to use the correct build of software, and needs to configure the software with the appropriate settings. After some testing he needs to save off the data to the appropriate places for analysis and archival. It seems to me that this type of application would be appropriate to implement as a web application. This would help me manage deployments better and would automate the CM/data flows. I have been casually monitoring the Web Serial, Web USB, and Web Socket APIs, since they would enable me to implement the low-level communications I need. The opposition to these standards bums me out, but I keep hoping that the security concerns can be resolved and that attitudes will change.
Keverw 7y ago
Looks like Web Bluetooth is more supported. Surprised Firefox doesn't support it. https://caniuse.com/#search=Web%20Bluetooth https://caniuse.com/#search=Web%20Bluetooth I know you can connect game controllers to your computer, but maybe that uses the Gamepad API instead. Haven't dug too much into that but was playing with a Babylon Demo and thought the camera controls with a Xbox One Controller was a bit nicer than using my mouse. https://caniuse.com/#search=Gamepad%20API https://caniuse.com/#search=Gamepad%20API
- musingsole 7y ago
  I think Web-Something is going to be critical for the next few years of IoT development. WebBluetooth looks like an obvious candidate, and if it works, the niche for WebUSB gets smaller. I've played with WebBluetooth some and hope it gets more love!
  - Keverw 7y ago
    Only bad thing is apparently Bluetooth spec has a connection limit. Sounds like it's 7? So sounds like some people might be pushing close to that... Say they have their Magic Mouse, Magic Keyboard, Airpods(probably counts as 2 connections) and then sometimes the case status shows up too. So 5 connections. Looks like the limit is 7, so some are pushing it. [0] https://superuser.com/questions/931188/how-many-devices-can-be-hooked-up-to-one-pc-bluetooth-adapter-at-a-time https://superuser.com/questions/931188/how-many-devices-can-...
    - TAForObvReasons 7y ago
      I wouldn't count WebUSB dead yet. People lament the death of WebSQL but https://caniuse.com/#feat=sql-storage https://caniuse.com/#feat=sql-storage points to 77.59% availability despite having been "killed" years ago
chubs 7y ago
You'd flash the (now-defunct) Chip SBC using Chrome - I always wondered how that worked, it must have been WebUSB! It worked brilliantly. Pity the tech hasn't found much take-up. I can imagine use-cases for it are scarce. http://linuxgizmos.com/hackable-arm-linux-sbc-starts-at-9/ http://linuxgizmos.com/hackable-arm-linux-sbc-starts-at-9/
MuffinFlavored 7y ago
Super clickbait title. It's not being removed from Chrome...
pjmlp 7y ago
WebUSB is pretty much alive on the Chrome VM. The last week's released Android Flash Tool, makes use of it. https://flash.android.com/ https://flash.android.com/
schappim 7y ago
WebUSB is very much NOT dead. We use it every day in the latest version of Chrome w/ our WebUSB Printer and Scales in Chrome Version 79.0.3945.130 (Official Build) (64-bit) and Edge. The website's comment system is what is dead. Getting a 403 when posting a comment: https://files.littlebird.com.au/Shared-Image-2020-02-04-20-18-46-hMKf4 https://files.littlebird.com.au/Shared-Image-2020-02-04-20-1...
fbn79 7y ago
Currently using it in a commercial project to control microscope lights form a web-app. Works on Linux and MacOS. Not on windows because Windows cannot see the device as a Webcam and a generic USB endpoint at the same time (my old StackOverflow question https://stackoverflow.com/questions/44942495/getusermedia-and-webusb-over-the-same-device-windows https://stackoverflow.com/questions/44942495/getusermedia-an...). In the beginning the project was born to run on vanilla Google Chrome but now is distribuited with NWJS. I would really love to see a definitive good WebUsb crossbrowser API spec.
qubex 7y ago
Meanwhile, I just used WebUSB to flash an updated version of the firmware to my NumWorks calculator.
hatemben 7y ago
Great discussions and apologies as I am checking this very very late. The purpose of my post was not to create buzz as some of you mentioned. I have been in the web industry since 2001 contributing in open source community, and author of an online PHP magazine since 2005. creating buzz was somehow part of my business, but not this time. WebUSB was really a very cool approach to connect Web to USB devices in spite of all the security issues that you may or you may not face. I had the chance to work on it and see its limitations two years ago. I found out very small of successful implementations and solutions (Google use it to flash Android from the web, finally (: ). To make this thread more interactive, I am adding a proof of concept of a code generator to generate WebUSB code :-) https://github.com/hatemben/usbmon https://github.com/hatemben/usbmon Feel free to fork/test and play with. It's true that there are tons of security issues related to WebUSB, and there are always solutions to security issues. For me WebUSB is dead two years ago, I just remembered to announce it last week. -Hatem

63 points by hatemben 7y ago

About ten years ago, I wrote an IE/win7 plugin that broke the security model of IE to allow the browser to communicate with a USB device (in this case, a remote control). It was a nasty, nasty hack, and things like this shouldn't be allowed. Management insisted that our product have a web-interface because they had information that our competitor was going from desktop apps to web apps. Ironically, our competitor was never able to get its web interface working.

anderspitman 7y ago

I find the push to turn web browsers into VMs for running sandboxed JavaScript/WebAssembly applications fascinating. WebUSB, WebGPU, WebTransport, etc etc. I think it's really cool, and enables cool things, but I have 1 problem with it. I wish we separated the browser application from the VM application. ie, let us make simple, secure content with HTML and minimal CSS. For things like Wikipedia and even a lot of YouTube that's all you need. People can use an extremely simple (and private/secure!) program to access this kind of content. A text version of my personal site is browsable with cURL or even netcat[0]. Make the VM a separate program that people use for fancy web apps. [0]: https://anderspitman.net/19/#netcatable https://anderspitman.net/19/#netcatable

ar-nelson 7y ago
This is how the Web was originally designed, which is why we had Flash and Java applets. But it's hard to make those VMs secure, and yet somehow it's been easier to keep modern browsers reasonably secure as they keep adding features.
- anderspitman 7y ago
  One problem is that browser vendors are using the complexity of modern browsers to create an oligopoly. When even Microsoft doesn't want to maintain their own browser, something is wrong. A simple browser that only implemented a subset of HTML and the good parts of CSS (ie flexbox) could be implemented easily by a small team.
  - api 7y ago
    The driver is the desire by web app builders to build more and more niftiness into web apps. The browser vendors and standards bodies are attempting to satisfy this desire and that's leading down a path that is having the effect of creating an oligopoly because a browser must become this enormous OS-inside-an-OS. I don't think it's a conspiracy. Most things that look like conspiracies are in fact unplanned outcomes that result from an unintentional alignment of multiple perverse incentives. A different way of saying the same is that most things that appear to be conspiracies are actually "emergent" behaviors in complex systems. A different example of something similar is real estate hyperinflation. I don't think somebody sat down and said "lets make housing impossible for any family making less than 5X the local median income to reasonably afford." What happened instead was that multiple decisions made for independent and unrelated reasons created an aligned set of perverse incentives that drove the price of housing nuts. There is no one cause or one responsible party.
    - redwall_hp 7y ago
      Flash reached a point where it was basically unmaintainable spaghetti, and not something that was going to be trivially reimplemented by a third party. Sadly, that's exactly what's happening to the Web now. Instead of being standards-first, and browsers implement it, we've basically shifted to descriptive standards that attempt to formalize what a corporate cabal unilaterally decides. And we're in inch away from a homogeny of browser engines...
      - bawolff 7y ago
        Well multilaterally decide. Its a small group but firefox isnt totally irrelavent yet. And thats ok in my opinion. The IETF describes itself as "rough consensus and running code" and it seems to work well. I dont have a problem with the web following that model.
    - anderspitman 7y ago
      You're not wrong, but people have been pointing these issues out for years, and browser vendors are very aware of these opinions, and have taken no serious action I can see to realign their incentives. EDIT: But that can also be explained by incentives+emergent behavior. So at the end of the day, you're simply correct.
- thu2111 7y ago
  There's no mystery to it. Look at Firefox. It's actually not more secure than old Java used to be. It has CVEs all the time. Chrome constantly patches security bugs too. The difference is they have much more aggressive automatic upgrade processes than Flash or Java did, so bugs remain usable for way less time. And Chrome did sandboxing. But Firefox doesn't/didn't. It got a free pass from the community because Mozilla is somehow seen as "not a corporation" and did a lot of drum beating about openess/webbyness/etc. So people gave it a break although the architecture wasn't really any different to something like Java applets and if anything was much worse.
deleted 7y ago
[deleted]
JohnFen 7y ago
I really wish this is the direction the web would go. This "browser as OS" stuff isn't something that I'm even a little OK with, and I'd love to have a browser that simply didn't have the support for any of it.
- VoxPelli 7y ago
  Deactivate javascript: Done
  - progval 7y ago
    And then you can't see the article, because its CSS hides the text and Javascript un-hides it; and people call you an extremist.
    - VoxPelli 7y ago
      That's not a good way to handle it, harmful to the web :/
    - gpderetta 7y ago
      I wish there was a reader mode only browser. You would need to somehow extract navigational links though.
    - deleted 7y ago
      [deleted]
  - JohnFen 7y ago
    Yes, I do that already, but that doesn't remove the code in the browser. Also, I'd really love a JS interpreter that was restrictive enough that I could leave it on without exposing me to this stuff.
    - VoxPelli 7y ago
      Not just an interpreter – unless there's a standardized subset that one can look for as a web developer then one can't really adopt to it (through either graceful degradation or progressive enhancement). Same reason why eg. Noscript addons creates havoc at times. Web sites expects a certain baseline and when it's not there, they expect that javascript will be disabled altogether and <noscript>-tags to get executed, but just disabling some code prohibits that fallback, making it less usable than fully disabling js.
untog 7y ago
And it's entirely possible to do that today. Things like WebUSB require permission prompts, which you can say no to or disable entirely.
roca 7y ago
> let us make simple, secure content with HTML and minimal CSS. Browsers aren't stopping you or Wikipedia or Youtube from sticking to HTML and minimal CSS. Your problem isn't with browsers, it's with Web developers who don't share your priorities.
- clSTophEjUdRanu 7y ago
  *it's users who don't share your priorities.
  - javajosh 7y ago
    *it's Capital that doesn't share your priorities.
  - roca 7y ago
    That too.
- anderspitman 7y ago
  Yep, but there is a bit of a chicken/egg problem. If someone created a wicked-fast, private, secure browser that worked with a subset of HTML/CSS, people could start designing their sites in a way that's compatible with both that and modern browsers. It would actually be less work for the developer because you need to become familiar with a smaller number of tags and properties. Over time hopefully bigger sites would make themselves compatible, and eventually you get a killer app like Wikipedia on board and the rest is history. </pipedream>
  - roca 7y ago
    Sorry but this vision is totally unrealistic. You're right there's a chicken/egg problem: no-one's going to use that fantasy browser, because it can't browse the Web. We know this because faster experimental browsers exist, and essentially no-one uses them. Even browsers with tens or hundreds of millions of users struggle to get Web developer attention, even when they're almost completely compatible with the dominant browser and don't require fundamentally rearchitecting, and arguably crippling, one's Web site. Also, from a technical point of view, ripping out JS and DOM APIs does not magically mean you get a "wicked-fast, private, secure browser". It would be a lot more secure, but building a fast HTML/CSS rendering engine that still has to handle window resizing, zooming, incremental loading, editing and other interaction is still incredibly hard, in fact not hugely easier than supporting JS. (Source: I'm a former Mozilla distinguished engineer who worked on this stuff.) By far the easiest path to such a browser would be to take an existing engine and rip out stuff, and I don't think you're going to end up with something much faster. Disabling JS in a regular browser is going to give you most of the wins.
svnpenn 7y ago
You used to be able to do this: https://en.wikipedia.org/wiki/HTML_Application https://en.wikipedia.org/wiki/HTML_Application
- at_a_remove 7y ago
  Don't laugh but I made one of these last year, just needed something dead simple.
  - svnpenn 7y ago
    For a more modern solution, you could use PHP or similar: https://cup.github.io/rosso/html-application https://cup.github.io/rosso/html-application
    - at_a_remove 7y ago
      No, I mean I made something that I didn't have to install anything for. PHP wasn't on the machine. But I could do .hta. Boom.
- bawolff 7y ago
  And now we have electron. Everything old is new again.
baroomba 7y ago
HTML clients & standards have stagnated badly because we know javascript and heavy-handed CSS can work around any problems—even if those solutions are almost always bad (usually: highly janky, at least). Example: Table sorting. Hell, maybe table pagination, too. This is part of why developing HTML-based UI still seems so weird and shitty compared to native, even with the aid of Javascript. Those native SDKs provide way more support for common, basic use cases. Even within the narrow scope of rich document format & display, HTML without Javascript is crippled (see again: super-basic and common table functionality). Plus you'll get a hell of a lot better performance letting C/C++/Rust handle those kinds of basics, rather than trying to re-create them in CSS and Javascript. Another example: there's a clear, fairly common need for tiled dynamically-loading images, as in maps applications. That should be a tag, and... that's all. Just a tag. To get that whole thing. A couple properties to enable/disable things like zooming. Some sensible standard for how to request tiles by X/Y at a given total canvas size (so, just a convention for image URLs) so that just has to be implemented once per server-side language, and can easily be pre-generated and served from actual files. A way to drop other elements on the image at some X/Y value for pins or linking people's faces to wikipedia entries or whatever, kinda like old school imagemap elements. That's clearly useful even for document-centric usecases (aside from maps, consider, say, ultra-high-res images of painted church ceilings). The browser and HTML should include that. Search. Complete- or hint-as-you-type search fields should be a built-in element, with results from local or remote (some convention for the URL) markup-based sources. There's a ton of stuff like that which, in 2020, really ought not require Javascript. Lots of which are still basically rich-document UI elements that've been in demand for 15-25 years at this point, with the holes filled a thousand times over at great cost in person-hours by slow, janky, battery-eating JS and CSS. And that's not even considering overhauling HTML to better suit use in "applications", which could also be done and arguably should be done, since we've pretty much lost the battle to keep that from happening. I'd love more of the Web to be Javascript-light or -free, but modern HTML standards & clients aren't really up to the task. Mostly because (I think) Javascript has freed them from having to worry about it. "Table sorting by column? Well yes of course everyone wants that basically everywhere all the time, but let Javascript handle it".
- anderspitman 7y ago
ptx 7y ago
That text protocol is pretty much what HTTP looked like originally[1]. If you just support an optional "GET " before the document path, you'll essentially have an implementation of HTTP 0.9. [1] https://www.w3.org/Protocols/HTTP/AsImplemented.html https://www.w3.org/Protocols/HTTP/AsImplemented.html
- anderspitman 7y ago
  Yup. Once I got to the point I was considering adding support for range requests for streaming videos, I figured it would make more sense to implement a subset of HTTP. HTTP started as a pretty dang good protocol and I really hope we never full ditch HTTP/1.1 in favor of the newer binary versions. I'm all for progress, but simple things should remain simple.
pjmlp 7y ago
I agree, but at this stage the Chrome VM has won. Safari is still relevant due to iOS and iPad not macOS, and although I mostly use FF privatly, it is seldom a project acceptance requirement to also validate against it. Ironically it were the IE haters that kind of helped this to happen.
sandoooo 7y ago
So what you're saying is we should build a browser inside the browser sandbox?
boring_twenties 7y ago
Not exactly related but you might enjoy curling this website: https://wttr.in https://wttr.in

ksbakan 7y ago

Why does the site need a loading bar to display a text only post? It sucks that webusb is cjome only, but there are definitely at least a few projects using it.

sowbug 7y ago
It works on Edge.
- loeg 7y ago
  Edge is either a dead end or Chrome now.

cjbprime 7y ago

It seems bad form to declare something is dead when you didn't work on it directly, and other people clearly are working on it as evidenced by the latest version of the spec being less than two months old. I don't know whether WebUSB is healthy or not -- but the OP clearly doesn't either.

nimish 7y ago

WebUSB sounds like a truly gaping security hole. Imagine exploiting USB drivers over the web (yes, even though USB doesn't require DMA support, the drivers operate on a very low level -- https://security.stackexchange.com/questions/118854/attacks-via-physical-access-to-usb-dma https://security.stackexchange.com/questions/118854/attacks-...). WebGPU is more useful but direct access to hardware that could have coherent memory access/DMA is just irresponsible. Chrome needs it for chromebooks. Not sure why it's needed for less constrained machines.

VoxPelli 7y ago
Did you read this? https://wicg.github.io/webusb/#security-and-privacy https://wicg.github.io/webusb/#security-and-privacy Maybe give feedback here? https://github.com/WICG/webusb/issues/ https://github.com/WICG/webusb/issues/
- BoorishBears 7y ago
  I did literally last night (what a happy coincidence!) and it gave me a great laugh "We identified the biggest security problem with this, but to get adoption we're going to rely on prompts (which we all know users pay attention to)" Then the next section is: "We know how the previous shortcomings can be exploited to pwn the host too, hosts, don't let yourselves get pwn'd k thnx" What feedback is there to give, they know what's wrong, they just don't care.
  - VoxPelli 7y ago
    Longer related thread: https://github.com/w3ctag/design-reviews/issues/108 https://github.com/w3ctag/design-reviews/issues/108
    - BoorishBears 7y ago
      Isn't that a play by play of exactly what I described?
- nimish 7y ago

VoxPelli 7y ago

Google themselves just made it possible to flash Android devices from within the browser, by using WebUSB: https://android-developers.googleblog.com/2020/01/flashing-android-open-source-project-builds.html?linkId=81318357 https://android-developers.googleblog.com/2020/01/flashing-a... I interpret the definition of "dead" here to be: No other implementation than the one in Chrome Rather than: No implementation or spec work at all

tjoff 7y ago
I sure consider anything only working in one browser to be dead. Now that might change as we soon will only have one browser.
- VoxPelli 7y ago
  I would say it's "bad", but "dead" isn't the right term for me in that case
- qubex 7y ago
  I think you’ve confused “so far has failed to take off” with “dead”.

untog 7y ago

The title here is pretty misleading. WebUSB certainly isn't dead, but it's true that Google are the only ones pushing it forward.

pedrovhb 7y ago

I just got an Ergodox-EZ (ergonomic split keyboard which takes some adapting to), and their helpful training tool [0] leverages WebUSB (which I didn't even know about before I started using it). It's useful because it can talk to the keyboard to find out what's the current layout and layer, and show you the relevant info and keys being pressed. From my point of view as a user: on one hand it kind of sucks because I use Firefox as my main browser, and launching Chrome/Chromium every time is a bit out of my usual path. On the other hand, I appreciate not having to install something on my computer just for this. It's nice for small apps that you won't be interacting with that often or for too long. [0] https://configure.ergodox-ez.com/train https://configure.ergodox-ez.com/train

sayhello 7y ago
And it's nice that the web app only has a narrow set of permissions. You could imagine the same for an unzipping app. It theory, an unzipping app doesn't need anything else than specific file system permissions, i.e. read for a specific set of bytes and write access to a specific filepath. https://github.com/GoogleChromeLabs/unarchiver https://github.com/GoogleChromeLabs/unarchiver I work on the Capabilities team on Chrome and I think it's pretty cool the web can do more, and provide safe experiences for users.

semireg 7y ago

This topic fascinates me because I've successfully built an app and business around an Electron app (no Linux, yet) that connects to USB devices on Mac and Windows. The app uses native node modules for USB (not chrome). I've been successful using these npm modules: "@nodert-win10-rs3/windows.devices.custom" and "enumerated" on Windows and "usb" on Mac. Interestingly, "usb" relies on libusb which isn't really an option for the common Windows user. A naive developer will read about WebUSB and think, "oh, Electron is Chrome, so this must be a good solution!" but remember that Electron apps consist of one node process (main) and multiple chrome processes (renderers, aka, BrowserWindow objects). In my experience, it is poor design to exclusively connect to USB hardware using a BrowserWindow. Instead, it's much better to use the main node process to handle all exclusive USB access, and then push state to renderers using IPC. So, once you go down this road you realize that WebUSB on Electron isn't viable. The idea seems good, but was dead on arrival for me. Your mileage may vary. Ten years ago I would never have identified as a hardware-focused software developer. Now it's become part of my professional identity. My speciality is Electron/USB. You can check out my USB-heavy Windows/Mac app at https://www.label.live https://www.label.live. I'm available for consulting if you have a need for custom desktop software that talks to hardware. I've solved dozens of incredibly difficult problems over the last few years. Super fun.

anaisbetts 7y ago
> Instead, it's much better to use the main node process to handle all exclusive USB access, and then push state to renderers using IPC. You should absolutely not do this - don't do anything in the main process at all; blocking it even a little bit makes your entire app janky and hang'y. If you want to connect to USB hardware in an isolated context, create a hidden renderer process (aka a BrowserWindow that you don't call `show` on), though tbh I would just use your existing BrowserWindow, I'm not sure why you immediately dismiss it as "poor design".
- semireg 7y ago
  You’re assuming the USB read and writes block, but they are in fact async and work quite well for this purpose. My app is document-based so the user may have multiple label designs open. Because of this, USB is handled from a central location. That could be another renderer, but then you have to shuttle data from renderer to renderer (via main) which in and of itself becomes laborious.

shadowgovt 7y ago

Ah, that's inconvenient. A probably-viable (but also inconvenient) alternative is to code your own bridge: a server that talks the relevant USB protocol in the host OS and exposes an HTTP endpoint that a browser can connect to. More complicated than having the browser just be the bridge, and it introduces the significant risk of mis-implementing the security model and leaving your hardware open for remote-zombification though.

Ecco 7y ago

The title is completely misleading. It should read "I couldn't use WebUSB". And WebUSB is by no mean dead. Geez, it just got supported by Microsoft in the last version of Edge!

schappim 7y ago
Yeah, surprised Dang left it as is...

emddudley 7y ago

I write a lot of engineering and test software that interacts with hardware. Generally it communicates over serial or UDP. I package the software as an executable that gets installed on lab PCs. There is a lot of configuration management. An operator has to use the correct build of software, and needs to configure the software with the appropriate settings. After some testing he needs to save off the data to the appropriate places for analysis and archival. It seems to me that this type of application would be appropriate to implement as a web application. This would help me manage deployments better and would automate the CM/data flows. I have been casually monitoring the Web Serial, Web USB, and Web Socket APIs, since they would enable me to implement the low-level communications I need. The opposition to these standards bums me out, but I keep hoping that the security concerns can be resolved and that attitudes will change.

Keverw 7y ago

Looks like Web Bluetooth is more supported. Surprised Firefox doesn't support it. https://caniuse.com/#search=Web%20Bluetooth https://caniuse.com/#search=Web%20Bluetooth I know you can connect game controllers to your computer, but maybe that uses the Gamepad API instead. Haven't dug too much into that but was playing with a Babylon Demo and thought the camera controls with a Xbox One Controller was a bit nicer than using my mouse. https://caniuse.com/#search=Gamepad%20API https://caniuse.com/#search=Gamepad%20API

musingsole 7y ago
I think Web-Something is going to be critical for the next few years of IoT development. WebBluetooth looks like an obvious candidate, and if it works, the niche for WebUSB gets smaller. I've played with WebBluetooth some and hope it gets more love!
- Keverw 7y ago
  Only bad thing is apparently Bluetooth spec has a connection limit. Sounds like it's 7? So sounds like some people might be pushing close to that... Say they have their Magic Mouse, Magic Keyboard, Airpods(probably counts as 2 connections) and then sometimes the case status shows up too. So 5 connections. Looks like the limit is 7, so some are pushing it. [0] https://superuser.com/questions/931188/how-many-devices-can-be-hooked-up-to-one-pc-bluetooth-adapter-at-a-time https://superuser.com/questions/931188/how-many-devices-can-...
  - TAForObvReasons 7y ago
    I wouldn't count WebUSB dead yet. People lament the death of WebSQL but https://caniuse.com/#feat=sql-storage https://caniuse.com/#feat=sql-storage points to 77.59% availability despite having been "killed" years ago

chubs 7y ago

You'd flash the (now-defunct) Chip SBC using Chrome - I always wondered how that worked, it must have been WebUSB! It worked brilliantly. Pity the tech hasn't found much take-up. I can imagine use-cases for it are scarce. http://linuxgizmos.com/hackable-arm-linux-sbc-starts-at-9/ http://linuxgizmos.com/hackable-arm-linux-sbc-starts-at-9/

MuffinFlavored 7y ago

Super clickbait title. It's not being removed from Chrome...

pjmlp 7y ago

WebUSB is pretty much alive on the Chrome VM. The last week's released Android Flash Tool, makes use of it. https://flash.android.com/ https://flash.android.com/

schappim 7y ago

WebUSB is very much NOT dead. We use it every day in the latest version of Chrome w/ our WebUSB Printer and Scales in Chrome Version 79.0.3945.130 (Official Build) (64-bit) and Edge. The website's comment system is what is dead. Getting a 403 when posting a comment: https://files.littlebird.com.au/Shared-Image-2020-02-04-20-18-46-hMKf4 https://files.littlebird.com.au/Shared-Image-2020-02-04-20-1...

fbn79 7y ago

Currently using it in a commercial project to control microscope lights form a web-app. Works on Linux and MacOS. Not on windows because Windows cannot see the device as a Webcam and a generic USB endpoint at the same time (my old StackOverflow question https://stackoverflow.com/questions/44942495/getusermedia-and-webusb-over-the-same-device-windows https://stackoverflow.com/questions/44942495/getusermedia-an...). In the beginning the project was born to run on vanilla Google Chrome but now is distribuited with NWJS. I would really love to see a definitive good WebUsb crossbrowser API spec.

qubex 7y ago

Meanwhile, I just used WebUSB to flash an updated version of the firmware to my NumWorks calculator.

hatemben 7y ago

Great discussions and apologies as I am checking this very very late. The purpose of my post was not to create buzz as some of you mentioned. I have been in the web industry since 2001 contributing in open source community, and author of an online PHP magazine since 2005. creating buzz was somehow part of my business, but not this time. WebUSB was really a very cool approach to connect Web to USB devices in spite of all the security issues that you may or you may not face. I had the chance to work on it and see its limitations two years ago. I found out very small of successful implementations and solutions (Google use it to flash Android from the web, finally (: ). To make this thread more interactive, I am adding a proof of concept of a code generator to generate WebUSB code :-) https://github.com/hatemben/usbmon https://github.com/hatemben/usbmon Feel free to fork/test and play with. It's true that there are tons of security issues related to WebUSB, and there are always solutions to security issues. For me WebUSB is dead two years ago, I just remembered to announce it last week. -Hatem