GlimmerBlocker is no longer maintained and should no longer be used as web sites have migrated from using plain http to using https (i.e. encrypted) which prohibits modification by a proxy unless you resort to install custom SSL certiticates on the client.

You should use a browser extension instead.

It was made as a hobby project during 2007-2008 by Peter Speck. It features both a custom http server and http client and a Mac OS X control panel.

GlimmerBlocker did not only block requests but also allowed for adding custom css and javascript to the pages. It also allowed for modification of the page html before the browser receives the html, which made some modifications much easier than DOM based modifications.

Asked questions

Safari keyword expansions don't work anymore

Apple has upgraded Safari in Mac OS X 10.8.2 so it performs Google searches using SSL (https) and this makes it impossible for GlimmerBlocker to intercept the searches and perform keyword expansions.

However, there is a Safari extension which provides the same functionality: KeySearch by Matt Swain.

My company proxy needs a password

Use Authoxy (it's free). In GlimmerBlocker's network tab, set the proxy to Authoxy's port number.
The request flow is then: Safari → GB → Authoxy → CompanyProxy → Website.

Ads has reappeared

When you install GlimmerBlocker it sets the proxy configuration for the network interfaces. If you later add another interface (e.g. 3G wireless) the proxy settings then GlimmerBlocker can't automatically update the network settings as it runs with reduced permissions to enhance security. You can fix the proxy settings by opening the GlimmerBlocker System Preferences Panel, choosing the "Network" tab, and click "Update Now" in the "Network proxy settings" section.

Keywords searches with special characters fail

That keywords work at all is because Safari sends the invalid URL-hostnames to GlimmerBlocker (spaces is not an allowed character in hostnames), but when the hostname contain a quote, Safari gives this message before even contacting GlimmerBlocker. So GlimmerBlocker can't fix it. The only solution is to petition Apple to include proper keyword search in Safari.

Ads on https pages are not blocked

When Safari fetches an https page using a proxy, it doesn't really use the http protocol, but makes a tunneled tcp connection so Safari receives the encrypted bytes. The advantage is that any intermediate proxies can't modify or read the contents of the page, nor the URL. The disadvantage is, that GlimmerBlocker can't modify the content. Even if GlimmerBlocker tried to work as a middleman and decoded/encoded the content, it would have no means of telling Safari to trust it, nor to tell Safari if the websites certificate is valid, so Safari would think you have visited a dubious website.

Fortunately, most ad-providers are not going to switch to https as serving pages using https are much slower and would have a huge processing overhead on the ad-providers servers.

Bulletin board

Very much needed. I did start installing a Django based board, but was then completely drowned in work. This will come as soon as I get the time.

Why are settings in /Library/GlimmerBlocker?

The reason GlimmerBlocker stores its settings in /Library/GlimmerBlocker instead of /Library/Preferences/GlimmerBlocker is that /Library/Preferences is writeable by users who is allowed to administer the mac, even when they have not authenticated. The files in /Library/GlimmerBlocker can only be changed when the user has authenticated.

Adblock Plus rules

Please send me the URL of sites which has ads that the current included filters doesn't block. This will improve GlimmerBlocker for everybody, including those that doesn't like the shotgun approach to blocking that the Adblock Plus rules use.

There are several problems with supporting Adblock Plus filters:

1. The file format is very badly documented. Even the writing filters document doesn't fully document the format.

2. There is no consideration for upgrade path. Old versions of Adblock Plus didn't support comments, and when they introduced comments, the old Adblock Plus read the comment lines as URLs to block. Their response was "chances of these rules actually matching anything are very low". If they add new features in the future, the current Adblock Plus still doesn't know how to skip those lines.

3. The Adblock Plus rules doesn't fit well into GlimmerBlocker design of filters. GlimmerBlocker is optimized for site-specific filters (and general ad-networks) and not for "block all URLs with this substring".

So I would have no standard to code against and Adblock Plus upgrades could easily break GlimmerBlocker; I would have to chase the tail of Adblock Plus whenever they ship a new version. In addition to this, I'll have tons of users complaining that GlimmerBlocker doesn't work; see all the comments on the Adblock Plus blog and in their bug database because the EasyList filters are overly broad and makes too many websites non-functional. For example, EasyList blocks all URLs which contains "/rotation/*.php?" which easily can be used on many sites without being an ad.

So I'm very partial to ad support for it, and I'll much prefer if you notified me of non-blocked ads instead.

Old version for Tiger (10.4)

There have never existed a version of GlimmerBlocker which runs under OS X 10.4

The problem is that under the hood there is large differences between Tiger and Leopard (10.5). Leopard added a lot of functionality and fixed a lot of bugs; bugs that GlimmerBlocker would have to work around. So supporting Tiger would add a huge complexity in the System Preferences panel and in managing the proxy server. For the end-user, the difference between Tiger and Leopard might seem small, but it's huge for developers. I have only limited time and resources so I have to be very frugal with adding complexity to the code, and would rather use my resources for making an even better version for Leopard users.