Is Adblock Plus for Chrome (formerly AdThwart) superior...

[lewisje]

...to Michael Gundlach's AdBlock for Chrome (which has been ported to Safari)?

Is it more efficient at parsing the filter lists, or perhaps it somehow overcame the difficulty highlighted in this issue, which has caused Gundlach's extension to sometimes fail to block content (on Chrome, not Safari)?

I ask this mainly because of your motivation for taking up the project, Wladimir Palant; it seems as if you decided the time had come to move on to other browsers and then saw the creator of AdThwart struggling to find the time to keep developing his extension.
Then again you might just make this extension superior if it isn't already, much as you turned the original AdBlock for Firefox (which like Gundlach's early versions could only hide content rather than blocking it, albeit more due to the incompetence of the original developer than any limitations of the platform) into the veritable security/speed/annoyance-blocking powerhouse of Adblock Plus.

Oh, on a side note, are there any plans to port this to Safari? Gundlach developed a porting library that may prove useful (although it may need more work, because so far it is merely sufficient to port Gundlach's own extension).

[vasa1]

I'm really happy to hear the news.

I took it for a test run today on my internet banking site because of the https factor. The content blocker that I've been using so far with Chrome has been Privoxy which does not handle https. I'm happy to say that not just display but the download of unnecessary images could be effectively blocked.

After a little bit of poking around for an .ini file, I actually looked at the options and found the way to refine rules by editing raw text and including wildcards!

Incidentally, I'm on Chrome 10.0.612.1 (Official Build 69289) dev.

[Wladimir Palant]

@lewisje: Don't expect wonders. Performance-wise the main limiting factor is Chrome itself - its extensions API imposes quite severe limits on ad blocking efficiency. People say that AdThwart is faster than Michael Gundlach's Adblock but given that I am only familiar with the former I can neither confirm that nor do I know what the reason is if that's true.

My main short-term goal is making Adblock Plus for Chrome fully compatible with Adblock Plus for Firefox, especially by reusing the same code. Unfortunately, all existing ad blocking projects only claim compatibility but use different approaches for many important details. This makes filter lists (which are built with Adblock Plus for Firefox in mind) less efficient than they could be, it also causes some issues that could be easily avoided (e.g. filter subscriptions that don't get updated any more).

The mid-term goal is a better and more powerful user interface. Both Adblock and AdThwart assume that you want to stick with pre-made lists and never want to add filters on your own. Adding your own filters is possible but significantly harder than necessary - so nobody will really want to do it. That's not really an acceptable situation for us, we want people to contribute back to the filter lists occasionally. A user base that will only consume the work of a handful volunteers isn't a viable way.

And there is a long-term goal as well of course: improve Chrome and make sure it is a better platform for us. I already made my first contribution yesterday by moving WebKit bug 45586 forward which is really crippling for any ad blocking extension. I hope that this bug will be fixed now.

[Wladimir Palant]

Oh, on a side note, are there any plans to port this to Safari?

Yes, my blog post actually mentioned that. I would guess that we will first get Adblock Plus for Chrome into a state where we are reasonably happy with it (3-4 months?) and then create a Safari port. The extension systems for the two browsers are similar enough that it shouldn't be a big problem.

[ttjoseph]

@lewisje: Don't expect wonders. Performance-wise the main limiting factor is Chrome itself - its extensions API imposes quite severe limits on ad blocking efficiency.

(I'm Tom Joseph.) In particular, Chrome's extensions API is not synchronous. This means essentially that the backend filter engine, when queried about a page resource, cannot return an answer in time (or in the appropriate execution context) to actually block the loading of that resource. IIRC (and maybe things changed since the last time I looked), Gundlach's solution was to load the entire backend filter engine into each loaded webpage to avoid using Chrome's extension message-passing system. This allows more complete blocking but it is apparently slow.

In AdThwart/ABPC, there are only a few simple filters cached in each page, covering a substantial portion of ads without having to query the backend. The rest of the ads are either hidden from the start of page loading by CSS rules or else removed after they are loaded. IMHO this provides a better user experience.

Notably, as Wladimir mentioned, Safari's extensions API is very similar to Chrome's. The most interesting difference is that Apple added a synchronous message passing API. Their developer documentation even gave an example of how to write an ad blocker using it!

Also, Chrome does not allow for blocking requests made by page objects (e.g. Flash) as Firefox does, which is why blocking ads inside Flash videos is often impossible. YouTube only works because we can rewrite the flashvars parameter, which specifies the ads shown in a given video. If Google cared enough they could "fix" that.

[lewisje]

I think this has already been suggested, but is one of the planned user-interface changes going to be registration of the abp: pseudo-protocol, so that the various subscription links actually work, or is it not possible for a Chrome extension to do that?

Also thanks for the technical overview Mr. Joseph; it sounds like a user should pick AdThwart if the primary goal is speedier Web browsing or AdBlock if the primary goal is to keep out potential malvertising, although both extensions help to achieve both goals.

[Wladimir Palant]

but is one of the planned user-interface changes going to be registration of the abp: pseudo-protocol

Of course. That's actually one of the easier things to implement (once we have more code from Adblock Plus/Firefox on the backend side).

In AdThwart/ABPC, there are only a few simple filters cached in each page, covering a substantial portion of ads without having to query the backend. The rest of the ads are either hidden from the start of page loading by CSS rules or else removed after they are loaded. IMHO this provides a better user experience.

Yes, that's most likely the reason why AdThwart is faster. However, I think that we can still improve here. Tom, I didn't discuss this idea with you yet - I consider passing the matcher data to the content script. Currently this is complicated because the matcher references filter objects directly, I want to change it to reference filter text only (needed for Firefox as well to allow caching matcher data between browser starts). The content script would only create filter objects for potential matches, that should keep the performance impact minimal. On the other hand, this will allow blocking downloads instead of hiding on far more occasions.

[tiik]

I think adthwart uses:
1. beforeload on major adservers
2. onload css hides some elements
3. onload js removes elements(hidden by css)
4. afterload adfilter helper

* all filters are used(not necessary)
* plugin data, such as flash and jre, can never be touched. (inherent from webkit engine)

is it possible to use beforeload more often?

ideally,
1. extract needed filters by domain from filter pools
2. try to apply filters using beforeload (please focus on this.)
3. onload css hides some elements (can do 4. first)
4. onload js removes elements(hidden by css)
5. afterload adfilter helper

* this is the fastest blocking mechanism now for chrome8.
* please update jquery ui after.

[Wladimir Palant]

is it possible to use beforeload more often?

Yes, see my post above yours.

[anonymoose]

Give us back our devil icon The only reason I used AdThwart over the old AdBlock Plus was because of it D:

Seriously, the stop sign icon is lame and SCARY. The little devil was cute. Just look at all the comments on the extension page, the people have spoken.

Expand the idea too, if you want. A targeting reticle is a good idea for adblock on. Maybe a radar. Perhaps hold a contest, but please oh please, give us back the little devil.

[dariop]

I Prefer the DEVIL, probably will change to another blocker soon (because of the icon).

[fanboy]

Code: Select all

// We've gotten rid of Fanboy's list, so migrate those users to EasyList
    if(filterFilesEnabled["fanboy"] == true) {
        filterFilesEnabled["easylist"] = true;
        delete filterFilesEnabled["fanboy"];
        localStorage["filterFilesEnabled"] = JSON.stringify(filterFilesEnabled);
    }


Definetly no love shown

[MRMe]

omg people cant be happy we finally all got ABP+ for chrome and everyone screams about a icon i like it myself please dont change it on the account of people complaining about it. its the signature mark of adblock + .

[halfbacked]

they killed fanboy list

[ttjoseph]

Code: Select all

// We've gotten rid of Fanboy's list, so migrate those users to EasyList
    if(filterFilesEnabled["fanboy"] == true) {
        filterFilesEnabled["easylist"] = true;
        delete filterFilesEnabled["fanboy"];
        localStorage["filterFilesEnabled"] = JSON.stringify(filterFilesEnabled);
    }


Definetly no love shown

Fanboy, that was from quite a while ago. Some of your filters slowed down Chrome quite a bit. Not your fault, it was a WebKit/Chrome issue. So I auto-migrated those users away because they were complaining.

In the current version, nothing prevents users from pasting in the URL to subscribe. It's Wladimir's decision whether to reintroduce your list into the Options page.