Hacker News Reader

Comment by tdicola | Hacker News Reader

This is going to be really annoying since hardware access from HTML5 is still very rough and not even standardized. Stuff like talking to a serial port isn't even on the radar (so good luck programming a board like BBC micro:bit, Arduino, etc. without a native app), and efforts like WebUSB are still extremely early and not even a full standard. I feel like the product managers making this decision are completely oblivious to the major gaps between chrome app support & HTML5 support. This line in particular is basically a giant middle finger to folks in this situation: "Developers who can’t fully move their apps to the web can help us prioritize new APIs to fill the gaps left by Chrome apps."

So in short, Google proves once again to _never_ take a bet on their technology.

View on HN

Websites with hardware access? what could possibly go wrong?

Browsers already are a overly complex security nightmare. Moreover the recent example of this stupid but rather simple battery API has shown us several, some more and some less obvious ways of how it can be abused. But sure Google will implement WebUSB and all sort of other shit they may imagine, the others will follow as always. In the end the browser will finally be the OS in your OS but worse and with a huge attack surface.

What's the alternative? If an app needs such functionality to work and it cannot work within a browser, the user will have to install a native app which aren't nearly as well sandboxed right now (Windows, Mac, Linux).

> > Websites with hardware access?

> the alternative? [...] install a native app which aren't nearly as well sandboxed right now (Windows, Mac, Linux).

err, the sandboxing works because web APIs don't already expose things which are suggested to be exposed here. Exposing them will break that "sandbox", to a certain (major) degree, atleast.

Most importantly, as a user, don't install programs which can't be trusted because sandboxing is no magic bullet and will never be. In addition to that better redirect the work that would go into these browser features to improve the native sandboxing mechanisms of the operating systems.

> Most importantly, as a user, don't install programs which can't be trusted because sandboxing is no magic bullet and will never be.

Perfect is the enemy of good! It's better than the alternative and that's all that matters.

Sure nothing is perfect and I did not say that we shouldn't improve sandboxing but I do not think that moving everything into the browser is the better alternative. The problem doesn't get easier only because it's in the browser and as a nice topping every random website is now free to try to break the sandbox.

UWP is sandboxed, Mac App Store apps are sandboxed, Mac apps from outside the store can opt-in to sandboxing, flatpaks are sandboxed, snaps are sandboxed.

In terms of maturity, all of these techniques are probably more mature than any WebUSB/Browser hardware access thing/abysmal-of-the-day.

Reading your comment on a Chromebook that hasn't failed me once including all the others i have had makes me scratch my head. If anything this, to me, seems the most secure approach compared to what's out there. Doesn't it make to you? A secure, lean Linux hosting a lean UI layer that sandboxes web and native apps.

The BBC micro:bit happens to be a bad example, since the editors [1] are exactly web apps with no hardware access. The editors compile the code in the browser and provide the ARM binary as a .hex file that the user downloads onto the micro:bit, which is a USB mass storage device.

[1]: https://www.microbit.co.uk/create-code

Yeah but not every board can do USB storage bootloader, and there are troubles with it like ignoring Mac OSX .DS_store files, etc. Been there, done that, USB mass storage bootloading kinda sucks.

Also if you load stuff like MicroPython on the micro:bit you can't access its serial REPL from the web. That sucks, plain and simple.

The article mentions using Electron or NW.js if you want to continue building apps on web technologies that need deeper platform access.

Is there a reason that those are worse options than Chrome apps?

Each Electron/NW.js app will be packaged with a whole huge runtime.

It's not all bad - there's more freedom with these.

It's possible but it's not an easy switch. And god help you if you have to mix native code with Electron. Getting a node-gyp toolchain spun up on Windows is a complete and total nightmare. Add Electron and its very specific version of Node into the mix (which totally confused node-gyp) and it's really awful.

Nah, it's not that hard, not sure why you had so much trouble

Source: Have written many many Electron node modules

It used to be hard, but when you have tried it last time? These days its as simple as hitting.

    npm install --global node-gyp
    npm install --global --production windows-build-tools

There's also the alternative of switching to a Chrome extension, no?

Different sets of APIs[1]. For example Socket, USB are only App APIs. Though I guess they could roll app APIs into extensions… hopefully. Socket API especially.

Only Chrome apps work on Chrome OS and developing a Chrome app is way easier: Chrome takes care of the back-end and Google offers an app store.

To be fair, did many people actually place a significant 'bet' on Chrome Web Apps? Even from the beginning that wouldnt sound like a very wise bet.

Just last December, Open Whisper Systems announced Signal Desktop, a Chrome Web App[0]. I am not sure how significant you would consider the Web to a messaging platform, but most of their competition has a Web app by now.

[0]: https://whispersystems.org/blog/signal-desktop/

Did you place a bet on this technology? Tell us about it.

I didn't personally but there's stuff out there like chromeduino and Codebender that could be broken by this: https://chrome.google.com/webstore/detail/chromeduino/dmkinc... or https://chrome.google.com/webstore/detail/codebender-app/mag...

I did, I wanted a multi-platform GUI with USB access for my milling machine software.

there are workarounds, for usb device over wifi there is this: https://github.com/cnlohr/espusb if you are hardcore enough it is possible to add usb host support too

Reply on news.ycombinator.com