[remon]

Sure but any probabilistic approach is either relatively inaccurate reduces it's usefulness for this use case, or accurate which raises the same identifiability concerns cookies would introduce. I guess my point was; this has been thought about already. (Pseudo) anonymized attribution is a bit of a solved problem and you can do it with or without cookies. That's mostly a implementation detail rather than a distinguishing feature.

[alkonaut]

> (Pseudo) anonymized attribution is a bit of a solved problem and you can do it with or without cookies.

How is it typically done without cookies then?

> any probabilistic approach is either relatively inaccurate reduces it's usefulness for this use case, or accurate which raises the same identifiability concerns cookies would introduce

How so? Even if it's accurate you wouldn't be storing anything the information (random id or fingerprint) for the individual user, so you would only be able to answer with reasonable certainty whether you saw the user before or not. You can't identify anyone from that (other than identify them as a new vs returning user) so there is no identifiability concern, unless of course one thinks that constitutes a concern in itself which I don't think the GDPR does.

[remon]

Maybe we're disconnecting. Cookies are just a standardised way to communicate a small key/value set between client/browser and server through HTTP headers. It's not inherently (in)secure, sensitive, etc. There are zero things you can do with cookies that you cannot do without and there are no inherent differences in security, they're just very convenient if you're in HTTP world.

And yes what you said is exactly right; you're allowed to fingerprint a unique user and track data with that fingerprint as the sole unique identifier without any PII legislation (GDPR, CCPA, etc.) compliance issues. You just cannot store any information that allows linking PII data to that fingerprint in either direction. In other words, attribution to a random UUID that just happens to represent an anonymous user is not an issue.

Circling back to the original comment; there is no (good) argument against cookies if you're basically doing exactly what cookies are doing. Umami using it as a USP is, at best, a little odd.

[pbowyer]

> you're allowed to fingerprint a unique user and track data with that fingerprint as the sole unique identifier without any PII legislation (GDPR, CCPA, etc.) compliance issues.

That is not true. E.g.

1. https://ico.org.uk/about-the-ico/media-centre/news-and-blogs...

2. https://ico.org.uk/for-organisations/direct-marketing-and-pr... specifically https://ico.org.uk/for-organisations/direct-marketing-and-pr...

This is for the UK, I am not up to date with other European regulators.

[tremon]

fingerprint a unique user

I don't think this is correct, or at the least it's unfortunately phrased. If your fingerprint is so specific that it can distinguish unique users, it is covered under GDPR compliance. I don't know too much about the CCPA so not sure if it's the same there.

Yes, you are allowed to collect device statistics such as form factor, viewport size etc. But if you can distinguish between two different users with identical devices accessing your site at the same time, under GDPR you have an obligation to inform [14]. And if you can recognize a returning user across sessions, you also need consent.

[14] https://gdpr-info.eu/art-14-gdpr/

[remon]

If the random user ID is truly anonymous (so, cannot be linked back to an identifiable person even with other data you have), it is not personal data under GDPR and no obligation to inform or consent is needed. If the data processor stores any information that makes PII attribution possible then, and only then, does it fall under GDPR, CCPA, etc. That random ID being persisted on the device allowing for subsequent attribution is still not PII sensitive unless/until the aforementioned identifiability barrier is breached. This is exactly why prominent analytics platforms (Plausible, Matoma, Mixpanel if configured correctly, etc) all offer data hygiene barriers.

I suspect what's happening here is that the word "user" is making things ambiguous here. It was meant in the context of attributable session, not as the data subject as per GDPR language for example.

[alkonaut]

As far as I'm aware, any online identifier, even a random number created by me, falls under the GDPR. This answer lays it out pretty well

https://law.stackexchange.com/questions/82133/are-auto-gener...