I suggest you bring this up in the "to cookie or not to cookie" thread
so the right people get cc'ed. I personally agree with you.
/ Jonas
Brad Porter wrote:
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
