[whatwg] Re: Cross Domain Policies

[Malcolm Rowe]

Hi Jim, 

[This isn't entirely on-topic anyway, and (more importantly) I don't feel 
qualified to answer many of your points, so I've left some of them 
unanswered.] 

Jim Ley writes:
>> 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.
> I'm sure there's plenty of scenarios where web-services are purely
> controlled by IP address authentication, there are some on the
> corporate LAN I spend all too many days on.

Yup, but the server administrator has to do something to enable scripts 
loaded from other domains to be able to issue calls. It's not something that 
the user can screw up (I appreciate your point that it doesn't seem to be 
something the user can *disable* either...). That was explicitly mentioned 
in the document. 

>> 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),
> No, the reason it's there is to allow SOAP calls to other domains
> without needing raised security priviliges, it's introducing laxxer
> security (normally no scripts can make cross-domain requests that get
> data).  Please don't pretend it's there to tighten security.

Sorry, I didn't mean to imply that this model was better that the existing 
model (same-origin, etc). I meant that it was better than nothing. I should 
have said something like: 

Some server operators would like to permit untrusted scripts to access their 
services (for example: a public service, or a service hosted by a separate 
ASP). From the document, it appears that the only reason that this mechanism 
exists is [..]. If it wasn't for those reasons, it looks like there might 
not have been *any* SOAP security model (i.e., as there isn't any in HTML 
forms, for example). 

>> 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".
> Yep, that's a BAD thing!  It's not something to applaud, and it's
> certainly not something to sneak into a . release of a major UA.

It went into Mozilla 1.4 or 1.5, by the looks of things, hardly a 'point 
release' - what would you have them do, wait for 2.0? 

If you think there's a genuine security risk (and it sounds like you know a 
lot more about this kind of thing than I do), I'd recommend you raise a bug 
in bugzilla. If there's a problem, as you suggest, we should fix it before 
shipping Firefox 1.0. 

Regards,
Malcolm