Chromium devs want the browser to talk to devices directly via TCP,UDP(theregister.com)
theregister.com
Chromium devs want the browser to talk to devices directly via TCP,UDP
https://www.theregister.com/2020/08/22/chromium_devs_raw_sockets?
37 comments
Mitigated how? Websites are going to force users to click "allow."
The only websites which would force you are:
- legitimate websites using this feature for valid purposes, such as to control devices on your local network
- targeted malware attacks trying to hack devices on your local network
I’m certain we will not start getting popups for this on any mainstream website.
So as long as this permissions thing is more than a simple yes/no dialog, I’m not worried.
- legitimate websites using this feature for valid purposes, such as to control devices on your local network
- targeted malware attacks trying to hack devices on your local network
I’m certain we will not start getting popups for this on any mainstream website.
So as long as this permissions thing is more than a simple yes/no dialog, I’m not worried.
I’m not convinced because many of those “legitimate websites” don’t have a very good track record of respecting user security and privacy. Given past events, I find it hard to believe that the ad industry or the entertainment industry or any other industry won’t abuse access to these APIs. To make it worse, if popular websites wants permission to use these highly-invasive APIs, users would have no choice but to cave in. This worries me a lot.
Even if you don’t consider bad intentions, the security implications are huge. Imagine if Zoom had used this feature. The security fiasco a few months back would’ve been made a whole lot worse.
Even if you don’t consider bad intentions, the security implications are huge. Imagine if Zoom had used this feature. The security fiasco a few months back would’ve been made a whole lot worse.
The “legitimate websites” that disrespect privacy and security almost always do that in a way transparent to the user (ignoring the cookie prompts, but I don’t think that’s a fair comparison). For example, news websites could try and access my location info, but they don’t because there’s a permission prompt which would appear.
For this particular feature, there can be no meaningful transparency whatsoever. Permission to use TCP or UDP is very, very different from permission to access location info. Any user can easily imagine the possible consequences of allowing the latter, but the definitely not the former. Heck, no one can possibly know the actual consequences unless someone goes through the effort to reverse engineer websites using this feature.
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.
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.
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.
> 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.
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.
Users have been dialog blind for decades. They instinctively click OK. This hasn’t been helped by the laws passed forcing almost every website to pop up a “we use cookies” dialog. As usual, anytime the government gets involved in regulating anything it doesn’t understand it makes the problem worse.
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
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
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.
Yeah, rename IETF to GETF (Google Engineering Task Force). The only thing that prevents total domination today is iOS with its WebKit only policy.
Might that be one of the reasons Apple keeps that strict rule? Other than the disallowing of W+X of course.
For once I actually hope apple keeps up with that policy just to spite google
It's quite ironic when one company's anti-competitive behavior paradoxically results in them preventing another company from achieving total monoculture domination.
Seriously this. Ironically Apple defends us from monopoly, maybe accidentally.
> .. 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.
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.
worse because :
1) its competent at doing its job
2) google dont care too much about their products once they release them.
2) google dont care too much about their products once they release them.
ChromeOS has won, expect ads for Web development to eventually turn into Chrome developer.
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.
> 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?
So websites will have to apply and get Google approval?
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?
Is there any precedent for that sort of thing in Chrome?
"Please install this extension" is one that springs to mind.
Disclaimer: I work at Google, but unrelated to any of this.
Disclaimer: I work at Google, but unrelated to any of this.
Thank you for the disclaimer even if it wasn't strictly related.
"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.ht...
You mean the things they've been talking about deprecating since 2016?
https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
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.
Cross platform "native APIs" I hope?
Also whats "in it" for Google and Microsoft to promote PWAs, ie what would make them withdraw their support to PWAs?
Also whats "in it" for Google and Microsoft to promote PWAs, ie what would make them withdraw their support to PWAs?
Depends, cross platform native like APIs are one thing.
The other is when an application is packaged for the store, the native APIs are automatically made available, no need for you to manually write any FFI.
This how it used to work for old Edge, and Edge Chromium might eventually get something similar.
https://docs.microsoft.com/en-us/microsoft-edge/progressive-...
And on Android,
https://developers.google.com/web/android/trusted-web-activi...
The other is when an application is packaged for the store, the native APIs are automatically made available, no need for you to manually write any FFI.
This how it used to work for old Edge, and Edge Chromium might eventually get something similar.
https://docs.microsoft.com/en-us/microsoft-edge/progressive-...
And on Android,
https://developers.google.com/web/android/trusted-web-activi...
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?
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?
Chrome uses setuid, so it’s already root-ish.
> 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.
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.
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
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.
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.
Any issues that exist about using it for DDoS attacks already exist for the available network request APIs.