Cliqz is shutting down
51–59 of 59 posts
Re: Cliqz is shutting down
#52Ok, so it's kind of difficult to compete with Google. I get that. How about building decentralized search engines? Basically ActivityPub, but for search engines. Any known efforts in this direction?
There is YaCy which has pretty terrible results but is P2P. There used to be a P2P search engine called FAROO that was better but seems to have been shutdown. I wrote a blog post comparing search results quality earlier this year. YaCy came in last, even behind Cliqz. https://www.kylepiira.com/2020/02/07/which-search-engine-has...
I mean, obviously, there is more to building a "search engine" than just a big fat searchable index. I think where Google shines is to understand what you mean, not what you wrote. This is a pretty complex task, I guess.
Re: Cliqz is shutting down
#53Earlier quoted context omitted.
> Advertisement as implemented today is a privacy hazard, but there are other ways to do it, client-side, which is what Cliqz attempted. https://en.wikipedia.org/wiki/Cliqz#Integration_with_Firefox : "According to the Firefox support website, this version of Firefox collects and sends data to the Cliqz corporation including text typed in the address bar, queries to other search engines, information about visited webp…
This claim on the Wikipedia is factually incorrect: "This data is tied to a unique identifier allowing Cliqz to track long-term performance." Thanks for noticing it, we will create an issue. UUIDs only applies to telemetry, which is not the data being described in the paragraph: queries, scrolling, amount time spend, urls, etc. For this kind of user data (HumanWeb) there is no uuid, neither implicit or explicit. Ther…
This is accurate. They partnered with us at FoxyProxy to prevent browser telemetry from revealing users' IP addresses and other metadata.
These guys are above board and even if there may have been a problem in 2017 with Firefox, that was no longer the case in 2018, 2019, and 2020. They bent over backwards and jumped through many hoops to hide their users' identity. They were very interested in the solving the engineering problem around anonymization. I know this from first-hand experience.
This is a loss larger than many people realize. There are so few companies with such integrity and who put their users first, above profits or shareholders.
Re: Cliqz is shutting down
#54Earlier quoted context omitted.
> Advertisement as implemented today is a privacy hazard, but there are other ways to do it, client-side, which is what Cliqz attempted. https://en.wikipedia.org/wiki/Cliqz#Integration_with_Firefox : "According to the Firefox support website, this version of Firefox collects and sends data to the Cliqz corporation including text typed in the address bar, queries to other search engines, information about visited webp…
This claim on the Wikipedia is factually incorrect: "This data is tied to a unique identifier allowing Cliqz to track long-term performance." Thanks for noticing it, we will create an issue. UUIDs only applies to telemetry, which is not the data being described in the paragraph: queries, scrolling, amount time spend, urls, etc. For this kind of user data (HumanWeb) there is no uuid, neither implicit or explicit. Ther…
That claim comes directly from Mozilla's support page on the subject¹:
> Firefox shares the following data with Cliqz to provide functionality and improve performance of the Cliqz feature for everyone:
> - Search queries & webpage data: This includes text as you type in the address bar, queries you send to certain search engines, and data about the webpages you visit and interactions with those pages, such as mouse movements, scrolls, and time spent.
> - Interaction data: This includes your interactions with specific fields and buttons in the Cliqz feature. This data is tied to a unique identifier allowing Cliqz to understand performance over time.
So, if that's "factually incorrect", you should take it up with your business partners.
> There are plenty of papers on the topic, independent audits, the code is open-source and the data can be inspected. HumanWeb data is 100% record-unlikable, we have no way to know if two messages received come from the same person or not.
For now. Things can always change, and promises can always be broken. It'd be a lot easier to trust Cliqz if it wasn't collecting such data at all, let alone sending it to remote servers with a pinky promise that it's anonymized.
----
¹: https://support.mozilla.org/en-US/kb/cliqz-recommendations-f...
Re: Cliqz is shutting down
#55Earlier quoted context omitted.
> 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".
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…
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.
Re: Cliqz is shutting down
#56Earlier quoted context omitted.
This claim on the Wikipedia is factually incorrect: "This data is tied to a unique identifier allowing Cliqz to track long-term performance." Thanks for noticing it, we will create an issue. UUIDs only applies to telemetry, which is not the data being described in the paragraph: queries, scrolling, amount time spend, urls, etc. For this kind of user data (HumanWeb) there is no uuid, neither implicit or explicit. Ther…
> we have no way to know if two messages received come from the same person or not. This is accurate. They partnered with us at FoxyProxy to prevent browser telemetry from revealing users' IP addresses and other metadata. These guys are above board and even if there may have been a problem in 2017 with Firefox, that was no longer the case in 2018, 2019, and 2020. They bent over backwards and jumped through many hoops…
Why the ruckus then? Because some assume that is data is sent, privacy is compromised, period. They do not know how to do it, and they assume it's impossible. Instead of checking the claims for themselves (code is public, data can be inspected, documentation, etc.) they prefer to stick to their belief system, which is more comfortable and does not imply hard work. The press release that FF -- written by one of these people with a lot of biases and published without review -- did not help as it was misleading.
We did a big mistake back then. Instead of rebutting it, we chose to ignore the FUD assuming that facts would prevail. They did not.
Sadly the community is "scared", we have been congratulated and lauded by anyone who checked our systems. But never endorsed in public, there is little to gain and a lot to lose (you are getting a sneak preview right now).
Sad story, extremely frustrating too, but there is nothing we can do now.
Re: Cliqz is shutting down
#57Earlier quoted context omitted.
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…
> 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…
> 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
Re: Cliqz is shutting down
#58Earlier quoted context omitted.
> 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…
>> 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 multip…
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).
----
Re: Cliqz is shutting down
#59Earlier quoted context omitted.
> we have no way to know if two messages received come from the same person or not. This is accurate. They partnered with us at FoxyProxy to prevent browser telemetry from revealing users' IP addresses and other metadata. These guys are above board and even if there may have been a problem in 2017 with Firefox, that was no longer the case in 2018, 2019, and 2020. They bent over backwards and jumped through many hoops…
There were no problems in 2017 or before, we were doing the same exactly the same during Firefox times (we went through security and privacy audits). Data collection is and always was safe wrt to privacy. Why the ruckus then? Because some assume that is data is sent, privacy is compromised, period. They do not know how to do it, and they assume it's impossible. Instead of checking the claims for themselves (code is p…
If my eyes rolled any harder I'd likely pull a muscle.
Let's dissect this a bit:
> Because some assume that is data is sent, privacy is compromised, period.
It ain't about it being sent (though that's bad, too). It's about it being collected at all. Cliqz collects and aggregates my data somewhere, and that is therefore a violation of my privacy, even if (for now) it's on my local machine (I could certainly routinely delete that collected data, much like I do with cache and cookies, but then what's the point of using Cliqz in the first place?).
> Instead of checking the claims for themselves (code is public, data can be inspected, documentation, etc.)
I have checked the claims for myself (to the best of my ability). None of them address the very real concern of the aggregated data being, you know, aggregated. Just because it's on my local machine doesn't mean it's guaranteed to stay that way; every second it's on my machine is a liability that anyone who's privacy-conscious would want to eliminate (and anyone who's not privacy-conscious doesn't care about).
Like, there's no argument that Cliqz's HumanWeb is at least less evil than traditional tracking systems, but it still relies on aggregation of data, and that is still a massive privacy hazard. Not to mention that the data that is sent¹ is still rich with datapoints that could be used for fingerprinting (the papers seem to suggest there are "heuristics" to detect and anonymize this, but said papers are pretty light on detail, and source code is meaningless since we don't know if it's what's actually running server-side). And also not to mention the rather sketchy distribution methods, like piggybacking on .NET downloads via chip.de in a manner that's been a hallmark of spyware since Y2K.
> they prefer to stick to their belief system, which is more comfortable and does not imply hard work.
"Am I out of touch? No, it is the children who are wrong."
----
> Sad story, extremely frustrating too, but there is nothing we can do now.
Not with that attitude. The search engine technology y'all developed is pretty interesting from a technical standpoint, and could be put to use (I'm sure DDG would be interested in adding it to their mix, or perhaps Ecosia could use it to diversify their Bing/Yahoo results the way DDG does with their in-house crawler). Same with Ghostery's more efficient network request blocking engine² (though it seems like Ghostery's development is still ongoing, no?), which could be useful in other ad and tracker blockers. Neither of these are much in the way of money-makers (well, maybe the search one is, if y'all license it), but it'll at least help make the best of a lousy situation.
I get that it sucks - I've similarly felt the pain of a product into which I've put my blood, sweat, and tears ultimately failing. It's easy to write off the detractors and critics as simply uninformed masses who just "didn't understand how great of a product we have". It's harder to admit that the product wasn't great, or the name was terrible, or the market wasn't as big as anticipated, or what have you.
I'm confident that being the bright and enthusiastic people y'all are, you'll find your footing again. Just, um, try to come up a name that doesn't scream "adware" like "Cliqz MyOffrz" next time, lol. And maybe instead of writing off your criticisms as "FUD", actually examine why those criticisms persist and what you can do to better address them.
----
¹: https://cliqz.com/en/whycliqz/transparency
²: https://whotracks.me/blog/adblockers_performance_study.html