Chromium devs want the browser to talk to devices directly via TCP,UDP
theregister.com
theregister.com
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'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?
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...
Is there any precedent for that sort of thing in Chrome?
Disclaimer: I work at Google, but unrelated to any of this.
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.