W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: Need PDF of MS' input [Was Re: Seeking earlier feedback from MS]

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 26 Jun 2008 09:25:17 -0700
Message-ID: <4863C2ED.1090708@sicking.cc>
To: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
Cc: Sunava Dutta <sunavad@windows.microsoft.com>, Arthur Barstow <art.barstow@nokia.com>, Marc Silbey <marcsil@windows.microsoft.com>, public-webapps <public-webapps@w3.org>, Eric Lawrence <ericlaw@exchange.microsoft.com>, Chris Wilson <Chris.Wilson@microsoft.com>, David Ross <dross@windows.microsoft.com>, "Mark Shlimovich (SWI)" <marksh@microsoft.com>, Doug Stamper <dstamper@exchange.microsoft.com>, Michael Champion <Michael.Champion@microsoft.com>

Zhenbin Xu wrote:
>> I think some people are as concerned about their personal photo album
>> as
>> they are about their bank account, so i'm not sure there is a big
>> difference between the two. But I do agree that some parts of personal
>> data is likely to have different security requirements than other
>> parts.
>>
>> I don't know how the banking people will feel about CS-XHR. It should
>> be
>> as safe as any other HTTP/HTTPS transaction and banks seem happy to
>> send
>> banking data using those protocols.
>>
> 
> [Zhenbin Xu] I suspect banks would ever be comfortable to allow request
> coming from third-party domains and rely on client side enforcement of
> the x-domain policy sending down from server.

Why is that? They are already relying on client side enforcement to 
prevent other sites from reading the users private financial data and 
performing financial transactions with the users accounts.

It's the client that prevents other webpages running in the client from 
reaching into the DOM of the bank page to read or modify it. It's the 
client that protects the responses from the cross-site requests that are 
possible in todays browsers (such as from <img>, <iframe>, <style>, 
<script>) from leaking to the requesting site. It's the client that 
prevents the users private cookie data that are used to authenticate all 
requests from leaking to the rest of the world.

> Merely exposing the policy
> to client is already dangerous information disclosure in that kind of
> situation. And if banks will not be using it, trying to create a solution
> for them is not a good proposition.

Sending the policy to the client is optional, so should not be a concern 
for banks which can just keep the policy on the server.

> Targeting public data only allows XDR to solve a big problem yet remain secure.
> We can easily come up many useful Mashup scenarios by simply aggregating x-domain
> public data on the web today.

Please lets not make this into an XDR vs. Access-Control discussion. I 
believe Sunava has already stated that XDR isn't intended as a 
competitor or replacement to Access-Control.

It is quite clear that microsoft is intending to ship XDR with IE8 and I 
am fine with that. You are quite welcome to try to get more parties, 
such as browser vendors and/or w3c, to accept the XDR proposal, but lets 
keep that as a separate discussion in separate threads. The discussion 
about Access-Control is big enough as it is.

/ Jonas
Received on Thursday, 26 June 2008 16:26:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:26 GMT