[whatwg] TCPConnection feedback
shannon at arc.net.au
Wed Jun 18 05:50:00 PDT 2008
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 184.108.40.206: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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg