Researchers Expose Cunning Online Tracking Service That Can’t Be Dodged

KISSmetrics has a post explaining how the tracking works. <a href="http://www.kissmetrics.com/how-it-works" rel="nofollow">http://www.kissmetrics.com/how-it-works</a> They claim that simply using AdBlock is enough to defeat the tracking. They also claim "KISSmetrics has never, and will never, share anonymous customer activity of what people did on customer A’s site with customer B."

I usually use Firefox with it set to forget everything on exit, along with the Noscript plugin. Does anyone know if this tracking service would work on a FF user running Noscript?<p>By the way, using Noscript has made me aware of something that I didn't previously know: many sites call Javascript from lots of other domains. I've seen websites with as many as 18 other domains listed on the Noscript pull down menu. And I have seen an increasing number of XSS alerts as well.

Jeez guys, not all tracking is evil. You know all that awesome content that exists on the web? Well the people that make and distribute that content need information to make your experience better. Let's say you start a new site. Let's use 8tracks for example: they provide a two-tiered service, one free and premium. The free service exists to drive you to a paid account, but you still derive value from it, nonetheless. In exchange for that free value, you give them stats that they use with their advertisers, who in turn give them cash they can then use to make your experience better. It's a give and take system. Thankfully, money isn't the only currency on the web, a little bit of info and some advertising goes a long way. I am willing to trade value for value, it's fair that way.

Why single out Kiss Metrics? One example, I visited Fox News last month and found they set up an HTML5 database called, in a rather unsubtle choice, "evercookie". I can't confirm that this is the case currently, though since the ability to view HTML5 databases in Preferences seems to now be missing from all the browsers I have (which seems odd, too!).

I'm not sure these researchers understand how private-browsing functions. The session in a private-browsing window is only private from the non-private sessions and only private from future private-sessions when all private sessions -- private-browsing windows -- are destroyed.<p><a href="http://imgur.com/a/LjjYf" rel="nofollow">http://imgur.com/a/LjjYf</a><p>Here I have a non-private session, where I have request i.js (a second time), invoking an If-None-Match check with my non-private ETag of i.js. Opening a private session, my request to i.js does not invoke my non-private session's ETag and subsequent If-None-Match -- i.js is fetched as if my session has no memory of the URI.<p>In the second shot, I had closed my private session opened in the first test, and I then opened a new private session, without closing my previous non-private session. Again, my private session requests a new i.js, with no idea of the non-private session's nor the first, now closed, private session's version.<p>The onus is on browsers to restrict inner-private-session storage from leaking between tabs, but it could be quite messy.

I tried to do my best figuring out what this cunning new method is, but the article seems to have no information. Is it just that it's using my browser's ETags cache?<p>Also, what's with referring to ETags as a "theoretical technique never before seen in the wild"? It's pretty friggin standard.

Analytics is here to stay. Unless this practice is regulated (which in turn can end up being heavy handed and far reaching and in turn could discourage innovation) analytics will remain a big piece of what IT will focus on, mainly in getting a 360 degree view of their customers.<p>Instead of regulating everytime we see a practice that we may not agree on, how about we treat it like when the "iPhone location" fiasco broke. Do not criminalize the possession of customer data or even tracking, criminalize distribution or malicious use of it. If Company A wants to know where I came from, so that they can share their ad dollars effectively, I am ok with it. But do ensure that they dont share it with other companies in that network (whether Kissmetrics or someone else) for any reason. My online identity remains my own, it does not need to be dissected for further analysis by doubleclick, kissmetrics et al.

There is nothing more evil in modern business than marketers. Between real life experience and MBA classes I have come to despise most everything involved in modern marketing, especially in the technology space.

You know, when individuals access a company's computer using technically valid means (e.g. a username and password or by logging in from multiple locations), then its criminal charges, international arrest warrants, and jail time. [1] [2]<p>But when companies do it to people, oh its just a clever programming trick, and its not a problem because you could install additional software to prevent it from happening [3].<p>The law is showing up pretty clear that simply because you <i>can</i> access a computer system, does not mean that you may, and indeed that doing so without the user's permission is a crime. Causing a computer to store data on a user and then serve that data back to another computer seems dodgy without permission. Doing it when the user has taken reasonable steps to prevent it from happening? Class action time!<p>[1] <a href="http://www.techdirt.com/articles/20110722/02351315202/how-cisco-justice-department-conspired-to-try-to-destroy-one-mans-life-daring-to-sue-cisco.shtml" rel="nofollow">http://www.techdirt.com/articles/20110722/02351315202/how-ci...</a><p>[2] <a href="http://www.geek.com/articles/geek-pick/aaron-swartz-spent-months-stealing-data-from-mit-now-facing-35-years-in-prison-20110719/" rel="nofollow">http://www.geek.com/articles/geek-pick/aaron-swartz-spent-mo...</a><p>[3] <a href="http://www.kissmetrics.com/how-it-works" rel="nofollow">http://www.kissmetrics.com/how-it-works</a>

Can it be dodged by emptying browser cache as well blocking iframes which I assume is causing such content to be stored in browser?<p>Edit: seems so: snip ... the persistent tracking can only be avoided by erasing the browser cache between visits.

<i>That Can't Be Dodged</i><p>Very interesting article, but the proclamation you can't avoid it seems a bit too far. When my browser exits it both deletes cookies and clears the cache, which looks like it's enough to break the tracks.

I've worked with the KM folks. Great people, genuinely kind, and they want to make a great product. I think it's disgusting to single out a startup like this, especially right as they are gaining traction with some big-name clients.<p>There is value in what they are doing, and there's absolutely nothing wrong with it. They are tracking user behavior completely anonymously.

"This is yet another example of the continued arms-race that consumers are engaged in when trying to protect their privacy online..."<p>I don't think arms race is a good analogy here. Arms race is a good analogy for virus-makers and antivirus software, since their goals are exact opposites.<p>The goal of analytics sites like KISSmetrics is to measure and understand the behavior of their customers as a group, not as specific individuals. The goal of people who wish to remain untracked is to avoid having personally identifiable information about them stored without their consent. These goals are not opposites and don't necessarily result in an arms race.

This has been known about for years, and was a concern on various mailing lists years ago. The solution at the time was said to be that browser vendors will build in tools for cache control in the same way they have for cookie controls.<p>The first sites to exploit this were, as always, porn sites. They used Etags in referral tracking to avoid webmaster fraud. (the webmaster would have to include a script from the affiliate co which would set an Etag).<p>You know what is more interesting? The Last-Modified header. The HTTP spec says that you are supposed to put a date in there, but it also says not to bother parsing the date if you are a client since date parsing is such a pain in the ass. So clients just copy the date string and store it and then replay it subsequent requests.<p>you can put whatever the hell you want in a last-modified field and <i>all</i> browsers will just store it and then replay it later in subsequent requests to the same resource. for eg.<p>initial request:<p><pre><code> GET /_modified_test HTTP/1.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Cache-Control: max-age=0 Connection: keep-alive Host: localhost:8888 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_6) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.830.0 Safari/535.1 </code></pre> initial server response from my dev server (note Last-Modified header used):<p><pre><code> HTTP/1.0 200 OK Server: Dev/1.0 Date: Sat, 30 Jul 2011 11:48:25 GMT content-type: text/html; charset=utf8 Last-Modified: random_token_i_set Cache-Control: no-cache Expires: Fri, 01 Jan 1990 00:00:00 GMT Content-Length: 1634 </code></pre> subsequent browser request to the same resource:<p><pre><code> GET /_modified_test HTTP/1.1 Host: localhost:8888 Connection: keep-alive Cache-Control: max-age=0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_6) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.830.0 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 If-Modified-Since: random_token_i_set </code></pre> with new webapps now being single-page with either hashchange or pushstate support, it means almost all requests are made on the backend to the same resource, so you can track the user across all pages on the entire site and across other sites.<p>concerning, but a known problem. even with these headers patched there is still a lot of information that can be used to fingerprint clients (ie. having everything switched off is still a fingerprint that makes you unique). I don't think chrome, safari, IE or Firefox will ever implement these advanced features, it will be up to somebody else to release a browser that is more privacy aware or to maintain a plugin that is.<p>I wrote a plugin that does this, but a lot of information still leaks through (it is in my github but I haven't released/announced it in any way). I am contemplating just forking webkit and doing a whole separate 'privacy aware' browser but haven't found the time. in short, the browser makers know about this, and have known about it for years - there is just no real interest in providing user tools to fully anonymize users.<p>Edit: if anybody is interested in the plugin it is here: <a href="https://github.com/nikcub/Parley" rel="nofollow">https://github.com/nikcub/Parley</a><p>it blocks all third party requests and provides other features. it works, just needs a bit of a clean up and release.

Looks to be using the individual etags associated with each cached object. Pastebin: <a href="http://pastebin.com/FhUYuRsb" rel="nofollow">http://pastebin.com/FhUYuRsb</a>

"I would be having lawyers talk to you if we were doing anything malicious." -- this seems like the type of defense that a good lawyer would tell you never to use.

great comments.<p>we're planning to follow up with a post that has the technical details of the Etag stuff (sorry about 'light on detail', it was a press piece after all).<p>you're right in that it's been a known method that has been written before (samy had it in evercookie which we site in the paper and a few others have blogged about it). what seemed new (at least to me) was actually encountering it 'in the wild' on a top50 site like hulu. if this type of thing been written about before, definitely let me know so we can cite it.<p>fwiw, yes noscript would block the javascript that kissmetrics uses to respawn using html5/etags, however there's still the swf that regenerates using flash cookies. also josh highlights ways the you could do this with javascript disabled using CSS (kissmetrics actually also uses hidden values in CSS as well if you look at the src)<p>either way, blocking javascript/flash would render hulu, and other 'rich media' services like it, largely useless unfortunately.<p>RE: foxnews/polldaddy. actually they were naming their database 'evercookie' some time ago although they've seemed to have changed that (now it's just called pd_poll__). you can see the script they use here which they use html5 and swf databases: <a href="http://pastebin.com/0ieZ2i22" rel="nofollow">http://pastebin.com/0ieZ2i22</a> (prettyfied from <a href="http://static.polldaddy.com/p/4424060.js" rel="nofollow">http://static.polldaddy.com/p/4424060.js</a> )<p>it's likely that polldaddy/foxnews are using these techniques so to ensure that a given computer only gets to vote 'once'. however, i think there are probably much better ways to do this.<p>hope that helps. i'll link a blogpost down here somewhere (which means that i actually have to start blogging finally ;)

Title is misleading. I routinely 'dodge' this - all it takes is disabling caching. If you understand how caching works, it's trivial to conclude that it's possible to use etags for tracking. It's the same with the CSS-based browser history attack - if your browser is storing data, and it's possible for a server to tell you're storing it, it can be used to track you.

The issue is clearly not that they're tracking. The issue is that they're going to extremely devious lengths to prevent you from removing their ability to track you using standard tools.<p>I've quite a few /etc/hosts entries, blocking third party cookies, clearing cookies &#38; cache on close, no flash cookies, and so on, but I always expect they'll be something they can find still.

The article focuses mostly on legal measures (e.g. lawsuits, regulation), but my guess is that those would only deter the largest companies. What I'm more worried about is why 'incognito' modes in current browsers don't appear to stymie this tracking, and how likely it is that that can be fixed.

I generally browse with Javascript, cookies, and plug-ins off (except for a few whitelisted sites). From what I understand of the technology (it loads some javascripts initially), I think that would dodge it.

is there any indication on where the data is stored?

I put together a detailed follow-up on the KISSmetrics/Hulu respawning mechanisms outlining exactly how they work (although this is probably pretty basic for most the audience here).<p>Details here: <a href="http://ashkansoltani.org/docs/respawn_redux.html" rel="nofollow">http://ashkansoltani.org/docs/respawn_redux.html</a><p>Feel free to send comments/suggestions.<p>Also nikcub - very enlightening about the Last-Modified header! It reinforces my point that the solution to all this might not be technical but require policy guidance as to best practices, etc.

&#62; So if a user came to Hulu.com from an ad on Facebook, and then later, <i></i>using a different browser on the same computer<i></i>, visited Hulu.com from Google, and then at some point signed up for the premium service, KISSmetrics would be able to tell Hulu all about that user’s path to purchase (without knowing who that person was).<p>It seems their method relies on using cached javascript files to identify a user. How then are they able to track the same user using a different browser? Is it by IP address?

Peerblock can be set to block port 80 by all list or leave it open. I want to be able to enable some blocklists for 80 but not others. So I can block ads and stuff like this at the stack instead of the browser, but leave the other lists affecting only other ports, for torrents etc. I don't think it makes peerblock too complex to have some lists that block everything and some everything but 80.

What's the cunning part? I skimmed the article and it seemed to have everything other then the technique.

Ironically, they would never be caught if only they assigned different blobs to the same user on different properties, like KS_cookie XOR hash(property_name).

Whats next.. tracking users using browser exploits ?

Wow, an effing moral panic here. I thought KissMetrics was a darling startup?<p>Anyways, assuming they could offer their service tracking only on a customer's site, they should be serving from a subdomain, no?

Doesn't this achieve the exact same purpose as logging a combination of the user's IP address + user-agent + maybe some other stuff? Don't need no complicated, cunning technology to do this...

"Then, if that user eventually signs up during a later visit, KISSmetrics will associate their previously anonymous profile with their email address or user name. Which means that site admins can look at both how a user is currently using their site, and how they used it months or years before they actually created an account"

Looks like it's using a variant of a technique I demonstrated a while back: <a href="http://joshduck.com/blog/2010/01/29/abusing-the-cache-tracking-users-without-cookies/" rel="nofollow">http://joshduck.com/blog/2010/01/29/abusing-the-cache-tracki...</a>

Sorry but what a bunch of crap... Privacy people are so annoying... If your concerned about this kind of tracking stop using online porn - otherwise As you were