Sneaky tracking code (finally) purged from Microsoft sites Microsoft has deleted code on its MSN website that secretly logged visitors' browsing histories across multiple web properties, even when the users deleted browser cookies to elude tracking. Microsoft announced the move in a tersely worded blog post published on Thursday. That's the same day that a researcher revealed that MSN …
Do ETag caching and Flash cookies bypass porn-mode protection on chrome/IE/whathaveyou? I wouldn't be surprised if they did, and someone somewhere is sniggering at my giant hat fetish.
Meanwhile, note that ETag caching as tracking is not going to go away any time soon. What these researches do is the following:
Send HTTP Request without ETag. Get HTTP Response with an ETag and some cookies. Delete cookies. Send HTTP Request with ETag. Get HTTP Response with cookies, which are same as before (Coincidentally this is what they are calling "cookie respawn", which somehow suggests that they are brought back to life, while in fact they are just being reset by server to same values). <= Proof of tracking.
Meanwhile, the next-gen ETagger (NGE) could be a little more sneaky. Let's suppose that the cookie contains a unique identifier, which is typically just a large number. By using miracles of mathematics NGE could mangle this identifier each time it's not being verified by a cookie.
Send HTTP Request without anything. Get HTTP Response with ETag, cookies, etc. Delete cookies. Send new HTTP Request with ETag. The server receives a cookieless request which still has an ETag. The server then sends out a new cookie with the uid that can be randomly transformed back into the original uid. The researches now receives a HTTP Response with a new cookie. He or she is now convinced she's not being tracked.
The transformation function need not be very complicated to be sufficiently advanced to bypass visual inspection. Of the top of my head [f(int uid, int seed) -> string] could be [seed + delimeter + md5(uid) xor seed]. At inspection it seems trivial to recover the uid, but you'd have to know the function definition to do so. Oh and of course you can construct much more advanced schemes, that are very hard to break even if you know what you are looking for.
So, welcome to trackable internets!
"Send HTTP Request without ETag. Get HTTP Response with an ETag and some cookies. Delete cookies. Send HTTP Request with ETag. Get HTTP Response with cookies, which are same as before"
<ignorance mode on>
So what's happening on the server that allows them to do that???
Is it that the ETag is being used as a type cookie to track the browser? This is different to what I understand a ETag should be, a mechanism for the caching of webpage elements (pages, images etc,) to reduce bandwidth usage and server load.
So is it not a simple matter of disrupting the ETag to break the tracking, at the cost of increased bandwidth which wouldn’t seem too much of a problem given the broadband speeds most of us have.
Sites that don’t use this form of tracking could still use age response header or cache control directives even though it may not be as effective as using ETags for this purpose
Or am I being naïve (or possibly just old) and missing something
<ignorance mode off>
ETag is just a number in the HTTP Request/Response spiel. Server sets it so that we echo the same number back when we try to download same content, presumably so that if we download a high-resolution picture of a woman with a giant hat, next time we visit the same woman we could ask the server if the content has changed. I say my ETag, server says 304 - Same giant hat. Then I know I can just trust my cache, else I download the new image. Think of this as a receipt for the resource you already downloaded.
But this number may as well be a dud. This dud ETag has nothing to do with the resource in question (typically it's a hash of the resource or a timestamp), and is just a way for the server to ID me. So when I bring this receipt back to the server, it knows that I've visited before. Somewhere this number has been stored, along with whatever cookies they want to give me. The number in the ETag is receipt for the cookies I checked out previously!
Now the server checks my cookies, and finds that I have deleted them. If so, they just reassign the cookies that I have deleted that were associated with this ETag.
We could just ignore/strip Response ETags to get rid of this bug/feature. Since it's part of HTML 1.1 standard, it's unlikely to be removed from compliant browsers, no matter how fast your internets have become.
They can virtually force you to buy their products, so why would they care about a bit of bad PR?
Nothing that a bit of spin doctoring can't fix.
As in "This was old code that we were gonna remove anyway. Now we've done it faster"
Does anybody *really* believe that spin?
It doesn't matter whether they do anyway. We will all still dutifully buy PC's loaded with MSWare without giving it a moments thought and many of us will even willfully pay for a second time simply because the preloaded version isn't the exact one we wanted.
What does the Windows user icon mean?
They got caught with their hands in the cookie jar and that is their reply?
They know they didn't share data with people outside MS which means they know exactly what was being collected and who inside Microsoft they were sharing that data with. So much for respecting people's privacy and giving them "choice" (unless the choice is to use MS services or not use them!)
"intentionally or not"
That's funny. Companies can unintentionally develop complex code to bypass basic functionality?
Really, I wish Americans could call a spade a fucking spade and not couch statements like a legal brief. Code gets written on purpose. And this sort of code was and is evil. MS and others did it, they did it intentionally and they will continue to do it until it is illegal or it becomes unprofitable.
Dweeb
Reading the original article perhaps a wish to [ahem] integrate user's experience across the entire MS estate (e.g. single login to multiple Microsoft sites etc.) led to frustration with conventional browser cookie limitations....
http://cyberlaw.stanford.edu/node/6715
Thinking about the security and privacy implications, telling users about these, opt outs etc. never happened.
No excuse - but an explanation other than white cat stroking.
"a wish to integrate user's experience"
They can already do that with *normal* cookies. People who do not want to have an "integrated user experience" will disable cookies specifically for that reason.
What MS did was "integrate" their users experience despite said users express choice not to be integrated.
When using hotel wifi hotspots, one must often first agree to the hotel's Ts & Cs.
When using my iPhone in such circumstances, I've noticed that the redirected-from URL at the top of the hotel's legal page is sometimes "www.Apple.com", hinting that the iPhone has perhaps been programmed to call home.
The iPhone one is probably just everyone using the same sample code (http://developer.apple.com/library/ios/#samplecode/Reachability/Introduction/Intro.html) for their 'is the internet' reachable tests - the sample uses www.apple.com as the target URL to test for WAN access . I know I've just cut+pasted that into apps where I needed to know network status, and I suspect it would trigger a hotel wifi re-direct page when it runs.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
