From the “big fricking surprise department” comes the news that “private browsing is hard to implement“. Well, duh!

Also, quite obvious: the biggest problem were “Flash cookies” – again, duh!, since they are stored outside of the browser, so there is not very much the browser can do about them. There are many ways users can be “tracked”, and the given the obsession of security companies focusing on cookies, advertising (and other companies interested in profiling users) will surely (if they haven’t done so already) diversify their options. A few other options I didn’t mention until now for tracking users:

• Using Silverlight / signed Java applets to create markers
• Using interactions with other plugins (like asking the Windows Media Player to download a plugin for example)
• Using other tricks in the HTTP protocol. From the Google Browser Security Handbook:
  

  Trivia: as hinted earlier, ETag / If-None-Match, as well as Last-Modified / If-Modified-Since header pairs, particularly in conjunction with Cache-Control: private, max-age=… directives, may be all abused to store persistent tokens on client side even when HTTP cookies are disabled or restricted. These headers generally work the same as the Set-Cookie / Cookie pair, despite a different intent.

The last option can be detected / defended against by the browsers, however the rest are beyond the browsers control normally.

Conclusion: true anonymous browsing involves such high sacrifices and reduction in functionality (demonstrated by the decloak Metasploit project for example) that very few users would be willing to use it, and it is certainly far from a “one-click solution”.