> without informing the user. This would allow a popular page (say a facebook > profile or banner ad) to perform massive DOS against web servers using > visitors browsers without any noticeable feedback (though I guess this is > also true of current HTTPXMLRequestObjects).
XMLHttpRequest only allows connections to the origin server ip of the script that created the object. If a TCPConnection is supposed to be able to connect to other services, then some sort of mechanism must be implemented so that the targeted web server must perform some sort of approval. The method of approval must be engineered in such a way that approval process itself cannot be the target of the dos attack. I can imagine something implemented on the DNS servers and then some digital signing of the script using public/private key certificates. > I propose that there be requirements that limit the amount and type of data > a client can send before receiving a valid server response. If the client must send information trough the TCPConnection initially, then we effectively stop existing servers such as IRC-servers from being able to accept connections without needing a rewrite. > There should also be a recommendation that UAs display some form of status > feedback to indicate a background connection is occurring. Agree. > > HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is > going > > to send back the appropriate handshake response. If TCPConnection is limited to connect only to the origin server, or servers validated by certificates, then this will never be a problem. If we take active measures against STMP, then we should do the same against POP3, IMAP etc as well. > It is always possible that non-http services are running on port 80. One > logical reason would be as a workaround for strict firewalls. So the main > defense against abuse is not the port number but the handshake. The original > TCP Connection spec required the client to send only "Hello\n" and the > server to send only "Welcome\n". The new proposal complicates things since > the server/proxy could send any valid HTTP headers and it would be up to the > UA to determine their validity. Since the script author can also inject URIs > into the handshake this becomes a potential flaw. Consider the code: The protocol should not require any data (not even hello - it should function as an ordinary TCPConnection similar to implementations in java, c# or any other major programming language. If not, it should be called something else - as it is not a TCP connection.
