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

> 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 sounds like an application of client-server security principles to this 
situation. However, this is not a client-server security, but rather a 
user-deputy-server security situation. XDR and XHR/CS have little to do with 
direct client/server breeches, we can already create a http clients that 
send anything we want. The approach of enforcing of security on a client is 
indeed bad practice, but that is not the issue. Browser based cross-site 
requests are all about how trusted deputies act and the use of their 
authority and trusted information. In user-deputy-server security models 
providing information such that deputies can do PEP and enforce certain 
security guidelines is actually beneficial and can be good practice. 
Analysis needs to be performed using the correct security model.

> 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.

I really don't see how broad statements of support towards one model or the 
other bring us closer to convergence on cross-site request. There may be 
certain aspects of XDR that I like, but there are numerous orthogonal 
issues, and unfortunately I have heard very few clear-headed specific 
technical reasons for these specific decision choices in XDR. Hopefully no 
one actually wants two divergent models in browsers, so each of these issues 
needs convergence. Do any XDR proponents have technical reasons for every 
one of the divergences (API, access model, header limiting, method limiting, 
etc.)?

> 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.

It seems common to think that a simple API equates to simplicity for web 
developers. Unfortunately this is not always the case. Sometimes simplicity 
in the API simply pushes the burden of complexity on to web developers or 
creates less secure models:
1. syntax rules for allowing/denying domains - No syntax rules means that 
web developers must code the logic for allowing/denying domains. Complexity 
is pushed to developers.
2. two-step dance for POST requests - This is undeniably more secure than 
the XDR model. Preventing requests with side effects until opt-in 
authorization is obviously safer. I don't see what the argument is here. 
This is a blatant new vector of attack that XDR opens (and it did _not_ 
exist before, it is impossible to send a request with pure JSON data by 
POSTing forms).
3. detailed lists of headers that are transmitted - If developer must send 
Accept header and the XDR model refuses, what will they do? They probably 
will have to create some new code that puts the header in the parameters. 
And then they have to patch their servers to be able to parse Accept headers 
and parameter headers. Huge burden of complexity on the developers.
Does simplicity in the security model really equate to simplicity for 
developers?
All that being said, I am not opposed to efforts to simplify XHR/CS. 
However, I would love to hear constructive comments rather than, just that 
XDR is simpler. Dropping syntax rules for allowing/denying domains actually 
does not seem like a bad idea to me, even though I just argued for it :). I 
actually do appreciate the efforts towards those ends.

> (2) Adopt JSONRequest and its general thrust, but review its details 
> critically (e.g., only allows JSON data
> natively - XML data must put into something like an "xml:" property),

Really, you want JSONRequest to support XML? You do realize we would need to 
change the name right :)

Kris

Received on Tuesday, 15 April 2008 05:21:39 UTC