I'm still alive.

Yes, development has, of late, been slow. I've been occupied with other things (primarily my day job and--shameless plug--a little meta-search engine I wrote).

That doesn't mean I've abandoned the project, and I still welcome bug reports and feature requests, though you should expect slow responses on the latter.

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.

Errata

Apparently Codeplex doesn't update RSS feed items if they're changed. So, the new link for the comprehensive blacklist is here.

I hope.

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.

What to do if you find AdblockIE doesn't work

If AdblockIE isn't loading, it's probably due to this bug. Follow the instructions posted in the comments section for a (clumsy) workaround.

This should be fixed in the next version. See this thread for more information.

.NET 3.5 Requirement

Some people have asked about why AdblockIE requires .NET 3.5. The short answer is that I wrote this addin for my own use, on my own machine, and on my machine I already have .NET 3.5.

The more technical answer is that I made some very limited use of .NET 3.5-only technologies--specifically, XML Linq. This comprises a total of maybe thirty lines of code, however, so it should only take someone familar with C# half an hour or so to rewrite for .NET 2.0.

I'll happily take a submitted patch that renders this 2.0 compatible. I don't, however, plan to do this myself. The time I can devote to this project is currently very limited, and I'd rather spend it adding cool new features and making AdblockIE more fast and reliable rather than rewriting the parts that rely on .NET 3.5. That's why it's open source, however--because you can change the source, submit patches, or fork it into a whole new project that does what you want.