Live data from Hacker News

How we built a GDPR-compliant website analytics platform without using cookies

usefathom.com

41–50 of 129 posts

Re: How we built a GDPR-compliant website analytics platform without using cookies

#41

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

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

Re: How we built a GDPR-compliant website analytics platform without using cookies

#42

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

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 cont…

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.

Re: How we built a GDPR-compliant website analytics platform without using cookies

#43

Earlier quoted context omitted.

Whole new language & codebase. Old developer left, we don't write Go.

So it's not as easy as just pushing the update to the repo. We are still committed to open-source, but we also have a business to run and need to make a living here (we're two dudes who care about privacy, not a huge company with deep pockets) :) The community version is getting a full update soon. We just have to focus on profit a bit (this keeps us in business and able to update the repo).

Speaking as someone who built an analytics business while still maintaining an open source version of the code, I can confirm that it's hard. Sometimes it starts off as one small patch that only makes sense for the hosted service, but you can't push to the OS branch until the code is refactored to protect secrets.

I cannot give you any tips on managing your time between the two, but you may want to consider raising your prices. Back in 2011, we ran our basic account at $50/mo, Business at $150/mo and Enterprise at $CallMe/mo. We could probably have upped that after a year with all the new features we'd put in, but we were acquired before the 2y mark and dropped the first 2 plans.

We still maintain the open source version of the code, but neither of the original founders work on it (for me it's gone back to being a hobby because there are now people paid full time to work on it). We still get questions about the lag in updates. We typically do quarterly bulk pushes to the open source version now.

Re: How we built a GDPR-compliant website analytics platform without using cookies

#44

Earlier quoted context omitted.

Whole new language & codebase. Old developer left, we don't write Go.

Out of curiosity, which language did you choose to write the new code base?

We are writing Version 2 in PHP 7.3 with Laravel. We're pleased with it's performance (our hosted solution operates at large scale using Laravel) and it's our favourite language to work with. We'll be building the frontend in EmberJS and it will be incredibly fast.

Re: How we built a GDPR-compliant website analytics platform without using cookies

#45
I am not sure what exactly they did here. How do they persist the hash between requests?

My guess is they use localStorage and sending the hash to their servers with each request.

So we are talking about a mechanism that’s just like a cookie.

As long as they don’t have any PII and can’t figure out who the user was, then I think the GDPR gives them an exception.

But “without cookies” claim is dubious!

Re: How we built a GDPR-compliant website analytics platform without using cookies

#46

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

> 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 ow…

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

Re: How we built a GDPR-compliant website analytics platform without using cookies

#47
post #45

I am not sure what exactly they did here. How do they persist the hash between requests? My guess is they use localStorage and sending the hash to their servers with each request. So we are talking about a mechanism that’s just like a cookie. As long as they don’t have any PII and can’t figure out who the user was, then I think the GDPR gives them an exception. But “without cookies” claim is dubious!

[deleted]

Re: How we built a GDPR-compliant website analytics platform without using cookies

#48
post #9

We are incredibly open to any ideas, comments or concerns on how we're doing this. This is a big step up from what we had previously, but there’s always room for improvement. Happy to hear thoughts in the comments.

Hi Paul, thanks for being open about this. I have a big, important question. ICO, the agency in charge of enforcing GDPR and related legislation in England, released guidance earlier this month on the topics of cookies. One of the most notable parts of this guidance is that "device fingerprinting" is treated the same as a cookie[1]. And also that website analytics requires consent to use cookies or similar technologi…

[deleted]

Re: How we built a GDPR-compliant website analytics platform without using cookies

#49

Earlier quoted context omitted.

So it's not as easy as just pushing the update to the repo. We are still committed to open-source, but we also have a business to run and need to make a living here (we're two dudes who care about privacy, not a huge company with deep pockets) :) The community version is getting a full update soon. We just have to focus on profit a bit (this keeps us in business and able to update the repo).

Speaking as someone who built an analytics business while still maintaining an open source version of the code, I can confirm that it's hard. Sometimes it starts off as one small patch that only makes sense for the hosted service, but you can't push to the OS branch until the code is refactored to protect secrets. I cannot give you any tips on managing your time between the two, but you may want to consider raising y…

Thanks for sharing your story. It is hard and we have to fight to not resent OSS because of 0.001% of the OS community. Open-source software has contributed significantly to our lives, and we love it, so we're going to be pursuing OS Version 2 regardless of a few angry people.

Re: How we built a GDPR-compliant website analytics platform without using cookies

#50
post #45

I am not sure what exactly they did here. How do they persist the hash between requests? My guess is they use localStorage and sending the hash to their servers with each request. So we are talking about a mechanism that’s just like a cookie. As long as they don’t have any PII and can’t figure out who the user was, then I think the GDPR gives them an exception. But “without cookies” claim is dubious!

We have been GDPR compliant for many months but our aim here was to meet E-Privacy demands.

We don't use localStorage... Read the blog post, we don't use cookies.

Post reply on HN