8 ms·

Chromium devs want the browser to talk to devices directly via TCP,UDP

46 points by dazhbog 6y ago

throwaway189262 6y ago
Chrome's monopoly is going to be worse than the IE days. Microsoft was more negligent than intentional. Google has been waiting for the day for a decade. Look at what happened to Android. Google play services started out innocent, now it's half the OS. And "safety net", like the "patriot" act, is the nail in the coffin. Buckle in bois for some good old fashioned monopoly fun
- dimator 6y ago
  I thought Play Services was designed to house more and more of the OS, so that Google could get back some control over updates, instead of letting device manufacturers never update their Android versions.
  - throwaway189262 6y ago
    It's also conveniently not open source
    - rahkiin 6y ago
      And not available when sideloading
- nuker 6y ago
  Yeah, rename IETF to GETF (Google Engineering Task Force). The only thing that prevents total domination today is iOS with its WebKit only policy.
  - rahkiin 6y ago
    Might that be one of the reasons Apple keeps that strict rule? Other than the disallowing of W+X of course.
  - 0xdeadb00f 6y ago
    For once I actually hope apple keeps up with that policy just to spite google
  - needle0 6y ago
    It's quite ironic when one company's anti-competitive behavior paradoxically results in them preventing another company from achieving total monoculture domination.
    - nuker 6y ago
      > .. company's anti-competitive behavior .. I'm an Apple user and I paid premium specifically for this "anti-competitive behavior". I'm totally behind its policies. I feel protected from malware, scams and privacy leaks. Developers may complain all they want, not my problem.
    - fomine3 6y ago
      Seriously this. Ironically Apple defends us from monopoly, maybe accidentally.
- senectus1 6y ago
  worse because : 1) its competent at doing its job 2) google dont care too much about their products once they release them.
- pjmlp 6y ago
  ChromeOS has won, expect ads for Web development to eventually turn into Chrome developer.
- devwastaken 6y ago
  Chromium won the tech war, and V8 won the Js war. The only way to compete with chromium now would be to put webkit onto windows, but even then webkit is just duplicating the standards.
nuker 6y ago
> Google senior staff software engineer Alex Russell said, "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" So websites will have to apply and get Google approval?
- ridiculous_fish 6y ago
  I had the same question, but I think a more generous read is that there will be some permissions flow with higher friction than the typical pop-up dialog. Is there any precedent for that sort of thing in Chrome?
  - lrem 6y ago
    "Please install this extension" is one that springs to mind. Disclaimer: I work at Google, but unrelated to any of this.
    - spicybright 6y ago
      Thank you for the disclaimer even if it wasn't strictly related.
- duskwuff 6y ago
  "Chrome Apps"?? You mean the things they've been talking about deprecating since 2016? https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
  - pjmlp 6y ago
    PWAs have replaced Chrome apps, hence why Microsoft and Google are making them as powerful as native apps, specially if packaged via the store, which even exposes native APIs as browser extensions.
    - aitchnyu 6y ago
onion2k 6y ago
A lot of the security concerns listed in the article, while entirely valid, would be mitigated by a combination of a permissions check similar to the ones that already exist for things like the Clipboard API and a UI element to show what connections are in use and sending data. Any issues that exist about using it for DDoS attacks already exist for the available network request APIs.
- waon 6y ago
  Mitigated how? Websites are going to force users to click "allow."
  - onion2k 6y ago
    Websites are going to force users to click "allow." That's a bit strong. A website can't force a user to anything. The point is that to use the feature nefariously without the user knowing it's happening is relatively easy to prevent by putting the feature behind a permissions flag. If the user actively wants a website to be able to make connections they can say yes. If the user doesn't know then they ought to be saying no, but really they won't and they'll say yes if the warning isn't scary enough. The browser vendors could also do things like throttling connections or asking for permission again if things look too weird.
    - ResidentSleeper 6y ago
      Most people I know just click "yes" on all popups until the website starts working. In between every other website asking for notification/location permissions and a huge pile of GDPR popups (which are actively hostile towards users that attempt to opt-out), we've managed to condition web users into routinely agreeing to give up their privacy and security. Hooray.
      - nuker 6y ago
        > Most people I know just click "yes" on all popups until the website starts working This. Defaults matter. You cannot introduce a privacy sensitive feature just with a permission dialog box. You must expect that most users just click through, and continue to protect those "dumb" users.
saxonww 6y ago
Some thoughts The design proposal doesn't say one way or the other, but I guess/hope this would be plumbing through to the underlying OS IP stack, otherwise your browser would need to obtain its own IP address. The source repo for this is called raw-sockets but nothing implies that's what they would actually use/require; raw sockets usually require root. The proposed API is just to open sockets. Does this mean all these non-HTTP protocols are going to be implemented separately? Will they ship with Chromium, or are we looking at web sites sending down a bunch of wasm-compiled protocol implementations? Honestly, the developer thread was really enthusiastic but didn't seem to account for the vast gulf between "can open a tcp socket" and "functional mail client". It's interesting that in the security mitigations section of the explainer doc, the author is explicit that listening for incoming connections is not part of the proposal _yet_. The developer thread is full of ideas that would require incoming connections (DHT specifically) though. Also, the idea that this unlocks communication with legacy systems seems counter to the idea that hostnames resolving private addresses won't work. I guess you get around this by making your app have connection profiles (common with RDP, Chrome OS SSH app does this, etc.). I think this makes the most sense if you consider a web browser to actually be a rich UI toolkit that happens to speak HTTP. Should these developers get to write other network clients with CSS/JS frontends, or not?
- withinboredom 6y ago
  Chrome uses setuid, so it’s already root-ish.
- henriquez 6y ago
  > Should these developers get to write other network clients with CSS/JS frontends, or not? Google is wrecking web standards with their IE6 browser, shoving it full of unrelated crap to make their jobs easier and then strong-arming everyone to pretend they actually followed a process. Chrome sync, Web MIDI or the fact WebRTC shipped with a zero day firmly baked into a draft spec that couldn’t be fixed for years. Ok Google.
waon 6y ago
This proposal would make ebay's job of port scanning their users a lot easier. https://news.ycombinator.com/item?id=23436775 https://news.ycombinator.com/item?id=23436775
shirshak55 6y ago
Welcome to Chrome monopoly. Show as off as u are doing opensource (yeah 90% opensource) but hide DRM , do some weird trick to make YouTube fast using some shadow/hidden api, spread ads like malware using extension manifest v3 . Look at Andriod how hard it is to use ad blocker.
devwastaken 6y ago
This would be great if it could be done sanely, but it can't. A quick example would be making an ntp background service in wasm that can sync time for group video playback.

46 points by dazhbog 6y ago

Chrome's monopoly is going to be worse than the IE days. Microsoft was more negligent than intentional. Google has been waiting for the day for a decade. Look at what happened to Android. Google play services started out innocent, now it's half the OS. And "safety net", like the "patriot" act, is the nail in the coffin. Buckle in bois for some good old fashioned monopoly fun

dimator 6y ago
I thought Play Services was designed to house more and more of the OS, so that Google could get back some control over updates, instead of letting device manufacturers never update their Android versions.
- throwaway189262 6y ago
  It's also conveniently not open source
  - rahkiin 6y ago
    And not available when sideloading
nuker 6y ago
Yeah, rename IETF to GETF (Google Engineering Task Force). The only thing that prevents total domination today is iOS with its WebKit only policy.
- rahkiin 6y ago
  Might that be one of the reasons Apple keeps that strict rule? Other than the disallowing of W+X of course.
- 0xdeadb00f 6y ago
  For once I actually hope apple keeps up with that policy just to spite google
- needle0 6y ago
  It's quite ironic when one company's anti-competitive behavior paradoxically results in them preventing another company from achieving total monoculture domination.
  - nuker 6y ago
    > .. company's anti-competitive behavior .. I'm an Apple user and I paid premium specifically for this "anti-competitive behavior". I'm totally behind its policies. I feel protected from malware, scams and privacy leaks. Developers may complain all they want, not my problem.
  - fomine3 6y ago
    Seriously this. Ironically Apple defends us from monopoly, maybe accidentally.
senectus1 6y ago
worse because : 1) its competent at doing its job 2) google dont care too much about their products once they release them.
pjmlp 6y ago
ChromeOS has won, expect ads for Web development to eventually turn into Chrome developer.
devwastaken 6y ago
Chromium won the tech war, and V8 won the Js war. The only way to compete with chromium now would be to put webkit onto windows, but even then webkit is just duplicating the standards.

nuker 6y ago

> Google senior staff software engineer Alex Russell said, "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" So websites will have to apply and get Google approval?

ridiculous_fish 6y ago
I had the same question, but I think a more generous read is that there will be some permissions flow with higher friction than the typical pop-up dialog. Is there any precedent for that sort of thing in Chrome?
- lrem 6y ago
  "Please install this extension" is one that springs to mind. Disclaimer: I work at Google, but unrelated to any of this.
  - spicybright 6y ago
    Thank you for the disclaimer even if it wasn't strictly related.
duskwuff 6y ago
"Chrome Apps"?? You mean the things they've been talking about deprecating since 2016? https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
- pjmlp 6y ago
  PWAs have replaced Chrome apps, hence why Microsoft and Google are making them as powerful as native apps, specially if packaged via the store, which even exposes native APIs as browser extensions.
  - aitchnyu 6y ago

onion2k 6y ago

A lot of the security concerns listed in the article, while entirely valid, would be mitigated by a combination of a permissions check similar to the ones that already exist for things like the Clipboard API and a UI element to show what connections are in use and sending data. Any issues that exist about using it for DDoS attacks already exist for the available network request APIs.

waon 6y ago
Mitigated how? Websites are going to force users to click "allow."
- onion2k 6y ago
  Websites are going to force users to click "allow." That's a bit strong. A website can't force a user to anything. The point is that to use the feature nefariously without the user knowing it's happening is relatively easy to prevent by putting the feature behind a permissions flag. If the user actively wants a website to be able to make connections they can say yes. If the user doesn't know then they ought to be saying no, but really they won't and they'll say yes if the warning isn't scary enough. The browser vendors could also do things like throttling connections or asking for permission again if things look too weird.
  - ResidentSleeper 6y ago
    Most people I know just click "yes" on all popups until the website starts working. In between every other website asking for notification/location permissions and a huge pile of GDPR popups (which are actively hostile towards users that attempt to opt-out), we've managed to condition web users into routinely agreeing to give up their privacy and security. Hooray.
    - nuker 6y ago
      > Most people I know just click "yes" on all popups until the website starts working This. Defaults matter. You cannot introduce a privacy sensitive feature just with a permission dialog box. You must expect that most users just click through, and continue to protect those "dumb" users.

saxonww 6y ago

Some thoughts The design proposal doesn't say one way or the other, but I guess/hope this would be plumbing through to the underlying OS IP stack, otherwise your browser would need to obtain its own IP address. The source repo for this is called raw-sockets but nothing implies that's what they would actually use/require; raw sockets usually require root. The proposed API is just to open sockets. Does this mean all these non-HTTP protocols are going to be implemented separately? Will they ship with Chromium, or are we looking at web sites sending down a bunch of wasm-compiled protocol implementations? Honestly, the developer thread was really enthusiastic but didn't seem to account for the vast gulf between "can open a tcp socket" and "functional mail client". It's interesting that in the security mitigations section of the explainer doc, the author is explicit that listening for incoming connections is not part of the proposal _yet_. The developer thread is full of ideas that would require incoming connections (DHT specifically) though. Also, the idea that this unlocks communication with legacy systems seems counter to the idea that hostnames resolving private addresses won't work. I guess you get around this by making your app have connection profiles (common with RDP, Chrome OS SSH app does this, etc.). I think this makes the most sense if you consider a web browser to actually be a rich UI toolkit that happens to speak HTTP. Should these developers get to write other network clients with CSS/JS frontends, or not?

withinboredom 6y ago
Chrome uses setuid, so it’s already root-ish.
henriquez 6y ago
> Should these developers get to write other network clients with CSS/JS frontends, or not? Google is wrecking web standards with their IE6 browser, shoving it full of unrelated crap to make their jobs easier and then strong-arming everyone to pretend they actually followed a process. Chrome sync, Web MIDI or the fact WebRTC shipped with a zero day firmly baked into a draft spec that couldn’t be fixed for years. Ok Google.

waon 6y ago

This proposal would make ebay's job of port scanning their users a lot easier. https://news.ycombinator.com/item?id=23436775 https://news.ycombinator.com/item?id=23436775

shirshak55 6y ago

Welcome to Chrome monopoly. Show as off as u are doing opensource (yeah 90% opensource) but hide DRM , do some weird trick to make YouTube fast using some shadow/hidden api, spread ads like malware using extension manifest v3 . Look at Andriod how hard it is to use ad blocker.

devwastaken 6y ago

This would be great if it could be done sanely, but it can't. A quick example would be making an ntp background service in wasm that can sync time for group video playback.