Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

>From web developer's perspective, the idea of having a completely divergent 
API and technique for doing cross-site requests between browsers does not 
seem beneficial. As much as possible I would hope that MS and CS-XHR can 
converge. It seems like there are a number of differences that can be 
analyzed individually. Are there specific parts of the CS-XHR that IE finds 
objectionable, that is more specific than just broad sweeping statements 
about security? I appreciate Tyler's attempts at specifics, but they have 
been proven incorrect. Is it possible that IE could at least converge and 
get behind parts of CS-XHR?

1. Why do we need a new API (XDomainRequest) to do cross-site requests? Why 
can't I make cross-site requests with my existing code that uses 
XMLHttpRequest? This seems completely orthogonal to security, and as a 
developer I am certainly not eager to write a bunch of branch logic for a 
new API. The proposal mentioned not wanting to "bolt on security" which has 
zero value for web developers, maybe that is some internal IE team 
motivation.

2. Why does XDomainRequest need to use a different header names than CS-XHR? 
Once again, the actual names of the headers seems completely orthogonal to 
security. Why can't XDR use "Referer-Root" and "Access-Control" headers? 
Even if IE refused to implement method check request and granular host 
names, there is no reason XDR can't at least use the same syntax and 
semantics. Servers that want to support cross-browser cross-site request 
will need to handle two different sets of headers.

3. Why are POST and DELETE not allowed in XDR? I haven't seen any evidence 
to suggest these represent security breaches. They certainly not harmful 
with CS-XHR since they must servers must opt-in and authorize them. In my 
opinion this is devastating omission. REST is critical part of the future of 
web applications.

4. Why are developers restricted from setting the Accept-* and Content-Type 
headers in XDR? Once again the restriction and the inevitable content 
sniffing will likely harm security more than help it.

5. Why can't I send a request synchronously? This is essentially tied to the 
API. XDomainRequest does not provide async/sync choice. With FF3 (and any 
browsers that follow suite) new continuation-style handling of synchronous 
requests, this could possibly become a more important request mechanism than 
async in the future. There certainly isn't any security reason to deny such 
capability.

6. Why does XDR not use the method check technique from CS-XHR? This has 
been demonstrated to be more secure than XDR. XDR is prone to sending POST 
requests that otherwise not possible with traditional form posts (like a 
POST with JSON data in it, which is impossible to do with a form).

6b. Why not allow cookies? IMO, the idea that a server can make a better 
decision about security by having less information is bizarre. With requests 
that have side effects, ultimately it is the server that has to make the 
final decision about whether to accept the request or not. The whole idea 
that servers can make better decisions if they know less (don't know the 
cookie information) seems very strange to me.

7. Why does XDR prevent secure connections (HTTPS)?
I am hoping this is just a bug, and somone didn't actually make such a 
design choice.

Are there any specific issues in the CS-XHR that MS finds objectionable? I 
certainly could commiserate with objecting to XML processing instructions. I 
would love to see that be omitted. Or does MS object to the complexity of 
CS-XHR? Even a partial compromise would be better than the wild divergence 
that it seems we are headed towards. I can't understand how that can be seen 
as beneficial for web developers.

> That is the big problem with XDR’s restrictions. Well, aside from its
> breaking of REST by disallowing PUT and DELETE and setting the
> Content-Type and Accept-* headers, while favouring SOAP (which DOES have
> the ability to delete() and authenticate) and encouraging content
> sniffing. I hope you can see why I don’t share your enthusiasm for
> Microsoft’s proposal :).

>From a web developer perspective, I completely agree, these excessive 
restrictions mean that we have a lot of hacks, interoperability problems, 
and resulting insecurities ahead of us if we use XDR as it is.

> In order to acquire the desired functionality (for which it needs the
> user’s credentials), with XDR the resource host will most likely end up
> passing the authentication information along in the GET query string
> (bad), probably requiring the user to fill in his credentials on the
> origin site (bad), and sending the user’s password plain over the wire
> (bad).

I agree, and want to add that being able to implement OAuth from the client 
side should be extremely important use case for a cross-site request 
mechanism.

Thanks,
Kris

Received on Monday, 7 April 2008 15:01:05 UTC