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
