Would you mind sharing the source and year for these numbers? The only stats I found were not from 2019 and coal was higher than 9.7%.
951 karma · joined November 15, 2016
1. All clients download a database of offers locally (they are basically vouchers, we call them offers because they have the potential to make users save money).
2. While browsing with this feature enabled, URLs of pages as well as some other information accessible locally are processed by the extension which tries to detect the intent of buying something online.
3. When an intent corresponding to one of the items in the local database is found, an offer is shown with a coupon that can be used to save money.
What sets it apart from ads in my opinion is that everything happens client-side and that the offer is only shown when there is a clear intent to buy something (instead of all pages with traditional ads). This means that users will actually see very few of them, but that they should be very relevant and useful (you save money).
We're currently proposing a mix of client-side private offers (not unlike Brave) and paid products (e.g.: Ghostery premium, and more are being worked on as we speak). Users should have a choice.
> I notice you said your products are designed to not require private data collection; presumably that means they do it, but could in theory work without doing it. That comes across as weasel words.
No. That means that we do not collect personal data. And being able to do so took (and still takes) a lot of research and careful design.
1. Cliqz is not an advertising company, it's a search company and we push hard for privacy protection in everything we do (private search, antitracking, adblocking, etc.) 2. Privacy policies are legally binding, and in ours we state that no personal data is collected. We designed our features and products to not require collection of any private data (that includes our search engine). 3. I'd like to point out that in Firefox, by default, your queries are sent to advertising company Google. So I don't understand all the heat when Mozilla tries to find more privacy-friendly alternatives to Google. In this case, they replaced Google by Cliqz (again, an independent German search company focusing on privacy, building its own index: no Bing results involved) in Germany, for 1% of the users. That seems to perfectly fit in Mozilla's mission of protecting users' privacy.
For the study, measurements were run with one of our personal laptops (an X1 Carbon from 2016 with an i7 U6600 CPU and 16 GB of Ram, which is indeed a pretty powerful machine). We tried very hard to limit the impact of frequency throttling due to limited thermal dissipation of the device for the long-running benchmarks. In fact, for the measurements we put the laptop outside at 0 degrees Celsius, and we could observe that the CPU temperature did not go beyond 60 degrees (which is pretty low).
Do you have any suggestions on how we could improve this setup? We welcome all contributions.
Thank you for taking the time to read this study. We do not think we claimed anything that was false in this study (although the scope might not be as wide as some would expect or desire); this is not a reason to be dismissive. We have ourselves a lot of respect for the work done at Brave.
> Brave is intentionally slow on parsing and do as much work there because it doesn't parse from client code, it only use already parsed lists from memory.
That was indeed one of the things measured, but not the most important one. In fact we explicitly say that this is a one time operation and does not necessarily matter, especially if as you suggest you can perform this work backend-side and ship the serialized version to clients. What is more interesting is the time it takes for matching requests.
> "The memory usage of Brave could not be evaluated using the devtools and thus is not included in this section." That doesn't make sense, I wonder if it's maybe using a very old version based on the old muon code base? If you can get the memory from Chrome you can get it from Brave.
If we got this thing wrong we would be very happy to update the results with the correct measurements. The version we used was the latest version from `master` on the following repository: https://github.com/brave/ad-block
> No information was given about versions that were tested.
This is indeed unfortunate and we will be correcting this. The measurements were performed last week with the latest version of each projects but we should definitely indicate the exact version used.
> Total parsed rules is too small.
Too small for what exactly? Easylist is one of the most popular lists and it's pretty common to use it as a base-line for comparison. It is trivial to re-run the experiment with different lists given that all the code is open-source.
We would be really happy to see people running the same benchmarks and try to reproduce the results!
It has been suggested in another comment that Chrome could give visual indications of the performance of extensions. They already do some of this to track the memory used.
Source: https://github.com/betafish-inc/adblock-releases#intro and https://en.wikipedia.org/wiki/AdBlock
1. Matching the $domain option using an optimized Trie data-structure
2. Parsing domains using the public suffix list, also based on a Trie data-structure
I would love someone well-acquainted with the uBlock Origin code-base to update the benchmark so that we can compare.
Edit: All the code to create the dataset (as well as the dataset used for the study itself) and to run the benchmark and analyze the results (create the plots, etc.) is available on the repository and should be reasonably easy to run locally.
* The blocking engine operated by either Safari or Chrome is a black-box and independent devs will have a harder time understanding it, tweaking it, improving it, debugging it.
* Chrome devs are now playing nicely and get feedback and propose some improvements to the APIs but there is no warranty this will happen again, or that they will invest time/energy in the future improving this part of the browser.
* It's harder to work with this API than a JavaScript code-base you control.
* Chrome seems a bit better here but for Safari the documentation is pretty poor.
* You also don't get feedback regarding the rules which matched on a page and this makes it harder to debug or give nice insights to users.
That's only a few points from my personal experience but I discussed multiple times with developers of other privacy-enhancing extensions/apps and we shared similar feelings.
I would love to hear your thoughts about this. From our point of view, the argument is not that the native content blocker is slow or fast but instead that it's not an acceptable trade-off, for different reasons (see link below). We also show that some of the most popular content-blockers are more than fast enough in this regard. I would love Chrome to propose this declarative API as an addition to the current WebRequest APIs and incentivize developers to use it when it makes sense. But replacing the current WebRequest's blocking capability with this would prevent extensions from protecting users as efficiently as today.
I wrote a bit more about other reasons I think the declarative API as only blocking capability of the browser is not a good thing IMO: https://news.ycombinator.com/item?id=19175265
> There's a few issues with the conclusion here. First, they article measures and discusses only the time required to block a single request. Modern web pages are issuing many, many more requests than that, like the 35 that this page issues. At median timings, that would put the DuckDuckGo blocker at almost 300ms, well within what humans can notice.
That is true, but on the other hand the DuckDuckGo blocker is the exception here and they could likely improve this performance if it becomes their focus (one way would be to use one of the faster open-source alternatives). If you consider uBlock Origin, Adblock Plus or Ghostery, we see that even blocking 100 requests would not take much time (probably around 1 ms with Ghostery).
> The second is that this API is not used solely by the popular content blocking extensions, but by a variety of other extensions. The Chome team's performance concerns likely stem from the fact that a user won't be able to differentiate the browser slowing down and an errant extension slowing down the network requests, and there are examples of extensions that use this API to issue additional network requests or do slow things down. If you cherry-pick the good citizens of this API to show that performance isn't a problem in general, you're not showing that performance can't or shouldn't be the reason, just that it isn't the reason for the fast good citizens. What this data could be used to argue is that imposing strict deadlines on the execution time of these extensions would allow the content blockers that the community cares about to continue to function as they do today while also placing a performance cap on bad extensions.
There are indeed examples of extensions doing bad things: collecting private data, etc. But we are talking about diminishing the potential privacy protection of all users to prevent some abuse. On the other hand, the manifest v3 will not prevent extensions from being slow, or doing bad things. Extensions will still be able to use content-scripts, inject arbitrary content in pages or send any private data home. WebRequest listeners will also still be accessible (only not in blocking mode) which can allow any data collection.
So yes, I think these changes could in theory prevent some cases of abuse, but I strongly believe that they will overall weaken the privacy protection of users and that this is not an acceptable trade-offs.
To me this reaction from the Chromium devs is missing one of the most fundamental issues. I'm not fundamentally against the declarative API because of technical limitations; I am against it because it is a strong innovation lock. The current extension ecosystem is flexible enough to allow hundreds (maybe thousands) of people to actively work on privacy-enhancing extensions (ad-blockers, anti-tracking, etc.) and the technologies, heuristics, solutions to protect users' privacy on the Web are constantly evolving. The APIs are not used today the same way they were used 2 years ago. If Chrome decides to "freeze" the blocking capabilities of the browser into a declarative API that no one but Chrome devs can improve, they will be preventing people from finding new solutions to tracking and advertising (at least from extensions). It does not matter if they replicate 100% of the capabilities of today's ad-blockers, as long as it does not allow evolution and adaption it will become obsolete. There is precedent in this matter: Safari also has a similar API and it has been a huge pain for ad-blockers developers. The reason is simple: Apple or Google do not have the same strong intensives that we have to continuously improve the blocking capabilities of the user agent. My fear is that this declarative API will be an ok-replacement for today's content blockers, but will not allow the same kind of fast paced development we benefit from today in the space of privacy extensions.
Unfortunately, as you suggest, the complexity of arbitrary precision multiplication kicks in and performance suffers.
I understand that you are not competing with uBlock. But I’m always a bit sceptical when I read that it’s faster because it’s C++. Since it is not necessarily true and some measurement is needed before being able to reach this conclusion. I understand though that blocking from the network gives some (constant factor?) advantage compared to a JavaScript extension.
Did you run some comparison to back this? I would love to see some numbers.
From your perspective, how well do the most popular privacy-protection extensions protect us from the kind of PII leakage identified by Local Sheriff. And how could we improve those tools to increase the protection?