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
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.
It's quite ironic when one company's anti-competitive behavior paradoxically results in them preventing another company from achieving total monoculture domination.
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.
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?
> 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.
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.
37 comments
[ 5.6 ms ] story [ 112 ms ] threadLook 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'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.
2) google dont care too much about their products once they release them.
So websites will have to apply and get Google approval?
Is there any precedent for that sort of thing in Chrome?
Disclaimer: I work at Google, but unrelated to any of this.
You mean the things they've been talking about deprecating since 2016?
https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
Also whats "in it" for Google and Microsoft to promote PWAs, ie what would make them withdraw their support to PWAs?
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...
Any issues that exist about using it for DDoS attacks already exist for the available network request APIs.
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.
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.
- 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.
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 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?
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.
https://news.ycombinator.com/item?id=23436775