Hacker News Reader

Comment by krsdcbl | Hacker News Reader

Not a lawyer myself, but as far as my understanding goes you are identifying your user already by determining his ip, and all the transformations you do to create an id is still reversible with the fixed seeds in your script - so you'll end up sending data to google that makes the user idenfiable nonetheless, so i HIGHLY doubt this is a legitimate way around gpdr.

correct me if I'm making wrong assumptions here, as staid - not a lawyer either, just having lots to do with the topic as a EU based webdeveloper.

View on HN

This is my understanding as well - no matter how obfuscated the final identifier is, if you derived it from PII then it’s considered PII as well.

However, IANAL.

If the final identifier can't be reverse engineered to identify the specific individual is it PII?

So A user visited me on the 12th. That user visited me again on the 15th. Is that PII?

This is how I understand GDPR as well. Just hashing the IP address along with other static values is too easy to reverse and not considered anonymization under GDPR.

For https://plausible.io we added a daily salt to the hash for this exact reason. By deleting the salt at the end of each day, the hash becomes impossible to reverse and visitor data can be considered anonymous.

We lose unique visitor tracking beyond one day, but for most sites this is a small price to pay to remove annoying consent banners.

That's only from your perspective.

Website owners are still sending visitors IP-addresses your way. They have to trust you to do the hashing and deleting the salt (and pepper?) and not delivering data to others (4th party).

Another problem you - and others like goatcounter have - is described here https://blog.paranoidpenguin.net/2020/07/plausible-analytics....

I thought that "CNAME cloacking" was already addressed by uBlock and most similar tools last year already? I don't think it's a very effective method to bypass them.

At least, that's what I can gather from the linked issue and https://github.com/gorhill/uBlock/releases/tag/1.25.0 – so I'm not sure if I understand that article.

In goatcounter the whole CNAME thing was just intended as a cute "shortcut" so you can have "stats.example.com"; I assumed that all adblockers would deal with that correctly, and it was never intended as a way to bypass them (and certainly never advertised as such).

As for "selling IP address", how do you know "blog.example.com" isn't just collecting and selling that? Or HN for that matter?

Then use a shortcut :)

What about the (naive) users that d'ont use uBlock and similar tools and d'ont even know they exist?

BTW Goatcounter collects potential personal data. The querystring is not removed, is stored and presented to the website owner.

Googles system of removing the last part of the IP address exists specifically so you can be compliant. If you use tricks to store the data anyway, obviously you’re non compliant once more.

Additionally you are now doing an additional request to Cloudflare, which probably requires you to link to their privacy policy for that service?

This is probably little of a grey area. I don't think that the IP-address by itself is considered personal data since it usually doesn't single out a specific living person. Unless you pair it with other information, like date and time.

But if IP was considered personal data you would need an active consent from the user where you also inform them why you are doing this, which paragraph in GDPR gives you legal right to do this, how long the data is stored and you will need a data processing agreement with Cloudflare. You will also need to be able to prove that you made sufficient effort to make sure you are not handling data of someone under 16 years of age.

People often think that GDPR is made to forbid processing of personal data. Actually you can pretty much do anything with peoples information and still be GDPR compliant. It's more that it becomes such a hassle to do it and still be compliant that it's just not worth it to collect personal data "just because you can".

IP-addresses (with date/time of access) are considered personal data as stated by the ECJ in the case C‑582/14 from 2016 http://curia.europa.eu/juris/document/document.jsf?docid=184...

My IP address hasn't changed in over a year. I am the only one using that IP address. So no, it is not a grey area and yes, it is personal data.

Seems like you could fix this issue by generating a random salt for the unique ID and placing it in local storage. Never send the salt value to the server, but incorporate it in the unique ID. This would keep the uniqueness property, but eliminate your ability to reverse the computation to retrieve PII.

Wouldn't that just be a contrived session ID?

I'm not sure exactly the definition of a session ID, but maybe? It would be what I described, and if I described a session ID, then yes.

Yes since GDPR states that personal data is any piece of information that uniquely identifies a living person, creating a unique identifier for each visitor by definition will make you a data processor.

But a unique identifier doesn't necessarily identify a living person, particularly in isolation. It's just that it's frequently associated with a load of additional information that could eventually be used to identify someone (think advertising cookies when associated with a load of browsing data). So you can't escape from scope by saying you're using a unique ID rather than a name.

IP addresses are slightly different because that address can be used to identify the subscriber in certain cases (who in turn may or may not be an individual).

Suppose the government wants to know what a particular user was reading on your site. They can calculate the hashed ID for that user and then serve a warrant requesting the data for that ID.

Obfuscation of the ID doesn't help.

So under GDRP are you not allowed to log who visits your site? For say... abuse protection? Assuming you do not share this data with any 3rd party.

No, GDPR explicitly carve out exception if for reasonable purposes. DDOS and abuse protection would fall under that. Marketing however won't.

You can, but you need to explicitly state in your data policy that this is what the data is used for and you can never use this data for any other purpose.

IANAL: If you were allowed to use GDPR under an exemption, perhaps abuse protection, is that the only purpose the data will be used for by yourself and GA?

If you or a data processor you use, uses the data for secondary purposes not covered by any exemption to opt-in consent, I believe you would have to get opt-in consent for those secondary purposes beforehand.

Note: the cookie law is the ePrivacy directive (and national interpretations like PECR) and it goes beyond GDPR in some ways, as the ICO states "Although cookies that process personal data give rise to greater privacy and security risks than those that process anonymous data, PECR apply to all cookies." ( https://ico.org.uk/for-organisations/guide-to-pecr/cookies-a... )

Reply on news.ycombinator.com