Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Direct Sockets API in Chrome 131

chromestatus.com

Post reply on HN
Print view View original

131–140 of 171 posts

Re: Direct Sockets API in Chrome 131

#131

Post by mmis1000 »

chrismorgan wrote: post #11
phildenhoff wrote: post #4

Earlier quoted context omitted.

Interesting — the Firefox team’s response was very negative, but didn’t (in my reading) address use of the API as being part of an otherwise essentially trusted app (as opposed to being an API available to any website). In reading their comments, I also felt the API was a bad idea. Especially when technology like Electron or Tauri exist, which can do those TCP or UDP connections. But IWA serves to displace Electron,…

> but didn’t (in my reading) address use of the API as being part of an otherwise essentially trusted app That’s what the Narrower Applicability section is about https://github.com/mozilla/standards-positions/issues/431#is... >. It exposes new vulnerabilities because of IP address reuse across networks, and DNS rebinding.

- It is possible, if not likely, that an attacker will control name resolution for a chosen name. This allows them to provide an IP address (or a redirect that uses CNAME or similar) that could enable request forgery.

This is quite trival, not even possible though. DNS server is quite a simple protocol. Writing a dns that reflect every request from aaa-bbb-ccc-ddd.domain.test to ip aaa.bbb.ccc.ddd won't take you even for a day. And in fact this already existed in the wild.

Re: Direct Sockets API in Chrome 131

#132

Post by modeless »

IshKebab wrote: post #129
bpfrh wrote: post #66

Earlier quoted context omitted.

You can also use WebTransport with streams for tcp and datagramms for udp https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...

Not peer to peer though presumably?

Yes and not in Safari yet either. Someday I hope that all parts of WebRTC can be replaced with smaller and better APIs like this. But for now we're stuck with WebRTC.

Re: Direct Sockets API in Chrome 131

#133

Post by mmis1000 »

hipadev23 wrote: post #59

What about WebTransport? I thought that was the http/3 upgrade to WebSockets that supported unreliable and out-of-order messaging

I think WebRTC data channels will be a good alternative if you want peer to peer connection. WebTransport is strictly for Client-Server architecture only.

Re: Direct Sockets API in Chrome 131

#135

Post by sroussey »

apitman wrote: post #116
remram wrote: post #101

Earlier quoted context omitted.

It doesn't work now so it's never going to work?

GitHub might work someday. Wide enough adoption that you can host a service without an IPv4 address will never happen.

Honestly, it could be a feature rather than a bug…

Re: Direct Sockets API in Chrome 131

#137

Post by [deleted] »

troupo wrote: post #95
meiraleal wrote: post #89

Earlier quoted context omitted.

Cry me a river. Apple doesn't need you to defend their strategic and intentional PWA boycott.

Which part of "is not a w3c standard and not any standards track" do you not understand? Do you understand that for something to become a standard, it needs two independent implementations? And a consensus on API? Do you understand that "not on any standards track" means it's Chrome and only Chrome pushing this? That Firefox isn't interested in this either? Do you understand that blaming Apple for everything is borde…

[deleted]

Re: Direct Sockets API in Chrome 131

#138

Post by mschuster91 »

crote wrote: post #38
chocolatkey wrote: post #3

When reading https://github.com/WICG/direct-sockets/blob/main/docs%2Fexpl... , it's noted this is part of the "isolated web apps" proposal: https://github.com/WICG/isolated-web-apps/blob/main/README.m... , which is important context because the obvious reaction to this is the security nightmare

That doesn't really make it any better, if you ask me. The entire Isolated Web Apps proposal is a massive breakdown of the well-established boundaries provided by browsers. Every user understands two things about the internet: 1) check the URL before entering any sensitive data, and 2) don't run random stuff you download. The latter is heavily enforced by both Chrome and Windows complaining quite a bit if you're tryi…

> If you follow those two basic things, websites cannot hurt your machine.

Oh yes they can. Quite a bunch of "helper" apps - printer drivers are a bit notorious IME - open up local HTTP servers, and not all of them enforce CORS properly. Add some RCE or privilege escalation vulnerability in that helper app and you got yourself an 0wn-from-the-browser exploit chain.

Post reply on HN