Hacker News Reader

Comment by DueDilligence | Hacker News Reader

.. and we're fast on-track of a webkit extension to block this BS.

To be clear, they’re not generating unique headers. They’re setting them to the day start, so they can tell if the requester has already been to the site today or not. It actually seems pretty reasonable.

They way they are using it is providing less information than a UID cookie would, but the same amount of information as a boolean "previously visited" cookie. However, now that the technique is known there is nothing stopping people from using the same method to store a UID date, and privacy protecting clients will have difficulty differentiating between the two, so best to eliminate this as a fingerprinting method altogether.

But you can't have as many bits in a UID date as for a generic cookie, and a privacy protecting client could just ignore the ones that don't make sense. Does a 1978 date make sense? Probably not. You could scale this up to the millions, probably, but it won't scale infinitely.

roblox has ~50mm daily users (DAU), and if my math is correct (it probably isn't) you could have hour granularity (only 0-23) timestamps on 6 files, each day, and track 191mm unique users. I used roblox because i knew their DAU off-the-cuff - because roblox requires a login, they know who you are anyhow.

But if you do 1 second granularity a mere 2 cache timestamps are enough to fingerprint everyone on the planet, each day.

is my math wrong, here?

People keep saying in this thread "there is nothing stopping people from using the same method" to do something else! I think that this is an irrelevant criticism. This is a valid attempt to minimize the amount of information collected on visitors and still providing a unique visitors per day count, and the fact that someone could build a similar but different system that looks like a cookie isn't relevant.

They demonstrated a PoC that uses an HTTP feature in a way it wasn't intended to add entropy to fingerprinting techniques. Discussing how this same exploit could be used maliciously by others and how to prevent that isn't criticism of the PoC, it is standard security practice.

There probably is one already: this method is so old that the documentation of privoxy shows[1] how to defeat it. I can confirm it works: their example[2] website says I've visited 61996 times.

[1]: https://www.privoxy.org/user-manual/actions-file.html#OVERWR...

[2]: https://lastmodified.normally.com/

Why block it entirely when you can just feed them garbage data?

Whats the motivation to block/misinform?

This allows site owners get statistics on page views/uniques/bounces without unique identifier cookies or javascript injections.

I’m all for blocking any abusive tracking methods, but this looks to me like creative website statistics that works for single domain. What’s the harm by measuring that?

> Whats the motivation to block/misinform?

What’s the motivation to submit to it?

Allowing websites to get a somewhat accurate count of visitors plus bounce rate helps them to tell how they’re doing. Hopefully, they use that to guide developing a better product/service.

If you can allow them to do that without getting tracked, it’s win-win. You get a better experience when they build a better service.

While this particular implementation doesn't track individuals, couldn't your trivially start tracking individuals by sending them unique random times like last-modified: 12 Mar 1978 12:34:56 GMT thereby giving them a ~30 bit unique identifier for as long as the file is cached?

Only if you disregard the amount of latitude that the semantics of these headers give to UAs that would effectively thwart this method of tracking.

If I fetch your /foo.html today in November 2022, and you send me a last-modified from 1978, that gives me and my UA a huge range from which to select a different datetime (anywhere between the 1978 value and now-ish) on my next request. How are you going to correlate my original and subsequent requests if in the latter I ask if you've got a copy that's been modified since 1999?

Sure, a UA could do a whole lot of things to resist fingerprinting.

But users go to the web with the browser they've been given.

Apple, famously, forbids its users to speak HTTP with anything else on iOS.

Context is important. The replied-to comment starts off, "While this particular implementation doesn't track individuals, couldn't your trivially start tracking individuals by[...]"

An acceptable response, then (to both you and the original commenter), follows: "While some particular browser version doesn't currently protect individuals from that proposed form of tracking, any browser vendor could trivially start thwarting that form of tracking by exploiting the latitude afforded to UAs by the semantics of these headers." And that's the form that the previous comment takes and how it should be understood. The fact that "users go to the web with the browser they've been given [i.e., today, and which isn't providing this sort of tracking protection]" doesn't change anything; we are explicitly talking about steps that each side _can_ take in the arms race related to the subject of this discussion...

Sending a garbage Last-Modified time might confuse the server and cause unpredictable problems for the user. Blocking it is safe because the server will just assume this is the first time the user has visited the website.

Reply on news.ycombinator.com