It's talking about two separate issues which initially confused me, one of which is inappropriate data sharing.
The cunning part technically is their repurposing of "etags". These aren't that widely known about but it's a mechanism by which you can ask a webserver "I've already downloaded this file before, has it changed?". Typically the etag will be a revision number, or a hash of the file. The header to create one looks like this:
ETag: "686897696a7c876b7e"
And then in future requests your browser will include the header:
If-None-Match: "686897696a7c876b7e"
In the request. If the file hasn't changed since you last downloaded it, you get a 304 Not Modified. Given that you can store absolutely arbitrary data in the ETag, it's easy to see how this can be used to track users (and the same applies to the Last-Modified header, which is treated exactly like an ETag by your browser despite containing a date).
The cunning part technically is their repurposing of "etags". These aren't that widely known about but it's a mechanism by which you can ask a webserver "I've already downloaded this file before, has it changed?". Typically the etag will be a revision number, or a hash of the file. The header to create one looks like this:
ETag: "686897696a7c876b7e"
And then in future requests your browser will include the header:
If-None-Match: "686897696a7c876b7e"
In the request. If the file hasn't changed since you last downloaded it, you get a 304 Not Modified. Given that you can store absolutely arbitrary data in the ETag, it's easy to see how this can be used to track users (and the same applies to the Last-Modified header, which is treated exactly like an ETag by your browser despite containing a date).