3 ms·
In TFA, it says > 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 d
by anonymoushn 4y ago
In TFA, it says
> 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.
- chii 4y ago> It seems like writing game netcode without setting up a WebRTC server should be reason enough. 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.
- anonymoushn 4y agoIf we're going to have games and audio on the web, which we do, we could at least have them work without mountains of additional latency or WebRTC servers. 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.
- fulafel 4y agoWebRTC is peer-to-peer so there's no additional network latency from the protocol. There's the TURN fallback for when the participants can't reach each other, in which case bouncing through a proxy is the best you can do anyway. (If some implementations have high processing latency on top of the network latency, this can be fixed without changing the protocol).
- mattnewton 4y ago> when the original design of it is meant to only display documents? Ship sailed, horse out of barn, etc etc on this point.
- girvo 4y agoWhile I may personally agree with your line of thinking there, we are about 15 years too late to argue that point I think.
- sascha_sl 4y ago> 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).
- account42 4y ago> when WebUSB dropped You mean when Google implemented it in their EEE fork of the web.
- meheleventyone 4y ago> this begs the question - is the browser really the right platform for a game where netcode like that is needed? Yes, it works pretty well using established technologies in the browser already.
- quietbritishjim 4y agoDDOS is essentially the exact opposite of what the parent comment is talking about.
- anonymoushn 4y agoCan you explain how "require that UDP packets be sent exclusively within the same domain as the originating code" does not address any of that comment's concerns, or are you just nitpicking?
- quietbritishjim 4y agoOops, I misunderstood "same domain", sorry.
- formerly_proven 4y agoSame domain is pretty meaningless until all browsers mitigate DNS rebinding, which as far as I know they still don't. And even that would presumably only help with private IPs.
- kragen 4y agoevil.example.com can easily set up a subdomain such that 192-168-2-44.home.evil.example.com resolves to 192.168.2.44, so requiring that UDP packets be sent exclusively within the same domain as the originating code doesn't help at all.
- nneonneo 4y agoRestricting origins doesn’t work thanks to a fun little trick called DNS rebinding. Let’s say you get the user to browse your site, say, attacker.com. They lookup your DNS and see that it’s 1.2.3.4, with a TTL of (say) 5 seconds. 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.
- nly 4y agoThis could be resolved by having the browser cache the IP and refresh it for child operations. Sure, this is a change in current behavior - but for a new feature like UDP, or arbitrary TCP, it could work.
- vlovich123 4y agoAs others have pointed out caching the DNS past the TTL is it’s own security problem. 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.
- asojfdowgh 4y agoHave a page load up a script from <nonce>.relevantdomain.tld, once the script sends back a packet to <nonce>.relevantdomain.tld, have the dns settings change subdomain to 192.168.0.1, and then etc 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