- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 26 Mar 2008 15:25:30 -0700
- To: Sunava Dutta <sunavad@windows.microsoft.com>
- CC: Arthur Barstow <art.barstow@nokia.com>, "Web API WG (public)" <public-webapi@w3.org>, "public-appformats@w3.org" <public-appformats@w3.org>, Eric Lawrence <ericlaw@exchange.microsoft.com>, Chris Wilson <Chris.Wilson@microsoft.com>, Zhenbin Xu <zhenbinx@windows.microsoft.com>, Gideon Cohn <gidco@windows.microsoft.com>, Sharath Udupa <Sharath.Udupa@microsoft.com>, Doug Stamper <dstamper@exchange.microsoft.com>, Marc Silbey <marcsil@windows.microsoft.com>, David Ross <dross@windows.microsoft.com>, Nikhil Kothari <nikhilko@microsoft.com>
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. Here's a re-summary of why that I've extracted from our proposal and our responses. For more details please refer to our proposal and the mail conversations on the topic: > > - XDR is provably secure and does not introduce new surface area of attack compared to HTML Forms. Like Hixie raised, this has been shown to be untrue. The XDR proposal let you POST data with any content-type to intranet servers, something which is not possible today. > - It's really simple to program against. I don't see that XDR is any simpler than access-control. To enable GET requests for XDR the server sends: XDomainRequestAllowed: 1 With access-control: Access-Control: allow <*> Neither of these look significantly simpler than the other. POST requests in XDR isn't safe (see above) so it's not really interesting to compare simplicity. Also, with XDR users have to learn a new API. With access-control you simply use the same APIs as you always have. > - While the existing proposal can do what XDR does and more, it is complicated with XHR and also tricky to implement. It took me about 2 days to implement the majority of access-control. This went up to maybe a week as more features were added. This is hardly significant time for any UA vendor. > As we mentioned before, authentication scenarios behave differently compared to XHR and so do headers. This is also untrue. When it comes to headers the difference between XHR and AC+XHR is much smaller than the difference between XHR and XDR. Authentication in XDR is significantly different from how authentication is done today as any authentication tokens have to be sent as part of the request body, so again XDR is much more different from XHR than AC+XHR is. > Editing the policy also quickly gets tricky as the number of rules increase. For public data aggregation scenarios web developers would benefit from the simple and secure XDR object. Again, to get equivalent level of functionality the only difference is XDomainRequestAllowed: 1 vs Access-Control: allow <*> so I don't see how XDR is simpler than XHR. Yes, if you want to use a larger feature set than what is supplied by XDR things get more complicated. But that doesn't seem like a useful comparison. So all in all i'm opposed picking up XDR into W3C. It currently suffers from bad security issues which I suspect would make most UA vendors not want to implement it, and it's a less useful subset of a spec that is already in development. Best Regards, Jonas Sicking
Received on Wednesday, 26 March 2008 22:27:19 UTC