Early on, it's not personally identifiable. No doubt there can be a lot of folks visiting the site only 10 times and never again.
But as someone continues to visit, they begin to narrow down who they are to "You're that guy that comes in here every day with a yellow hat". They may not "know" who you are but, they "know" who you are.
Eventually, there may be that one person that has the highest hit rate, who always stands out.
They could stop incrementing once they get to 10 (or something that's high but common enough to be shared by 1,000s of people).
Yes but you have absolutely nothing at all to associate that back to a person. Where are you going to find the data "personal information of some kind of the people who visit your site a lot?" You're not collecting it.
Using personal data to assign a cohort counts as using personal data. Duh. The approach described in the article doesn't use any personal data, though?
Quoting the European commission:
"Personal data is any information that relates to an identified or identifiable living individual. Different pieces of information, which collected together can lead to the identification of a particular person, also constitute personal data."
I'd hazard a guess that it's the second part under which the EC might find this to be within scope.
That doesn't mean you can't use it at all. It just places strong restrictions on what purpodes you can use it for. The important point is just that those restrictions are the same under GDPR for all of these technologies. It doesn't matter how you uniquely identify users, what matters is what you do with that information.
You may be able to look at the headers and see that a certain user made the most requests that day. That still tells you nothing about their identity.
What the technique may fall foul of, though, are cookie laws.
Edit: Huh, I stand corrected I don't know if this would count as personal data.
The post says that they don't combine datapoints because that would negate privacy.
Using it for user analytics, which is neither required to run the service, nor in the users interest, nor reasonably expected by the user, is almost definitly illegitimate use.
Multiple requests end up with the same time stamp which means individuals are not traceable but as an aggregate countable
Edit: I misread the article here, where it said each visit incremented the counter by one second. So my calculation is not correct!
both you and i visit the same new site today, we both get a file our browser caches with today's date at 00:00:01. Tomorrow when we go to the same site, our browser says we got the file yesterday, so the server sends a new modified date to the browser, set to tomorrow's date at 00:00:02. Both of us have the same "new" file with the new modification date/time.
if i go back the following day, the only thing the server knows for certain, from just this header, is that i've visited twice before. So i'm not counted as a unique visitor.
That this could be used by assigning a unique timestamp to each visitor is where everyone's mind is going, and it feels like half are annoyed there's another way to leak information, and the other half are annoyed they didn't think of it prior to the end-of-year marketing bonus deadline.
However, it sounds like they're using it just for quite minimal tracking. It sounds like the only thing they're tracking is how many people viewed the site how many times. They'll know that on a particular day, 1 person viewed the site 500 times, but won't know anything identifying about that person (e.g. IP, name, gender, any sort of unique ID).
~Every HTTP response has a Date field with a second-resolution timestamp that might be unique. Are you equally concerned about that?
(edit: spelling)
You have somehow perverted GDPR to believe it to mean `no client may ever hold a unique state`. Good luck to anyone making a claim that this is NOT possible in anything but the most rudimentary application.