Resent-From: [email protected]
From: "ext Jonas Sicking" <[EMAIL PROTECTED]>
Date: February 26, 2008 7:44:32 AM EST
To: Anne van Kesteren <[EMAIL PROTECTED]>
Cc: Brad Porter <[EMAIL PROTECTED]>, Daniel Veditz
<[EMAIL PROTECTED]>, "WAF WG (public)" <public-
[EMAIL PROTECTED]>, Window Snyder <[EMAIL PROTECTED]>, Brandon
Sterne <[EMAIL PROTECTED]>, Jesse Ruderman <[EMAIL PROTECTED]>
Subject: Re: To cookie or not to cookie
Archived-At: <http://www.w3.org/mid/[EMAIL PROTECTED]>
Anne van Kesteren wrote:
I'd like to see an update on this from the Mozilla folks. I think
if cookies are not part of the request we should simply nuke the
whole idea.
So we had another (and hopefully final :) ) security meeting at
mozilla today. I'll post a separate mail about the other issues
that came up as the only really big thing is the cookie issue.
So the prevailing opinion was that sending cookies without getting
the users consent is simply too easy to misunderstand. A server
that sends private data based on cookie information and include a
rule like
allow <linkedin.com>
has essentially just sent all the private data served on that URI
over to linkedin, without getting the users consent. And of course
this becomes many times worse if the rule is allow <*>. At that
point basically any private data for anyone to read.
While it can definitely be argued that the server should ask the
users consent first, just as it does before selling personal data
to other 3rd parties this seems like a much easier mistake to make.
Sending all your users personal information to a 3rd party like
linkedin requires an active action. Just adding a header to your
responses in order to allow mashups requires much less thinking.
There are three parties involved in this transaction. The user, the
requesting site and the target site. The spec clearly enforces that
the latter two parties are ok with this transaction. But asking the
user is left as a responsibility to the target site.
Unfortunately we are not convinced that all sites will get this
right. Especially given the ease at which this spec can be deployed.
So we have decided that we do not want to include cookies in the
request.
So at this point there are a few ways forward:
1. We can leave the spec as is and say that mozilla is intentionally
only implementing a subset of the spec at this point.
I'm not at all exited about this idea. It very much increases the
risk that server administrators will wrongly configure their
servers such that private user data will be wrongly exposed if
another UA implements access-control and do send cookies. This
includes both other browsers, and later versions of firefox.
If it comes to this we will likely simply drop support for access-
control for firefox 3 in order to not hinder deployment by other
vendors of the full spec.
2. We can change the spec to say that cookies should never be sent.
This would support the very common usecase of the data hosted on
the target site not being personal at all. Such as the ability to
fetch the latest ads on craigslist.org, or fetch the directions to
a destination from google maps.
But I'm not exited about this idea as sending cookies and auth
headers does have several security advantages when fetching private
data. Such as never having to expose any credentials to the
requesting site, and having built-in protection against distributed
dictionary attacks. Something that won't be possible if the
credentials have to be included in the request body.
3. We can change the spec to allow for requests both that include
cookies, and requests that don't include them. We'd further say
that before the UA makes a request that do include cookies it
should get the users permission to do so first.
This would support the very common usecase of the data hosted on
the target site not being personal at all. Such as the ability to
fetch the latest ads on craigslist.org, or fetch the directions to
a destination from google maps.
I think this could be a very interesting option, if done right. The
"how to ask the user for permission" part is tricky, but I think
doable. And it's something that the spec wouldn't have to work out
in detail, but can be left up to the UA.
The issue of how to determine if the request should be done with or
without cookies is something we would need to specify though. One
solution would be to say that unless the UA has any prior knowledge
(from for example a previous session), it should first make a
request that does not include cookies. If that request is denied
the UA should ask the user and then, if granted permission, do a
request that includes cookies.
This is very similar to how http authentication is usually done.
Do note that I'm prepared to go with any of the above three
options. If we really don't want to change the spec we are
perfectly happy with holding off on this feature for a future
firefox release.
If we go with 3, note that for the next firefox release we would
then act as if the user always denies the request to send cookies.
Implementing UI to ask the user is not going to happen for this
release. Nothing would prevent it from happening next release though.
One thing that might be worth considering is adopting the policy
Safari and Internet Explorer have for cookies. That is not
accepting third-party cookies, but always including cookies in the
request. Then again, there are already tracking methods without
cookies and are actively being used (Hixie pointed out paypal +
doubleclick on IRC) so I'm not sure whether complicated cookie
processing models are worth it at all.
That wouldn't actually change anything at all. The major concern is
sites sending replies that contain the users private data to GET
requests that include cookies. This will happen even if the reply
can't set additional cookies.
The third-party-cookie blocker thing is mostly there to (poorly)
stop sites from tracking a user across multiple sites.
I realize a lot of people are probably going to be disappointed
with this decision, me included. But I hope we can find a way
forward that minimizes the disappointment, even if that includes
removing support for any of this from the next firefox release.
/ Jonas
