SecurityEngineering/Jan2013WorkWeek/05-Cookies and Whatnot
Quick summary of the bits of our cookie system and how they work (or don't), then we'll discuss ways we might be able to make it better. (Brainstorm & refine).
1/16 at 10:00 am
Session Lead: Mike Connor
Relevant: http://jboriss.wordpress.com/2010/06/02/defeating-the-cookie-monster-
Quick overview:
Cookie DB lives in memory in big hash table. Finally migrated off plaintext files a few years ago. Cookies aren't ideal. More than the browser UI, most of what cookies do is reflect how the internet worked in 2003. There was a third party cookie setting that let cookies be sent but not set. Keep breaking the web when we try to fix things. Not tied to anything based on context, but in private browsing may be tied to windows or tabs.
Don't have:
- Nuanced cookie handling
- Fine-grained control over cookies
What do we need to do about cookies -- what can be better?
- Permissions are coarse
- P3P wasn't helping
One of mconnor's first huge patches for Mozilla was a big refactoring. We had an allow-per-session pref, but not a permission. CookiePermission is like nsIPermission -- but not. We had more ambiguity about "what happens" when we combine user-selected settings.
Four possible decisions on any cookie:
- Allow
- Allow for session
- First-party only
- Block
Recently added a first-party only for individual sites (permissions). General Principle: ** Explicit choices should override generic choices. **
Need to know who sets/changes these prefs.
Also had a mode that was to return third party cookies if they were set as a first party. This broke a lot of weird long-tail web Something similar is going to get turned back on: https://bugzilla.mozilla.org/show_bug.cgi?id=818340
We used to cap the number of cookies we stored -- old ones would get purged. As the tech is available, it gets used.
There have been "dubious" p3p policies published to work around limitations in some other browsers that rely on P3P to set cookie policies.
It would be helpful to identify "bad actors" so people can say no to sites. We have collusion, but we need some generic way to identify "badness" or ill-reputed sites.
mmc suggested that collusion graph submission (central server that collects info from collusion users to show the whole of the web) with a reputation system is in the works.
Relevant: https://wiki.mozilla.org/Privacy/Features/Per-Site_Third-Party_Cookie_Setting/Brainstorm_UX
One problem is that third-party cookie blocking is easy to work around with a double-redirect.
mconnor: What are we trying to solve?
mmc: want to enable add-on developers to experiment because probably there will be varied use cases and varied desired defaults. I want easier ways of trying out new policies.
Example, there was some feature in IE that allowed you to open a new window with a new cookie jar. Maybe we should explore something like that?
WHAT ELSE IS THERE?
- Separable cookie jars for session cookies?
- Opportunities for driving cookie changes based on needs of other security/privacy features
- ...?
Here's the "dumb thing": for a really long time there was this deep opposition to accepting cookies. But problem is that they want to be able to change the cookie and also receive the cookie. With really granular control (where we could eventually turn off cookies after so many transmissions) messes up lots of web site flows.
Do all the cookie permissions apply to HTML5 storage? No, this might be a problem. Can we create a more comprehensive data control tool for individuals (for all things like cookies)?
It would be cool to understand what's required to load a page. Might be nice to have a simpler set of "here are the types of things we'll accept" from various web sites. Right now it's all or nothing. Stuff is spread all about. The UX design team have talked about redesigning data storage stuff if people wanna implement it.
Our priorities have probably changed in the last number of years. Maybe we would design things differently today. Probably worth a shot to see if we can do better.
apps
lco asks: how does this play out in the app environment? How is this different? In B2G apps each have separate cookie jars. How are cookies gonna be different in the context of the phone, and what can we do to support that?
People probably want cookie clearing per-app. Where we don't have a "reset this app" button, we probably need better control for users. mconnor thinks we want data management, not cookie management.
mconnor thinks the main thing is to have a more comprehensive put on what we want privacy controls to be like on the internet.
- privacy controls per-app is obvious
- what is next? What are the things we want by default? What do we want to allow users to protect themselves from?
- Cookies, localstorage, cache -- these things and more should be unified in the user's view.
- Find ways for sites to *always* be not-remembered without being user visable.
Privacy isn't usually about the things we want it to be about. People should have a right to it regardless of what they do with privacy.
action items
- [mmc and ddahl] going to work in html5 storage stuff into the cookie add-on for TP study
- [lco] try to get design team to do a sprint on mock-ups for new settings panel
- [mmc] organize brainstorming session around organizing our thoughts around privacy controls and what kind of tools we can offer users to help them with their use cases.
