IE Team's Proposal for Cross Site Requests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
122 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

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

Michael[tm] Smith
"Close, Tyler J." <[hidden email]>, 2008-04-02 23:52 +0000:

> I think the AC4CSR spec is a goner, and so appreciate Microsoft
> stepping up with a proposal that seems more likely to survive
> study and deployment. Given the Mozilla announcement, now seems
> like the right time to move on from the AC4CSR proposal.

Speaking as the W3C team contact for the space in which this work
is being done, I want to note that the decision about how to
progress with the Access Control spec rests with the chair and
members of the working group who have invested many months now in
having active, open, public discussion around it and the use cases
and requirements underlying it.

  --Mike

--
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Moving the AC4CSR spec forward [Was: Re: What is Microsoft's intent with XDR vis-a-vis W3C?]

Arthur Barstow

Mike, All,

On Apr 3, 2008, at 12:46 AM, ext Michael(tm) Smith wrote:

> "Close, Tyler J." <[hidden email]>, 2008-04-02 23:52 +0000:
>
>> I think the AC4CSR spec is a goner, and so appreciate Microsoft
>> stepping up with a proposal that seems more likely to survive
>> study and deployment. Given the Mozilla announcement, now seems
>> like the right time to move on from the AC4CSR proposal.
>
> Speaking as the W3C team contact for the space in which this work
> is being done, I want to note that the decision about how to
> progress with the Access Control spec rests with the chair and
> members of the working group who have invested many months now in
> having active, open, public discussion around it and the use cases
> and requirements underlying it.

None of the members of the WG have indicated the work on the AC4CSR  
spec should stop thus it is still an active work item. I've noted:

Jonas indicated [1] he is working on a solution to the cookie issue  
he raised. I encourage others to contribute to this effort.

Maciej indicated [2] he will analyze the attack issues raised and  
respond.

Regarding the "tone" issue Tyler raised [3], I will respond to that  
separately (on WAF WG's public mail list).

-Regards, Art Barstow

[1] <http://lists.w3.org/Archives/Public/public-appformats/2008Mar/ 
0000.html>
[2] <http://lists.w3.org/Archives/Public/public-appformats/2008Apr/ 
0014.html>
[3] <http://lists.w3.org/Archives/Public/public-appformats/2008Apr/ 
0012.html>



Reply | Threaded
Open this post in threaded view
|

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

Laurens Holst-2
In reply to this post by Close, Tyler J.
Close, Tyler J. schreef:
> I've written several messages to the appformats mailing list. I suggest reading all of them. The most detailed description of the attacks are in the message at:
>
> http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B6507@...
>
> with a correction at:
>
> http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B650D@...

You do realise that with XDR, ‘resource host’ has no means to
authenticate the user using (relatively secure) HTTP digest authentication?

In order to acquire the desired functionality (for which it needs the
user’s credentials), with XDR the resource host will most likely end up
passing the authentication information along in the GET query string
(bad), probably requiring the user to fill in his credentials on the
origin site (bad), and sending the user’s password plain over the wire
(bad).

I think the history of HTML has taught us that if people want to do
something (e.g. styling), and you do not provide the means, they will
abuse other mechanisms (tables) to achieve their goals. I can assure you
people will work around the limitations of XDR in the same manner. The
least we can do is provide a mechanism that lets the user do what he
wants, yet is easy to control and secure.

That is the big problem with XDR’s restrictions. Well, aside from its
breaking of REST by disallowing PUT and DELETE and setting the
Content-Type and Accept-* headers, while favouring SOAP (which DOES have
the ability to delete() and authenticate) and encouraging content
sniffing. I hope you can see why I don’t share your enthusiasm for
Microsoft’s proposal :).

~Grauw

--
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.


lholst.vcf (196 bytes) Download Attachment
smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Kris Zyp-4

>From web developer's perspective, the idea of having a completely divergent
API and technique for doing cross-site requests between browsers does not
seem beneficial. As much as possible I would hope that MS and CS-XHR can
converge. It seems like there are a number of differences that can be
analyzed individually. Are there specific parts of the CS-XHR that IE finds
objectionable, that is more specific than just broad sweeping statements
about security? I appreciate Tyler's attempts at specifics, but they have
been proven incorrect. Is it possible that IE could at least converge and
get behind parts of CS-XHR?

1. Why do we need a new API (XDomainRequest) to do cross-site requests? Why
can't I make cross-site requests with my existing code that uses
XMLHttpRequest? This seems completely orthogonal to security, and as a
developer I am certainly not eager to write a bunch of branch logic for a
new API. The proposal mentioned not wanting to "bolt on security" which has
zero value for web developers, maybe that is some internal IE team
motivation.

2. Why does XDomainRequest need to use a different header names than CS-XHR?
Once again, the actual names of the headers seems completely orthogonal to
security. Why can't XDR use "Referer-Root" and "Access-Control" headers?
Even if IE refused to implement method check request and granular host
names, there is no reason XDR can't at least use the same syntax and
semantics. Servers that want to support cross-browser cross-site request
will need to handle two different sets of headers.

3. Why are POST and DELETE not allowed in XDR? I haven't seen any evidence
to suggest these represent security breaches. They certainly not harmful
with CS-XHR since they must servers must opt-in and authorize them. In my
opinion this is devastating omission. REST is critical part of the future of
web applications.

4. Why are developers restricted from setting the Accept-* and Content-Type
headers in XDR? Once again the restriction and the inevitable content
sniffing will likely harm security more than help it.

5. Why can't I send a request synchronously? This is essentially tied to the
API. XDomainRequest does not provide async/sync choice. With FF3 (and any
browsers that follow suite) new continuation-style handling of synchronous
requests, this could possibly become a more important request mechanism than
async in the future. There certainly isn't any security reason to deny such
capability.

6. Why does XDR not use the method check technique from CS-XHR? This has
been demonstrated to be more secure than XDR. XDR is prone to sending POST
requests that otherwise not possible with traditional form posts (like a
POST with JSON data in it, which is impossible to do with a form).

6b. Why not allow cookies? IMO, the idea that a server can make a better
decision about security by having less information is bizarre. With requests
that have side effects, ultimately it is the server that has to make the
final decision about whether to accept the request or not. The whole idea
that servers can make better decisions if they know less (don't know the
cookie information) seems very strange to me.

7. Why does XDR prevent secure connections (HTTPS)?
I am hoping this is just a bug, and somone didn't actually make such a
design choice.

Are there any specific issues in the CS-XHR that MS finds objectionable? I
certainly could commiserate with objecting to XML processing instructions. I
would love to see that be omitted. Or does MS object to the complexity of
CS-XHR? Even a partial compromise would be better than the wild divergence
that it seems we are headed towards. I can't understand how that can be seen
as beneficial for web developers.

> That is the big problem with XDR’s restrictions. Well, aside from its
> breaking of REST by disallowing PUT and DELETE and setting the
> Content-Type and Accept-* headers, while favouring SOAP (which DOES have
> the ability to delete() and authenticate) and encouraging content
> sniffing. I hope you can see why I don’t share your enthusiasm for
> Microsoft’s proposal :).

>From a web developer perspective, I completely agree, these excessive
restrictions mean that we have a lot of hacks, interoperability problems,
and resulting insecurities ahead of us if we use XDR as it is.

> In order to acquire the desired functionality (for which it needs the
> user’s credentials), with XDR the resource host will most likely end up
> passing the authentication information along in the GET query string
> (bad), probably requiring the user to fill in his credentials on the
> origin site (bad), and sending the user’s password plain over the wire
> (bad).

I agree, and want to add that being able to implement OAuth from the client
side should be extremely important use case for a cross-site request
mechanism.

Thanks,
Kris


Reply | Threaded
Open this post in threaded view
|

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

Close, Tyler J.
In reply to this post by Laurens Holst-2


Laurens Holst wrote:

> Close, Tyler J. schreef:
> > I've written several messages to the appformats mailing
> list. I suggest reading all of them. The most detailed
> description of the attacks are in the message at:
> >
> >
> http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B65
> [hidden email]
> >
> > with a correction at:
> >
> >
> http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B65
> [hidden email]
>
> You do realise that with XDR, 'resource host' has no means to
> authenticate the user using (relatively secure) HTTP digest
> authentication?

I both realize and support XDR's decision to not transmit the user's HTTP auth credentials. These credentials are semantically equivalent to the use of cookies described and attacked in the references cited above.

As an aside, HTTP digest authentication is no more secure than transmission of a plaintext password. The space of user passwords is so small that a brute force attack against a password hash is feasible.

> In order to acquire the desired functionality (for which it needs the
> user's credentials), with XDR the resource host will most
> likely end up
> passing the authentication information along in the GET query string
> (bad), probably requiring the user to fill in his credentials on the
> origin site (bad), and sending the user's password plain over
> the wire
> (bad).

Since general understanding of application security is so muddled and incomplete, I have no doubt that many developers will choose to have their users give their credentials to third-party sites. Hopefully, developers for more valuable Web resources will have a better understanding of the available approaches and make better decisions. For example, one approach is similar to a one-time-use credit card number. The web page for a hosted resource includes an authorization token that the user can drag and drop onto a third party web page. This token authorizes a single request of a predetermined type. Often this user action will be required regardless of any security policy, since the third party web page will need to be told what resource it should send its request to. Both the authorization token and the resource identifier can be specified by the user in the same user interface gesture.

> I think the history of HTML has taught us that if people want to do
> something (e.g. styling), and you do not provide the means, they will
> abuse other mechanisms (tables) to achieve their goals. I can
> assure you
> people will work around the limitations of XDR in the same
> manner. The
> least we can do is provide a mechanism that lets the user do what he
> wants, yet is easy to control and secure.

I agree with the goal stated in the last sentence above and it is a significant part of my rationale for opposing the use of ambient authority. Ambient authority, as implemented by cookies and HTTP auth, is hard to control and secure, especially when user requests are created in collaboration with a third party, such as is the intended case with cross-domain browser requests. The attacks linked to above demonstrate some of these problems. In contrast, I think explicit authorization tokens can feasibly be controlled and used in a secure way, such as described in the example above.

There are many other reasons to oppose reuse of existing ambient authority mechanisms in a cross-domain request proposal. See the end of this email for another important reason.

> That is the big problem with XDR's restrictions. Well, aside from its
> breaking of REST by disallowing PUT and DELETE and setting the
> Content-Type and Accept-* headers, while favouring SOAP

I characterize the web-apps that I develop as being RESTful, and don't see any compelling value proposition in the various SOAP related specifications. The XDR proposal adequately supports all of the programming patterns that I find useful in a RESTful web browser application. This outcome doesn't seem to be accidental, but rather seems to be the result of the IE Team's approach of modelling their proposal off the defacto security policy defined by HTML 4. The prohibition against HTTP methods other than GET and POST, as well as the limitations on HTTP headers, do not originate with the XDR proposal, but rather are a carry over from the HTML 4 specification. I doubt the authors of the HTML specification intended to be creating a security policy when they specified the limitations upon the FORM element, but that is in effect what they were doing. The limitation on the FORM's method attribute to the values of "get|post" has become a security policy relied upon by Web resources. The same is true of the use of HTTP headers. We have all been building our web applications within these constraints, for as long as there has been a Web. The XDR proposal does not introduce any new limitations that we must abide by in creating web applications, and so cannot be said to break anything.

My own opinion is that the bulk of the power of the RESTful approach comes from the ability to define a custom URI namespace, do POSTs, and GETs with caching. These things are supported by the XDR proposal.

> I hope you can see why I don't share your enthusiasm for Microsoft's proposal :).

That the XDR proposal enables cross-domain requests with minimal complexity and in a way which is unlikely to cause IT administrators to disable the feature, is, in my opinion, reason enough to be enthusiastic. The XDR proposal seems like something that could be a stable platform on which to start building new kinds of applications.

I think the XDR proposal also gets some important deployment advantages from its avoidance of existing ambient authority mechanisms. Many web sites are composed of both public and private resources living inside the same URI namespace. For example, take a look at the structure of the W3C site. Both member only and public resources share the same URI namespace. Under XDR, the W3C could safely add a XDomainRequestAllowed header to all responses across the whole site. As a result, all the public resources become accessible through XDR, but the member-only resources remain protected, since XDR is unable to access or submit HTTP auth credentials. In contrast, detailed engineering work, and a corresponding security audit, would be required for the W3C to adopt the AC4CSR proposal; otherwise, the member-only resources would be vulnerable to XSRF attacks.

--Tyler

Reply | Threaded
Open this post in threaded view
|

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

Jon Ferraiolo-2

Hi Tyler,
I agree with many of your arguments below. To me, it boils down to three issues, security, simplicity, and architecture. I believe security concerns trump all others, and my analysis is that Microsoft's security team made the right calls with the XDR proposal, taking the conservative approach where no headers, cookies or other credentials are transmitted to other domains, and the policy enforcement point (PEP) is assumed to be on the server. This aligns with the de facto security model for today's Web where a user establishes trust with the single domain, where the user and that domain share secret information only between themselves, such as the information stored in cookies. At OpenAjax Alliance, we have a Security Task Force which contains some industry experts on web security issues and the strong consensus (different than unanimity) was a preference for XDR, mainly for security reasons. On the simplicity side, XDR is appropriately simple (roughly as simple as JSONRequest), whereas Access Control has incrementally added complexity (syntax rules for allowing/denying domains, two-step dance for POST requests, detailed lists of headers that are transmitted) to the point that it is now a small beast. On the architecture side, Access Control is just plain wrong, with the PEP on the client instead of the server, which requires data to be sent along the pipe to the client, where the client is trusted to discard the data if the user isn't allowed to see the data; it is just plain architecturally wrong to transmit data that is not meant to be seen. Regarding the criticsm of XDR with more complex workflows where two sites need to work in coordination with each other, possibly including the use of cookies from the two sites, there are lots of ways to skin that cat and for security reasons (such as CSRF concerns) should not be done within the context of the cross-domain request mechanism. For example, HTML5 allows postMessage(), so you can set up a web page with two IFRAMES, each talking to a different server, and have them do client-side communications via postMessage(); also, there are various server-side alternatives to address these scenarios. Regarding the criticism of XDR for not supporting PUT and DELETE, to me those complaints are minor and fixable. Given that MS has proposed that XDR be taken up by W3C, add an issue about whether XDR should support PUT and DELETE. The one negative with XDR is the process by which Microsoft proposed it, where they were largely silent during the many months that the Access Control spec evolved, only to unleash an alternate proposal at a late stage. Microsoft instead should have been involved in the Access Control activity from its early stages. However, we shouldn't punish the Web by choosing the wrong technical approach just because of how Microsoft engaged in the discussion. Given all of the above, my preference would be for W3C to take XDR to Recommendation and drop Access Control as this would be better for the Web community due to better approaches to security, simplicity, and architecture. It is clear from the thousands of emails on this list that others have different opinions, but that's what mine is.

Jon

Inactive hide details for "Close, Tyler J." <tyler.close@hp.com>"Close, Tyler J." <[hidden email]>



To

Laurens Holst <[hidden email]>

cc

Maciej Stachowiak <[hidden email]>, Jonas Sicking <[hidden email]>, Eric Lawrence <[hidden email]>, Sunava Dutta <[hidden email]>, Ian Hickson <[hidden email]>, "Web API WG (public)" <[hidden email]>, "[hidden email]" <[hidden email]>, Chris Wilson <[hidden email]>, Zhenbin Xu <[hidden email]>, Gideon Cohn <[hidden email]>, Sharath Udupa <[hidden email]>, Doug Stamper <[hidden email]>, Marc Silbey <[hidden email]>, David Ross <[hidden email]>, Nikhil Kothari <[hidden email]>

Subject

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



Laurens Holst wrote:
> Close, Tyler J. schreef:
> > I've written several messages to the appformats mailing
> list. I suggest reading all of them. The most detailed
> description of the attacks are in the message at:
> >
> >
>
http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B65
> [hidden email]
> >
> > with a correction at:
> >
> >
>
http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B65
> [hidden email]
>
> You do realise that with XDR, 'resource host' has no means to
> authenticate the user using (relatively secure) HTTP digest
> authentication?

I both realize and support XDR's decision to not transmit the user's HTTP auth credentials. These credentials are semantically equivalent to the use of cookies described and attacked in the references cited above.

As an aside, HTTP digest authentication is no more secure than transmission of a plaintext password. The space of user passwords is so small that a brute force attack against a password hash is feasible.

> In order to acquire the desired functionality (for which it needs the
> user's credentials), with XDR the resource host will most
> likely end up
> passing the authentication information along in the GET query string
> (bad), probably requiring the user to fill in his credentials on the
> origin site (bad), and sending the user's password plain over
> the wire
> (bad).

Since general understanding of application security is so muddled and incomplete, I have no doubt that many developers will choose to have their users give their credentials to third-party sites. Hopefully, developers for more valuable Web resources will have a better understanding of the available approaches and make better decisions. For example, one approach is similar to a one-time-use credit card number. The web page for a hosted resource includes an authorization token that the user can drag and drop onto a third party web page. This token authorizes a single request of a predetermined type. Often this user action will be required regardless of any security policy, since the third party web page will need to be told what resource it should send its request to. Both the authorization token and the resource identifier can be specified by the user in the same user interface gesture.

> I think the history of HTML has taught us that if people want to do
> something (e.g. styling), and you do not provide the means, they will
> abuse other mechanisms (tables) to achieve their goals. I can
> assure you
> people will work around the limitations of XDR in the same
> manner. The
> least we can do is provide a mechanism that lets the user do what he
> wants, yet is easy to control and secure.

I agree with the goal stated in the last sentence above and it is a significant part of my rationale for opposing the use of ambient authority. Ambient authority, as implemented by cookies and HTTP auth, is hard to control and secure, especially when user requests are created in collaboration with a third party, such as is the intended case with cross-domain browser requests. The attacks linked to above demonstrate some of these problems. In contrast, I think explicit authorization tokens can feasibly be controlled and used in a secure way, such as described in the example above.

There are many other reasons to oppose reuse of existing ambient authority mechanisms in a cross-domain request proposal. See the end of this email for another important reason.

> That is the big problem with XDR's restrictions. Well, aside from its
> breaking of REST by disallowing PUT and DELETE and setting the
> Content-Type and Accept-* headers, while favouring SOAP

I characterize the web-apps that I develop as being RESTful, and don't see any compelling value proposition in the various SOAP related specifications. The XDR proposal adequately supports all of the programming patterns that I find useful in a RESTful web browser application. This outcome doesn't seem to be accidental, but rather seems to be the result of the IE Team's approach of modelling their proposal off the defacto security policy defined by HTML 4. The prohibition against HTTP methods other than GET and POST, as well as the limitations on HTTP headers, do not originate with the XDR proposal, but rather are a carry over from the HTML 4 specification. I doubt the authors of the HTML specification intended to be creating a security policy when they specified the limitations upon the FORM element, but that is in effect what they were doing. The limitation on the FORM's method attribute to the values of "get|post" has become a security policy relied upon by Web resources. The same is true of the use of HTTP headers. We have all been building our web applications within these constraints, for as long as there has been a Web. The XDR proposal does not introduce any new limitations that we must abide by in creating web applications, and so cannot be said to break anything.

My own opinion is that the bulk of the power of the RESTful approach comes from the ability to define a custom URI namespace, do POSTs, and GETs with caching. These things are supported by the XDR proposal.

> I hope you can see why I don't share your enthusiasm for Microsoft's proposal :).

That the XDR proposal enables cross-domain requests with minimal complexity and in a way which is unlikely to cause IT administrators to disable the feature, is, in my opinion, reason enough to be enthusiastic. The XDR proposal seems like something that could be a stable platform on which to start building new kinds of applications.

I think the XDR proposal also gets some important deployment advantages from its avoidance of existing ambient authority mechanisms. Many web sites are composed of both public and private resources living inside the same URI namespace. For example, take a look at the structure of the W3C site. Both member only and public resources share the same URI namespace. Under XDR, the W3C could safely add a XDomainRequestAllowed header to all responses across the whole site. As a result, all the public resources become accessible through XDR, but the member-only resources remain protected, since XDR is unable to access or submit HTTP auth credentials. In contrast, detailed engineering work, and a corresponding security audit, would be required for the W3C to adopt the AC4CSR proposal; otherwise, the member-only resources would be vulnerable to XSRF attacks.

--Tyler



pic30332.gif (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Thomas Roessler

On 2008-04-14 08:07:10 -0700, Jon Ferraiolo wrote:

> On the architecture side, Access Control is just plain wrong,
> with the PEP on the client instead of the server, which requires
> data to be sent along the pipe to the client, where the client is
> trusted to discard the data if the user isn't allowed to see the
> data; it is just plain architecturally wrong to transmit data
> that is not meant to be seen.

This seems to confuse the attacker model a bit.  It's not about the
user not being permitted to see the data, it's about a web
application from a different origin not being allowed to manipulate
the data, even though the user is allowed to see the data.

See this message:
  http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0290.html
... for a more detailed discussion of that topic, and some links.

Regards,
--
Thomas Roessler, W3C  <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

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

Kris Zyp-4
In reply to this post by Close, Tyler J.

>> You do realise that with XDR, 'resource host' has no means to
>> authenticate the user using (relatively secure) HTTP digest
>> authentication?
>
> I both realize and support XDR's decision to not transmit the user's HTTP
> auth credentials. These credentials are semantically equivalent to the use
> of cookies described and attacked in the references cited above.

These attacks have been proven to not be the fault of cookies. Therefore it
makes sense that auth credentials would also not create such attack vectors.

>
> As an aside, HTTP digest authentication is no more secure than
> transmission of a plaintext password. The space of user passwords is so
> small that a brute force attack against a password hash is feasible.

What does this have to do with the HTTP digest authentication? The digest
authentication provides a secure of way transmitting passwords. You protect
against brute force attack with attempt limitations, not password
encryption. If you don't use such measures it doesn't matter you how you
encrypt your passwords, you will still be prone.

>
>> In order to acquire the desired functionality (for which it needs the
>> user's credentials), with XDR the resource host will most
>> likely end up
>> passing the authentication information along in the GET query string
>> (bad), probably requiring the user to fill in his credentials on the
>> origin site (bad), and sending the user's password plain over
>> the wire
>> (bad).
>
> Since general understanding of application security is so muddled and
> incomplete, I have no doubt that many developers will choose to have their
> users give their credentials to third-party sites.

What a depressing outlook for the future. Developers are stupid, so we will
make sure they can't use real security measures because they are more
complex. The reality is developers been pushing the limits of what they can
do securely on the web. Web developers are more than capable of using real
measures like OAuth to authorization, if they are given adequate mechanism
for doing so.

>> breaking of REST by disallowing PUT and DELETE and setting the
>> Content-Type and Accept-* headers, while favouring SOAP
>
> I characterize the web-apps that I develop as being RESTful, and don't see
> any compelling value proposition in the various SOAP related
> specifications. The XDR proposal adequately supports all of the
> programming patterns that I find useful in a RESTful web browser
> application.

Yeah, it seems quite trendy to call your web services RESTful even if you
never use PUT and DELETE. True read/write RESTful services on the web are
heavily dependent on PUT and DELETE.

> The XDR proposal does not introduce any new limitations that we must abide
> by in creating web applications, and so cannot be said to break anything.

It certainly doesn't break anything existing, but it does attempt to take
allow cross-site communication, such comunication will have fundamental
semantics broken which could have enabled powerful interoperability.

> That the XDR proposal enables cross-domain requests with minimal
> complexity and in a way which is unlikely to cause IT administrators to
> disable the feature, is, in my opinion, reason enough to be enthusiastic.
> The XDR proposal seems like something that could be a stable platform on
> which to start building new kinds of applications.

I actually really appreciate the effort to make things more simpler.
However, I do not understand how creating a new API, and creating a new set
of headers is going to make things simpler. The code necessary to deal with
the new APIs is certainly going to impose a burden on developers. If
simplicity is really goal of IE, why not work with W3C on simplifying the
current proposal? Most of the differences are completely orthogonal to
simplicity like header names, and the JS API. One could easily just subset
the W3C/CS proposal to the level of simplicity of XDR.


Kris


Reply | Threaded
Open this post in threaded view
|

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

Jon Ferraiolo-2
In reply to this post by Thomas Roessler

Thomas Roessler <[hidden email]> wrote on 04/14/2008 08:21:50 AM:

> On 2008-04-14 08:07:10 -0700, Jon Ferraiolo wrote:
>
> > On the architecture side, Access Control is just plain wrong,
> > with the PEP on the client instead of the server, which requires
> > data to be sent along the pipe to the client, where the client is
> > trusted to discard the data if the user isn't allowed to see the
> > data; it is just plain architecturally wrong to transmit data
> > that is not meant to be seen.
>
> This seems to confuse the attacker model a bit.  It's not about the
> user not being permitted to see the data, it's about a web
> application from a different origin not being allowed to manipulate
> the data, even though the user is allowed to see the data.


The comment in question wasn't about CSRF or other data-setting attacks on a server, but instead about how it is architecturally wrong to send data that ultimately will be thrown out when it reaches the client. If I was outside of the standards world and wrote some code that did this, I would be embarrassed to show such an implementation during a code walkthrough. The policy check should be done before the data is transmitted.

Jon

Reply | Threaded
Open this post in threaded view
|

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

Jonas Sicking-2

Jon Ferraiolo wrote:

> Thomas Roessler <[hidden email]> wrote on 04/14/2008 08:21:50 AM:
>
>  > On 2008-04-14 08:07:10 -0700, Jon Ferraiolo wrote:
>  >
>  > > On the architecture side, Access Control is just plain wrong,
>  > > with the PEP on the client instead of the server, which requires
>  > > data to be sent along the pipe to the client, where the client is
>  > > trusted to discard the data if the user isn't allowed to see the
>  > > data; it is just plain architecturally wrong to transmit data
>  > > that is not meant to be seen.
>  >
>  > This seems to confuse the attacker model a bit.  It's not about the
>  > user not being permitted to see the data, it's about a web
>  > application from a different origin not being allowed to manipulate
>  > the data, even though the user is allowed to see the data.
>
> The comment in question wasn't about CSRF or other data-setting attacks
> on a server, but instead about how it is architecturally wrong to send
> data that ultimately will be thrown out when it reaches the client. If I
> was outside of the standards world and wrote some code that did this, I
> would be embarrassed to show such an implementation during a code
> walkthrough. The policy check should be done before the data is transmitted.

XDR seems to force much more data to be transmitted only to be thrown
away. In the case of site A loading data from site B the whole resource
is first transferred from site B to the client. Only then does the
client make the decision to throw that data away if site B hasn't
allowed cross-site access to the data.

This does not only force the whole resource to be transferred only to be
thrown away, it also forces the PEP to be the client as the server is
given absolutely no information about who site A is.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Sunava Dutta
In reply to this post by Sunava Dutta

Thanks for the participation and comments.

I think this discussion is best continued in a telecon. I’m working with Doug Schepers to see what we can schedule here.

Once again, thanks for sharing thoughts and providing feedback.

 

From: Sunava Dutta
Sent: Thursday, March 13, 2008 9:07 PM
To: Sunava Dutta; Web API WG (public); [hidden email]
Cc: Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: RE: IE Team's Proposal for Cross Site Requests

 

Adding the WAF group since they have also been working on a similar technology.

 

From: Sunava Dutta
Sent: Thursday, March 13, 2008 8:47 PM
To: Sunava Dutta; Web API WG (public)
Cc: Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: IE Team's Proposal for Cross Site Requests

 

Purpose

XDR helps web developers to create secure mashups, replacing less secure or non-performant approaches, including SCRIPT SRC’ing content or IFRAME injection.

 

Microsoft would like to submit XDR to the W3C for standardization so that other browsers can benefit from this technology.

 

 

XDomainRequest (XDR)

Table of Contents

1.0   Summary

2.0   Background: Overview of how XDR allows cross site requests

3.0   API Documentation: Lists the programming interface/methods/properties

4.0   Security Model Flowchart: Highlights the security checks that IE8 makes for an XDR Request.

5.0   Sample Site and Script: For developers wishing to create an XDR page.

6.0   Developer Benefits of using XDR: Covers XDR’s strengths by demonstrating XDR’s goals of security and simplicity.

7.0   Developer Release Notes: A short bulleted list of issues developers should we aware of when using the object and a summary of what XDR cannot do.

1.0 Summary

With Cross Domain Request (XDR) developers can create cross site data aggregation scenarios. Similar to the XMLHttpRequest object  but with a simpler programming model, this request, called XDomainRequest, is an easy way to make anonymous requests to third party sites that support XDR and opt in to making their data available across domains. Three lines of code will have you making basic cross site requests. This will ensure data aggregation for public sites such as blogs etc will be simple, secure and fast. XDR is an approach designed from the grounds up with a focus on security. We understand the current cross domain XMLHTTPRequest proposal and recognize its ability to provide a broader set of services particularly around declarative auditing for access control based scenarios and authenticated connections. It does however come at the risk of more complexity and surface area of attack. While these are certainly compelling scenarios we realize that existing implementations have bugs (linked 1, 2), some of which are resolved from the past like TOUCTOU and others like DNS Rebinding remain mostly unaddressed. In addition, maintaining configuration is challenging post deployment as Flash has encountered (wildcarding) in the past. The IE team is not comfortable implementing a feature with a high surface area of attack and open/incoming security issues and proposes XDR as a safer alternative.

 

2.0 Background

 

 

Browsers enforce the same site origin policy, which blocks web pages from accessing data from another domain. Websites often work around this policy by having their server request content from another site’s server in the backend, thus circumventing the check within the browser.

 


 


 

 

 

 

 

Text Box: Figure 1 – IE7 and below need to make a request to the mashup server which then needs to be proxied to the web server.

 

In IE8 web pages can simply make a cross domain data request within the browser using the new XDomainRequest object instead of a server-to-server requests.

Cross domain requests require mutual consent between the webpage and server. You can initiate a cross domain request in your webpage by creating a xdomainrequest object off the window object and opening a connection to a particular domain. The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with a XDomainRequestAllowed header with the value “1” for true.

 

For example, a server’s asp page includes the following response header:

Response.AppendHeader("XDomainRequestAllowed","1");

 

 

 

Security note: Cross domain requests are anonymous to protect user data, which means that servers cannot easily find out who is requesting data. As a result, you only want to request and respond with cross domain data that is not sensitive or personally identifiable.

 


3.0 API Documentation

 

 

Methods

Once you create a xdomainrequest object, you can use the open() method to open a connection with a domain’s server. This method supports the GET and POST HTTP methods and takes the URL to connect to as a parameter. Once you’ve opened a connection, you can use the send() method to send a data string to the server for processing if needed. For example:

 

// 1. Create XDR object

xdr = new XDomainRequest();

 

//2. Open connection with server using POST method

xdr.open(“POST”, “http://www.contoso.com/xdr.txt”)

 

//3. Send string data to server

xdr.send(“data to be processed”)

 

XDR also has an abort() method to cancel an active request, which takes no parameters. Data is not available on an abort.

 

Properties

·         responseText - After the server responds, you can retrieve the data string through the read-only responseText property.

·         timeout - You can use the timeout property to set or retrieve the number of milliseconds the browser should wait for a server to respond.   IE defaults to no timeout if this property is not explicitly set. If the request times out, data is not available.

·         contentType – If you are posting data to the server, use the contentType property to define the content type string that will be sent to the server. If you are using a GET then this property will allow you to read the content type.

 

Events

XDR has the following events:

·         onerror – this event fires when there is an error and the request cannot be completed. For example, the network is not available

·         ontimeout – this event fires when the request reaches its timeout as defined by the above timeOut property. If the request times out data is not available.

·         onprogress – this event fires while the server responds to the request by streaming data back to the browser.

·         onload – this event fires when the cross domain request is complete and data is available.

 

Security note: Cross domain requests can only be sent and received from a web page to URLs in the following IE zones. We discourage Intranet sites from making XDR data available to help prevent intranet data from leaking to malicious Internet sites.

 

 

 

Webpage equests data from a URL in the following zone:

 

 

Local

Intranet

Trusted (Intranet)

Trusted (Internet)

Internet

Restricted

Webpage is in the following zone:

Local

Allow

Allow

Allow

Allow

Allow

Block

Intranet

Block

Allow

Allow

Allow

Allow

Block

Trusted (Intranet)

Block

Allow

Allow

Allow

Allow

Block

Trusted (Internet)

Block

Block

Block

Allow

Allow

Block

Internet

Block

Block

Block

Allow

Allow

Block

Restricted

Block

Block

Block

Block

Block

Block

 

Security note: When using these XDR, safely handling data provided by another web application is a critical operation.

 

For instance, the response could be parsed directly by Javascript, or it could be evaluated with a freely available JSON parser (see http://www.json.org/) or it could be inserted into a DOM as static text (using .innerText).

 

 

 

Server Side

The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with an XDomainRequestAllowed header with the value “1” for true.

For example, a server’s asp page includes the following response header:

Response.AppendHeader("XDomainRequestAllowed","1");

This can be done in IIS, for example, using an ASP.NET page. The line of code below can be embedded in your ASP page to return the header.

 

<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data

 

 

4.0 Security Model Flowchart

XDR Flowchart

5.0 Sample Site and Script

 

Please refer to the AJAX Hands on Labs on MSDN for demo script. This will need to be set up on your machine from the resource files.

 

6.0 Other Developer Benefits of Using XDR

1.        Simple development model.

a.        On the server, the server operator must simply add one new header to his HTTP response indicating that cross-domain sources may receive the data.  HTTP Headers can be added by any CGI-style process (PHP/ASPNET/etc) or by the web server software (Apache/IIS/etc) itself.

b.        On the client, the XDR object is all about cross-domain-requests.  Because XDR is a new object we are not forced to “bolt on” cross-domain security.  For example, XDR has no means of adding a custom header, because custom headers are dangerous for cross-domain security as the current web model does not expect a custom header being sent across domains. We’ve encountered experiences when web applications in the past if encountering a custom header using XHR assume it’s coming from the same site.

 

2.        Provably secure

a.        The XDR security model is simple.  The client sends a request that clearly identifies its cross-domain nature, and the server must respond in kind for the Same-Origin-Policy to be relaxed such that the client can read the response.  If the server does not set the response header (a “non-participating” server), the client script is not permitted to read the response or determine anything about the target server.

 

b.        XDR is very tightly scoped to minimize the risk of increasing security exposure of the browser.

1.        Specifically, any request sent by XDR could also be emitted by a properly coded HTML FORM object.  Hence, any “non-participating” web server put at risk by XDR is also at risk from simple HTML.

 

Note: The only additional exposure XDR adds is the ability of the client to set a specific Content-Type header.

 

2.        As XDR strips all credentials and cookies, it prevents even less attack surface for use in a Cross-Site-Request-Forgery (CSRF) attack than a HTML Form.

 

c.        XDR attempts to block cross-zone/protocol requests, an ASR which exceeds that undertaken elsewhere in the browser (e.g. SCRIPT SRC) due to compatibility concerns.

 

3.        Improved Access  Control “Locality”

a.        Unlike policy file-based security, the XDR handshake is a part of the HTTP request and response.  This means that XDR is not at risk from DNS-Rebinding or Time-of-Check-Time-of-Use attacks.

b.        Policy files must be located in a particular location on the server, which may cause operational problems for users with limited permissions on the server.  For example, consider the shared hosting case, where only one admin may write to the server root, but many users have permissions to write to sub-folders.  The users must petition the admin for an update to the policy file.

 

4.        Access-Control Flexibility

a.        As Access-Control is based on a per-response basis, the server may choose to allow or deny access based upon any criteria desired.  For instance, Referer of client, time of day, number of requests per hour, etc, etc.

b.        The XDR security model prevents attackers from easily determining the access control rules of the server.  The server may keep their rules as a trade secret.

 

7.0 Developer Release Notes

·         Not yet available across browsers; not a W3C standard.

·         Services must be explicitly coded to operate with XDR. 

·         As HTTP Methods are deliberately limited, standard REST-based interop is not possible.

·         As credentials are not provided by the browser, the client must transmit them in the request body.  This typically should not be a problem but this could prevent use of the HttpOnly attribute on cookies that must be sent for credentials.

·         The XDR handshake is HTTP-specific and cannot be directly translated for reuse in other protocols or situations (E.g. raw socket access). 

 

 

 

--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer

One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418

FAX# (425) 936-7329

 


image001.png (41K) Download Attachment
image004.png (36K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Anne van Kesteren-2

On Wed, 23 Apr 2008 04:26:39 +0200, Sunava Dutta  
<[hidden email]> wrote:
> Thanks for the participation and comments.
> I think this discussion is best continued in a telecon. I'm working with  
> Doug Schepers to see what we can schedule here.
> Once again, thanks for sharing thoughts and providing feedback.

Wouldn't it be better if the IE Team first addressed the issues raised so  
far with XDomainRequest in an e-mail? Getting this information in a  
teleconference is not very convenient as minutes are often of poor quality  
and teleconferences don't allow for thinking arguments through and  
studying them.

Kind regards,


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Ian Hickson

On Wed, 23 Apr 2008, Anne van Kesteren wrote:

>
> On Wed, 23 Apr 2008 04:26:39 +0200, Sunava Dutta
> <[hidden email]> wrote:
> > Thanks for the participation and comments.
> > I think this discussion is best continued in a telecon. I'm working with
> > Doug Schepers to see what we can schedule here.
> > Once again, thanks for sharing thoughts and providing feedback.
>
> Wouldn't it be better if the IE Team first addressed the issues raised
> so far with XDomainRequest in an e-mail? Getting this information in a
> teleconference is not very convenient as minutes are often of poor
> quality and teleconferences don't allow for thinking arguments through
> and studying them.

That seems reasonable. It would also be good to get Microsoft's promised
(and long overdue) technical feedback on the XMLHttpRequest and Access
Control specifications. For example, there have been multiple claims that
these specifications have security problems, but so far nobody has
responded to the requests for a description of these problems. It would be
difficult to make any useful progress on a telecon without this feedback
available first, since we would be unable to carefully consider the
feedback on a call.

I look forward to the replies from the IE team regarding the above topics.
I think such e-mails are a prerequisite to any attempt to reconcile the
XDR proposal with the XMLHttpRequest and Access Control specifications.

In the meantime, I propose that we continue with the work on the
XMLHttpRequest and Access Control specifications.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Anne van Kesteren-2
In reply to this post by Anne van Kesteren-2

On Wed, 23 Apr 2008 10:01:33 +0200, Anne van Kesteren <[hidden email]>  
wrote:

> On Wed, 23 Apr 2008 04:26:39 +0200, Sunava Dutta  
> <[hidden email]> wrote:
>> Thanks for the participation and comments.
>> I think this discussion is best continued in a telecon. I'm working  
>> with Doug Schepers to see what we can schedule here.
>> Once again, thanks for sharing thoughts and providing feedback.
>
> Wouldn't it be better if the IE Team first addressed the issues raised  
> so far with XDomainRequest in an e-mail? Getting this information in a  
> teleconference is not very convenient as minutes are often of poor  
> quality and teleconferences don't allow for thinking arguments through  
> and studying them.

I was told it would be good to point out some of those e-mails. Here's a  
subset of the e-mails that as far as I can have not been addressed by the  
IE Team:

   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0211.html
   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0212.html
   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0125.html
   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0056.html


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Chris Wilson-12
Given the multitude of issues raised, and the obvious back-and-forth that denotes many differing opinions, I'd suggest having a telecom to discuss these questions, and make sure that Sunava, Eric and myself can attend.

-----Original Message-----
From: Anne van Kesteren [mailto:[hidden email]]
Sent: Wednesday, April 23, 2008 1:31 AM
To: Sunava Dutta; Web API WG (public); [hidden email]
Cc: Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: Re: IE Team's Proposal for Cross Site Requests

On Wed, 23 Apr 2008 10:01:33 +0200, Anne van Kesteren <[hidden email]>
wrote:

> On Wed, 23 Apr 2008 04:26:39 +0200, Sunava Dutta
> <[hidden email]> wrote:
>> Thanks for the participation and comments.
>> I think this discussion is best continued in a telecon. I'm working
>> with Doug Schepers to see what we can schedule here.
>> Once again, thanks for sharing thoughts and providing feedback.
>
> Wouldn't it be better if the IE Team first addressed the issues raised
> so far with XDomainRequest in an e-mail? Getting this information in a
> teleconference is not very convenient as minutes are often of poor
> quality and teleconferences don't allow for thinking arguments through
> and studying them.

I was told it would be good to point out some of those e-mails. Here's a
subset of the e-mails that as far as I can have not been addressed by the
IE Team:

   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0211.html
   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0212.html
   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0125.html
   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0056.html


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Ian Hickson

On Tue, 29 Apr 2008, Chris Wilson wrote:

> On Wed, 23 Apr 2008 10:01:33 +0200, Anne van Kesteren wrote:
> > On Wed, 23 Apr 2008 04:26:39 +0200, Sunava Dutta wrote:
> > >
> > > I think this discussion is best continued in a telecon.
> >
> > Wouldn't it be better if the IE Team first addressed the issues raised
> > so far with XDomainRequest in an e-mail? Getting this information in a
> > teleconference is not very convenient as minutes are often of poor
> > quality and teleconferences don't allow for thinking arguments through
> > and studying them.
> >
> > Here's a subset of the e-mails that as far as I can have not been
> > addressed by the IE Team:
> >
> >   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0211.html
> >   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0212.html
> >   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0125.html
> >   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0056.html
>
> Given the multitude of issues raised, and the obvious back-and-forth
> that denotes many differing opinions, I'd suggest having a telecom to
> discuss these questions, and make sure that Sunava, Eric and myself can
> attend.

I'm with Anne on this. Please reply to the e-mails before convening a
telecon. It is very difficult to carefully consider feedback in the
context of a telecon.

The problem isn't "back-and-forth" denoting "many differing opinions", the
problem is that we don't know what Microsoft's opinion _is_.

Telecons are by their nature much less open, and minutes are almost
uniformly so poor that it is hard to impossible to get precise technical
details out of telecons. A telecon would not be appropriate at this point.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Maciej Stachowiak


On Apr 29, 2008, at 2:14 PM, Ian Hickson wrote:

>
> On Tue, 29 Apr 2008, Chris Wilson wrote:
>>
>> Given the multitude of issues raised, and the obvious back-and-forth
>> that denotes many differing opinions, I'd suggest having a telecom to
>> discuss these questions, and make sure that Sunava, Eric and myself  
>> can
>> attend.
>
> I'm with Anne on this. Please reply to the e-mails before convening a
> telecon. It is very difficult to carefully consider feedback in the
> context of a telecon.
>
> The problem isn't "back-and-forth" denoting "many differing  
> opinions", the
> problem is that we don't know what Microsoft's opinion _is_.
>
> Telecons are by their nature much less open, and minutes are almost
> uniformly so poor that it is hard to impossible to get precise  
> technical
> details out of telecons. A telecon would not be appropriate at this  
> point.

I would also prefer to see a clear statement of Microsoft's position  
in written form ahead of the telecon. By their nature, these are  
issues that need careful analysis, and cannot be evaluated fully in  
the context of a teleconference.

Regards,
Maciej


Reply | Threaded
Open this post in threaded view
|

Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE Team's Proposal for Cross Site Requests]

Arthur Barstow
In reply to this post by Anne van Kesteren-2

Sunava,

Several of the active contributors of the AC spec and XHR{2} specs  
have now asked you and your colleagues for follow-ups before a voice  
conference.

Would you folks please follow the four UIRs Anne listed below and  
provide feedback as requested?

-Regards, Art Barstow


On Apr 23, 2008, at 4:31 AM, ext Anne van Kesteren wrote:

>
> On Wed, 23 Apr 2008 10:01:33 +0200, Anne van Kesteren  
> <[hidden email]> wrote:
>> On Wed, 23 Apr 2008 04:26:39 +0200, Sunava Dutta  
>> <[hidden email]> wrote:
>>> Thanks for the participation and comments.
>>> I think this discussion is best continued in a telecon. I'm  
>>> working with Doug Schepers to see what we can schedule here.
>>> Once again, thanks for sharing thoughts and providing feedback.
>>
>> Wouldn't it be better if the IE Team first addressed the issues  
>> raised so far with XDomainRequest in an e-mail? Getting this  
>> information in a teleconference is not very convenient as minutes  
>> are often of poor quality and teleconferences don't allow for  
>> thinking arguments through and studying them.
>
> I was told it would be good to point out some of those e-mails.  
> Here's a subset of the e-mails that as far as I can have not been  
> addressed by the IE Team:
>
>   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0211.html
>   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0212.html
>   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0125.html
>   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0056.html
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>


Reply | Threaded
Open this post in threaded view
|

RE: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE Team's Proposal for Cross Site Requests]

Sunava Dutta

Art,
I apologize for the delay but we're currently coming up with a plan moving forward to regarding how we want to proceed with cross domain. Our timeframe for responses to the questions below is tied to that plan. As you can imagine, the Web API's support for XDR is something we believe would go a long way towards securing cross domain. The current WG decision based on the survey will cause us to re-strategize significantly.
Chris, out platform architect will get back soon with a response.


-----Original Message-----
From: Arthur Barstow [mailto:[hidden email]]
Sent: Friday, May 02, 2008 3:57 AM
To: Sunava Dutta; Eric Lawrence; Chris Wilson
Cc: ext Anne van Kesteren; Web API WG (public); [hidden email]; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Marc Silbey
Subject: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE Team's Proposal for Cross Site Requests]

Sunava,

Several of the active contributors of the AC spec and XHR{2} specs
have now asked you and your colleagues for follow-ups before a voice
conference.

Would you folks please follow the four UIRs Anne listed below and
provide feedback as requested?

-Regards, Art Barstow


On Apr 23, 2008, at 4:31 AM, ext Anne van Kesteren wrote:

>
> On Wed, 23 Apr 2008 10:01:33 +0200, Anne van Kesteren
> <[hidden email]> wrote:
>> On Wed, 23 Apr 2008 04:26:39 +0200, Sunava Dutta
>> <[hidden email]> wrote:
>>> Thanks for the participation and comments.
>>> I think this discussion is best continued in a telecon. I'm
>>> working with Doug Schepers to see what we can schedule here.
>>> Once again, thanks for sharing thoughts and providing feedback.
>>
>> Wouldn't it be better if the IE Team first addressed the issues
>> raised so far with XDomainRequest in an e-mail? Getting this
>> information in a teleconference is not very convenient as minutes
>> are often of poor quality and teleconferences don't allow for
>> thinking arguments through and studying them.
>
> I was told it would be good to point out some of those e-mails.
> Here's a subset of the e-mails that as far as I can have not been
> addressed by the IE Team:
>
>   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0211.html
>   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0212.html
>   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0125.html
>   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0056.html
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>



Reply | Threaded
Open this post in threaded view
|

Re: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE Team's Proposal for Cross Site Requests]

Ben Adida-2

Sunava Dutta wrote:
> Art, I apologize for the delay but we're currently coming up with a
> plan moving forward to regarding how we want to proceed with cross
> domain.

Sunava,

I've been lurking on this list for a while, and wanted to ask a question
that I don't think has been answered on the list.

The IE8 White Paper on "Better Ajax Development" says:

"Cross-domain requests are anonymous to protect user data, which means
that servers cannot easily find out who is requesting data. As a result,
you only want to request and respond with cross-domain data that is not
sensitive or personally identifiable."

Is that an accurate representation of MS's position, that XDR should
never be used to request sensitive/private information, only generic
public data?

Thanks,

-Ben Adida
[hidden email]

1234567