W3C home > Mailing lists > Public > public-appformats@w3.org > March 2008

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 26 Mar 2008 15:25:30 -0700
Message-ID: <47EACD5A.3030507@sicking.cc>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 26 March 2008 22:27:20 GMT