Just saw this one. It is an old comment, but let me try to answer as I find the question interesting.
The post on Human Web (https://0x65.dev/blog/2019-12-03/human-web-collecting-data-i...) has a brief section regarding differential privacy. Maybe check that one out first.
My take on it: although we do see value in differential privacy, we do not believe it fits well in our particular case. The critical moment is to decide what data should be sent by the client. Once data it is out, it is out. It is not possible to apply anonymization once it is on the server. If someone knows how it can be done safely, I would be highly interested.
We consider our chosen approach - breaking record linkage before sending - safer for our use-case and simpler. Do not underestimate the simplicity argument. Differential privacy is a powerful technique, but it is also very complex; there are lots of pitfalls and it is crucial to make good choices for the parameters.
Would be a good topic for another blog post. ;-)
Edit: after considering it more, I realize you can certainly apply some mechanisms from differential privacy to play a part in the data collection schemes.
Yes, we are not the only approach. Even when we started collecting data back in 2014 it wasn't the only one. But we did not find any suitable off-the-shelf solution back then.
Homomorphic encryption was discarded because some data to be send needs to be on the clear. For instance a url we need to fetch, so cannot transform it. Also, computationally is very expensive.
Federated learning is actually closer to what we do, take our approach as federated learning where each node is a single user and where all aggregation of records need to happen there, so that record-linkage on the final collector is impossible.
Tomorrow and the day after tomorrow we are releasing the technical details on different blog-posts, this one was more a motivation/introduction to the main dish.