InformAction Forums

Hi,
Thanks for NS and the forum.

See the latest persistent cookie article from wired

System: XP Home SP3.
Fx 5.0.1, NS AMO Beta subscription.
Minimal whitelist, not even the big G.
Generally only "temporarily allow" current top level site and individual Flash placeholders when necessary for functionality. Frames and other html embeddings similarly banned unless necessary.
Refcontrol extension set to "block" by default.
Fx set to clear cache at each session close.
Generally Fx sessions closed daily if not twice daily - ie no tabs persist into new session.
CCleaner set to clear Flash cookies - which it does reliably, both with the user and site storage directories.
I fancy that this method - plus the fact we don't use Ggl services - keeps the kind of persistent cookies described in the article at bay. Can NS power users confirm this by answering the following question/s?

Questions: 1. Are the etags described in the wired article made using JS?
2. If NS doesn't block their creation, are we reliably deleting them by clearing the Fx cache?

Gentle *bump*, if anyone has time.

There's an old rfe about etag tracking.

Etag tracking does not (in theory) require scripting, only cache. The server just sends a etag for an image that is unique to the user, then on every visit the browser sends back this unique id to the server. If the tracking is being done by a 3rd party server, then one could block this server (or specific resources on it) in ABE.

cheers, al_9x, did note your contribution to that rfe.
Feeling more certain now that emptying cache at each session will be sufficient for my browsing anonymity

Caching and networks these days; wonder how much extra work it would make for servers if caching could be toggled.

Anyway thanks again.

See this thread at crypto-geek Bruce Schneier's blog, in which numerous preferences were suggested in Fx itself to prevent the attack. Including, of course, NoScript, because Kmetrics does use scripting as one means.

Someone named "tommy" also suggested using Sandboxie, appropriately configured, to delete these "undeletable" cookies. Any other good sandboxing or virtualization solution, properly configured and used, should be able to do the same.

Note: This site cannot endorse, support, or be liable for products made by other parties over which we have no control. Regard all advice on such as personal opinions, and investigate thoroughly before choosing solutions.

Tom T. wrote:Someone named "tommy" also suggested using Sandboxie, appropriately configured, to delete these "undeletable" cookies. Any other good sandboxing or virtualization solution, properly configured and used, should be able to do the same.

You don't need sanboxing or virtualization to clear your cache.

al_9x wrote:

Tom T. wrote:Someone named "tommy" also suggested using Sandboxie, appropriately configured, to delete these "undeletable" cookies. Any other good sandboxing or virtualization solution, properly configured and used, should be able to do the same.

You don't need sanboxing or virtualization to clear your cache.

True, but there are plenty of other privacy attacks that don't involve the cache. I kind of thought you'd be aware of them.

KISSmetrics seems to have changed its story, and its practices, since the lawsuit was filed. Regardless, I don't trust people who say that they use aggregate data only, or worse, that they anonymize all personal data and don't connect it across web sites. Might as well block as many privacy leaks as possible, no?

Please read the actual research paper, http://ashkansoltani.org/docs/respawn_redux.html. It was a follow-up to a 2009 paper. Excerpt from 2009 (linked at the previous):
***************************
"This is a pilot study of the use of 'Flash cookies' by popular websites. We find that more than 50% of the sites in our sample are using flash cookies to store information about the user. Some are using it to 'respawn' or re-instantiate HTTP cookies deleted by the user. Flash cookies often share the same values as HTTP cookies, and are even used on government websites to assign unique values to users. Privacy policies rarely disclose the presence of Flash cookies, and user controls for effectuating privacy preferences are lacking."
********************************
Flash cookies are not stored in the browser cache. http://en.wikipedia.org/wiki/Flash_cook ... _locations
Most people wouldn't expect a Flash cookie if they didn't view a Flash video. So clearing your cache is not enough.

Excerpt from 2011 update:
******************************
"... found that websites were circumventing user choice by deliberately restoring previously deleted HTTP cookies using persistent storage outside of the control of the browser (a practice we dubbed ‘respawning’).

"In our follow up study, we found that Hulu was still respawning deleted user cookies using homegrown Flash and Javascript code present on the Hulu.com site. Additionally, Hulu, Spotify, and many others were also respawning using code provided by analytics firm KISSmetrics.* Hitten Shah, the founder of KISSmetrics, initially confirmed that the research surrounding respawning was correct in an interview with Ryan Singel although he later criticized the findings after a lawsuit was filed."

(*Hulu and KISSmetrics have both ceased respawning as of July 29th 2011)"
************************************
It would be good to have read more about the offensive practices before raising the single nit, but thanks for the opportunity to post these links and provide more information to users about what's going on, and what to do about it. Cheers.

Tom T. wrote:

al_9x wrote:

Tom T. wrote:Someone named "tommy" also suggested using Sandboxie, appropriately configured, to delete these "undeletable" cookies. Any other good sandboxing or virtualization solution, properly configured and used, should be able to do the same.

You don't need sanboxing or virtualization to clear your cache.

True, but there are plenty of other privacy attacks that don't involve the cache. I kind of thought you'd be aware of them.

The objective here was to understand etag tracking and countermeasures to it (note the OP's 2 questions). Your post implied that one needs sandboxing and virtualization for it, that's not the case. I have no objections to you covering other attacks, but let's keep it clear, cache purging is a sufficient countermeasure to etag tracking, specifically.

al_9x wrote:The objective here was to understand etag tracking and countermeasures to it (note the OP's 2 questions). Your post implied that one needs sandboxing and virtualization for it, that's not the case. I have no objections to you covering other attacks, but let's keep it clear, cache purging is a sufficient countermeasure to etag tracking, specifically.

saywot wrote: <snippet>
Fx set to clear cache at each session close.
Generally Fx sessions closed daily if not twice daily - ie no tabs persist into new session.
CCleaner set to clear Flash cookies

Daily or twice-daily clearing of cache, Flash cookies, etc. still allows a lot of tracking, KISS and otherwise. Restarting, or emptying the sandbox, much more frequently is part of my recommended use of Sandboxie, as in the thread linked to @ Schneier blog. Sandboxing or virtualization can help prevent other vectors that KISS hasn't told us about yet, or haven't been discovered yet. (And by other companies, including methods not yet invented.)

The OP asked about blocking KISSmetrics (completely, we'd assume) in the title of his post, but confined his question to etag tracking. IMHO, limiting the answer to that one method does OP a disservice by implying that defeating etag tracking alone is enough to defeat all of KISSmetrics. YMMV.

KissMetrics: Worse than Reported - Undeleteable Cookie Survives Wipe

therube wrote:KissMetrics: Worse than Reported - Undeleteable Cookie Survives Wipe

As you said there, the concept of fingerprinting browsers and machines has been around for years. But that guy changed almost everything. The thought of them retrieving BIOS stirings is spooky. If they're taking advantage of Windows Genuine Notification, that's one more reason to delete it. If they're using Windows Genuine Advantage, you can get rid of that so long as you don't mind getting your MS Updates manually, and perhaps having to keep LegitCheckControl.dll on a flash drive, and put back on the machine occasionally. However, a while back MS started allowing even pirated OSs to get *security-only* updates, on the very wise grounds that a pirated machine that is botnetted, etc. is a threat to all of us legitimate owners as well. You may not get "optional" or non-security-related downloads without the LCC/WGA dll.

I once tried deleting oembios.bin, using a winlogon.exe that was modified not to require the BIOS string, not for any nefarious purpose, but just to save the 13MB of disk space. Machine was happy at first, but within a few weeks or a month or two, problems started cropping up.

Perhaps the suggestion about deleting WinGen Notification, and moving WGA off the machine until needed, would disrupt their ability to fetch the BIOS string.
Get a new mobo.
Or own more than one computer, and rotate among them, just to mess with them.
Find two or three friends you trust, both morally and technically, and rotate computers among yourselves every week.

(In the long run, it's a losing battle. But at least let's make them fight for it.)

therube wrote:KissMetrics: Worse than Reported - Undeleteable Cookie Survives Wipe

Thanks for the link.
Interesting enough reading, and for my general browsing uses I can't be thankful enough for NS. The i.js needs to run to scrape up any extra-browser info, so surely with a careful whitelisting approach there's no need to be any more worried about bios/general hardware id than, for instance, Adobe Flash objects. Fingerprinting has indeed been around for yonks - agreed, therube.

Using the free SIW utility from Gabriel Topala, we could find no serial number or similar once-off motherboard or BIOS machine ID - and for the rest of the information, I'm guessing you'd have to have a database like the EFF test to find out whether your own particular hardware configuration was unique; and I highly doubt it is possible unless you're also in an unusual location such as a corporate network.
Of course the tie-in to Win dlls is noted from contributor TomT, but once again... with NS and a minimal whitelist, the i.js isn't going to run without the user's say-so.