As I understand, a browser receiving even an unauthenticated GET request on a resource from a JavaScript Agent, will pass the result on to the JS Agent only if the server adds the
Access-Control-Allow-Origin: http://hello-world.example header to the response. I could not quite find it specified clearly in the spec that this has to be so, but it seems to flow from the example given in the introduction. [[ If a resource author has a simple text resource residing at http://example.com/hello which contains the string "Hello World!" and would like http://hello-world.example to be able to access it, the response combined with a header introduced by this specification could look as follows: Access-Control-Allow-Origin: http://hello-world.example Hello World! ]] And it is the experience of this being required that led me to build a CORS proxy [1] - (I am not the first to write one, I add quickly) So my argument is that this restriction could be lifted since 1. GET is indempotent - and should not affect the resource fetched 2. If there is no authentication, then the JS Agent could make the request via a CORS praxy of its choosing, and so get the content of the resource anyhow. 3. One could still pass the Origin: header as a warning to sites who may be tracking people in unusual ways. Lifting this restriction would make a lot of public data available on the web for use by JS agents cleanly. Where requests require authentication or are non-indempotent CORS makes a lot of sense, and those are areas where data publishes would need to be aware of CORS anyway, and should implement it as part of a security review. But for people publishing open data, CORS should not be something they need to consider. Henry [1] https://github.com/read-write-web/rww-play/blob/master/app/org/w3/readwriteweb/play/CORSProxy.scala Social Web Architect http://bblfish.net/
