I think a lot of people don't realize it's possible to use UDP in browsers today with WebRTC DataChannel. I have a demo of multiplayer Quake III using peer-to-peer UDP here: <a href="https://thelongestyard.link/" rel="nofollow">https://thelongestyard.link/</a><p>Direct sockets will have their uses for compatibility with existing applications, but it's possible to do almost any kind of networking you want on the web if you control both sides of the connection.
When reading <a href="https://github.com/WICG/direct-sockets/blob/main/docs%2Fexplainer.md">https://github.com/WICG/direct-sockets/blob/main/docs%2Fexpl...</a>, it's noted this is part of the "isolated web apps" proposal: <a href="https://github.com/WICG/isolated-web-apps/blob/main/README.md">https://github.com/WICG/isolated-web-apps/blob/main/README.m...</a> , which is important context because the obvious reaction to this is the security nightmare
I found this issue indicating a bad idea for end user safety:<p><a href="https://github.com/mozilla/standards-positions/issues/431">https://github.com/mozilla/standards-positions/issues/431</a>
I prefer web apps to native apps any day. However, web apps are limited by what they can do.<p>But what they can do is not consistent - for example, it can take your picture and listen to your microphone if you give permissions; but it can't open a socket. Another example: Chrome came out with an File System Access API [2] in August; it's fantastic (I am using it) and it allows a class of native apps to be replaced by Web Apps. As a user, I don't mind having to jump through hoops (as a user) and giant warning screens to accept that permission - but I want this ability on the Web Platform.<p>For Web Apps to be able to complete with native apps, we need more flexibility Mozilla. [1]<p>[1]: <a href="https://mozilla.github.io/standards-positions/" rel="nofollow">https://mozilla.github.io/standards-positions/</a>
[2]: <a href="https://developer.chrome.com/docs/capabilities/web-apis/file-system-access" rel="nofollow">https://developer.chrome.com/docs/capabilities/web-apis/file...</a>
I saw this proposal years ago now and was initially excited about it. But seeing how people envisioned the APIs, usage, etc, made me realize that it was already too locked down. Being able to have something that ran on any browser is the core benefit here. I get that there are security concerns but unfortunately everyone who worked on this was too paranoid and dismissive to design something open (yet secure.) And that's where the proposal is today. A niche feature that might as well just be regular sockets on the desktop. 0/10
I’m excited, and anticipate some interesting innovation once browser applications can “talk UDP”. It’s a long time in the making. Gaming isn’t the end of it — being able to communicate with local network services (hardware) without involving an API intervening is very attractive.
Anything that moves the web closer to its natural end state— the J(S)VM is a win in my book. Making web apps a formally separate thing from pages might do some good for the web overall. We could start thinking about taking away features from the page side.
Status of specification: "It is not a W3C Standard nor is it on the W3C Standards Track."<p>Status in Chrome: shipping in 131<p>Expect people claiming this is a vital standard that Apple is not implementing because they don't want web apps to compete with App Store. Also expect sites like <a href="https://whatpwacando.today/" rel="nofollow">https://whatpwacando.today/</a> uncritically just include this
From "Chrome 130: Direct Sockets API" (2024-09) <a href="https://news.ycombinator.com/item?id=41418718">https://news.ycombinator.com/item?id=41418718</a> :<p>> <i>I can understand FF's position on Direct Sockets</i> [...] <i>Without support for Direct Sockets in Firefox, developers have JSONP, HTTP, WebSockets, and WebRTC.</i><p>> <i>Typically today, a user must agree to install a package that uses L3 sockets before they're using sockets other than DNS, HTTP, and mDNS. HTTP Signed Exchanges is one way to sign webapps.</i><p>But HTTP Signed Exchanges is cancelled, so arbitrary code with sockets if one ad network?<p>...<p>> <i>Mozilla's position is that Direct Sockets would be unsafe and inconsiderate given existing cross-origin expectations FWIU: <a href="https://github.com/mozilla/standards-positions/issues/431">https://github.com/mozilla/standards-positions/issues/431</a> </i><p>> <i>Direct Sockets API > Permissions Policy: <a href="https://wicg.github.io/direct-sockets/#permissions-policy" rel="nofollow">https://wicg.github.io/direct-sockets/#permissions-policy</a> </i><p>> <i>docs/explainer.md >> Security Considerations :
<a href="https://github.com/WICG/direct-sockets/blob/main/docs/explainer.md#security-considerations">https://github.com/WICG/direct-sockets/blob/main/docs/explai...</a> </i>
Something tells me this is more to do with a product Google wants to launch rather than a genuine attempt to further the web.<p>I’ll keep my eyes on this one, see where we are in a year
All nice and welcome. At what point browser becomes full blown OS with the same functionality and associated vulnerabilities yet still less performant as it sites on top of other OS and goes through more layers. And of course ran and driven by one of the largest privacy invader and spammer of the world
Great, so now a mis-click and your browser will have a field day infecting your printer, coffee machine and all the other crap that was previously shielded by NAT and/or a firewall.