
Chromium devs want the browser to talk to devices directly via TCP,UDP - dazhbog
https://www.theregister.com/2020/08/22/chromium_devs_raw_sockets?
======
throwaway189262
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

~~~
nuker
Yeah, rename IETF to GETF (Google Engineering Task Force). The only thing that
prevents total domination today is iOS with its WebKit only policy.

~~~
needle0
It's quite ironic when one company's anti-competitive behavior paradoxically
results in them preventing another company from achieving total monoculture
domination.

~~~
fomine3
Seriously this. Ironically Apple defends us from monopoly, maybe accidentally.

------
nuker
> 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?

~~~
duskwuff
"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...](https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html)

~~~
pjmlp
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
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?

~~~
pjmlp
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-...](https://docs.microsoft.com/en-us/microsoft-
edge/progressive-web-apps-edgehtml/windows-features)

And on Android,

[https://developers.google.com/web/android/trusted-web-
activi...](https://developers.google.com/web/android/trusted-web-activity)

------
onion2k
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
Mitigated how? Websites are going to force users to click "allow."

~~~
onion2k
_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
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
> 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.

------
waon
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)

------
saxonww
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?

~~~
henriquez
> 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.

------
shirshak55
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
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.

