[yellowapple]

> Brave is a great browser, respects to Brendan and team. We both "fight" against Google.

Using Google's browser as the basis for one's own browser is certainly an interesting way to "fight" against Google.

Much like how collecting ad performance / analytics data from users is an interesting way to achieve privacy as a "strict design requirement".

[solso]

Brave is based on Chrome, whereas Cliqz is based on Firefox (just to be precise). Note that ownership of code is not the same of ownership of a service... if Brave is depending on Google services, then you would be right (what happens with the [meta]searchers. But the code is open, and can be forked at will (there are some caveats to that claim, licences, internal APIs, etc.)

You can collect data from users and still do not compromise their privacy, it's how you do it that matters, becomes a design requirement. Collecting a url visited, can lead to build a user history (privacy hazard) or not. It's an design choice. The whole mantra that data!=privacy is doing a lot of damage (for anyone curios we did publish plenty of material on the topic, https://0x65.dev/blog/2019-12-02/is-data-collection-evil.htm...)

[yellowapple]

> Note that ownership of code is not the same of ownership of a service... if Brave is depending on Google services, then you would be right

Unless Brave is prepared (i.e. has the necessary staff) to be able to independently develop their Chromium base without any help from Google whatsoever, then they are dependent upon at least one Google service - specifically, Google's development of Chromium.

> The whole mantra that data!=privacy is doing a lot of damage

No. The whole mantra that "privacy is possible when hoarding data" is what is doing damage. Every byte of data you collect is a liability - a privacy and security compromise waiting to happen. Even assuming your intentions were good and pure (which, as you might guess, I take with a hydrostatically-equilibrious and neighborhood-clearing grain of salt), even locally-stored analytics/performance data is a rich target for less-than-benign actors, and it's information that more often than not has no business being collected.

That is:

> You can collect data from users and still do not compromise their privacy

This is definitionally false. The very collection of data compromises one's privacy, by nature of it having been collected. Sometimes that compromise is necessary, but nothing Cliqz did seemed particularly necessary.

[solso]

>> You can collect data from users and still do not compromise their privacy

> This is definitionally false. The very collection of data compromises one's privacy, by nature of it having been collected.

That's not definitionally false, if it sounds false to you is because you have an implicit assumption that does not apply.

Data from users does not imply user sessions on the collector side (session as a set of multiple data points belonging to the same user).

If sessions are collected, then, privacy is impossible to guarantee. We are well aware of that, having worked on this problems for almost 20 years. But that's precisely what Cliqz never did. All messages from our users are record-unlinkable for us, meaning that we have no way to reconstruct any session.

If you are interested, check the HumanWeb posts on https://0x65.dev/ or the papers https://0x65.dev/pages/dissemination-cliqz.html

[yellowapple]

> That's not definitionally false, if it sounds false to you is because you have an implicit assumption that does not apply.

That "implicit assumption" is awareness of what "privacy" and "data collection" mean, and it very much applies (arguing otherwise is revisionist). Ergo: "definitionally false".

In particular:

> Data from users does not imply user sessions on the collector side

Yes it does, because otherwise collecting that data is pointless. Further:

> All messages from our users are record-unlinkable for us, meaning that we have no way to reconstruct any session.

Not if a malicious actor (which may or may not include a future or even current version of you) taps into the locally-stored tracking data. The very existence of that data and its collection thereof is a fundamental security and privacy risk. Just because you ain't currently siphoning it to remote servers doesn't mean malware can't do so, or that a "critical security update" can't reprogram the Cliqz browser/addon to do so.

That is: whether the aggregation happens client-side or server-side does not change the basic fact that the aggregation is happening, and that aggregated data remains a juicy target (and to make matters worse, even if you did want to safeguard that data, it's effectively outside your control). That very aggregation itself is therefore a violation of my privacy.

And this is all taking Cliqz' claims at face value. We could certainly dig further into how we're supposed to take your word that you are indeed discarding unique identifiers (including IP addresses). We could (and should) certainly do the same for other sites claiming to discard such identifiers, but given DuckDuckGo (for example) ain't in the business of peddling sleazy-looking adware¹ (to my knowledge at least), I'm at least slightly more inclined to take their word for it.

I'll give Cliqz credit for at least trying to address these issues in the hopes of finding a creative solution that gives advertisers what they want without egregious privacy violations, but - having read the papers before, and reading them again - I'm still pretty thoroughly unconvinced. I'd much rather not have tracking at all, like how newspaper and magazine ads work (barring some substantial leap in technology, newspapers and magazines never tracked my "engagement" with the ads within or how long my eyeballs were looking at them or how quickly I turned the page or what have you).

----

¹: https://cliqz.com/en/cliqz-angebote