RE: Access Control Spec and Cookies

Thank you for asking Art.

We agree with stripping user data like Cookies from cross-site requests to protect user privacy. I'm adding Sunava who is our local expert on cross domain communication.

-----Original Message-----
From: Arthur Barstow [mailto:art.barstow@nokia.com]
Sent: Friday, February 29, 2008 1:25 PM
To: Maciej Stachowiak; Adele Peterson; Marc Silbey; Doug Stamper; Anne van Kesteren; public-appformats@w3.org
Subject: Access Control Spec and Cookies

Browser Vendors, Maciej, Adele, Marc, Doug, Anne,

There has been a rather lengthy discussion regarding the Access
Control for Cross-site Requests spec and Cookies, starting with this
thread from Jonas:

  <http://www.w3.org/mid/47BE7A2A.8040605@sicking.cc>

Due to concerns about exposing a user's cookies, Mozilla decided they
will not send cookies in this model:

  <http://www.w3.org/mid/47C409B0.3040706@sicking.cc>

We are all very interested in other browser vendors' position on this
issue. Would you please share your view on this?

Regards, Art Barstow
---


Begin forwarded message:

> Resent-From: public-appformats@w3.org
> From: "ext Jonas Sicking" <jonas@sicking.cc>
> Date: February 26, 2008 7:44:32 AM EST
> To: Anne van Kesteren <annevk@opera.com>
> Cc: Brad Porter <bwporter@yahoo.com>, Daniel Veditz
> <dveditz@mozilla.com>, "WAF WG (public)" <public-
> appformats@w3.org>, Window Snyder <window@mozilla.com>, Brandon
> Sterne <bsterne@mozilla.com>, Jesse Ruderman <jruderman@gmail.com>
> Subject: Re: To cookie or not to cookie
> Archived-At: <http://www.w3.org/mid/47C409B0.3040706@sicking.cc>
>
>
> 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
>

Received on Friday, 29 February 2008 22:29:32 UTC