> If DDoS was the concern, just require that UDP packets be sent exclusively within the same domain as the originating code.
So you couldn't do any of these things.
> And again - what actual benefits would there be to raw UDP access? The article is very light on specifics.
It seems like writing game netcode without setting up a WebRTC server should be reason enough.
Five seconds later, the user’s DNS cache entry expires. Your page triggers a new request to attacker.com. Since the TTL has expired, they do another DNS lookup - and you serve them a different IP address, say, 192.168.1.1. Now they make a new request to that IP believing that they’re still accessing attacker.com.
With HTTP requests there’s at least the possibility of detecting these attacks via the Host header (even if that doesn’t usually happen in practice). With raw UDP, however, the attacking packets would be indistinguishable from legitimate ones.
I think the fix is actually to disallow resolution when the TTL is too short (eg <1 hour) and refusing new outbound requests once the IP address changes without a refresh of the page. However, I’m not a security / network expert so there may be a critical flaw in that idea.
the war between safe things and unsafe things is endless, so we shouldn't be adding a massive unsafe thing and then bodging patches onto it to make it "safer" than completely unsafe
this begs the question - is the browser really the right platform for a game where netcode like that is needed?
Why make the browser even more complex, when the original design of it is meant to only display documents? If we keep going down this road, you'd end up with an operating system inside the browser.
Arguably, we're already there. I stopped pretending the web wasn't going to be the common platform of the future when WebUSB dropped and I learned you can root a Nintendo Switch from Chrome OS. Without the Linux part.
If you build something today, without too many resources backing you up, and you want it to run anywhere, you build something that resembles a PWA with Electron wrappers. (resembling because it could also be something like Flutter).
You mean when Google implemented it in their EEE fork of the web.
I would also like it if web sites would display documents, allow the browser's "find" feature to work, and not use "responsive UI" to delete the form that I'm halfway done filling out when I resize my window, but I don't think my preferences have much weight here.
(If some implementations have high processing latency on top of the network latency, this can be fixed without changing the protocol).
Ship sailed, horse out of barn, etc etc on this point.
Yes, it works pretty well using established technologies in the browser already.
There is no HTTP headers for raw UDP.