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.
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.
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.
