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
