10 ms·

Chromium devs want the browser to talk to devices, computers directly

123 points by kiyanwang 6y ago

classichasclass 6y ago
As a gopher dweeb forced to write hackarounds like an external helper to get Firefox into Gopherspace again (either a proxy server: https://addons.mozilla.org/en-US/firefox/addon/overbitewx/ https://addons.mozilla.org/en-US/firefox/addon/overbitewx/ or an actual executable: https://addons.mozilla.org/en-US/firefox/addon/overbitenx/ https://addons.mozilla.org/en-US/firefox/addon/overbitenx/), I'm torn. I would love to see the browser able to speak raw TCP again like I could when XUL/XPCOM extensions were still a thing. But this should really be restricted to browser extensions rather than arbitrary websites because we know someone is going to abuse it, and if we go full Windows Vista as proposed here and ask every connection to be confirmed it will eventually annoy people enough that security will be slackened (and then someone is going to abuse it).
- dependenttypes 6y ago
  The next thunderbird will contain OpenPGP support build-in because they are finally getting rid of XUL addon support and enigmail would not work with it.
  - floatingatoll 6y ago
    Context: https://blog.thunderbird.net/2019/10/thunderbird-enigmail-and-openpgp/ https://blog.thunderbird.net/2019/10/thunderbird-enigmail-an... > "It has always been my goal to have OpenPGP support included in the core Thunderbird product."
kevingadd 6y ago
Until widespread code-signing exists on the web this seems incredibly reckless to expose. Even if you require https and put it behind a modal, history has shown that both of those measures are not impenetrable barriers to attackers and raw sockets open up a whole new set of attacks. HTTPS is basically useless for authenticating dangerous code: There are thousands of https domains out there that you can easily put your own code onto, and many of them have EV/DV certificates with reputable names like GitHub attached to them so there won't be any obvious red flags other than the text of the domain name. A prompt with a textbox in it is a barrier but it's not hard to get users to paste random stuff into text fields (just look at the big message that appears when you open devtools in Discord warning people not to paste stuff in there) and I agree with the concern that eventually the text box will be made friendlier. Many existing Dangerous APIs have worst-case attacks that just do things like talk to a USB device from a small list of authorized devices or talk to a MIDI keyboard. Raw Sockets are an entire new world of attacks: Hit a router or PC on the local network with a zero day and get persistent root on it, then use that to spread through the network and perform a ransomware attack, etc. The blink team needs to accept reality and catch up with where native apps have been for over a decade: Require code signing with revocable certificates and pair that with a mechanism to ensure the code was signed by the owner of the domain.
- lukevp 6y ago
  Why does discord even let users access dev tools? This is trivially easy to disable in prod builds. Seems odd. Is there a valid use case?
  - ddulaney 6y ago
    I assume the parent is referring to the web version, where a big warning is output on the console of the browser’s built-in dev tools. I don’t know of any way for a website to disable the browser’s dev tools.
    - lukevp 6y ago
      Makes sense, forgot there was a web client. Thanks!
  - throwaways885 6y ago
    Many products show this warning e.g. Google Photos, Facebook.
  - akersten 6y ago
    > Why does discord even let users access dev tools? This is trivially easy to disable in prod builds. Even if you disable the usual way to pop the dev tools open in desktop electron mode, this is a dangerous attitude. A malicious client can always edit the DOM, send arbitrary data to your server, read whatever you send back, etc. "Disabling the dev tools" is never the correct solution to any security problem.
    - lukevp 6y ago
      I didn’t say that they should do this for security of the execution environment of the code, I’m not sure how you got to that interpretation. The GP said that there is output to tell users not to compromise themselves by blindly pasting unsafe code, which is easily prevented by disabling dev tools altogether, and there is no reason for an end user to have access to dev tools in an electron app. The other replies are probably what the GP meant and were related to the web version of discord.
api 6y ago
Security concerns here are overblown, and this is IMHO more useful than WebRTC. This is how it should have been done to begin with, as well as the ugly hack known as web sockets. There should be some restrictions. No ports under 1024 without asking the user would go a long way. Anyone saying “the web isn’t an application platform” needs to just accept reality. That ship sailed almost 20 years ago.
- zepto 6y ago
  Overblown?
- xg15 6y ago
  > That ship sailed almost 20 years ago. Which would still be some time after the 1024 port distinction stopped being relevant for security.
Animats 6y ago
"Note that this capability is already available to Chrome Apps and Extensions and in no scenario will we be handing it out like candy to any website that asks nicely; [the API] will come with a higher barrier to use." Involving Google as a gatekeeper, of course. Google is trying to establish the level of control on the Web it has on Android.
- ffpip 6y ago
  Google just wants browsers to become more powerful cuz then more people will use Chromebooks. since everything can be done on a browser. Why do you think PWA's are being pushed so hard by google? So people can build PWA's that also run on Chromebooks. No need for native apps
  - dsun179 6y ago
    I think PWA's were pushed because the google cannot crawl native applications for its search engine.
    - tenuousemphasis 6y ago
      It's not any one of these reasons, it's likely all of them.
    - oakesm9 6y ago
      With a few tweaks to a native app, they can https://firebase.google.com/docs/app-indexing https://firebase.google.com/docs/app-indexing On Android they already crawl your app with various devices when you upload it to Google play and let you know about any crashes or accessibility issues. Nothing to stop them capturing the content too if they wanted.
  - dmitriid 6y ago
    > Google just wants browsers to become more powerful cuz then more people will use Chromebooks. This has little to do with Chromebooks. Google just want to be the single purveyor of the web, period. They already have the most popular browser. Firefox and Safari fought them on quite a few fronts [1]. Then Edge became Chrome. Now Mozilla basically laid off everyone. Safari only exists on MacOS and iPhones (a large market, yes, but small in the grand scheme of things). Chrome will only accelerate its blatant disregard of anyone and push more and more internally developed barely tested crap. [1] https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/ scroll down to harmful. Of course, many of those considered harmful are already implemented in Chrome. WebUSB, enabled by default in Chrome 61. Signed HTTP Exchanges, enabled by default in Chrome 73. Media Feeds, enabled by default in Chrome 85. And so on
adriancr 6y ago
Local apps - I can install once and check signature. - I can store them in a backup for later forensics if they do something bad. - I can firewall the process only to required services. - I can disable outside network access for local process. - I can analyze what it does before and after the fact. - They can be scanned by a malware scanner / virus scanner. Web apps: - need network access to load (and probably at runtime?),I cant firewall off... - can be refreshed by app provider - targetted to a specific user. - Traffic is bundled together with chromium? - I have no clue after the fact what happened. I cant sniff https traffic that app used to load its code... Bad App owners should be considered as well... or well intentioned but hacked ones...
- ReactiveJelly 6y ago
  We could bring those advantages to web apps, but there isn't money in it, so it won't happen yet.
  - adriancr 6y ago
    wouldn't that mean making them native apps, like something on top of electron? seems like reinventing the wheel.
    - kevingadd 6y ago
      The web platform has lots of tech now for fully offline web apps - the currently used term for this is a 'PWA' or Progressive Web Application. On Android and iOS in many cases there's a little option in your browser to install a website as a PWA, which puts it on your home screen and locally caches the assets. IIRC Twitter and Google Maps both support this for their website. Of course, writing a PWA is still a huge pain in the ass, and it doesn't give you those guarantees you mention from native apps - auditability, etc. But maybe it could get there, who knows...
- kbrosnan 6y ago
  There are ways to write webapps that work offline. https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Offline_Service_workers https://developer.mozilla.org/en-US/docs/Web/Progressive_web... and https://developers.google.com/web/fundamentals/codelabs/offline https://developers.google.com/web/fundamentals/codelabs/offl... go over what is needed to accomplish this.
nikkwong 6y ago
I don't know; I understand the cynicism here.. But can we assume an optimistic scenario where vendors are able to properly address the security implications and this enables web developers to build all kinds of new applications? I for one would love to be able to write web applications that could, say, control the lights in my house or smart devices. I hate interfacing with my phone to control these types of actions; I don't have the same bandwidth with my phone as I do with a full-blown computer, and therefore use my phone as little as possible. Therefore, I am closed off from really having fine-grained control over the devices on my LAN. Using the browser for this type of behavior would be awesome, IMO.
- edoceo 6y ago
  You lost me at "assume an optimistic scenario where vendors are able to properly address the security implication".
- adriancr 6y ago
  Home assistant?, ifttt?, raspberry pi with zigbee/zwave module?, smart devices with web hooks? You probably can control most smart devides with web apis, check out home assistant code for that... But they go to manufacturers portal. Too bad most manufacturers have an interest in you paying them subscriptions...
- nobodyandproud 6y ago
  The cynicism isn’t fully appreciated, if the optimistic scenario is assumed. Security is hard, and exposing more by default (or making it defacto required) is simply asking for trouble.
  - zepto 6y ago
    It’s funny - in the arguments about Apple and the App Store, I’ve seen plenty of people making the opposite case - ‘it’s not scary out there’, the security benefits of the App Store are ‘bullshit’, etc.
    - nobodyandproud 6y ago
modernerd 6y ago
The upcoming WebTransport/QuicTransport seems like it would address similar use-cases but with some built-in security considerations: https://web.dev/quictransport/ https://web.dev/quictransport/ https://wicg.github.io/web-transport/#privacy-security https://wicg.github.io/web-transport/#privacy-security
greenyoda 6y ago
See also yesterday's discussion: https://news.ycombinator.com/item?id=24249392 https://news.ycombinator.com/item?id=24249392
jart 6y ago
Could we please just fix native software development, so it doesn't suck, rather than adding the kitchen sink to web browsers? Web pages and JavaScript are the only universally trusted medium for sharing information and simple software. Making it possible for news websites to touch ethernet/usb/serial/gpu compromises that. Same goes for optimizations ilke JIT'ing and WebAssembly which have certainly done a great job making it possible for Gawker to reprogram the microcode in AMD K8 CPUs. Has the long tail of browser innovations made the web go faster? No. It went faster in 2010 IMHO. Whatever performance glut the geniuses who work on Chrome end up creating, it'll just get gobbled by more aggressive display ads and things like wild-eyed web component frameworks.
- coldtea 6y ago
  >Could we please just fix native software development, so it doesn't suck, rather than adding the kitchen sink to web browsers? Only in the sense that we can fix child hunger rather than spending money in e.g. condo development. That is, technically yes, but nobody with real means cares enough to do it, and those without means don't care enough or have enough power to pressure them...
- giancarlostoro 6y ago
  I think WASM will eventually produce the solution (hear me out before you tune out). I've been thinking about this for a while. So we have WASI[0], which doesn't yet address the UI issue, but there's half a dozen at least projects attempting to create runtimes for WASM. If most languages wind up compiling for WASM / WASI I think eventually a good effort could be done towards a WASI-UI or WASUI. Imagine if major OS platforms had a common UI framework that any language can produce a UI for, every major browser already supports WASM, why not a WASI based common runtime that would benefit every OS that supports it. I havent seen anyone else discussing this I've just been contemplating it for a while and I'm not sure what it would look like short of recreating a cross-platform X window system. However, as crazy as I sound my reason for this is simple: the issue with a lot of UI frameworks is that they tend to be language specific and are mostly useful to the languages they officially or directly support. If you can build a UI compatible stack that any language can target, you can gain a lot more adoption. I could easily see Rust, D, Go, etc supporting a common UI runtime. Electron sells itself rather easily cause most devs are familiar with HTML / CSS / JS. What we need is a cross-platform cross-language solution that isn't XML based but something a language can implement rather simply, or maybe even a compiler / standard library could manage. [0]: https://wasi.dev/ https://wasi.dev/
tasubotadas 6y ago
This is good. I guess. I have to develop relatively complex desktop-like applications on Chromium platform and I still feel that there are quite a few gaps until it can become a full desktop-able development platform. What's really missing for me is Android-like permission system where website could request permissions to access webcam, bluetooth, microphone, local storage, notifications, audio playback etc... At the moment, most of the access is provided by a number of different APIs, and, in some instances, it is heuristics-based decision (looking at audio playback).
klyrs 6y ago
Browsers in ring 0? Why not, it's 2020, anything could happen. Ditch WASM, more languages support ASM anyhow.
m1cl 6y ago
No.
totetsu 6y ago
Would webkit ever come along with this?
- millstone 6y ago
  Absolutely not.
sayusasugi 6y ago
Guys, "The Birth & Death of JavaScript" was supposed to be a joke. In all seriousness though, I'm beginning to get tired of webdevs reading OS books and going "oh, this would be a great addition to The Web™". Slap "in the browser" after a feature all operating systems have supported for decades and you'll hit the front page of HN in no time. What's old is new again and all that.
chmod775 6y ago
Have they even fixed websocket portscanning, canvas/audio/font fingerprinting, their crippled request blocking API etc. etc. before coming up with this new privacy and security nightmare? Can we maybe have a breather? There must be something about the term sandboxed environment that makes people want to poke holes in it.
wdr1 6y ago
I would have loved this in 2008 for the Beijing Olympics. My team created the point of sale, which included printing specialized tickets on specialized printers. These were going to be deployed across 1,000+ Bank of China locations, including many in pretty remote regions. Instead, we created an applet to handle the IO with the printer. It was a nightmare. All sorts of little differences between Windows XP & JRE made it ridiculous hard to debug. While the banks were given exact specs, the culture was such that whenever they would have a problem, they insist the machine was the right spec, which wasn't true 90% of the time.
cannedslime 6y ago
I am kind of against all of this, as it will inevitably lead to better fingerprinting. I already think its a serious breach of privacy that browsers supply hardware information such as joysticks and game controllers connected etc. without any kind of permission dialog. This is even worse because it allows for malicious websites to absolutely pwn the living sh*t out of the end user. You thought that ebays port scanning through websockets was bad, then just wait to see what they will use this for.
z3t4 6y ago
Would probably be better to have abstractions on the protocol level rather then raw ip or radio.

123 points by kiyanwang 6y ago

As a gopher dweeb forced to write hackarounds like an external helper to get Firefox into Gopherspace again (either a proxy server: https://addons.mozilla.org/en-US/firefox/addon/overbitewx/ https://addons.mozilla.org/en-US/firefox/addon/overbitewx/ or an actual executable: https://addons.mozilla.org/en-US/firefox/addon/overbitenx/ https://addons.mozilla.org/en-US/firefox/addon/overbitenx/), I'm torn. I would love to see the browser able to speak raw TCP again like I could when XUL/XPCOM extensions were still a thing. But this should really be restricted to browser extensions rather than arbitrary websites because we know someone is going to abuse it, and if we go full Windows Vista as proposed here and ask every connection to be confirmed it will eventually annoy people enough that security will be slackened (and then someone is going to abuse it).

dependenttypes 6y ago
The next thunderbird will contain OpenPGP support build-in because they are finally getting rid of XUL addon support and enigmail would not work with it.
- floatingatoll 6y ago
  Context: https://blog.thunderbird.net/2019/10/thunderbird-enigmail-and-openpgp/ https://blog.thunderbird.net/2019/10/thunderbird-enigmail-an... > "It has always been my goal to have OpenPGP support included in the core Thunderbird product."

kevingadd 6y ago

Until widespread code-signing exists on the web this seems incredibly reckless to expose. Even if you require https and put it behind a modal, history has shown that both of those measures are not impenetrable barriers to attackers and raw sockets open up a whole new set of attacks. HTTPS is basically useless for authenticating dangerous code: There are thousands of https domains out there that you can easily put your own code onto, and many of them have EV/DV certificates with reputable names like GitHub attached to them so there won't be any obvious red flags other than the text of the domain name. A prompt with a textbox in it is a barrier but it's not hard to get users to paste random stuff into text fields (just look at the big message that appears when you open devtools in Discord warning people not to paste stuff in there) and I agree with the concern that eventually the text box will be made friendlier. Many existing Dangerous APIs have worst-case attacks that just do things like talk to a USB device from a small list of authorized devices or talk to a MIDI keyboard. Raw Sockets are an entire new world of attacks: Hit a router or PC on the local network with a zero day and get persistent root on it, then use that to spread through the network and perform a ransomware attack, etc. The blink team needs to accept reality and catch up with where native apps have been for over a decade: Require code signing with revocable certificates and pair that with a mechanism to ensure the code was signed by the owner of the domain.

lukevp 6y ago
Why does discord even let users access dev tools? This is trivially easy to disable in prod builds. Seems odd. Is there a valid use case?
- ddulaney 6y ago
  I assume the parent is referring to the web version, where a big warning is output on the console of the browser’s built-in dev tools. I don’t know of any way for a website to disable the browser’s dev tools.
  - lukevp 6y ago
    Makes sense, forgot there was a web client. Thanks!
- throwaways885 6y ago
  Many products show this warning e.g. Google Photos, Facebook.
- akersten 6y ago
  > Why does discord even let users access dev tools? This is trivially easy to disable in prod builds. Even if you disable the usual way to pop the dev tools open in desktop electron mode, this is a dangerous attitude. A malicious client can always edit the DOM, send arbitrary data to your server, read whatever you send back, etc. "Disabling the dev tools" is never the correct solution to any security problem.
  - lukevp 6y ago
    I didn’t say that they should do this for security of the execution environment of the code, I’m not sure how you got to that interpretation. The GP said that there is output to tell users not to compromise themselves by blindly pasting unsafe code, which is easily prevented by disabling dev tools altogether, and there is no reason for an end user to have access to dev tools in an electron app. The other replies are probably what the GP meant and were related to the web version of discord.

api 6y ago

Security concerns here are overblown, and this is IMHO more useful than WebRTC. This is how it should have been done to begin with, as well as the ugly hack known as web sockets. There should be some restrictions. No ports under 1024 without asking the user would go a long way. Anyone saying “the web isn’t an application platform” needs to just accept reality. That ship sailed almost 20 years ago.

zepto 6y ago
Overblown?
xg15 6y ago
> That ship sailed almost 20 years ago. Which would still be some time after the 1024 port distinction stopped being relevant for security.

Animats 6y ago

"Note that this capability is already available to Chrome Apps and Extensions and in no scenario will we be handing it out like candy to any website that asks nicely; [the API] will come with a higher barrier to use." Involving Google as a gatekeeper, of course. Google is trying to establish the level of control on the Web it has on Android.

ffpip 6y ago
Google just wants browsers to become more powerful cuz then more people will use Chromebooks. since everything can be done on a browser. Why do you think PWA's are being pushed so hard by google? So people can build PWA's that also run on Chromebooks. No need for native apps
- dsun179 6y ago
  I think PWA's were pushed because the google cannot crawl native applications for its search engine.
  - tenuousemphasis 6y ago
    It's not any one of these reasons, it's likely all of them.
  - oakesm9 6y ago
    With a few tweaks to a native app, they can https://firebase.google.com/docs/app-indexing https://firebase.google.com/docs/app-indexing On Android they already crawl your app with various devices when you upload it to Google play and let you know about any crashes or accessibility issues. Nothing to stop them capturing the content too if they wanted.
- dmitriid 6y ago
  > Google just wants browsers to become more powerful cuz then more people will use Chromebooks. This has little to do with Chromebooks. Google just want to be the single purveyor of the web, period. They already have the most popular browser. Firefox and Safari fought them on quite a few fronts [1]. Then Edge became Chrome. Now Mozilla basically laid off everyone. Safari only exists on MacOS and iPhones (a large market, yes, but small in the grand scheme of things). Chrome will only accelerate its blatant disregard of anyone and push more and more internally developed barely tested crap. [1] https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/ scroll down to harmful. Of course, many of those considered harmful are already implemented in Chrome. WebUSB, enabled by default in Chrome 61. Signed HTTP Exchanges, enabled by default in Chrome 73. Media Feeds, enabled by default in Chrome 85. And so on

adriancr 6y ago

Local apps - I can install once and check signature. - I can store them in a backup for later forensics if they do something bad. - I can firewall the process only to required services. - I can disable outside network access for local process. - I can analyze what it does before and after the fact. - They can be scanned by a malware scanner / virus scanner. Web apps: - need network access to load (and probably at runtime?),I cant firewall off... - can be refreshed by app provider - targetted to a specific user. - Traffic is bundled together with chromium? - I have no clue after the fact what happened. I cant sniff https traffic that app used to load its code... Bad App owners should be considered as well... or well intentioned but hacked ones...

ReactiveJelly 6y ago
We could bring those advantages to web apps, but there isn't money in it, so it won't happen yet.
- adriancr 6y ago
  wouldn't that mean making them native apps, like something on top of electron? seems like reinventing the wheel.
  - kevingadd 6y ago
    The web platform has lots of tech now for fully offline web apps - the currently used term for this is a 'PWA' or Progressive Web Application. On Android and iOS in many cases there's a little option in your browser to install a website as a PWA, which puts it on your home screen and locally caches the assets. IIRC Twitter and Google Maps both support this for their website. Of course, writing a PWA is still a huge pain in the ass, and it doesn't give you those guarantees you mention from native apps - auditability, etc. But maybe it could get there, who knows...
kbrosnan 6y ago
There are ways to write webapps that work offline. https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Offline_Service_workers https://developer.mozilla.org/en-US/docs/Web/Progressive_web... and https://developers.google.com/web/fundamentals/codelabs/offline https://developers.google.com/web/fundamentals/codelabs/offl... go over what is needed to accomplish this.

nikkwong 6y ago

I don't know; I understand the cynicism here.. But can we assume an optimistic scenario where vendors are able to properly address the security implications and this enables web developers to build all kinds of new applications? I for one would love to be able to write web applications that could, say, control the lights in my house or smart devices. I hate interfacing with my phone to control these types of actions; I don't have the same bandwidth with my phone as I do with a full-blown computer, and therefore use my phone as little as possible. Therefore, I am closed off from really having fine-grained control over the devices on my LAN. Using the browser for this type of behavior would be awesome, IMO.

edoceo 6y ago
You lost me at "assume an optimistic scenario where vendors are able to properly address the security implication".
adriancr 6y ago
Home assistant?, ifttt?, raspberry pi with zigbee/zwave module?, smart devices with web hooks? You probably can control most smart devides with web apis, check out home assistant code for that... But they go to manufacturers portal. Too bad most manufacturers have an interest in you paying them subscriptions...
nobodyandproud 6y ago
The cynicism isn’t fully appreciated, if the optimistic scenario is assumed. Security is hard, and exposing more by default (or making it defacto required) is simply asking for trouble.
- zepto 6y ago
  It’s funny - in the arguments about Apple and the App Store, I’ve seen plenty of people making the opposite case - ‘it’s not scary out there’, the security benefits of the App Store are ‘bullshit’, etc.
  - nobodyandproud 6y ago

modernerd 6y ago

The upcoming WebTransport/QuicTransport seems like it would address similar use-cases but with some built-in security considerations: https://web.dev/quictransport/ https://web.dev/quictransport/ https://wicg.github.io/web-transport/#privacy-security https://wicg.github.io/web-transport/#privacy-security

greenyoda 6y ago

See also yesterday's discussion: https://news.ycombinator.com/item?id=24249392 https://news.ycombinator.com/item?id=24249392

jart 6y ago

Could we please just fix native software development, so it doesn't suck, rather than adding the kitchen sink to web browsers? Web pages and JavaScript are the only universally trusted medium for sharing information and simple software. Making it possible for news websites to touch ethernet/usb/serial/gpu compromises that. Same goes for optimizations ilke JIT'ing and WebAssembly which have certainly done a great job making it possible for Gawker to reprogram the microcode in AMD K8 CPUs. Has the long tail of browser innovations made the web go faster? No. It went faster in 2010 IMHO. Whatever performance glut the geniuses who work on Chrome end up creating, it'll just get gobbled by more aggressive display ads and things like wild-eyed web component frameworks.

coldtea 6y ago
>Could we please just fix native software development, so it doesn't suck, rather than adding the kitchen sink to web browsers? Only in the sense that we can fix child hunger rather than spending money in e.g. condo development. That is, technically yes, but nobody with real means cares enough to do it, and those without means don't care enough or have enough power to pressure them...
giancarlostoro 6y ago
I think WASM will eventually produce the solution (hear me out before you tune out). I've been thinking about this for a while. So we have WASI[0], which doesn't yet address the UI issue, but there's half a dozen at least projects attempting to create runtimes for WASM. If most languages wind up compiling for WASM / WASI I think eventually a good effort could be done towards a WASI-UI or WASUI. Imagine if major OS platforms had a common UI framework that any language can produce a UI for, every major browser already supports WASM, why not a WASI based common runtime that would benefit every OS that supports it. I havent seen anyone else discussing this I've just been contemplating it for a while and I'm not sure what it would look like short of recreating a cross-platform X window system. However, as crazy as I sound my reason for this is simple: the issue with a lot of UI frameworks is that they tend to be language specific and are mostly useful to the languages they officially or directly support. If you can build a UI compatible stack that any language can target, you can gain a lot more adoption. I could easily see Rust, D, Go, etc supporting a common UI runtime. Electron sells itself rather easily cause most devs are familiar with HTML / CSS / JS. What we need is a cross-platform cross-language solution that isn't XML based but something a language can implement rather simply, or maybe even a compiler / standard library could manage. [0]: https://wasi.dev/ https://wasi.dev/

tasubotadas 6y ago

This is good. I guess. I have to develop relatively complex desktop-like applications on Chromium platform and I still feel that there are quite a few gaps until it can become a full desktop-able development platform. What's really missing for me is Android-like permission system where website could request permissions to access webcam, bluetooth, microphone, local storage, notifications, audio playback etc... At the moment, most of the access is provided by a number of different APIs, and, in some instances, it is heuristics-based decision (looking at audio playback).

klyrs 6y ago

Browsers in ring 0? Why not, it's 2020, anything could happen. Ditch WASM, more languages support ASM anyhow.

m1cl 6y ago

No.

totetsu 6y ago

Would webkit ever come along with this?

millstone 6y ago
Absolutely not.

sayusasugi 6y ago

Guys, "The Birth & Death of JavaScript" was supposed to be a joke. In all seriousness though, I'm beginning to get tired of webdevs reading OS books and going "oh, this would be a great addition to The Web™". Slap "in the browser" after a feature all operating systems have supported for decades and you'll hit the front page of HN in no time. What's old is new again and all that.

chmod775 6y ago

Have they even fixed websocket portscanning, canvas/audio/font fingerprinting, their crippled request blocking API etc. etc. before coming up with this new privacy and security nightmare? Can we maybe have a breather? There must be something about the term sandboxed environment that makes people want to poke holes in it.

wdr1 6y ago

I would have loved this in 2008 for the Beijing Olympics. My team created the point of sale, which included printing specialized tickets on specialized printers. These were going to be deployed across 1,000+ Bank of China locations, including many in pretty remote regions. Instead, we created an applet to handle the IO with the printer. It was a nightmare. All sorts of little differences between Windows XP & JRE made it ridiculous hard to debug. While the banks were given exact specs, the culture was such that whenever they would have a problem, they insist the machine was the right spec, which wasn't true 90% of the time.

cannedslime 6y ago

I am kind of against all of this, as it will inevitably lead to better fingerprinting. I already think its a serious breach of privacy that browsers supply hardware information such as joysticks and game controllers connected etc. without any kind of permission dialog. This is even worse because it allows for malicious websites to absolutely pwn the living sh*t out of the end user. You thought that ebays port scanning through websockets was bad, then just wait to see what they will use this for.

z3t4 6y ago

Would probably be better to have abstractions on the protocol level rather then raw ip or radio.