Proposed privacy feature for web browser

A bit of back-story

Cookies are small bits of data web sites can store on your computer. When the website creates a cookie, it can protect your information by choosing to limit the lifespan of the cookie, and the sites and pages which will get access to the data.

Whenever the user goes to a website, any cookies that site has access to are sent automatically with the request for the page.

While web browsers often give users the option of whether to allow cookies to be stored, and have a mechanism for deleting cookies, this is not enough. Most of the data protection is at the discretion of the website which sets the cookie - not the discretion of the user.

Some users choose to disallow cookies completely, but most modern websites will not function properly without them.

Modern browsers do restrict cookies to a single domain, but that does not prevent website B from colluding with website A to read data and track users' activity.

• Log in to website A - a cookie is created.
• Load website B - The page includes a reference to a URL on website A.
• Your cookie and a reference to website B is sent to website A, allowing A to track your activity. A can then return personal data in the response, which website B can do whatever it wants with.

It would have been nice if this functionality had been blocked as a security risk long ago, but it was not. As a result, most modern websites are designed to take advantage of it, and would not function if it was directly prevented.

Cookie Jars

Cookie jars are a way to logically separate websites you visit, to prevent multiple sites from colluding to track you.

Cookie jars are an additional component connected to the domain which cookies are registered to. Each jar will only hold cookies from a single domain.

Each browser window will have a list of cookie jars it may access, similar to the PATH environment variable in execution shells. Let's call this variable COOKIEJARS.

When a new window/tab is opened, or when a URL is manually entered, COOKIEJARS will be set to null.

When a URL is loaded for which there are existing cookies (which are in jars not listed in COOKIEJARS), the user might (depending on jar settings and user preferences) get a prompt explaining that the website wants access to data it stored there previously.

If the cookie jar request matches the window's domain (no cross-site reference), the dialog might say:

• The page at <url> would like to access data it previously stored on your computer

If there is only one cookie jar for the site, present the following options:

• Allow this window to access the cookie jar (which adds the jar to COOKIEJARS)
• Allow this site to access the cookie jar (which allows all future same-domain accesses to this jar)
• Clear this site's data (deletes jar)
• Never store data for this site (deletes jar and sets domain to only use temporary cookies which will be removed when the session ends)
• Use multiple cookie jars

If there are multiple cookie jars (or the 'Use multiple cookie jars' option is chosen), present a dialog allowing the user to:

• Rename existing cookie jars for this domain
• Delete existing cookie jars for this domain
• Select an existing cookie jar for this domain
• Select no existing cookie jars

If the cookie jar request does not match the window's domain (cross-site reference), the dialog might say:

• The page at <window url> would like to access data stored on your computer by <request site>

and should have the following options:

• Allow this window to access the cookie jar (which adds the jar to COOKIEJARS)
• Allow this site to access the cookie jar (which allows all future accesses to this jar from the window's domain)
• Allow all sites to access the cookie jar (which allows all future accesses to this jar)
• Prevent this site from accessing the cookie jar (which prevents all future accesses to this jar from the window's domain)
• Prevent any other sites from accessing the cookie jar (which prevents all future accesses to this jar except from its own domain)
• Use multiple cookie jars

If there are multiple cookie jars (or the 'Use multiple cookie jars' option is chosen), present a dialog allowing the user to:

• Rename existing cookie jars for this domain
• Delete existing cookie jars for this domain
• Select an existing cookie jar for this domain
• Select no existing cookie jars
• Remember my choice for this site (always use the selected option for the window's domain)

When a website creates a cookie, if COOKIEJARS already includes a jar for the domain, the cookie will be stored in that jar. If not, a new jar will be created for the domain, and the cookie stored there. This new jar will be added to COOKIEJARS. If the user chose to deny access to an existing jar when the site was loaded, this will lead to two jars for the site, possibly holding different data.

With multiple cookie jars per domain, a user might be logged in to two different facebook accounts at once, in different tabs/windows.

Inheritance

A good metric to use might be the 'referer' header value - any time a referer would be sent with a request, the window should inherit the COOKIEJARS variable from the window the referer URL came from. Based on user preferences, this inheritance could be restricted to within the same domain, or not.

Impact

If user preferences are set to automatically open cookie jars when requested, there is no user experience impact. Cookie jars will be one-to-one with domains, offering no new functionality.

If user preferences are set to never open cookie jars, each new window or session will start with a clean slate. No dialogs will be displayed, but the user experience will be impacted in that all cookies will essentially be session cookies.

If user preferences are set to ask the user before opening cookie jars, a dialog will be presented the second time a cookie-using site is visited, informing the user that stored data will be sent.

It's hard to know the level of impact this will have, without more research.

My hope is that the impact will be minimal (similar to prompting to remember passwords). Most users will probably choose to automatically open the jars for their most common sites, minimizing the impact.

If there is a user preference setting to automatically allow same-domain access to cookiejars, but ask before allowing cross-site accesses, that might be a good balance between reduced user impact and improved privacy.

Scope of privacy protection

This will not prevent tracking by IP address. External site references will still be loaded, and cookies will still be stored for use within the current session. It will be a dramatic improvement over the current situation though, putting privacy back in the hands of the user to a large degree (without crippling the web).