- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 20 Dec 2009 04:58:45 +0000 (UTC)
- To: "Mark S. Miller" <erights@google.com>
- Cc: Adam Barth <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>
On Sat, 19 Dec 2009, Mark S. Miller wrote: > > And that is why in my response, I stated "For the same reason, we are > not *serving the interests* of an origin by adding that origin's name to > the ACL for a resource." [emphasis added] Say that grantor G seeks to > grant to service A at origin O permission P to access resource R. Say G > does this using the path of least resistance suggested by the CORS > mechanism (and repeatedly suggested as a sound practice in this thread) > -- by adding O to R's ACL. If service B at origin O is malicious, it can > certainly steal P, so that is not my present concern. > > Rather, if A and B are both "services maintained by different parties > hosted on a single origin" O, where A and B are politely trying to stay > out of each other's way, then G inadvertently disrupts the correct > operation of B by causing permission P to be applied to B's requests > merely as a side effect of trying to grant P to A. This does not serve > the interests of B, nor of the origin serving as the host for such > mutually trusting but separately maintained services. Indeed. That's why CORS is per-URL on the server, and not per-origin. That's exactly Anne's point, and is why CORS is designed to grant permissions per-resource and not per-origin, on the server. (Obviously as Adam pointed out, the client side can only be per-origin for historical reasons. That's unfortunate, but there it is.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 20 December 2009 04:59:17 UTC