- From: Shannon <shannon@arc.net.au>
- Date: Wed, 18 Jun 2008 22:50:00 +1000
Frode B?rli wrote: > > 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. > > Using DNS is an excellent idea, though I would debate whether the certificate is needed in addition the DNS record. Perhaps the DNS record could simply list domains authorised to provide scripted access. The distributed nature and general robustness of DNS servers provides the most solid protection against denial of service and brute-force cracking which are the primary concerns here. Access-control should probably be handled by the hosts usual firewall and authentication methods which is trivial once the unauthorised redirect issue is dealt with. The biggest issue I see is that most UAs are probably not wired to read DNS records directly. This means adding DNS access and parsing libraries for this one feature. Having said that I can see a whole range of security issues that could be addressed by DNS access so maybe this is something that HTML5 could address as a more general feature. One feature that comes to mind would be to advertise expected server outages or /.'ing via DNS so the UAs could tell the user "Hey, this site might not respond so maybe come back later". It is worth considering allowing scripts to access devices without said DNS rules but with a big fat UA warning, requiring user approval. Something like "This site is attempting to access a remote service or device at the address 34.45.23.54:101 (POP3). This could be part of a legitimate service but may also be an attempt to perform a malicious task. If you do not trust this site you should say no here.". This would address the needs of private networks and home appliances that wish to utilise TCPConnection services without having the desire or ability to mess with DNS zone files. > > 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. Shannon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/5754064a/attachment.htm>
Received on Wednesday, 18 June 2008 05:50:00 UTC