The chosen country is important. `uva` may be more commonly associated with the University of Virginia in the US. For Netherlands (same query) https://search.brave.com/search?q=uva&country=nl will correctly point to Universiteit van Amsterdam.
At present we default to country US. We're looking to implement better defaults soon.
> When someone points out that someone did something bad, clarifying they only did it to 1% of one country's users isn't a super strong defense.
I don't see where I made this "clarification".
Let's be clear. Firefox was trying to test switching from Google to Cliqz (where it had a stake). Mozilla had a difficult time trying to break the golden cage they find themselves in. To their credit, they did try. Ultimately the Cliqz-Firefox integration was, unilaterally, cancelled. If your main source of revenue comes from your “competitor” you are slowly pushing yourself to irrelevance.
And also, the privacy issue again: I addressed a similar question in another comment in this thread [0]. If you want to spread FUD, please make a proper case.
This statement is misleading. Firstly, for context here's the paragraph you ought to be referring to:
> This experiment also includes the data collection tool Cliqz uses to build its recommendation engine. Users who receive a version of Firefox with Cliqz will have their browsing activity sent to Cliqz servers, including the URLs of pages they visit. Cliqz uses several techniques to attempt to remove sensitive information from this browsing data before it is sent from Firefox. Cliqz does not build browsing profiles for individual users and discards the user's IP address once the data is collected. Cliqz's code is available for public review and a description of these techniques can be found here.
This section is a horrible write up of what happened. Over the years, among a lot of other privacy tech (e.g. [0][1][2]), we developed a privacy-preserving data collection framework we call Human Web [3]. The gist of it is simple: Users contribute data. There's no way to link any two messages with one another making it impossible to build profiles out of the data. In fact, most of the URLs are dropped thanks to these strict checks. Mozilla, Princeton University and Red Pen Team have audited the approach. The code is open-sourced [4]. Feel free to audit it, and also please feel free to use it in your projects. If you are genuinely interested in the approach, please read [3] and let's discuss details.
Here's the bigger issue. We have created an unhealthy, and wrong narrative around privacy vs data collection. It's a false dichotomy. We also wrote at length about this here [5]. Data from people, is not the same as personal data. Record linkage here is key, and we prevent it - even at a network level [6].
Hey, I am working on Cliqz Search [0] and would be very thankful if you point me to quality issues. I use it daily myself (in English) and will make sure those issues are addressed.
Fundamentally, Google protects its search by owning all entry points to it (or paying massive fees for competition-prohibitive distribution deals.
The strategy can be seen at play with the Chrome browser, Android and its licensing model for hardware manufacturers, paying Firefox and Apple for placing search as default in their respective platforms. They know that once distribution barriers for search fall, their existence is threatened, explaining even moves like Google Fiber.
Hey, thanks for using Cliqz. We're working hard on improvements for each one of the things you mentioned (in that order as well) - so things will definitely get much smoother over the next couple of months.
https://beta.cliqz.com/ is currently available as any other webpage, and will continue to be available in the same way in the future. I think what's being referred to is another search product (search as you type) we have in the Cliqz Browser. I work on these.
Reading big difficult books is offered as a way to teach reasoning from first principles. On how to go about it:
"We have our recommended ten-stage process for reading such big books:
1. Figure out beforehand what the author is trying to accomplish in the book.
2. Orient yourself by becoming the kind of reader the book is directed at—the kind of person with whom the arguments would resonate.
3. Read through the book actively, taking notes.
4. “Steelman” the argument, reworking it so that you find it as convincing and clear as you can possibly make it.
5. Find someone else—usually a roommate—and bore them to death by making them listen to you set out your “steelmanned” version of the argument.
6. Go back over the book again, giving it a sympathetic but not credulous reading
7. Then you will be in a good position to figure out what the weak points of this strongest-possible argument version might be.
8. Test the major assertions and interpretations against reality: do they actually make sense of and in the context of the world as it truly is?
9. Decide what you think of the whole.
10. Then comes the task of cementing your interpretation, your reading, into your mind so that it becomes part of your intellectual panoply for the future."
I am not sure that is the case. GDPR makes provisions for personal data that can uniquely identify users. Blanket statements like: Local storage is not allowed I think are misleading. The state is persisted in the client's machine. Unlike cookies, which get attached to all requests in the specified path, local storage items are not transmitted with the request. Furthermore, in the approach I recommended earlier, no unique identifiers are being sent with the request at all. I am pretty sure that is GDPR compliant, but would love to be pointed to legal provisions that would suggest otherwise.
> it's a trade-off we are willing to accept.
Referrers, in my opinion, are not reliable enough to derive uniques, and I would assume (although I would not have any numbers to back it up), that the margin of error is very significant when you consider every condition under which referrers would not be sent (some very good cases when that happens are mentioned by other people in this very thread)
I think a more robust (and privacy-preserving) way to calculate uniques ( per time-frame as well) is to make use of the local storage / indexDB in the visitor's browser.
This is how it would work:
- Visitor X lands on your website.
- With some JavaScript you check local storage if `dailyUnique` for today's date is set.
- if yes, send `visit` signal
- if not set, send `unique visit` signal and set `dailyUnique` to local storage.
You can apply this to any analytics use case. Its is private and does not rely on referrers. We have been using this goal-attainment approach to do analytics at my company for quite some years.