
Cookieless cookies (2013) - dedalus
http://lucb1e.com/rp/cookielesscookies/
======
lucb1e
That's a surprise to see pop up again! Author here. Now I wish I had improved
the demo in the past years... It still generates the etag from a few static
parameters to make it work without JavaScript (as the page notes near the
bottom), a real implementation doesn't have that limitation because they don't
care to echo data (such as your note and visit count) back to you before the
image with etag even loaded. I should have switched it to display the data in
the image, so it works more accurately.

~~~
dedalus
The reason I submitted this now albeit dated is due to the fact that now GDPR
is alive, CCPA is in the works and overall privacy environment has changed to
kill the cookie in advertising as we know it. So there will be a need to
explore alternatives to do the same stuff without using cookies (e.g analytics
systems such as GA)

~~~
pierrefar
No that's not a solution. It's the tracking that counts, not the cookies. I
commented elsewhere on this thread more details:

[https://news.ycombinator.com/item?id=20394661](https://news.ycombinator.com/item?id=20394661)

~~~
lucb1e
And as I said six years ago
[https://news.ycombinator.com/item?id=6233362](https://news.ycombinator.com/item?id=6233362)
:p (not to diminish your comment!)

------
i_v
I was surprised to see that this tracking works across both regular and
private browsing in Firefox (67.0.4 on macOS). I can see the number of visits
increment and whatever message I've saved on either side is displayed to both.

~~~
Santosh83
Why is private browsing mode not emptying the cache then? Seems to be contrary
to the very purpose of the mode...

~~~
pdkl95
Private browsing mode wasn't (originally) intended to to prevent tracking by
websites. It's goal was to keep your browsing history _locally_ private. (i.e.
keep your pr0n viewing out of the local browsing history so your friends
wouldn't see what kind of porn you like when they borrow your laptop to check
their email.

That definition has expanded a bit (very) recently, but preventing website
tracking is usually a separate feature (adblockers, noscript, automatic cookie
deletion tools, firefox's recent "tracking blocker").

------
dalore
Wikipedia has a list of websites known to use this technique already:
[https://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags](https://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags)

Looks like KISSmetrics are getting sued with a class action lawsuit over using
this technique.

~~~
hinkley
There are a lot of very cool things that have been in or allowed by the HTTP
and HTML specs that have had to go because people can't be trusted to play
nice.

ETags are one of the biggest disappointments that way.

I wonder if there's a potential to fix this by suggesting a deterministic
version of ETags, that's based off of information the User Agent can see. Like
the Vary information, response headers and payload.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=6231039](https://news.ycombinator.com/item?id=6231039)

------
shock
In Firefox, setting

    
    
        browser.cache.disk.enable
        browser.cache.memory.enable
    

to false, seems to stop some of this from working. The last visit date still
works, but the text storage and number of visits does not.

~~~
gruez
It's not a perfect solution, though. You're going to stick out as one of
_those_ people who disabled their cache entirely. You mitigated this exploit,
at the cost of increasing your browser fingerprint entropy. Ideally you want
to clear your cache when you clear your cookies.

~~~
shock
How can a website detect a disabled cache vs. the cache being full, for
example?

------
singularity2001
I am shocked firefox still has such gaping privacy holes:

It's just one of many:
[https://samy.pl/evercookie/](https://samy.pl/evercookie/)

In the old discussion
([https://news.ycombinator.com/item?id=6231039](https://news.ycombinator.com/item?id=6231039))
it was revealed that some parties were sued and settled for $500,000.
Relatedly British Airways was just fined £183m. That's a beginning.

------
pmoriarty
_" Even when you disabled cookies entirely, have Javascript turned off and use
a VPN service, this technique will still be able to track you."_

It doesn't work if you disable image loading.

For 90%+ of the web browsing I do, I don't need to see images at all, and
browsing using emacs-w3m which I have set up to show only text and not load
any images suffices. Occasionally there might be some image I want to see on a
website and then I'll usually load it and view that one (or handful of images)
manually. Very very rarely, I'll visit a site with an image gallery, where
loading and viewing images one at a time is too painful, and then I'll just
open it in Firefox, which I have set up to load images.

I know not loading images by default is not a solution for most people, but
it's worked great for me for many years.

Update: A lot of replies are mentioning CSS. Just for the record: emacs-w3m
does not process CSS

~~~
danShumway
I'm not going to have time to experiment for the next few weeks, but I _bet_ I
could set up a version of this that worked via CSS as well.

Wouldn't affect you with since I believe w3m also doesn't ship with CSS. But
if anyone is reading this and thinking, "ah, disabling images in UMatrix will
do the trick" \-- _probably_ not?

~~~
pmoriarty
emacs-w3m does not process CSS

~~~
danShumway
More to the point, emacs-w3m does not have a cache at all.

That's the real thing to take away -- that images are not the issue, the cache
is the issue, and there are lots of things that can go into a cache beyond
just images. If you're not caching anything, you could probably load images by
default and you'd still be fine.

------
nine_k
This is a fundamental property of caching.

To avoid an extra fetch, _you have to explicitly tell the data source_ that
you already have this piece of data, and sending it is not required.

~~~
nfoz
Is there a way to design the http cache so that this is not true?

One way is for clients to first ask for the latest checksum/Etag from the
server, and compare it to what they have locally before requesting the
resource.

But maybe that's an extra round-trip. I wonder if a different design of HTTP
could have avoided all this.

~~~
nine_k
No, there us no way around it.

Either a page requests a linked resource, or not. If it does not, we can
assume that it has it cached. We can tell these two outcomes apart.

But we can make tracking much harder by not having the client send an ETag.
E.g. the server could send ETags of all page's resources in the initial
response, and let the client decide. This assumes that the server knows about
all the related resources, about the page structure, etc. This is not
unreasonable, but this does special-case HTML, and does complicate the server
quite significantly.

~~~
orf
Subresource integrity solves this issue.

------
poorman
I tried this on the 0.66.99 version of Brave and it works.

------
lunchables
I wasn't familiar with etags, so for anyone else curious I'll save you the
google search:

[https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/ET...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/ETag)

>If the resource at a given URL changes, a new Etag value must be generated.
Etags are therefore similar to fingerprints and might also be used for
tracking purposes by some servers. A comparison of them allows the
determination of whether two representations of a resource are the same. They
might also be set to persist indefinitely by a tracking server.

------
nfoz
[https://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags](https://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags)

------
kazinator
Interesting. You can store the data in a regular browser window, and it's
still there if you open the URL in a private window.

The private mode should have its own cache that is initially empty.

Idea: since private sessions are typically short-lived, they never have to
validate ETags. Basically just cache resources indefinitely and never ask "is
this item still valid". the cache is thrown away when the private session is
closed; that's what invalidates it.

------
megatoaster
Also read: clear gifs / web beacons

You may see this in your email to track how many times you open newsletters
and other items.

------
theon144
Firefox 69.0b3 here, works across refreshes but not when restarting the
browser or opening a private window.

------
arayh
Of course this can also be applied to all other forms of tracking for extra
persistence:
[https://news.ycombinator.com/item?id=1714446](https://news.ycombinator.com/item?id=1714446)

------
herpderperator
It's worth noting that when you do a hard refresh, obviously you won't get a
304 Not Modified, which is what this tracking relies on. So, if you wanted to
clear the state, that would be one way.

------
mstade
Interesting technique, I learned something new about ETags.

Probably a dumb question but: any reason this couldn't be reliably used
instead of cookies to track sessions, e.g. login status etc.?

~~~
recursive
The developer ergonomics are certainly less convenient. The ETag is tied to a
particular resource, not an origin.

------
pierrefar
Before anyone thinks this (and similar) approaches are a way around the GDPR's
cookie consent tracking crackdown: It's not.

The GDPR talks about online identifiers, of which cookies, IP address and
fingerprints are examples. If you read any regulator's guidance carefully,
you'll see they talk about "cookies and similar technologies", with just
"cookies" being used alone for brevity.

To rephrase tracking of any kind is the issue, not cookies. Don't mistake the
implementation for the activity.

Disclosure: Founder of a non-tracking web analytics service because of this
exact issue.

~~~
lucb1e
All true. Small note: whereas cookies are easy to identify as tracking, etags
have a legitimate purpose and you might not know that you're being tracked by
this method. It would be illegal not to disclose it, so I doubt any self
respecting company would do it, but also hard to detect.

------
tinus_hn
Clever but as you can’t analyze cross domain images I don’t think you can use
this to track people across the web.

~~~
pornel
You can analyze cross-domain images (and other resources) thanks to CORS.
There are many other variants of persisting data in cache via JS and CSS, so
only cache partitioning by top-level domain can stop it.

------
saltminer
On Chrome for Android it does not work with data saver enabled. Disabling it
causes it to work for me.

~~~
icebraining
Data Saver makes the images go through Google's servers, so the browser
doesn't get the ETag. On the other hand, it's much easier for Google itself to
track you.

------
joewee
Doesn’t appear to work with DuckDuckGo browser on iOS.

