The 3 Threats
Last week, a group of researchers released a paper detailing 3 major new threats to online privacy:
1. Canvas fingerprinting: This basically involves telling your browser to draw an invisible image. It is done in such a way that each browser is likely to draw the image slightly differently. This allows the site to identify your browser.
3. Cookie Syncing: This is the practice of two or more sites sharing a user identifier with each other, allowing the sites to combine their respective databases with each other to build a more detailed profile of their users’ browsing history.
These methods are far more difficult to defend against than the use of traditional http cookies, which are easily deleted. The paper argues that the most viable defenses would be at the regulatory level or built in by browser vendors who care about user privacy. Nevertheless, given the variety of mitigation techniques, both those cited by the authors and those that are not, the privacy conscious user is not completely helpless. My goal in this post is to compile a list of potential countermeasures cited by the authors, cited by other sources, and from my personal experience, so that users are not without recourse until the law catches up or browser vendors begin implementing the necessary defenses against tracking.
1. Defending against Canvas Fingerprinting
Let’s look first at canvas fingerprinting. The only specific countermeasure the authors mention is to have the browser ask the user’s permission for every canvas read attempt, as they claim Tor Brower does. But Wladimir Palant, author of the Adblock Plus plugin, argues that canvas fingerprinting may not be able to distinguish between users with the same configuration, thus possibly making the technique ineffective as a means of tracking millions of users.
A final option mentioned by ProPublica is to use the experimental Chameleon browser. I have not tried Chameleon and cannot vouch for its effectiveness.
2. Defending against Evercookies
Cookie respawning can work in both directions. For example, just as Flash cookies can respawn http cookies, the paper mentions that http cookies can also respawn Flash cookies. Adding in other vectors such as localStorage and IndexedDB greatly complicates the situation by allowing more opportunities for respawning. Once cookies from any of these vectors have been placed, the authors argue that the only way to terminate the tracking would be to clear all vectors (including all browsers) simultaneously.
Again, the paper cites Tor as a browser capable of clearing many vectors; more than 10 are listed. Unfortunately, most browsers are much less capable in this respect. The authors suggest disabling Flash cookies, but mention that localStorage and IndexedDB cannot be disabled, because it would break core functionality.
Adobe’s site provides instructions on how to disable the storage of Flash cookies, more formally known as local shared objects: Simply open the settings manager, and either delete Flash cookies placed by specific websites or simply delete Flash cookies stored by all sites.
I would suggest deleting all Flash cookies. I would also suggest visiting the second tab of the settings manager to prevent all future sites you visit from storing Flash cookies. Move the slider to “none,” and check “Never ask again”.
Firefox users have an alternative method of managing Flash cookies. The add-on BetterPrivacy allows you more control over Flash cookies. You can choose to delete specific Flash cookies, or to use customizable options such as automatically deleting all Flash cookies at regular time intervals.
Adobe’s article doesn’t mention the following settings, but while you’re configuring your Flash player, I would suggest that you apply them as well to protect your privacy:
1. In the first tab, “always deny” sites from accessing your camera or microphone.
2. In the second tab, don’t “Allow third-party Flash content to store data on your computer” and don’t “Store common Flash components to reduce download times”.
3. In the third tab, choose “always deny” to prevent websites from accessing information using an older system of security.
4. In the fifth tab, delete all sites, unless there are specific sites that you do wish to allow to access your camera or microphone.
5. In the seventh tab, you can choose to forbid sites from using your upload bandwidth to distribute files (this is similar to what BitTorrent does). This basically lets sites use your bandwidth so they don’t have to use as much of their own. Unless you want to allow this for some unique reason, I suggest you disable it.
Other Cookie Respawning Vectors
There are so many ways to respawn http cookies. If at least some, such as localStorage and IndexedDB, cannot be disabled, what is a concerned user to do?
For Windows users, one method is to contain the browser using a program like Sandboxie. When a browser is run “Sandboxed” (contained), it is unable to make certain changes to your computer. For example, if any cookies are downloaded while you are running a Sandboxed browser, all you would have to do to get rid of the cookies would be to empty the Sandbox when you’re done browsing.
Mac and Linux users don’t have the option of running Sandboxie, but they can run a virtual machine. Using software such as VMware Workstation or the free alternative VirtualBox, users can run a virtual machine, essentially a computer within a computer. Both VMware Workstation and VirtualBox have a “snapshot” feature that allows you to preserve the state of the virtual machine. You would simply install your choice of operating system onto a virtual machine and take an initial snapshot, then do all the surfing you want. Once you’re done, you can clean out all storage vectors simply by reverting to the snapshot. The virtual machine keeps your host (physical) computer from getting any cookies.
3. Defending Against Cookie Syncing
The authors claim that no tools specifically block cookie syncing. They suggest blocking all third-party cookies and http traffic as a blunt approach, but their tests show that even blocking third-party cookies only reduced the number of synced IDs and parties by “nearly a factor of two,” thus implying that even this blunt approach is not completely effective. The Twitter of one of the authors lists form-submission and redirects as two of the methods by which third-party cookie blocking is circumvented while also raising the possibility that there are other methods of circumvention.
Until all of these methods are identified and effective countermeasures found, there may be no way to effectively block all cookie syncing. But not all is lost. The authors point out that if syncing is the only threat left unchecked, simply clearing cookies can separate an individual’s browsing history before the clearing process from the user’s activity after the clearing process. It is only when respawning is combined with syncing that the histories may become linked. Thus, if we can prevent respawning, we can limit the effect of cookie syncing only to the current browsing session. For example, if you set Firefox to “Clear history when Firefox closes” and include “Cookies” in the list of items to be cleared, this should give you a clean slate every time you close and restart the browser as long as you’ve dealt with respawning.
The threats identified by this paper may significantly raise the stakes for users who wish to maintain their privacy on the Web. As the authors suggest, the burden on users would be lessened significantly if regulatory bodies and browser vendors take action to move the first line of defense further away from the everyday user.