[whatwg] Re: Cross Domain Policies

[Malcolm Rowe]

Jim Ley writes:
> Aswell as Malcolm's concerns with practicality of this, I have pretty
> significant concerns about the security of it - as it takes the
> security completely out of the hands of the user.

Just to clarify: I don't have any significant concerns about the 
implementation /per se/; I merely thought it would be relevant to point out 
that the implementation is another instance of a general 'problem' that the 
W3C TAG is currently looking at. 

As it happens, I note that this particular implementation *does* allow 
delegation, since the spec makes specific provision of it, so one of my 
'objections' is actually partially handled (although it still requires 
support from the server owner; not ideal). It still pollutes the URI 
namespace though. 

> I'm really quite alarmed by this approach in fact, [...] Also can you
> please put a great big security warning on the "What's new" that
> clarifies and explains exactly what these new "security models" are

Note that Doron started out by saying "Back at Netscape". Far from being 
recent, that document was written in April 2003. It also looks like it's 
been implemented in the Mozilla SOAP code since about then - see bugzilla 
bugs 183824 and 203371. 

The latter bug extends the model to allow a site to indicate that a service 
is accessible from script loaded from *any* URL (i.e., that it is a public 
service). Additionally, a list of 'public' services can be specified by a 
preference (xml.webservice.security.masterservices) - but don't worry, it's 
blank by default. 

Finally, note that signed scripts with sufficient privileges (and 'trusted' 
unsigned scripts?) bypass this restriction entirely. 

>[moved]
> If my bank makes a mistake and provides its web-service available to
> random domains there's nothing I can do to, to either be aware of it,
> or presumably disable it on an individual basis.

Correct, from what I've seen. But if your bank allows damage to be done 
using untrusted (and almost certainly unauthenticated) SOAP calls, you've 
got more to worry about. Bear in mind that the *only* reason that this 
mechanism exists is to prevent untrusted scripts from probing random SOAP 
services (and other non-SOAP HTTP services, too, as it happens), 
particularly ones that are accessible from your *internal* network. 

As it says in the document: "The proposed declaration file places the server 
operator, not the client in control of access to his server by untrusted 
scripts". 

Regards,
Malcolm