Hacker Newsnew | past | comments | ask | show | jobs | submit | JackWritesCode's commentslogin

I was linked to this post by a friend regarding the comments you made about Fathom's GDPR compliance.

1. The GDPR is regulation from the European Union

2. PIPEDA has an Exemption order for BC (British Columbia, Canada) and applies "in respect of the collection, use and disclosure of personal information that occurs within the Province of British Columbia".

Firstly, the Exemption order states "Whereas the Governor in Council is satisfied that the Personal Information Protection Act, S.B.C. 2003, c. 63, of the Province of British Columbia, which is substantially similar to Part 1 of the Personal Information Protection and Electronic Documents Act, applies to the organizations described in the annexed Order;"

Secondly, which part of BC's Personal Information Protection Act would undermine it's adequacy ruling under the GDPR?

Finally, let's get into Fathom's pageview/event collection script and explain how it works:

1. There is no collection, use and disclosure of personal information that occurs within the Province of British Columbia

2. EU traffic is automatically routed via EU Isolation and processed on German-owned servers. This allows us to stop US government snooping on EU traffic

3. Fathom Analytics is incorporated in BC. But nobody in BC has access to our EU Isolation infrastructure. I'm the CTO of Fathom Analytics and I have access to our EU Isolation infrastructure. I'm not in BC. Additional access to EU Isolation is from Germany only. Heck, not even GitHub Actions has access to EU Isolation, we self-host GitLab to keep things completely isolated. We put a lot of time and effort into this.

I'll wait back to hear back from you on which parts of the BC's PIPA undermine the adequacy ruling. Our lawyer here in Canada is incredibly well versed in Canadian privacy law, so we can definitely loop her in if there's any confusion here.

I hope that addresses your point and helps inform other people who may be reading this.


https://iapp.org/news/a/schrems-ii-impact-on-data-flows-with...

> To date, Alberta, British Columbia, and Quebec have privacy legislation that takes commercial activities in those provinces out of the federal jurisdiction through the "substantial similarity" exemption to PIPEDA. Federal privacy law defers to provincial law if a province meets the substantial similarity test, providing a baseline of privacy regulation across Canada. This division of authority is important, because for provinces recognized as substantially similar, their laws have not been given the stamp of "adequacy."

I might have framed my statement too strongly. Fathom can be GDPR compliant assuming additional contractual clauses are in place. That is what is mentioned in the linked IAPP assessment.

> 3. Fathom Analytics is incorporated in BC. But nobody in BC has access to our EU Isolation infrastructure. I'm the CTO of Fathom Analytics and I have access to our EU Isolation infrastructure. I'm not in BC. Additional access to EU Isolation is from Germany only. Heck, not even GitHub Actions has access to EU Isolation, we self-host GitLab to keep things completely isolated. We put a lot of time and effort into this.

The same could be said about Amazon, Google, and Azure employees and their data centre employees in Europe. What matters is effective control. You are not in BC but the company, and your position and responsibilities are governed by the laws of the province of British Columbia.

Although, in the case of Canada, SCCs will be actually effective as there are no surveillance laws similar to the US.


1. I understand the piece about "stamp" of adequacy. But when the Schrems II ruling happened, the world learned that we cannot always rely on "stamps" and need to look into the laws. At this moment in time, the European Commission says that Canada has adequacy ruling as a whole and there is no note about it not apply to British Columbia.

So my question to you is: Which part of the Personal Information Protection Act in BC would undermine the EU's adequacy decision towards BC? The reason I'm pushing on this question is because the "stamp" occurs for a reason. Please let me know where the PIPA would lead to the European Commission labelling BC as inadequate.

2. We're mixing things up here with Amazon, Google and Azure. Those companies are subject to FISA 702[1] and EO12333[2]. We are not subject to these surveillance laws here in Canada. I've spoken at length about this before, about how the US government could compel one of these companies to secretly spy on people using their EU infrastructure. So our company is not in the same position.

I'll wait for your specifics around the PIPA.

[1] https://en.wikipedia.org/wiki/Foreign_Intelligence_Surveilla... [2] https://en.wikipedia.org/wiki/Executive_Order_12333


Disclaimer: I am not a Privacy Lawyer, I am basing what I wrote here on the text of IAPP. I was looking for a reviewed PIPEDA adequacy decision. I saw references about it coming in 2020, then 2021, then 2022. Can't really find anything specific.

RE: 1

I am looking at this document: https://www.bclaws.gov.bc.ca/civix/document/id/complete/stat...

I assume this is up-to-date.

I will take one example: the Right to be forgotten. I don't see provision that satisfies the right to be forgotten: https://gdpr.eu/right-to-be-forgotten/

You seem to have a more in-depth understanding of PIPA. Can you point me towards a similar requirement in PIPA?

Looking at C-27, it appears that even PIPEDA is playing catch-up. But that was CPPA.

Btw. I am not suggesting Adequacy is always decided on privacy laws being EXACTLY like GDPR. Given the only reference to adequacy I found thus far was based on a 2001 review, I am not sure what would be appropriate criteria here beyond access to "an appropriate" level of legal protection.

The text in IAPP article refers to the adequacy of PIPEDA. Not Canada. It is actually interesting that there is no adequacy with Canada, but only with Canadian PIPEDA.

RE 2:

Right, I was referring to the fact that customers of Fathom sign contract/get into agreement with a company in British Columbia under its laws. It is mostly irrelevant where their CTO resides (it would be relevant if you resided in a non-adequate country, as your privacy policy would have to account for relevant data transfers).


Fathom's script forgets everybody by default, it's literally built into the tech. No EU personal data is touching Canada.

The background of Schrems II was that the US government can compel US companies to track foreign nationals and it would be lawful under US law. This is where the argument of "company in X under Y laws" comes into play. For example, Amazon is a US company. An EU subsidiary is still subject to it's parents control. If that parent is a US company, it's subject to US surveillance laws. Hello Schrems II.

So I'm not fully following why we're having a discussion around processing happening in Canada when personal data (IP Address) hits our EU Isolation infrastructure.

If you have any sources you can cite where the European Commission states BC as an exemption to Canada's adequacy ruling, please throw it back to me. I've not seen that.


No access logs are kept, users aren't profiled or tracked across multiple sites. Ad-blockers blocking privacy-first solutions encourage use of Google Analytics. Being able to bypass ad-blockers is a competitive advantage over GA, which then leads to companies dropping GA, which leads to less data hitting Google's servers. You can read more about ad-blockers vs privacy-first analytics here: https://usefathom.com/blog/ad-blockers-war


Thank you! Interesting read


Lmao. Hey, if I wasn't running Fathom, Dev Rel @ SingleStore is the only role I'd consider in tech right now. And I would definitely try to get some of those sweet shares as part of compensation. Alas, I don't own any SingleStore shares.


I completely agree! For the people following back home, who don’t want to move away from MySQL, can you let us know how to achieve a <10ms GROUP BY aggregation with a high cardinality column (11 million distinct values for “pathname”).

The query was:

SELECT SUM(pageviews) as total, pathname FROM pageviews GROUP BY pathname ORDER BY total DESC LIMIT 10.

If we don’t hear an answer from you, I’ll be really upset. Otherwise, we may have to add your ideas to the article!


By migrating to SingleStore, we didn’t have to change any persistence logic (we were already using SQL and Laravel Eloquent). Having explored doing that for Elasticsearch, it wasn’t something we wanted to do.

Looking back, I’m glad we went in this direction. Fathom has grown beyond what we could’ve imagined. Let’s see what happens over the next five years.


My wife thought it was funny ;)


Clickhouse isn’t really relevant for a lot of us. SingleStore outperforms clickhouse and the latter isn’t MySQL wire compatible. Far more features come with SingleStore too. And if you speak to people running Clickhouse, they’re also maintaining a Postgres set-up. With SingleStore, you get your OLTP and OLAP in one database. So our users & sites table sit in memory (backed up by disk), meaning ultra fast read/write speeds (comparable to clustered/high availability Redis). And then we put our pageviews/events in columnstore (disk) which offers rapid performance for analytical queries.


Definitely not. No regrets after making the move. March next year will be the two year mark.


I'm curious how you (and your team I presume) came to decide you need to build your own database?


We didn’t decide that, we used SingleStore


Very well written for newcomers. But I also appreciated the clarification in the auth section. I’ve used Laravel for years and the auth had confused me. Bootcamp makes things clearer.


Agreed. The next step here is to learn from what other people have written.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: