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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.