There is an even better solution: do not collect any data, especially when your customers are paying for your product.
If your business model involves subsidizing product prices with the prospect of tracking users and collecting personal data, consider releasing a version of your product that cost more, but does not engage in any data harvesting.
For a given product requirement, you have a set of potential reifications which include their data impact. There's not a zero or one dichotomy as you suggest. You can cut requirements, but all the ones that remain will have varying reliance upon data collection. The goal should be to minimize that impact to its least possible surface area while still delivering the same user value. It's especially toxic to pre-emptively collect data for unknown, or conjectured later requirements. YAGNI applies.
Of course, some products require data collection to function, and I agree that in such cases data collection should be kept at a minimum.
I was referring to products such as Windows. The consumer versions of Windows do not have UI controls for stopping telemetry entirely, nor is there a paid extension offered by Microsoft that disables it.
There is clearly a demand for a Windows version that offers complete privacy, yet Microsoft is not interested in meeting that demand.
Exactly! It's a high time for everyone to have an open discussion and have some strict implementation around what kind of data collection is considered fair? Search being a complex application as discussed in our previous articles on our blog (https://0x65.dev/) requires data and by that I mean real "Quality" data. When dealing with large datasets, circumventing through all the noise is probably a harder problem than search itself. This is where Human Web shines for us.
Consider this realistic scenario, for a user query, we have to navigate through an index of billions of webpages and come up with at-least 10 relevant results (which fill up page one). On top of that, make sure that the result on first position (top result) is most Relevant or Vital (a very broad and subjective metric) - All of this under fraction of a second. Add to this, the complexity involved dealing with an ever evolving and exploding content on the web, where we have different languages and region locales to deal with.
Through our blog articles, we want to re-emphasize that building an "Independent" search engine is very very complex and a challenging task, specially when we incorporate constraints encountered at our scale and the fact that we want to really abide by the principles of "Privacy by Design".
As with most we too could assume that "X" data point is readily available, let's collect it! But In reality, we always circle back. Literally, ask ourselves ... Does collecting X datapoint violate privacy for our user? If the answer to this is ever a "Yes", the X datapoint is dropped immediately and we DO NOT COLLECT IT! For us, features which rely on that datapoint X are just not deemed worthy!!! If the industry starts to replicate this practice, it would be a great win for Cliqz.
We could not agree more. We tried our best to make a case why the data or privacy dichotomy is a false one, especially in the context of building a search engine - one that is competitive and independent. Our rules are: no personally identifiable information (even minimize probabilistic attacks), minimize data collected to the bare minimum. This is what we use ourselves and what we want our families to use. We care.
It does come with challenges though.
1. It requires a change of mindset by the developers
2. Processing and mining data implies that code be deployed and run on the client-side.
3. The data collected might not be suitable to satisfy other use cases. Because data collected has been aggregated by users, it might not be reusable.
4. Aggregating past data might not be possible as the data to be aggregated may no longer be available on the client.
However, these drawbacks are a very small price to pay in return for the peace of mind of knowing that the data being collected cannot be transformed into sessions with uncontrollable privacy side-effects.
Disclaimer: I work at Cliqz (some of the comment comes from the article itself).
This is the problem, we do not need any more ad companies that care about our privacy. We need browser vendors that are in the primary business of creating browsers, and possibly charging for advanced features.
We need search engines that do not collect our entire browsing history and how we interact with sites on the pretense that its needed to deliver better search results, while their business model actually revolves around using the same data to deliver targeted ads.
Cliqz could very well collect data and use it only to make search better, and release paid search products for businesses and customers, but they chose to make their users the products.
I had doubts about why people were so upset about your company, but now I see it. Cliqz is esentially capitalizing on the growing privacy movement to market itself, uses subpar technical solutions to ensure data privacy (routing sensitive data through FoxyProxy), and in the end delivers the same old service: our data is harvested, and we are delivered targeted ads.
-----
REPLY:
-----
You're cherry-picking and putting things out of context:
> "the data collected is used to deliver targeted ads"
That's not said like this anywhere [e.g. in the linked privacy policy], because it would be false. We do targeted ads, but the targeting is done on the >>client<<, which is the only place that has your history information. It's not possible to do targeting outside the browser itself, because, unlike the rest, we do not have this information.
> you collect browser history
Also incorrect. We collect URLs, but on isolation, we never have the full history. In the article we discussed at length why this is dangerous, of course, we would not do the same.
> Uses subpar technical solutions to ensure data privacy (routing sensitive data through FoxyProxy)
> Cliqz could very well collect data and use it only to make search better, and release paid search products for businesses and customers, but they chose to make their users the products.
Everything we do is privacy preserving, the business model is no exception. We've been experimenting with paid products too (see: https://https://www.lumenbrowser.com/en/) - but it seems to me that if you had found that, you'd say "Yeah, but you want me to give credentials" - and suggest we live on donations instead. We need to be skeptical, and we thank you for that, but also be constructive and reasonable. Preventing anyone to improve the web, only helps companies that do not care about privacy.
> Cliqz is esentially capitalizing on the growing privacy movement to market itself.
We do not do it for marketing. We started building products with privacy in mind since 2014, back when privacy was even more niche than it is today. (from Day 2: Is data collection evil? [0]
I'm wary of companies that insist so much on collecting user data, especially when it's done at such a granular level. I keep wondering what did Mozilla have to gain from associating themselves with Cliqz.
Hi – thanks for the feedback. I’m Marc (disclaimer, I work at Cliqz). The goal of the collaboration was to jointly build a better, more private search engine. Don’t forget that every major browser today sends every keystroke of the Omnibar to either Google or Bing. No privacy mechanism in place (and don’t even get me started on all the tracker madness). We wanted to jointly replace that. Cliqz is building a new search from ground up with privacy by design. In the end the collaboration didn’t work out (for many reasons, lack of privacy was not one of them though). Firefox changed back to Google as search provider. Coming back to your point: There are many services that can’t be built without data. Search is one of them, without data you will have a very bad search engine, impossible to compete. We explain this in detail here: https://0x65.dev/blog/2019-12-02/is-data-collection-evil.htm... . We took maximum scrutiny, and this article about Human Web is exactly there to explain how we collect data that is needed, without the side effect of collecting personal data. We are so transparent about this, because we want the scrutiny. Our business does not depend on collecting personal data or actually any data. But our product needs a lot of data. Denying anyone to collect data – even if they are as open, transparent, and without any interest in personal information – just means you support those that are the incumbents and have no interest in privacy.
Is there a detailed writeup on the Human Web proxy network, specifically on the data transmission? It would be interesting to see how does it prevent Cliqz and proxy server operators from learning the user's IP address. Was Tor evaluated as an alternative for data transmission?
There is and it is planned for tomorrow! Stay tuned. As a small spoiler... We experimented with Tor in the past for this proxy network and it worked well but had other constraints (more tomorrow). Currently we rely on a third-party proxy provider (with a custom contract: they don't keep logs, etc.) and heavy crypto to make sure that we do not get any network-level information about users, and the proxies do not get any information about the content of messages. In Cliqz browser it's also possible to enable search through this proxy network for anonymity!
(disclaimer: I work at Cliqz) Not yet, but I'm literally working on it (or rather taking a break from working on it).
Short answer: The proxy will see your IP but does not share that information with us. To prevent the proxy from reading your content, we need to end-to-end the communication (and prevent statistical attacks based on the size of the encrypted data and so on).
Regarding Tor:
Yes, we experimented with sending through Tor. The main issue is that our code needs to run in a WebExtension, which is a restricted environment. You can only use WebSocket communication but no real TCP sockets. The next blog post in the series has more information and has a link to the code of our experimental Tor client (the native Tor client compiled with WebAssembly to be used in a WebExtension).
I hope the post will address your open questions. If not, you can ask tomorrow about the details of HPN.
> Denying anyone to collect data – even if they are as open, transparent, and without any interest in personal information – just means you support those that are the incumbents and have no interest in privacy.
This is a really weird argument to make. It comes off as extortionate (if you don't let us have the data, then even worse people will have the data).
I want to suggest that Cliqz has actually spent a lot of time being open and it really looks like at least one person at the company is putting a sincere effort into user privacy.
We should be extremely wary, but at this point I think their write ups at least deserve a read. I suspect it’s more a matter of the tech and/or trust being too difficult than one of bad intentions by anyone.
(I am unaffiliated and generally very pro-privacy, but read about this last year and the news coverage seemed unfair after exploring their site at the time)
21 comments
[ 3.8 ms ] story [ 58.2 ms ] threadday 1: Why the world needs more search engines https://www.0x65.dev/blog/2019-12-01/the-world-needs-cliqz-t...
day 2: Is data collection evil https://www.0x65.dev/blog/2019-12-02/is-data-collection-evil...
If your business model involves subsidizing product prices with the prospect of tracking users and collecting personal data, consider releasing a version of your product that cost more, but does not engage in any data harvesting.
By now it should be obvious that no privacy oriented company (or in fact any other company) should treat user data as product.
I was referring to products such as Windows. The consumer versions of Windows do not have UI controls for stopping telemetry entirely, nor is there a paid extension offered by Microsoft that disables it.
There is clearly a demand for a Windows version that offers complete privacy, yet Microsoft is not interested in meeting that demand.
Exactly! It's a high time for everyone to have an open discussion and have some strict implementation around what kind of data collection is considered fair? Search being a complex application as discussed in our previous articles on our blog (https://0x65.dev/) requires data and by that I mean real "Quality" data. When dealing with large datasets, circumventing through all the noise is probably a harder problem than search itself. This is where Human Web shines for us.
Consider this realistic scenario, for a user query, we have to navigate through an index of billions of webpages and come up with at-least 10 relevant results (which fill up page one). On top of that, make sure that the result on first position (top result) is most Relevant or Vital (a very broad and subjective metric) - All of this under fraction of a second. Add to this, the complexity involved dealing with an ever evolving and exploding content on the web, where we have different languages and region locales to deal with.
Through our blog articles, we want to re-emphasize that building an "Independent" search engine is very very complex and a challenging task, specially when we incorporate constraints encountered at our scale and the fact that we want to really abide by the principles of "Privacy by Design".
As with most we too could assume that "X" data point is readily available, let's collect it! But In reality, we always circle back. Literally, ask ourselves ... Does collecting X datapoint violate privacy for our user? If the answer to this is ever a "Yes", the X datapoint is dropped immediately and we DO NOT COLLECT IT! For us, features which rely on that datapoint X are just not deemed worthy!!! If the industry starts to replicate this practice, it would be a great win for Cliqz.
It does come with challenges though.
1. It requires a change of mindset by the developers
2. Processing and mining data implies that code be deployed and run on the client-side.
3. The data collected might not be suitable to satisfy other use cases. Because data collected has been aggregated by users, it might not be reusable.
4. Aggregating past data might not be possible as the data to be aggregated may no longer be available on the client.
However, these drawbacks are a very small price to pay in return for the peace of mind of knowing that the data being collected cannot be transformed into sessions with uncontrollable privacy side-effects.
Disclaimer: I work at Cliqz (some of the comment comes from the article itself).
--------------
REMOVED COMMENT:
--------------
Is data collected by Cliqz Browser and your search engine used in any way to provide the MyOffrz marketing service? https://myoffrz.com/en/
Edit: according to the privacy policy the browser and the data collected through it is indeed used to deliver targeted ads.
https://cliqz.com/en/privacy-browser
This is the problem, we do not need any more ad companies that care about our privacy. We need browser vendors that are in the primary business of creating browsers, and possibly charging for advanced features.
We need search engines that do not collect our entire browsing history and how we interact with sites on the pretense that its needed to deliver better search results, while their business model actually revolves around using the same data to deliver targeted ads.
Cliqz could very well collect data and use it only to make search better, and release paid search products for businesses and customers, but they chose to make their users the products.
I had doubts about why people were so upset about your company, but now I see it. Cliqz is esentially capitalizing on the growing privacy movement to market itself, uses subpar technical solutions to ensure data privacy (routing sensitive data through FoxyProxy), and in the end delivers the same old service: our data is harvested, and we are delivered targeted ads.
-----
REPLY:
-----
You're cherry-picking and putting things out of context:
> "the data collected is used to deliver targeted ads"
That's not said like this anywhere [e.g. in the linked privacy policy], because it would be false. We do targeted ads, but the targeting is done on the >>client<<, which is the only place that has your history information. It's not possible to do targeting outside the browser itself, because, unlike the rest, we do not have this information.
> you collect browser history
Also incorrect. We collect URLs, but on isolation, we never have the full history. In the article we discussed at length why this is dangerous, of course, we would not do the same.
> Uses subpar technical solutions to ensure data privacy (routing sensitive data through FoxyProxy)
There is a nice short reply here https://news.ycombinator.com/item?id=21696963, but just in case please have a look at the paper: https://arxiv.org/abs/1812.07927.
> Cliqz could very well collect data and use it only to make search better, and release paid search products for businesses and customers, but they chose to make their users the products.
Everything we do is privacy preserving, the business model is no exception. We've been experimenting with paid products too (see: https://https://www.lumenbrowser.com/en/) - but it seems to me that if you had found that, you'd say "Yeah, but you want me to give credentials" - and suggest we live on donations instead. We need to be skeptical, and we thank you for that, but also be constructive and reasonable. Preventing anyone to improve the web, only helps companies that do not care about privacy.
> Cliqz is esentially capitalizing on the growing privacy movement to market itself.
We do not do it for marketing. We started building products with privacy in mind since 2014, back when privacy was even more niche than it is today. (from Day 2: Is data collection evil? [0]
We under...
https://en.wikipedia.org/wiki/Cliqz#Integration_with_Firefox
Short answer: The proxy will see your IP but does not share that information with us. To prevent the proxy from reading your content, we need to end-to-end the communication (and prevent statistical attacks based on the size of the encrypted data and so on).
Regarding Tor: Yes, we experimented with sending through Tor. The main issue is that our code needs to run in a WebExtension, which is a restricted environment. You can only use WebSocket communication but no real TCP sockets. The next blog post in the series has more information and has a link to the code of our experimental Tor client (the native Tor client compiled with WebAssembly to be used in a WebExtension).
I hope the post will address your open questions. If not, you can ask tomorrow about the details of HPN.
There is also a new thread about it: https://news.ycombinator.com/item?id=21704850
This is a really weird argument to make. It comes off as extortionate (if you don't let us have the data, then even worse people will have the data).
We should be extremely wary, but at this point I think their write ups at least deserve a read. I suspect it’s more a matter of the tech and/or trust being too difficult than one of bad intentions by anyone.
(I am unaffiliated and generally very pro-privacy, but read about this last year and the news coverage seemed unfair after exploring their site at the time)