Hacker News Reader

Comment by AndrewStephens | Hacker News Reader

Most schemes of this kind are just more complicated cookies that people hope will avoid the GDPR provisions by dint of being obfuscated.

What the article is discussing looks (at first brush) to be a sensible way of aggregating users up-front before it hits the database, rather than later. So no personal data is stored.

Does this meet the requirements for a site to avoid notifying users under the GDPR? I have no idea.

Even with the best of intentions, if you use a service like this then you are relying on them a) doing what they claim, and b) not screwing up (by leaving logs around, etc).

If I use this service and data from my users gets leaked by Fathom, who gets blamed? The users were on my site, so I guess it is I that gets fined. Maybe the risk is worth it, maybe it isn't.

View on HN

In response to your final question, this[1] document from the UK's ICO has some interesting info. Essentially you're either a Data Controller (that would be your site in this example) or a Data Processor (Fathom, in this case -- probably?!).

"64. The ICO cannot even take action directly against a processor who is entirely responsible for a data breach, for example by failing to deliver the security standards the controller has required it to put into place. However, in these cases the ICO may decide not to take any enforcement action against the controller if it believes it has done all it can to protect the personal data it is responsible for and to ensure the reliability of its processor, for example through a written contract. However, whilst the ICO cannot take action against the processor, the data controller could take its own civil action against its data processor, for example for breach of contract."

Though it goes on to say that in some circumstances, the processor can _become_ a controller, in which case the ICO can go after it.

[1]: https://ico.org.uk/media/for-organisations/documents/1546/da...

And even if there was a data breach where myself & Paul were held at gunpoint and told export the database, there's no personal data to do anything with. Not even in our Redis queue! Our database is very boring, anonymous and simple, and we like it that way.

The GDPR (and other data privacy legislation) uses the concept of a "data controller" and a "data processor". Data controllers use a variety of data processors to deliver a service to their users.

If you ran a SAAS and used Fathom analytics, a SMTP email provider (to send password resets), a newsletter provider (for your monthly newsletter), a blog host etc. each of those would be data processors as you (the SAAS) are making the determination of where user data is going on the backend.

As a data controller, it's your responsibility to make sure that each of those services you are using is handling the data in an appropriate and safe way.

As to who gets fined if there is a data breach: the answer is likely nobody. I say this because it's not like you have a credit card on file and breach automatically means a fine. What really matters is what actions you're taking before and after a breach.

- As a data controller did you notify your users with no undue delay?

- As a data processor did you notify the SAAS with no undue delay?

- Did you identify the source of the breach? Did you take steps to remedy it?

For almost all these privacy regulations if you:

1. Take steps to protect user data/privacy like https, encryption etc.

2. Provide a mechanism to allow users to make data requests for their own identifying data

3. Notify users if there's a data breach

You would be in compliance.

> Does this meet the requirements for a site to avoid notifying users under the GDPR? I have no idea.

Not necessarily. It's a bit complex, but the fact that Fathom ingests personal data at all likely means that they must still be disclosed by whoever is using Fathom's code.

On the other hand, if Fathom were able to push data ingestion into the first party's infrastructure so that only aggregated data hits Fathom's own infrastructure, I'm pretty sure that would put Fathom in the clear due to the fact that they are no longer processing or storing personal data.

To Fathom's credit, I am a big fan regardless of the steps they seem to be taking with anonymization, and I will consider using them instead of GA for future projects.

What do you think about Recital 26? For GDPR, our stance can be found here: https://usefathom.com/data/

I am neither a lawyer nor a DPO, I just worked on GDPR compliance in the past, so take what I say with a grain of salt.

I went and reread parts of GDPR, and I think you are right, though not because of Article 26. I think it's pretty clear that after your ingestion the data has been in good faith anonymized to the degree that it is no longer personal, and therefore your analytics code should be exempt from consent rules.

The interesting question to me is whether a controller deciding to put your pixel on a page for analytics purposes counts as you processing on the controller's behalf to an extent requiring consent. I don't see any clause specifically regarding third party access to personal data (as opposed to third parties processing personal data), so I agree with your stance that it's most likely fine.

(obligatory IANAL) Recitals aren't legally binding in and of themselves, so I'd be wary of _relying_ on them _completely_.

That said, the articles of a regulation should be read in light of the recitals (as the latter are the rationale behind the actual binding legislation).

Trust me, we're not relying on Recital 26, that is just my thought experiment :) See here for our GDPR compliance: https://usefathom.com/data/

Reply on news.ycombinator.com