Re: To cookie or not to cookie

I have a couple thoughts on this:

a) The loss of functionality would be highly unfortunate as there are a huge class of applications that would be enabled by access-control that would no longer be possible

b) The sharing of personal information between site A and site B is a privacy issue more than a security issue.  Yahoo should not be sharing information with Linkedin without an explicit policy statement saying that it does so.  Historically the user-agents have not been in the position of stating or attempting to enforce privacy policy.  

c) The access-control policy is an opt-in framework for specifically enabling site-to-site sharing of data.  The decision to share a particular piece of data is explicit, not implicit.  Therefore, any entity that actually had a privacy policy in place would absolutely review before naively sharing user information with another site.  Any site which is worried about the privacy implications of a cross-site request simply has to do exactly nothing and no sharing occurs.

In conclusion, I do not see why Mozilla needs to try to get in the middle of user-data-sharing privacy issues and try to restrict or regulate them.  If the decision to share data was an unintended "side-effect" of some other functionality, it may make sense, but in this case the entity is making an explicit decision about whether to share a particular piece of data and has to be aware and consider the privacy issues themselves.

--Brad 

Jonas Sicking <jonas@sicking.cc> wrote: 
Always forgetting something... Please reply to this one to keep a few 
mozilla folks in the loop that aren't on the mailing list.

Jonas Sicking wrote:
> 
> Hi All,
> 
> During the security review of access control last tuesday at mozilla the
> issue of weather or not to send cookies and auth headers.
> 
> Below I will simply use 'cookies' to refer to 'cookie headers and
> authentication headers' for ease of reading.
> 
> 
> There are obvious feature advantages to sending cookies. For example it
> allows mashups where a users private data is used. For example a mashup
> site that combines a users personal calendar at google.com/calendar
> could be mashed up with upcoming concerts from livenation.com. As long
> as the user is logged in to google.com prior to visiting the mashup site
> this could be done automatically. Similarly linkedin.com could pull in
> my yahoo mail address book in order to populate my list of contacts, as
> long as the user has logged in to yahoo mail first.
> 
> 
> There are however security concerns with automatically sending cookies.
> 
> One concern we found was that it makes it very easy for a site to
> accidentally grant access to a users personal data without realizing
> this is done without the users consent. I.e. the worry is that server
> administrators will think that just because a request includes a users
> cookies, that the user has authorized the request. To use the examples
> above:
> 
> Google could add a rule like 'allow <*>' to let anyone use their
> calendar APIs. However, if a user visits an evil site, the evil site
> would then be able to read the users full calendar without any consent
> at all from the user.
> 
> Similarly, yahoo mail could add a rule like 'allow 
' since
> linkedin at the time always asks the user before loading the users
> address book. However later linkedin.com might decide to change their
> policy and automatically pull in the users address book without asking
> the user, or even decide to pull in the address book use it to market
> their site.
> 
> In both these cases the problem is definitely google or yahoo 
> configuring their servers wrong. They should not add 'allow' rules for 
> sites that they don't trust. The argument is that this is an easy 
> mistake to make.
> 
> 
> But there are also security concerns with not sending cookies too. The
> requesting site would have to ask the user for some credential that can
> then be used to authenticate the user at the target site. There is a big
> risk that this is often going to be the users normal username and
> password since anything else is going to be more inconvenient for the
> user (such as redirecting to the target site and ask the user to fetch a
> one-time login which is copy/pasted to the requesting site).
> 
> This both exposes the user to a greater risk since the requesting site
> is actually given the credential, and also risks creating a culture
> where people give out their passwords to other sites.
> 
> Again here you can make a strong case that the user should not give 
> his/her password to a site that they don't trust. But users make 
> mistakes too. And the argument is that we're forcing a culture where 
> users give out their credentials making that seem more normal to them.
> 
> 
> So to sum up:
> The risk when sending cookies is that sites that opt in to
> access-control don't realize what they are opting in to. I.e. don't
> realize that just because the request is coming from the user, that the
> user has authorized it.
> 
> The risk of not sending cookies is that it can create a culture where
> people give out their passwords to other sites.
> 
> Another way of looking at it is that there are 3 parties involved in an 
> Access-Control request. The requesting site, the target site and the 
> user. Access-Control enforces that two of the parties are ok with the 
> request happening, the requesting site and the target site. But the user 
> is not asked. The solution I've always had in mind for this is that the 
> target site is responsible for asking the user that handing out his/her 
> data is ok before doing so. However it's very possible that they will not.
> 
> 
> Possible solution:
> One possible solution that was discussed was that the browser could at 
> the time of the request ask the user something like "linkedin.com is 
> trying to read some of your personal data from yahoo.com, is this ok?". 
> There are several issues with this though. In general asking the user 
> security questions is a bad idea since many people don't understand the 
> issue.
> 
> Also, implementation wise it's tricky since the load will have to be 
> stalled until the user answers. This more or less require in-you-face 
> UI, such as a dialog which we're always trying to avoid.
> 
> Additionally, doing this pretty drastically changes the semantics of the 
> Access-Control spec. For now we have said that just because a request is 
> coming from the user doesn't mean that the user has approved it. Putting 
> up a dialog like that would seem to indicate that the user *has* indeed 
> requested the
> 
> 
> For now mozilla has decided *not* to send cookies, though we are very
> interested in hearing your feedback.
> 
> Best Regards,
> Jonas Sicking
>