Scratch that.

Call my last post a case of irrational exuberance. I recall now that I had looked at BeginNavigate2 before, too. It only fires for documents, not for images and embeds.

So I can't do all the fancy prefiltering I described in the last post. Nevermind.

Upcoming release

"Release early; release often."

I know I just pushed up 1.2, but I just realized I could hook the BeforeNavigate2 event and pre-filter downloads from blocked URLs before the download even begins. This should presumably save bandwidth, and stops blocked images/scripts from even loading (avoiding that momentary flicker on the screen).

It also, in my highly unscientific tests, seems to be faster.

There is a downside. In this event, I don't know

a) the type of the thing being downloaded (image, flash, etc)
b) the hosting site

This breaks some of the specificity of our rules, though I don't think that specificity is really used. But it means that if you had:

http://bad/
http://bad/

then downloads to http://bad/, even from site "exception," would be blocked. This is counter to the defined semantics.

So I think I'm going to break the rule semantics a bit for the next release, which will be coming shortly. I have to think about this a bit more--and look at what other adblockers do--before I figure out the right approach.

Bleeding Edge: Try a new, comprehensive ruleset

I haven't yet gotten around to writing a converter for Adblock Plus's filter rule lists (which is slightly complicated by the fact that we don't have a complete 1:1 mapping between our respective functionality, though it is close), but in the meantime, I spent a couple of minutes to create a host-based filter ruleset from the list at yoyo.org.

If you want to try this rather large rule file (nb: this many rules may degrade AdblockIE's performance), you can download it from . You should then copy this file to C:\Program Files\af0.net\AdblockIE\blacklist.xml (or wherever you installed AdblockIE to), overwriting the existing file. Reload IE and you're good to go.

Coming soon: An Adblock Plus-compatible importer.

A note on performance

In the 1.0 preview, AdblockIE ran most of the filtering asynchronously. That is, the webpage finished downloading, IE fired the "DocumentComplete" event, and AdblockIE spun off an asynchronous delegate to filter the DOM. This meant that, depending on threading considerations, the page could be loaded for a few milliseconds before it got fully filtered.

In 1.1, I did away with this, for the simple reason that my limited perf tests showed no advantage to this approach.

But with Apple, Google, Mozilla, and Microsoft releasing browser benchmarks every other week, you might be wondering what effect AdblockIE has on browser performance. I did a little bit of testing with the PerfTest BHO that's checked into the AdblockIE source tree. Unfortunately, as is often the case with this sort of thing, the results are far from conclusive.

In most cases, AdblockIE seems to add at most a few hundred milliseconds to total page load time. That's within the same order of magnitude as conscious visual perception, so probably not something to be too worried about.

On the other hand, there are pathalogical cases where AdblockIE can significantly slow down a page's load time. The New York Times Article Skimmer prototype is one such case, seemingly due to the weird and complicated JavaScript on the page.

Obviously I'm looking into these cases, and keeping IE fast is a big concern for me. (Unfortunately, the DOM-based filtering approach--which enables the NoScript-style JavaScript blocking--is inherently less efficient than simply blocking downloads at the HTTP layer.) In my very limited tests on the current alpha, I haven't seen any huge perf problems, or anything that indicates that this will be an architectural issue with AdblockIE. But we'll have to see how it scales when the ruleset grows, and see how it holds up on other machines and under other users.