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.

Hit the damn monkey.

If you don't remember these ads from a few years ago, then my new banner will probably seem surrealist at best.

Just a bit of weekend fun.

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.

1.1 Release Ahead of Schedule

This is embarrassing. I was going to make a release with the new features discussed below this weekend, after more testing. But I just discovered a bug in my installer setup that didn't show itself on my dev machine (a missing dependency that I had on my dev machine because it's my dev machine). While this is alpha software, I feel pretty stupid having pushed out an MSI that didn't actually work, especially since I did at least do nominal dev testing on a second machine.

I've just put up a new build, sooner than expected, with the fix and the new features. I also put up the dev and release builds. The only difference is that the dev build will show asserts and exceptions and logs data (which elements were blocked or not blocked) to %TEMP%\Low\adblock.log. If you're interested in this sort of thing, try the dev build. If not, stick with the release.

(In the future, I'll provide a simpler way for getting those data, but I didn't want to hold this release up any longer due to the MSI bug.)

As always, thanks for your patience while I'm still in the apha stage, and use the Discussions page to let me know about any problems.

Planning

I wanted to give readers a feel for what I'm currently working on and where some of the more important work items stand. First off, I seem to have a working fix for the unfiltered-on-refresh issue (Work around DocumentComplete not firing on refresh), which basically involves filtering on every DownloadComplete event, and some associated jiggery-pokery.

These fixes also seem to provide a partial resolution to Fails to block Google Pageads on Gmail, though I'm getting inconsistent results with Gmail still. I'm investigating.

I've also significantly reworked the rule syntax, though preserved backwards compatibility, to allow per-site rules and filtering of specific page elements, including <div> tags (Add stylesheet class-based blocking; add per-domain rule specificity). In the process, I've switched from the .NET regex engine to a much simpler handwritten globbing engine (supporting only wildcard and single-character wildcard--i.e. * and ?--a la shell globbing). This is a little limiting, but it should provide sufficient expressiveness for most rules, is a lot closer to what most other ad filters (e.g. Adblock Pro) do, and is roughly 45 times faster than .NET's regex engine. When I have a new alpha ready, I'll be sure to post some sample rules here with an explanation of their function and how to do advanced stuff.

These changes, collectively, provide the core requirements for Implement NoScript-style JavaScript blocking, though to make it usable I really need a toolbar GUI (if script blocking is on by default, you really need an easy way to enable scripts for certain sites, other than hand-editing an XML file).

I have a bit of testing and debugging to do still before I'm ready to put up a new release, as well as some perf testing and some other business (e.g., I'd like to add a keyboard shortcut for "reload unfiltered"). But hopefully I'll have a new alpha build by this weekend or early next week with all the new features.