Taking a break from the series on Android and NFC to revisit a recurring theme: privacy features in web browsers.
It has been 10+ years since Internet Explorer introduced the notion of downgrading cookies, as part of P3P-based cookie management introduced with version 6. To recap: HTTP cookies are small identifiers used by websites to track users across multiple visits. In terms of lifetime, cookies come in two flavors. Persistent cookies— so called because the expectation is that they are stored on persistent storage such as disk drive for long term access– have a fixed expiration date specified by the website, which can be as far into the future as the year 2038. By contrast session cookies are intended to be temporary, getting automatically discarded when the user exists their web browser. (Strangely certain usage patterns where the browser is always left running, as in Chromebooks and even incarnations of Chrome on Android, means this “temporary” period can span days or weeks.)
Downgrading is the act of converting a persistent cookie into a session cookie, with one twist: lifetime of the cookie is bounded by the session and original expiration specified by the website, whichever occurs first. This was an explicit design goal to prevent a website from discriminating against users who employ the feature. It is relatively easy to detect when cookies are rejected altogether, and compel the user to modify their settings. If downgraded cookies outlived their stated expiration date, a website could likewise detect that their long-term tracking cookies were not being retained: set a cookie with a very short lifetime on the order of seconds and check if it is still being replayed after that time period elapses. Stopping this also guarantees compatibility: if websites can’t detect whether a cookie was accepted ,or downgraded, even when they go out of their way, using the feature will not break an existing website that was relying on cookies during that browsing session either.
Downgrading is used judiciously in IE default P3P settings, as middle-of-the-road response to unsatisfactory policies, preferable to outright rejecting the cookie which may break the site. Other browsers followed suit with comparable features. For instance Firefox has an option to delete cookies automatically when user exits the browser. Interestingly enough, IE never exposed an option in the UI to downgrade all persistent cookies regardless of P3P policy. (Downgrade option is not offered in the advanced privacy preferences dialog, but it is possible to import custom XML settings to do that. Here is an example ZIP file containing custom settings to downgrade all first & third-party cookies.)
What changed in the intervening 10 years? Main difference is that cookies are no longer the only ubiquitous tracking mechanism. Granted this was never true, even at the height of the great Internet privacy scare over cookies. Many creative ways to abuse other stateful mechanisms for tracking has been discovered, including DNS, visited sites history and page cache. But these schemes all had limitations limiting their scaling. Into the void stepped in Flash, with its local shared objects and later HTML5 standardizing similar capabilities with session storage and local storage, complete with the imprimatur of W3C. Both mechanisms present websites with functionality comparable to HTTP cookies. In fact LSOs are dubbed “Flash cookies” informally, and they have the feature/disadvantage (depending on perspective) of functioning across multiple browsers.
More importantly from a privacy perspective, both operate outside the purview of existing cookie controls. For example P3P policy evaluation is not used to limit access to the DOM storage or Flash cookies. Downgrading cookies has no effect when the same tracking identifier is also stored as Flash LSO or in local storage, which outlives the cookie. This is not a theoretical concern: a 2009 study from Berkeley found sites “resurrecting” deleted cookies from Flash counterparts. A follow up study in 2011 showed similar tracking behavior using HTML5 storage and even the HTTP cache.
Privacy features in the browser have not kept up with the new reality. There is no equivalent to downgrade option for converting persistent DOM storage into session storage. Nor is there any option to synchronize the lifetime of Flash LSO to cookies from the same origin, to prevent one from being used to respawn the other. There are crude mechanisms in place for viewing/deleting stored LSOs per website, and blacklisting sites from using Flash storage in the future. But these mechanism are proprietary to Flash, not influenced by existing browser privacy settings that are readily accessible to the user. For example importing custom privacy settings with a blacklist of sites can block them from using cookies, but has no impact on alternative tracking mechanisms. (In fact Flash settings have such haphazard UI, as embedded control inside a web page hosted on a Macromedia website that the authors felt compelled to add this helpful explanation: “The Settings Manager that you see above is not an image; it is the actual Settings Manager itself.”) There is also the heavy-handed approach to private browsing which discards all state after the session ends– and even that was initially undermined by Flash, until Adobe kindly released an update in 2010. Neither of these mechanisms permit fine-grained control where scope of tracking is limited based on website policies.
It is a case of bit-rot operating at higher level. Strictly speaking cookie management in IE is still operational in the sense that it works as advertised. Yet it no longer serves the original purpose of protecting users against tracking, because it has not been improved/expanded to cover alternative mechanism for infringing on user privacy.