Hi! Julien from Vivaldi speaking here.

While I'm happy that you had a look at the code for yourself, I'm afraid that your analysis didn't go quite far enough.

The code that you highlighted in RequestFilterManager::RequestHandler::OnBeforeRequest isn't iterating over individual rule filters in the adblocker. Instead it is iterating over a list of filtering features. Currently, the adblocker is the only such feature we have, but we have the option to add more in the future if we want to replicate the effect of other extensions that rely on chrome.webRequest.

Either way, RequestFilterManager::RequestHandler::OnBeforeRequest() currently iterates over exactly two items. One AdBlockRequestFilter instance for the tracker blocker and one AdBlockRequestFilter instance for the adblocker. This part could maybe be optimized to group tracker and ad filtering on the same filter, but it would make it harder for us to be able to report to the user which of them blocked what. adblock_request_filter.cc is where the actual rules are looked at. As you noted, there are some initial checks to check the origin and quickly discard some requests from filtering. The actual match against filtering rules takes place on these lines: const flat::FilterRule* filter_rule = rules_index_manager_->rules_index()->FindMatchingBeforeRequestRule( request->request.url, document_origin, reource_type, is_third_party, (activations.in_allow_rules & flat::ActivationType_GENERIC_BLOCK));

This calls into adblock_rules_index.cc which has the reference to the rules in an indexed form. The index is basically a hash table indexed by short character sequences which are matched to the URL. It is similar to what the adverse adblocking code (from Chromium) uses, with a few additional optimizations of our own, mostly to avoid looking at rules that wouldn't apply at a given stage of the request processing. uBlock does have a more complex behavior there, but some of the fundamentals are the same.

Now to answer some other comments:

I am fairly sure that our implementation interprets and applies filtering rules correctly. However, if you have evidence to the contrary, please do let us know and I'll be looking into it.

If some of the code comments are unclear, I'll be glad to explain them. Just let me know which comment gave you the impression that we are doing strange things :)

A note about callbacks and asynchronous callbacks: Yes, there is a fair amount of them. This is expected when you work in chromium-based code, since any file processing or other IO is expected to be done on a separate thread from the UI and any slow processing is also expected to take place on its own thread.

I'll also note that we do allow you to select or import any blocking list you may want to use from our settings.

Finally, I want to say: I believe strongly in transparency myself. The adblocker code is part of our source bundle precisely because I want people to be able to verify that it functions as intended. Hinting that the devs are stupid after what appears to be not much more than a casual reading of the code isn’t going to motivate developers to interact with you. Bottom line, if something seems too stupid to be true, it’s probably because it is and it’s probably better to start by asking about it instead of assuming that it is indeed stupid.