Replace filtering engine with httpSwitchboard's

[franzone]

The Chrome extension httpSwitchboard claims to be faster and less memory consuming than AdBlockPlus. More about here:

​https://github.com/gorhill/httpswitchboard/wiki/Net-request-filtering:-overview#abp-filtering

Their UI sucks though.

So let's replace AdBlockPlus' code for parsing and enforcing ABP filter syntax with the backend of httpSwitchboard.

[mapx]

they are also talking about blocking inline javascript
​https://github.com/gorhill/httpswitchboard/wiki/Blocking-javascript-execution-reliably-in-Chromium-based-browsers

[trev]

Rejecting: replacing one code base by another one is usually a very bad idea. Their code base might (might!) be better than ours in some respects but it certainly has issues of its own. Code maintainability is a very obvious one, there are also quite certainly inconsistencies in their implementation. Finally, missing features are an issue - their bad UI partly stems from the underlying core being unable to support anything more complicated (filter groups, hit statistics etc.).

This doesn't mean that we cannot learn from each other. If there is some particular approach that is better in httpSwitchboard - I'll be happy to consider implementing it in Adblock Plus.

[sebastian]

You have to be careful when comparing HTTPSB to Adblock Plus. Note that HTTPSB only implements a subset of Adblock Plus filtering. They don't support element hiding, which is one of the main causes for the high memory consumption when using Adblock Plus. Neither do they support popup blocking.

Also HTTPSB doesn't keep track of the frame hierarchy, which adds some overhead when processing requests and matching exception rules, but is required to enable recursive whitelisting in Adblock Plus.

Also HTTPBS is closer tied to Chrome's extension API, while Adblock Plus has to use some abstraction in order to support multiple browsers, which also adds some overhead.

As trev said, there still might be some parts where we can learn from HTTPSB. But the main reason that it is faster and uses less memory is that HTTPSB is less powerful.

[franzone]

The developer of httpSwitchboard, gorhill, when I asked him about this thread via email, responded with the following:

For net requests, I personally rather stick with HTTPSB, if only because
it offers full disclosure about where web pages try to connect (and full
easy control). In the end, both can be used, I do not try to discourage
this.

I just benchmark the performance. I wanted numbers and people do
whatever they want with my findings (which others my want to reproduce
to be sure). It's purely technical curiosity driving me, not trying to
sell something.

Now regarding these benchmarks:

When I load EasyList+EasyPrivacy, HTTPSB recognizes 99.7% of *net
request-based* ABP filters (I consider popup and element hiding filters
a cosmetic thing, not related to net request (I am concerned they even
might give a false sense of security).

Informed consent/dissent is the primary purpose I set for HTTPSB, not
hiding from view stuff which has already left a footprint somewhere on
the net. This cosmetic aspect I see it more as a separate, specialized
(and optimized for this *one* purpose) extension.

In any case, my benchmarks focus on where they intersect, and note that
in my benchmarks I went out of my way to try to make ABP look good, and
HTTPSB look bad, i.e.:

• There was no element hiding filters used for ABP

• I did disable acceptable ads for ABP (meaning less filters to process)

• I did *not* disable default matrix rules (60,000 of them currently) in

HTTPSB (so results for HTTPSB include that extra overhead)

If I were to benchmark with a more apples-vs-apples approach, I expect
the results would look much worst for ABP -- not loading, and not
testing every single URL against 60,000 extra filters would undoubtedly
reduce HTTPSB's CPU and memory footprint.

Now, a key measurement with regard to net requests and ABP filters: ABP
tests over 120 filters per URL, while HTTPSB tests 8 filters per URL.

Consequence, to mitigate, ABP slapped a cache mechanism on top which
adds significantly to memory footprint. I think that's the biggest
improvement they could get, is how they generate a hash key from their
filters in order to obtain a better dictionary layout, and thus reduce
the number of tests per URL -- that was one of the key breakthrough in
HTTPSB with regard to process efficiently ABP filters.

I did not understand the comment "doesn't keep track of the frame
hierarchy ... is required to enable recursive whitelisting". Not sure
what they are referring to, so I can't tell whether I agree or disagree
for that part.

[franzone]

Meanwhile, gorhill (the developer of httpSwitchboard) has published another addon, that more directly competes with ABP: uBlock. It not only runs on Chrome, but also on Firefox and Safari.

​https://github.com/gorhill/uBlock

Can you evalute uBlock's engine? It's clear that it's based on httpSwitchboard's, and it would be interesting if the features that were missing in httpSwitchboard's engine when you evaluated it, are still missing in uBlock.