- From: Frode Børli <frode@seria.no>
- Date: Wed, 18 Jun 2008 22:41:01 +0200
>> 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. >> I agree completely. Just providing async HTTP is a weak use case compared >> to allowing client-side access to millions of existing (opted-in) services >> and gadgets. > It's clear that we need some kind of opt-in strategy or all web viewers will > become spam bots in short order. While I think it will be extremely useful > to have a raw tcp connection in the browser, and indeed you could use an > external service like dns to handle connection authorization, I think that > it will be much more difficult to drive adoption to that kind of standard. > In the meantime, we need to make the protocol enforce the opt-in. It should not be allowed to connect to any other host or ip-address than the IP-address where the script was retrieved from. Exactly the same security policy is enforced in Java applets and Flash. If the javascript should be able to connect to other servers, then there should be some sort of mechanism involving certificates and possibly also a TXT record in the DNS for each server that can be accessed. > In that case I agree that the name shouldn't be TCPConnection. I propose > SocketConnection instead. If some protocol is decided on, the protocol should have a name. I think the name of the object should be WebConnection or WebSocket. Still I do not believe it should have a specific protocol. If a protocol is decided on, and it is allowed to connect to any IP-address - then DDOS attacks can still be performed: If one million web browsers connect to any port on a single server, it does not matter which protocol the client tries to communicate with. The server will still have problems.
Received on Wednesday, 18 June 2008 13:41:01 UTC