W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

RE: IE Team's Proposal for Cross Site Requests

From: Chris Wilson <Chris.Wilson@microsoft.com>
Date: Thu, 22 May 2008 10:27:15 -0700
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: "public-webapi@w3.org" <public-webapi@w3.org>, Sunava Dutta <sunavad@windows.microsoft.com>
Message-ID: <E35CF0CC5D011D49943F61E242AF48AD0876B838C2@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>

Sorry, these fell down in my inbox due to a poor inbox rule construction.
Bjoern Hoehrmann [mailto:derhoermi@gmx.net] wrote:

>In evaluating Microsoft's XDR proposal I believe two questions are most
>important. First, how well does it address what people actually want to
>do in terms of cross site requests.

Agreed.  With the understanding, of course, that additional complexity adds security risk, probably in a non-linear fashion.

>The mechanism is very crude, you can
>not use methods other than GET and POST, you can't set headers, you have
>no standard methods for authentication, you can only transfer strings,

I think these are all true.

>you have to be able to manipulate the HTTP header,

I presume "you" in this case is the application author, meaning that they need to have access to the server in order to read and respond with the headers.  If so, yes.

>and it only works if
>you can use the special new API, not if you use some other methods to
>embed external resources.

I'm afraid I don't understand "other methods to embed external resources."

>If that is all developers want to do, XDR may be quite suitable. If, on
>the other hand, developers actually need and want additional methods,
>authentication, transfer data that isn't simply a string conveniently,
>and other things, it is quite possible they will come up with crude ad-
>hoc work arounds to address their requirements, and are highly likely to
>implement security vulnerabilities in their applications in the process;

Fair enough.  That's a good case for having extremely explicit use cases - not just "well, somebody might want to..." but actual use cases - for what scope we expect to cover here.  We expected XDR to have a more limited scope.

I'd point out that most of the missing bits you mention aren't hard to add to XDR in a more secure way - e.g., for authentication we could simply add a cross-domain-authenticate header, which then would have no chance of colliding with current authentication on current servers.  Cookies in general are a little harder to figure out how to do securely across x-domain and SO, but not impossible.

>more so if many different applications require different workarounds.

>It does not matter all that much to most users whether they get screwed
>because of a browser bug, or a web site bug. It appears that Microsoft
>realizes as much, citing how easily other solutions are misconfigured as
>one motivation for the XDR work, but it is very much unclear to me why
>developers are not going to make grave errors when setting up XDR-based
>sites and services.

If you believe that XDR doesn't cover the most critical core cases, and therefore MOST developers are going to be forced into making these grave errors, then you might be correct.

>The second questions is simply whether this is all. Is there going to be
>an "XDRv2" in "IE9" with more developer aids to build secure cross site

In short, I don't know.  If XHR2+AC still has the same security concerns, and web developers express the need for more functionality (as I think you feel they need, as per above), then yes, I expect we would expand it.

>Or other solutions in other Microsoft products? The latter would
>seem to be so in the case of the next version of Microsoft Silverlight.

I obviously can't speak for other Microsoft products.  Silverlight, of course, has to layer their code on top of what they can get out of other browsers' extensibility and networking (because they don't want to write their own network stack if they can avoid it).

>In the current Beta version you will find many of the things we hear are
>bad from the Internet Explorer Team, that is, policy files, cookies are
>sent, the same APIs are used for same-domain and cross-domain requests,
>and while there are two differnt kinds of policy files, and an upcoming
>full cross-domain model for socket access. But no apparent XDR support.

Indeed.  Because they have to work across browsers.  They'd like to expose XDR instead.

>That Microsoft itself cannot agree on one technology, or at least only
>one philosophy to approach the problem does not inspire confidence in
>any of the solutions, and the prospect of having to cope with several
>new cross domain access solutions, even though we already have too many,
>is rather worrying.

Again, because they have to work across browsers and platforms.  They have much different constraints than we do.

>Personally speaking, the IE Team's emphasis on security and simplicity
>is a welcome contrast to the XHR2+AC design team's emphasis on broad
>applicability, ease of deployment, and efficiency, but XDR is so limited
>in its ability that I might aswell continue using remote <script>s and
>HTML form posts, that at least works everywhere and the security impli-
>cations are well-known.

Part of the feedback we'd welcome is how additional functionality is needed in the real world.

Received on Thursday, 22 May 2008 17:28:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:27 UTC