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.

The request & response flow: How GlimmerBlocker works

This page documents how requests and responses flow thru GlimmerBlocker. It starts with a simplistic description which is then extended bit by bit to the complete description.

Extremly simplified flow

This is what happends with most requests/responses: those that are not blocked or modified.

1. Safari sends the request to GlimmerBlocker
2. ..GlimmerBlocker sends the request to the web-server.
3. ..The web-server sends the response to GlimmerBlocker.
4. GlimmerBlocker sends the response to Safari.

To speed up the response, the last two steps are performed concurrently, i.e. the response is streamed. GlimmerBlocker doesn't wait until it has received all of the response before it starts sending it back to Safari. Each time GlimmerBlocker has received a bunch of bytes, they are transmitted back to Safari. So the steps are really:

1. Safari sends the request to GlimmerBlocker
2. ..GlimmerBlocker sends the request to the web-server.
3. The web-server sends the response to GlimmerBlocker, which streams it back to Safari.

Filter Rules

When GlimmerBlocker has received a request, if finds all the matching rules and sorts them by priority.

Assuming the first rule is a "whitelist URL" rule (which doesn't want to modify content), the above list of steps is extended to:

1. Safari sends the request to GlimmerBlocker
2. ..GlimmerBlocker finds all rules that match the URL and sorts them by priority.
3. ..GlimmerBlocker gets a "whitelist URL" rule.
4. ..GlimmerBlocker sends the request to the web-server.
5. The web-server sends the response to GlimmerBlocker, which streams it back to Safari.

Blocking ads by URL

When the first rule has action = block, the steps are:

1. Safari sends the request to GlimmerBlocker
2. ..GlimmerBlocker finds all rules that match the URL and sorts them by priority.
3. ..GlimmerBlocker gets a "block URL" rule.
4. GlimmerBlocker sends back a transparent 1*1 pixel gif as response to Safari

The processing of the request is stopped at this place and the web-server is never contacted. For Safari, it seems like e.g. "doubleclick.net" always sends 1*1 pixel gifs no matter what the URL-path is.

Modifying responses

When the first rule wants to modify the content, e.g. adding a bit of css:

1. Safari sends the request to GlimmerBlocker
2. ..GlimmerBlocker finds all rules that match the URL and sorts them by priority.
3. ..GlimmerBlocker gets a "modify content" rule.
4. ..GlimmerBlocker sends the request to the web-server.
5. ..The web-server sends the response to GlimmerBlocker, which buffers all of the response (i.e. no streaming).
6. GlimmerBlocker executes the transformation javascripts and adds css/javascript snippes.
7. GlimmerBlocker sends the modified response to Safari.

Modifying requests

The request rules can send back some fixed response, change the url, specify some request-specific dns server or proxy. The request-rule javascripts are executed by GlimmerBlocker (not by Safari) before the web-server is contacted (if at all).

Sending back a fixed response:

1. Safari sends the request to GlimmerBlocker
2. GlimmerBlocker executes the script in the first matching request rule.
3. The rule sets the global t variable to e.g. "<script>window.close();</script>"
4. GlimmerBlocker sends this as the response to Safari.

Changing the URL: redirects

1. Safari sends the request for "http://www.nokia.com" to GlimmerBlocker
2. GlimmerBlocker executes the script in the first matching request rule.
3. The rule executes gb.response.sendRedirect("http://www.apple.com/iphone");
4. GlimmerBlocker sends a redirect-response back to Safari.

Safari will then fetch the Apple page using another request. This can be useful for sites which splits up articles into a gazillion pages and where you want to automatically redirect to the "single page" or print-friendly version.

Changing the URL: concealed/hidden

1. Safari sends the request for "http://www.nokia.com" to GlimmerBlocker
2. GlimmerBlocker executes the script in the first matching request rule.
3. The rule sets the gb.request.url variable to e.g. "http://www.apple.com/iphone"
4. GlimmerBlocker sends the request to Apple's web-server.
5. Apple's web-server sends the response to GlimmerBlocker, which streams it back to Safari.

In this case, Safari still thinks the page has an address of www.nokia.com, it doesn't know that the page was fetched from Apple. It is not a redirect!

Changing the dns server:

1. Safari sends the request for "http://www.apple.com" to GlimmerBlocker
2. GlimmerBlocker executes the script in the first matching request rule.
3. The rule sets the gb.network.dnsServers variable to e.g. "208.67.222.222"
4. GlimmerBlocker uses this dns server to resolve "www.apple.com"
5. GlimmerBlocker sends the request to web-server.
6. The web-server sends the response to GlimmerBlocker, which streams it back to Safari.

Changing the proxy server:

1. Safari sends the request for "http://www.apple.com" to GlimmerBlocker
2. GlimmerBlocker executes the script in the first matching request rule.
3. The rule sets the gb.network.httpProxy variable to e.g. "proxy.example.com"
4. GlimmerBlocker sends the request to the proxy-server.
5. The proxy-server forwards the request to the web-server, which contacts the web-server.
6. The proxy sends the response to GlimmerBlocker, which streams it back to Safari.

When a request rule changes the proxy or dns server, the change is request-specific, i.e. it doesn't "hang on" to the following requests.

Useful links

1. The object reference
2. Proxies
3. Transformation of responses