Ian-- Thanks for sharing your opinions. I'd like to take the opportunity to clarify a few points of confusion.
<<This is blatently untrue, a number of serious security problems with XDR have already been raised (such as the fact that it encourages content-type sniffing It's possible that you overlooked some mails on the thread? Vis-à-vis content-type sniffing, it was plainly stated that Content-Type sniffing is neither recommended, nor necessary. Any service which requires a client-sent Content-Type must be aware of the threat that the Content-Type header so sent is misleading and represents an attempt to attack the server. As XDR will not allow setting of the header (a change made based on feedback from this group), there is no possibility that a service developer will mistake the request header as authoritative. When this change is made, XDR will be unable to emit anything which could not have been sent by HTML forms. In this way, we can demonstrate that XDR does not introduce new attack surface in the browser platform. <<the fact that it encourages people to pass their credentials to untrusted third parties).>> XDR is a truly anonymous request and does not send credentials to ANY site (1st party, 3rd party), trustworthy or not. In this way, we have high confidence that there is no possibility of executing a CSRF attack against an unsuspecting legacy server which uses cookies or HTTP authentication. This can be contrasted with the CS-XHR proposal, in which credentials ARE automatically passed to 3rd party servers. <<It fails to address the majority of use cases for cross-domain data transfer on the Web.>> I think this will prove to be a difficult statement to prove one way or another. It is always challenging to enumerate the universe of current use-cases, let alone accurately predict those which will arise in the future. We absolutely agree that it is possible to define use cases that XDR does not accommodate. We believe that XDR enables the most common cross-domain scenarios with negligible impact to the attack surface of existing servers and the browser. We have been contributing to the Access Control spec for some time, and we recognize the work that has gone into the CS-XHR proposal. We have been monitoring the work on Access Control, CS-XHR, JSONRequest, and related proposals to ensure that XDR is secure against the various security threats the community has identified and has labored to block in the CS-XHR specifications. We are now offering the results of our work (XDR) back to the community in the hope that all will benefit. -Eric Lawrence Internet Explorer Security Program Manager -----Original Message----- From: Sunava Dutta Sent: Wednesday, March 26, 2008 2:29 PM To: Ian Hickson; Web API WG (public); [email protected] Cc: Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey; David Ross; Nikhil Kothari Subject: RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests] Adding my team back on the thread... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, March 26, 2008 2:22 PM To: Web API WG (public); [email protected] Subject: RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests] On Wed, 26 Mar 2008, Sunava Dutta wrote: > > IE would like to propose XDR as a new (Rec-track) spec for the Web API > WG. We think there is a place for both implementations within the > charter of the Web API. I think it would be very bad for the Web platform for there to be multiple ways to achieve this. We need to keep the platform simple, making it more complicated like this for no extra benefit merely acts as a "divide and conquer" strategy for proprietary platforms. > - XDR is provably secure and does not introduce new surface area of > attack compared to HTML Forms. This is blatently untrue, a number of serious security problems with XDR have already been raised (such as the fact that it encourages content-type sniffing, and the fact that it encourages people to pass their credentials to untrusted third parties). > - It's really simple to program against. IMHO keeping the existing XHR API is far simpler than introducing a slightly different API that solves nearly the same problem. > - It accommodates several scenarios around public data aggregation. It fails to address the majority of use cases for cross-domain data transfer on the Web. > - There may be a place for an access control model today, especially > around RESTful services. The model is extensible and powerful however > for the draft itself it will need more design thought to build a secure > implementation. I disagree, I think XHR and Access Control have been shown to be just as secure as XDR, possibly more so since they don't require bad security practices like XDR does. I strongly object to the Web API working group adopting a proprietary solution developed by one vendor with no external consultation, when the group has already spent several man-years' worth of time on a technologically superior, safer, and more comprehensive solution that has as much implementation experience and significantly more authoring experience, based on extending existing APIs instead of arbitarily introducing new, incompatible APIs. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
