I reread the entire thread. If I can restate the concern -- the concern is that a site will enable access without understanding what enabling access means and therefore unintentionally leak data. This is a risk with or without cookies, but the cookies means that the site might unintentionally leak user-specific data. The intention is to cripple the access-control functionality by eliminating cookies in order to prevent site authors from injuring themselves, thus eliminating a large class of valid use cases but preventing site-authors from leaking their own user-specific data covered by their own privacy policy. I'm reminded of the Ronald Reagan quote: "Government exists to protect us from each other. Where government has gone beyond its limits is in deciding to protect us from ourselves." I think trying to protect site authors from themselves is giving site authors far too little credit. --Brad
Brad Porter <[EMAIL PROTECTED]> wrote: Can you illuminate more clearly what the unintended consequence is for the server maintainer is caused by sending the cookies with the request? --Brad (Sent from mobile device) On Feb 22, 2008, at 9:47 PM, Jonas Sicking wrote: Brad Porter wrote: We should remember that non-malicious cross-site-requests with cookies go on all the time. A simple peek at your cookie store (or turning on accept/reject of cookies) will show that many sites make cross-site-requests with cookies all the time. Banner ads on the web work entirely based on cross-site GET requests with cookies. There is no same-origin policy for cross-site IMG, FRAME, etc requests with cookies. As I outlined in my "to cookie or not to cookie" email, the concern isn't that new attack vectors are introduced. The concern is that servers will enable access control without realizing what it means. / Jonas
