Hi all, I'm on the W3C's Web Security Context WG, where we got a request for review of your document "Access Control for Cross-site Requests". I'm glad there's a group working on this problem, as it's functionality that's sorely needed. I've got some comments of my own on your current design and have also collected some feedback from Doug Crockford, which I'm including in the email. We've both independently come to similar opinions on this first draft.
A significant portion of the proposal is devoted to specifying a policy language for determining whether or not a page from a particular "root URI" should be allowed to issue a cross-domain request to a particular server. I think the problem can be solved without the server and the client software agreeing on such a policy language. For example, rather than have the server specify the rules for cross-domain requests and have the client enforce these rules, the client should simply send the request information to the server and have the server enforce its own rules. I see no advantage to placing this logic in the client, as opposed to the server. Placing the logic in the client introduces significant complexity which creates many opportunities for implementation bugs, specification ambiguity and misunderstanding by web application developers, while possibly limiting the kinds of policies a server can enforce. There is also a significant factual error in the document's Introduction: """ However, it is not possible to exchange the contents of resources or manipulate resources "cross-domain". """ It *is* possible to manipulate resources "cross-domain". An HTML page can contain a FORM which submits an HTTP request "cross-domain". Submission of this request can be automated using Javascript. The Same Origin Policy only prevents the HTML page from accessing the response to the issued request. Manipulation is allowed. Only responses are protected, not requests. Below are comments from Doug Crockford: --- Begin Doug's comments --- re: http://www.w3.org/TR/access-control/ Currently, the script tag hack is the best available method for accessing data from a server other than the origin server. It works (in fact, it is programmatically much more convenient than the XMLHttpRequest) but it has horribly unacceptable security properties. There is an urgent need to a better alternative. The Access Control proposal is a big improvement over the current state of the art, but I wish that it could be better still. It is a patch on a patch, and while it appears that the patch will hold this time, I wish we could agree on a cleaner approach. Ideally, the server should be responsible for determining how it dispenses its data. Unfortunately, the Same Origin Policy has in many cases induced the abdication of the server's responsibility. The current proposal extends this bad practice. The server sends a policy statement with the data to the browser. The browser must interpret the policy statement and decide whether or not to deliver the data to the application. I think this is perverse. The server should not be putting bits on the wire that it does not want delivered. The proposal encourages bad practice. The proposal also invents another language. It presents another opportunity for system administrators to get something wrong. I believe there are more elegant and reliable approaches to providing a safe alternatives to the script tag hack. --- End Doug's comments --- --Tyler -- [1] "Access Control for Cross-site Requests" <http://www.w3.org/TR/access-control/>
