Zombie Cookies Just Won't Die
GMGruman wrote in to say "Microsoft embarrassed itself last week when it got caught using 'zombie cookies' — a form of tracking cookies that users can't delete, as they come back to life after you've 'killed' them. Microsoft says it'll stop the 'aberrant' practice. But Woody Leonhard says you ain't seen nothing yet. It turns out HTML5 offers a technical mechanism to give zombie cookies a new lease on life — and the Web browsers' private-browsing features can't stop them."
Microsoft says it'll stop the abhorrent practice
Fixed that for them.
Actually, an even more accurate quote might be:
Microsoft "says" it'll stop the abhorrent practice
SJW: Someone who has run out of real oppression, and has to fake it.
which seems to be the most common solution that's offered on fix-your-own-windows-problems forums
This is why it's nice to be able to rm -rf ~/.mozilla and rm -rf ~/.macromedia as a last-ditch effort.
And run your browser in VMWare, and wipe the VM you run your browser in clean when you exit. Or just don't browse the web anymore, since these shady practices are devaluing the platform as a whole. Which actually might be exactly what Microsoft wants...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
And start blaming your browser. If you enable "Private Browsing", and anything lives beyond that session, it can be nothing other than a browser bug.
Is there any good reason why one would want to use HTML5 at all? I mean, as a user? So far it all seems to be negative - a load of giving away user control and sovereignty over your own system, packaged as "Wow, cool new feature".
The "standard" Firefox plugins already take care of it.
No DOM storage without JavaScript, no Flash cookies without Flash -> NoScript
Most tracking cookies come from ad networks -> AdBlock Plus
Most tracking cookies come from third party domains -> RequestPolicy.
And if you get one anyway, you can also get rid of it -> BetterPrivacy.
The Tao of math: The numbers you can count are not the real numbers.
HTML 5 local storage worries the hell out of me. It's nothing new though because Microsoft has had an almost identical "userdata persistence" feature since forever. Try this link in IE browser http://samples.msdn.microsoft.com/workshop/samples/author/persistence/userData_1.htm
"Don't belong. Never join. Think for yourself. Peace." V.Stone, Microsoft Corporation
OK so the article cites localStorage as a problem, but Chrome at least treats it the same as cookies when clearing private data, and in incognito it shouldn't persist localStorage data across sessions (not sure about other browsers).
It also mentions that MS was sticking a JS file in the browser cache to recreate a cookie. This doesn't make sense since any file removed from the cache is just redownloaded, unless a custom version of the JS file is crafted for every client and is set to create a specific cookie value (but this isn't clarified in the article). But it sounds more like ETags are used, having nothing to do with the JS file being cached or not. I'm not sure how ETags work but I can't imagine they would be effective in incognito mode either since cache is never kept (and the article infers this is necessary).
Did I miss anything?
I am sorry, but just talking about cookies doesn't go far enough to describe what is happening here. It is about zombie browsers, that are just building in more and more functionality to turn your computer into a device that is not controlled by you, but is controlled by various special interests.
On the other hand you, as a user, are clearly not the customer of a browser developer company. The customers seem to be the advertisers, CAs, anybody that wants to control what you are doing. You, as a user, are a product. We used to say this about FB and such, but isn't this also true about browsers?
There needs to be a way for the user to control what is happening on his machine, otherwise it's not a general purpose computer, but some proprietary gadget that you have there. If this is not clear to the browser developers then there will be more forks built that will be Freer for the users, but there also maybe something else done, like a VM to control all of this run away software. Start it in a VM and when you are done, kill that VM and there is no cookie.
You can't handle the truth.
Microsoft disgust me. After decades of this sort of deceitful behaviour, it is evidently still too much to expect Microsoft to actually do the 'right thing' in the first place.
Even without any sort of ethics, they're also too stupid to actually learn their lesson that all these scams that Microsoft repeatedly perpetrate on their own customers always eventually get discovered and backfire with far more loss of face and therefore sales than presumably they gain from doing the thing in the first place.
Why is it that the only company mentioned here is Microsoft, when in fact the original research article shows this to be a lot more wide spread by some big names - none of which were mentioned here. From the Stanford article (http://cyberlaw.stanford.edu/node/6695): "We also examined a series of URL lists (spreadsheet) that contain 15,511 entries. The URLs and interest segments range greatly. Some URLs are for a landing page; others are for a specific page. Some interest segments are broad; others are fine-grained. A few example segments:
Segment 758: discount sites including Groupon and eBay Daily Deals Segment 876: sites about coffee, including Dunkin' Donuts, Folgers, and Starbucks Segments 984-989: home improvement sites including Home Depot and Grainger Segment 2701: pages about the Ford Fiesta Several interest segments are highly sensitive:
Segment 760: pages about getting pregnant and fertility, including at the Mayo Clinic Segment 2640: pages about menopause, including at the NIH and the University of Maryland Segment 2014: pages about repairing bad credit, including at the FTC Segment 2265: pages about debt relief, including at the FTC and the IRS"
Please folks - If you're going to bring this to our attention, how about leaving your obvious biases aside and tell the whole story so we can be truly informed? That we we can all be aware of just how widespread an issue this is instead of just another "Microsoft is Evil" piece.
Then it would at least stay dead for three days.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Can't you setup browsers to prompt to create local storage?
A lot of commenters here seem to be taking what I would consider as extreme measures in order to avoid these cookies. Running your browser in a VM which resets each time you close it? Installing numerous addons (I see someone listed 4 you need to install to cover yourself)? Does anyone else not think that perhaps instead of avoiding the issue, it should be tackled head on?
What I mean is - if this is such a serious issue, why are we standing by just letting it happen when we could be petitioning the various standards committees, plugin developers and browser manufacturers to do something about it? The so-called zombie cookie (or Supercookie) exists because we let it exist. It's clearly an exploit in the way various technologies work together and it should be treated as such, i.e. patched until it can't be done any more.
Furthermore, any company that uses this tactic should be taken to court since it's a clear and deliberate violation of privacy. I.e. if I decide to delete a cookie, I'm making it explicitly clear that I want it gone - I'm opting OUT, so keep it that way.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
I'm mostly glad to see the implementation of HTML5 everywhere, but it has some problems.
People thought that you could get rid of a lot of annoyances by increasing HTML5's capabilities to become more on par with Flash. Flash could be ditched. However, all it really means is that all the nuisances that were made in Flash (animated and noisy ads, commercials, persistent cookies, etc.) will now be made in HTML.
Flash wasn't really the problem... it was just one of the vectors FOR the problem. Now, HTML5+Javascript will take Flash's place in the eyes of marketers and spammers everywhere.
No functional difference there.
The article does a major disservice to everyone (and I wish we could mod it down) by making up the term "zombie cookies." This new bullshit term hides what's going on and makes us all a little bit stupider. All I have to do to answer your question, is tell you what the article is really about. Instead of making up a bullshit term to confuse you, I'll use a descriptive term.
Ready?
Flash Cookies. The article is about websites caught using Flash cookies instead of browser cookies.
See, asshole-who-wrote-the-article, that wasn't hard. Flash cookies. Now instead of misleading people into thinking their browsers have a problem with cookies and other local storage, people see that the real problem they have with their browsers is plugins, which allows them to run native code that totally bypasses all the browsers' policies.
Flash cookies. Watch all the questions disappear .. but oops .. all the traffic to the fucking article disappears too, since people don't have to click through, read the first article that makes the weird reference to zombies, then click through to another article that explains WTF "zombie cookies" are about.
Slashdot should not have linked to this piece of shit.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
If they'd just called it a "Jesus Cookie" no one would be complaining.
Then it would at least stay dead for three days.
And bugger off permanently after another 40 days or thereabouts.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
This reminded me of an old Slashdot article about Evercookie http://samy.pl/evercookie/
Please correct me if I am wrong on this; but it would seem that, in principle, it would be quite tractable to generate a 'local persistence profile' tracing the activity generated by loading a URL as a series of addition, deletion, and modification operations to the state that existed before the URL was loaded(in the same way the various browsers' dev tools allow you to trace the network activity and script execution associated with loading a URL). With that, the user would have broad power(limited largely by their desire not to wade through a massively complex interface) to immediately roll back all changes made on exit, on leaving the site, or on some schedule. Wrapping that in an interface simple enough to be used and powerful enough to be useful would be a bit tricky; but you'd have an extremely granular revision-control style record to work with, which would make adding a few basic features comparatively simple(ie. "All changes that occur when running in Porn Mode are reverted on exit" or "all changes that occur when I load evil.com are reverted when I navigate away from evil.com".)
It would even be doable, probably through the use of site-specific addons developed by the knowledgable, to selectively roll back certain changes but not others(ie. if webmailfoo writes a cache of my last 30 days of email to a local store, I don't want to roll that back; but I do want to roll back the changes made by the fooad network...) or even to programmatically modify locally stored data(that aren't cryptographically signed, or otherwise protected from any tampering other than deletion...)
The local threat certainly isn't getting any easier or less complex; but it is, at least, a software problem. It's the remote threat that you really have to worry about. Covering your tracks against a reasonably smart remote agent turns out to be pretty difficult, and you can't(legally) just go and purge their systems.
I remember back when scripts reading local files was regarded as a security hole in the browser, not a "cool new feature."
When the user explicitly consents to use of a specific local file or folder, it's a "cool new feature". When the user does not consent, it's a "security hole". Think of it as like a file upload control in an HTML form, but it works even when a web application is running offline from cache.
I just change the permissions on my cookies file to read only.
"Suppose you were an idiot..... And suppose you were a member of Congress... But I repeate myself."
To manage localStorage in Firefox 6, open the Options and go to Advanced > Network > Offline Storage.
Invisibility is futile. We need fake cookies, or randomly collected cookies, so that the advertising value of a cookie falls, i.e. "information inflation". Sure, Vehix knows now that I was car shopping, but what if EVERYONE had a copy of the Vehix search on their Html? What if in addition to the car I was really searching for, my browser held a record of every other car I wasn't interested in? Why can't we just run a random program, searching for random words, in the background, loading up on Zombie cookies from everywhere? "I'm Spartacus" http://retroworks.blogspot.com/2010/09/simpler-ideas-cookie-camouflage-digital.html
Gently reply
Well, maybe so, but the idiots that clicked his link and got infected by his trojan will keep filling your firewall log.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Greasemonkey is a plug-in for Firefox that allows automatically executing your own scripts whenever you go to URLs that match a given pattern. You could easily write a script that looks at document.cookie and alters whatever cookies it sees. The only hard part would be deciding which cookies to overwrite, and how.
At least for the video and audio, both Flash and HTML5 are functionally inferior to just <a>'s to files.
I see three advantages of Flash or HTML5 to providing links that an end user must play manually. How would you solve these use cases with just <a>'s?
All we have to do is shoot the zombie cookies in the head. If we take out the brain, we take down the ghoul.
I'll put on my user hat for a sec, so it will sound harsh, but Joe User doesn't care:
How would you solve these use cases with just <a>'s?
a) A web site can verify that the user agent has presented the entirety of one video before offering the link to another video.
Joe User: Not our problem. 10 years ago websites gave me all videos at and I could play and replay at my leisure. What's different now? [yeah, I know, bandwidth abuse, but still Joe User sees no benefit from the business implementation side of things and just clicking on the next link 100 times is still easier than paying a single dollar. Isn't that how Joe User leeches specific porn online?]
b) The advantage to the user is that the user can watch a message from a sponsor instead of providing payment details and paying for each view.
Joe User: I heard that the internet is supposed to be a place for sharing. Why do I need to "pay" anyone for goods I can find elsewhere for free? I can do just that to find ALL my music and videos for free, so I don't care about this one greedy "sponsor"
What's different now?
A decade ago, ISP-provided web hosting and banner-supported web hosting came with 0.005 GB of space. A decade ago, we were in the dot-com crash. A decade ago, broadband was an experimental, expensive technology, and there weren't enough viewers of bootleg online videos to have a noticeable effect of the use upon the potential market for or value of the copyrighted work. The entertainment industry was still fighting things like Napster and WinMX, which were used more often for single songs rather than albums or movies.
Joe User sees no benefit from the business implementation side of things
Joe User sees that videos are available on the Internet as opposed to not available on the Internet.
I would use DeepFreeze by Faronics which would ensure that a reboot would clean out any crap that may have been written to the disk. Simple. We use that were I work for student systems, Macs, PCs, and Linux. The downside is any persistent cookies you *do* need will be lost also. But if you're that concerned about being tracked, it's a fair trade off.
HTML5, which by design, gives unfettered access to certain storage areas, etc on your system via your browser.
Unfettered how? I thought access through <input type="file"> was limited to files that the user chose through an "Open" or "Save As" file chooser dialog presented by the system. From the File API spec: "The user is notified by UI anytime interaction with the file system takes place, giving the user full ability to cancel or abort the transaction. The user is notified of any file selections, and can cancel these. No invocations to these APIs occur silently without user intervention."