Undeletable Cookies(schneier.com)
schneier.com
Undeletable Cookies
http://www.schneier.com/blog/archives/2011/08/new_undeletable.html
16 comments
> Even if Hulu turned off cookie respawning via etags, you can still track users this way, on the server side. I guess the tricky thing is to correlate the etag of the tracker resource with the rest of the requests that a user makes on a site.
The important distinction is that the ETag is literally no different than a cookie, when used this way. Turning off caching is the new turning off cookies.
The important distinction is that the ETag is literally no different than a cookie, when used this way. Turning off caching is the new turning off cookies.
There is a difference: cookies get sent on requests to any resource in a domain, whereas etags get sent only to specific resources.
> ...the tricky thing is to correlate the etag of the tracker resource with the rest of the requests that a user makes...
Not tricky though. Just put 1-pixel Etagged gif on every page. It gets requested on each page. Or just associate (server-side or client-side) the user's session cookie with the Etag.
Not tricky though. Just put 1-pixel Etagged gif on every page. It gets requested on each page. Or just associate (server-side or client-side) the user's session cookie with the Etag.
From wikipedia:
ETags may be flushable by clearing the browser cache (but browser implementations may vary).
In 2007, two Mozilla Firefox add-ons were made to prevent the usage of ETags for tracking.[5][6]
[5]https://addons.mozilla.org/en-US/firefox/addon/safecache/ [6]https://addons.mozilla.org/en-US/firefox/addon/safehistory/
ETags may be flushable by clearing the browser cache (but browser implementations may vary).
In 2007, two Mozilla Firefox add-ons were made to prevent the usage of ETags for tracking.[5][6]
[5]https://addons.mozilla.org/en-US/firefox/addon/safecache/ [6]https://addons.mozilla.org/en-US/firefox/addon/safehistory/
The safehistory plugin doesn't seem to work for the newer versions based on the comments on their page.
Schneier does not tell so much here, instead he links to this article giving more details:
http://ashkansoltani.org/docs/respawn_redux.html
http://ashkansoltani.org/docs/respawn_redux.html
ETag and cache based cookies are old news. I assume that Schneier didn't notice these components last time he reported on evercookie.
[ http://google.com/search?q=evercookie ]
[ http://google.com/search?q=evercookie ]
It is a lot older than evercookie. I remember porn affiliate scripts that were using ETag back in 01-02. It is a well known method, as is using Last-Modified.
I wonder how this will be treated under the EU's Directive on cookies...
Edit: sorry, not found an answer yet, but the top Google result for 'EU cookies' is rather fun: http://www.davidnaylor.co.uk/eu-cookies-directive-interactiv...
Edit: sorry, not found an answer yet, but the top Google result for 'EU cookies' is rather fun: http://www.davidnaylor.co.uk/eu-cookies-directive-interactiv...
Reminds me to write a firefox plugin to strip etags and "if-none-match" - pretty sure most pages can function just fine without them and use last-modified, etc instead. Kind of surprised to not find anything yet on addons.mozilla.org
Last-modified is just as vulnerable as ETag are since you can set any string as the modified date (it doesn't have to parse as a date) and the browser will replay it
See my comment on the previous thread:
http://news.ycombinator.com/item?id=2825564
I am currently in the midst of writing a browser plugin to block all this bullshit:
http://github.com/nikcub/parley
considering just doing a browser fork since the browsers are so uncooperative.
See my comment on the previous thread:
http://news.ycombinator.com/item?id=2825564
I am currently in the midst of writing a browser plugin to block all this bullshit:
http://github.com/nikcub/parley
considering just doing a browser fork since the browsers are so uncooperative.
You do that, and I'll just assign a unique UNIX timestamp to each visitor.
That's a good point and this would not be practical in a regular browser session but if someone chooses private browsing, an extension could be sure to strip "last-modified" as well as "if-none-match".
Would hurt the server a little and reduce speed because there would not be any caching but still helps guarantee no tracking.
Would hurt the server a little and reduce speed because there would not be any caching but still helps guarantee no tracking.
On a properly written server you could "fuzz" the date of "if-none-match". Then it would still work for caching, but would not uniquely identify you.
The trouble is that most servers are not written properly, the date is not parsed, rather it's string compared with the file date.
For example if the server sends the timezone as EST vs +0400 the browser will send it back exactly as it gets it, when normally you would think that should not matter.
The trouble is that most servers are not written properly, the date is not parsed, rather it's string compared with the file date.
For example if the server sends the timezone as EST vs +0400 the browser will send it back exactly as it gets it, when normally you would think that should not matter.
Interesting. Wikipedia references two add-ons written back in 2007 for this purpose. No idea if they still work on more recent versions of FF.
http://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags
http://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags
The writeup about the two extensions for firefox is wrong, those two were meant to block the trick where you can determine if a user has visited a specific site/page by looking at the link color/state.
This is not news. Evercookie has been doing this for years, and it's just as easy to defeat as it was years ago.
http://samy.pl/evercookie/
http://samy.pl/evercookie/
We created a PoC a while ago showing ETag + browser fingerprinting to replace cookies/client-side storage: http://www.adperium.com/tracking
It works in all major (desktop) browsers, but not in some mobile browsers.
I think the cookie debate (in the EU) is not in the best interest of users: with cookies, the user has full control of the data stored, can easily purge cookies, etc. With user-tagging technology moving server-side, this gets a lot more complicated.
It works in all major (desktop) browsers, but not in some mobile browsers.
I think the cookie debate (in the EU) is not in the best interest of users: with cookies, the user has full control of the data stored, can easily purge cookies, etc. With user-tagging technology moving server-side, this gets a lot more complicated.
What it really boils down to is this: you cannot have both caching and privacy.
For the cache to work your browser must reveal to the server what it has already downloaded, this way or another. And the browser cannot really tell which of the downloaded pieces of data were specially generated to track this particular user.
A possible workaround is to create an intermediate cache to share it with multiple other people, but this creates other privacy concerns.
For the cache to work your browser must reveal to the server what it has already downloaded, this way or another. And the browser cannot really tell which of the downloaded pieces of data were specially generated to track this particular user.
A possible workaround is to create an intermediate cache to share it with multiple other people, but this creates other privacy concerns.
Even better is the paper (written 2003) linked in the comments of the article:
http://www.arctic.org/~dean/tracking-without-cookies.html
http://www.arctic.org/~dean/tracking-without-cookies.html
Obligatory link to Panopticlick:
http://panopticlick.eff.org/
I believe Google is doing this with its google voice product. We're unable to access our google voice accounts outside the USA, despite disabling flash, deleting all cookies, etc. The ironic thing is, of course, that this is when we need it the most, as we miss more calls being in a radically different time zone.
I'd say they disable access by IP, but I can access my account from two countries that are far outside the US.
Well, I'm using different IPs than the "home" IP we used when we signed up. Any attempts to get into google voice for me, though, say that it is not allowed outside the USA.
Yep, so they just filter by whatever IP you are connecting from from outside the US and that's it. Countless websites and services have been doing that for a looong time - just as evil but should not have anything to do with cookies because then you should be able to sign in just fine on a different machine and use voice.
What do you mean by this? I've always been able to send and receive texts through Google Voice in Canada, I can also call (only have it set up to call my gmail) using the web interface. What I've never managed to do is activate the app on my android phone to allow my send/receive texts there even if I couldn't do calls without a US phone number.
I sometimes run into a problem with Google that when I try to log out, I remain logged in. Even after deleting my cookies, I find myself logged in still. This may explain why.
That should never happen. You should email [email protected].
Why wouldn't google want people to access their voicemail,texts,etc and make web calls with their GV number all on the computer when they are outside of the country??
Because Google Voice is USA Only right now. I don't know why but that's the policy... and they've gone to surprising lengths to enforce it
Shouldn't you be able to "delete" them by clearing your browser cache?
They're using GeoIP. Use a US proxy. (Source: me trying to open a Google Account and use Voice via Tor)
Tried that, no dice. Hulu and the rest of the world thinks I'm in silicon valley, but google voice is more clever... somehow.
Hm, not sure what to tell you. Check the country you have specified in your account settings too, it has to match. All I can say is that I was able to create a "US Google Account" where my country said "United States of America", but was denied when I tried to access Google Voice. My Tor endpoint was in Russia. When I directed Firefox to use an HTTP proxy with a US endpoint, Google Voice fired right up and let me choose a phone number. Hope that info helps somehow.
The potential of etags as a way of tracking has been known about for a while...
To put the other side of this argument Kiss Metrics put up a pretty strong denial that they were using etags for tracking http://bit.ly/r5lPbx
Guess it might need a bit more research
To put the other side of this argument Kiss Metrics put up a pretty strong denial that they were using etags for tracking http://bit.ly/r5lPbx
Guess it might need a bit more research
Just don't post shortened links on HN. It's nice that you want click analytics for your post, but nobody wants that but you.
Here's where that bit.ly link heads to: http://blog.kissmetrics.com/official-kissmetrics-response-to...
Here's where that bit.ly link heads to: http://blog.kissmetrics.com/official-kissmetrics-response-to...
Well, they said that they "made the following changes" -- one of which is not using eTags. So I guess they stopped that.
(That said, they never aggregated this data across multiple websites, so I really don't get what the whole fuss was about.)
(That said, they never aggregated this data across multiple websites, so I really don't get what the whole fuss was about.)
They tried to make their cookies undeletable. Why would they do something like that? The fuss is that it's a bad, dishonest, skeezy thing to do. Kissmetrics has shown that they are not an honest company, they're a dishonest one that will disregard the privacy concerns of their user's visitors.
RyanGWU82 makes a good point though. People only whined about the "evercookie" method of tracking because of the potential for abuse (across multiple Web properties). Why on Earth would you care if someblog.com knows for sure that you've been to their site five times? I don't think the problem here is that you can be tracked using multiple methods that were not originally intended for use in tracking. I think the problem is that people always had a false sense of privacy (i.e., there was ignorance about what can and cannot be used to track your client).
You're accessing a remote server. There will always be a way for sites to track your visits. There is a necessity for those sites to track your visits. Don't care about their necessity to track you? Stop going to those sites.
You're accessing a remote server. There will always be a way for sites to track your visits. There is a necessity for those sites to track your visits. Don't care about their necessity to track you? Stop going to those sites.
See, I still don't understand how this is dishonest. They didn't try to make "undeletable cookies," they're not using cookies! I understand that to a layperson "cookie" means "anything that identifies me to a web site," but they're wrong, and what's dishonest about using an analytics mechanism that's not a cookie?
Even if -they- never aggregated the data, does that really mean that nobody aggregated the data? If the clients get raw data, couldn't they (privately) swap data with another client? I assume that if it can be done, it will be done.
Even if Hulu turned off cookie respawning via etags, you can still track users this way, on the server side. I guess the tricky thing is to correlate the etag of the tracker resource with the rest of the requests that a user makes on a site.