This seems to propose that you can only connect to a certain server, similar to the same-origin-policy. What I would really love instead is the possibility to connect to arbitrary IPs to be able to implement real P2P. The linked posts dismiss this early because of the possibility to cause DDOS, but really, you can already do that from a hacked desktop "Quake", so there is no harm in being able to do it from a browser-based "Quake". What you'd have to prevent is drive-by use of UDP, not use of UDP period.
I would propose having two HTML profiles in future, HTML document, and HTML application (and maybe HTML legacy). HTML document would be restricted in what you can do, and would be primarily for reading Hypertext. For HTML application you would have to go through a few clicks to install or activate it - now you are going to say that people will just click it away, but that is already the case with current desktop app installers, so it is not more insecure! An application profile page will be able to access the net just like any other native application. Most importantly, it will be able to bypass same-origin policy and send UDP and TCP anywhere - but not with credientials of course.
You'd still have the problem of being able to probe internal networks, and being able to manipulate UPnP routers. For the first, the network admin could have a group profile setting or similar to disable this kind of access. For the second, browsers could selectively block this on a case-by-case basis if needed.
For the problem of DDOS, I think we should not let that restrict us from implementing useful technologies. Rather we should fix it at the source. For example, maybe one could lock down certain routes if an attack is detected. All traffic along these routes is throttled, unless you send along a proof-of-work token. I'm just making this up, but my point is that I think we haven't exhausted all options here.
For p2p, you already have the webrtc data channel which handles all the nasty NAT traversal and DDoS issues. Its browser API should be less volatile now than it has been in the past.
Implementing a WebRTC data channel endpoint in a server is not for the faint of heart, though. You would have to implement a lot of complex RfCs.
You need a way to exchange the SDP message contents between your browser and the remote browser. How you do this is up to you. A central server is just the simplest way to do it.
"The linked posts dismiss this early because of the possibility to cause DDOS, but really, you can already do that from a hacked desktop "Quake", so there is no harm in being able to do it from a browser-based "Quake"."
No same-origin-policy would be lovely combined with XSS vulnerabilities.
Suddenly all the visitors of that website would be doing DDOS on a random host.
Well, I would not make that feature available from an included script from a third party domain, so XSS would not be an issue. I would make something like privileged application bundles that you had to authorize first - just like you have to install native apps. I know some people just click OK on everything, but there is no remedy to that other than giving up and not allowing general-purpose networking at all.
Also, people already exploit XSS for DDOS-ing, although not via UDP, but TCP/HTTP. Granted, you can possibly make a worse attack if you have UDP.
I would propose having two HTML profiles in future, HTML document, and HTML application (and maybe HTML legacy). HTML document would be restricted in what you can do, and would be primarily for reading Hypertext. For HTML application you would have to go through a few clicks to install or activate it - now you are going to say that people will just click it away, but that is already the case with current desktop app installers, so it is not more insecure! An application profile page will be able to access the net just like any other native application. Most importantly, it will be able to bypass same-origin policy and send UDP and TCP anywhere - but not with credientials of course.
You'd still have the problem of being able to probe internal networks, and being able to manipulate UPnP routers. For the first, the network admin could have a group profile setting or similar to disable this kind of access. For the second, browsers could selectively block this on a case-by-case basis if needed.
For the problem of DDOS, I think we should not let that restrict us from implementing useful technologies. Rather we should fix it at the source. For example, maybe one could lock down certain routes if an attack is detected. All traffic along these routes is throttled, unless you send along a proof-of-work token. I'm just making this up, but my point is that I think we haven't exhausted all options here.