|
Size: 5300
Comment:
|
← Revision 8 as of 2012-05-17 21:05:29 ⇥
Size: 26
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| 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. Next, each browser window will have a list of cookie jars it may access, similar to the PATH environment variable in execution shells. For the most seamless user experience, some cleverness will be needed in dynamically setting up and modifying the COOKIEJARS (for lack of a better name) variable. 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 not in jars 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 there are multiple jars for the site (see below), the user can choose which to use. The user might allow this for this window only (which adds the relevant jar to COOKIEJARS), or permanently (which sets a flag on the jar that it can be added any time this site is loaded). If denying access to the jar, the user should be prompted to either delete the existing cookie jar, or give it a meaningful name. This will help prevent clutter. Note - The message should inform the user when cross-site references are going on. For example, if nyt refers to a fb URL, which would get your fb cookie: The page at www.newyorktimes.com would like to access data stored on your computer by www.facebook.com 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. I believe the impact will be minimal (similar to asking to remember passwords), and most users will choose to automatically open the jars for their most common sites. 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). |
#redirect CookieSecurity |
