Status
| Multiple Cookie Jars | |
| Stage | Draft |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | ` |
{{#set:Feature name=Multiple Cookie Jars
|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature status note=` }}
Team
| Product manager | Sid Stamm |
| Directly Responsible Individual | Sid Stamm |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | Sid Stamm |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=Sid Stamm
|Feature feature manager=Sid Stamm |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=Sid Stamm |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
For many parts of the browser, including add-ons, it would be nice to maintain a separate cookie store or cookie jar. Currently the cookie service only allows one place (and one set of all cookies for a domain) but some features would benefit from having a different "profile" of cookies depending on the context in which the HTTP requests go out.
2. Users & use cases
- Safe Browsing traffic uses a cookie to make sure quality of service is adequate and abuse of the system goes mitigated. There's no reason cookies for the Safe Browsing service to be shared with those used by general traffic to Google properties (e.g., log into gmail). The Safe Browsing service could still operate properly if its cookies were separate from the rest of the user's http cookies, and the isolation of identification tokens would increase our users' control over HTTP-borne identifiers.
3. Dependencies
`
4. Requirements
- Backwards compatible: things assuming one cookie jar must still operate without code change.
- Arbitrary jarring: add-ons should be able to construct and use their own cookie jar.
Non-goals
`
Stage 2: Design
5. Functional specification
`
6. User experience design
We should revamp the Cookie UI to present multiple jars (if they're deployed) or change the delete-individual-cookies UI to make it clear which jar each cookie is in.
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
` {{#set:Feature open issues and risks=` |Feature overview=For many parts of the browser, including add-ons, it would be nice to maintain a separate cookie store or cookie jar. Currently the cookie service only allows one place (and one set of all cookies for a domain) but some features would benefit from having a different "profile" of cookies depending on the context in which the HTTP requests go out. |Feature users and use cases=# Safe Browsing traffic uses a cookie to make sure quality of service is adequate and abuse of the system goes mitigated. There's no reason cookies for the Safe Browsing service to be shared with those used by general traffic to Google properties (e.g., log into gmail). The Safe Browsing service could still operate properly if its cookies were separate from the rest of the user's http cookies, and the isolation of identification tokens would increase our users' control over HTTP-borne identifiers. |Feature dependencies=` |Feature requirements=* Backwards compatible: things assuming one cookie jar must still operate without code change.
- Arbitrary jarring: add-ons should be able to construct and use their own cookie jar.
|Feature non-goals=` |Feature functional spec=` |Feature ux design=We should revamp the Cookie UI to present multiple jars (if they're deployed) or change the delete-individual-cookies UI to make it clear which jar each cookie is in. |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}
Feature details
| Priority | P1 |
| Rank | 2 |
| Theme / Goal | Contextual Identity |
| Roadmap | Privacy |
| Secondary roadmap | Platform |
| Feature list | ` |
| Project | ` |
| Engineering team | Privacy |
{{#set:Feature priority=P1
|Feature rank=2 |Feature theme=Contextual Identity |Feature roadmap=Privacy |Feature secondary roadmap=Platform |Feature list=` |Feature project=` |Feature engineering team=Privacy }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}