[whatwg] Proposal for cross domain security framework

[Frode Børli]

>> 1. Browser downloads a script from server A.
>> 2. Script tries to connect to server B.
>> 3. Browser looks up server B's IP-address.
>> 4. Browser performs a reverse lookup of server B's IP-address and gets
>> a host name for the server.
>> 5. Browser looks up a special TXT record in the DNS record for Server
>> B, which states each of the IP addresses/host names that can hosts
>> scripts allowed to connect.
>>
>> DNS records are cached multiple places (including at the local
>> computer), so a DDOS attack attempting to take down DNS servers
>> probably not succeed.
> DNS-Server-Information is often not accessible for many hosts/shared hosts.

This is no problem, since the script that creates the connection can
be hosted on any host and included from any host. Server A includes
script from Server B. If the script from Server B creates a connection
to Server B, then Server A's page can communicate with Server B.

Secondly, there are a lot of hosts that allow you to edit DNS records
- and the rules of a free market will ensure that those who doesn't
will follow shortly.

> Adobe has some of the same Problems with the Adobe-Flash-Player.
> They use a crossdomain.xml-file to provide policy-informations.

That is ofcourse another solution. I like the DNS solution too as it
would be more scalable, since the server that would be under attack
would not have to serve millions of hits to the crossdomain.xml file.

But still, couldn't we combine the two methods? I have read the Adobe
article and it gave me another idea based on policy xml files:

If the socket is created like this: var socket = new WebSocket(host,
port); then DNS is checked.


If the socket is created like this: var socket = new
WebSocket("http://www.example.com/chatserver.xsocket");

Then the .xsocket file is an XML file specifying exactly how the
WebSocket should connect to the server and perhaps any restrictions on
the connections? It would be similar to including a script from a
server, but this would have the following benefits:

1. The chatserver.xsocket-file could be dynamically generated,
allowing many things that we may not think about today.
2. It would be suitable for shared servers.
3. It would allow for example Yahoo! to create services that you can
connect to simply by doing new
WebSocket("http://www.yahoo.com/services/search.xsocket")
4. To load balance, the url could redirect the connecting user to
another xsocket file on another server perhaps?

Frode