This site’s design is only visible in a graphical browser that supports web standards, but its content is accessible to any browser or Internet device. | WHY WE DO THIS


Dedicated to fed-up web developers:

The Browser Black List

An Active Tool to Affect change upon Browser Developers
A Proposal by Ross Olson
Circa 1998


The Browser Black List is a system that is designed for web developers as an active tool for promoting the use of 'good' browsers. Used properly, it could become a strong tool by which the web development community can actively effect change upon the the developers of future versions of web browsers.

The Browser Black List is an automated system by which web sites can deny access to specific web browsers (based on the USER-AGENT environment variable) that have been 'black listed' by a vote of the web developer community. Through the use of a central database, an update mechanism, and a browser detection system, web sites will have the ability to deny access to browsers that have been deemed, non-standards compliant, unsafe, buggy, or unsupported due to beta versioning.

Limited to 20 browsers, the black list will focus on new browsers that have not yet reached the 'average user'. Beta versions, buggy browsers and non-compliant browsers will be identified and user forwarded to a site that will explain why they are unable to reach the content that they wish to view.

Let me re-iterate the previous statement: This is for beta versions and newly released browsers only! The sins of a developer should not be paid for by the hapless 'user'.

The System

To facilitate the implementation of the Black List mechanism, let me break the system down into three parts: The filter, the listing update, and the voting/explanation site.

The Filter

The Filter system is a platform-specific implementation. Any programmable platform that can read a local text file and compare each line to an incoming USER-AGENT variable. Such a filter could easily be implemented as a CGI or an included 'mod' module in Apache, as as 'asp' or Active Server Page script for IIS, or through other methods. A JavaScript-based version may even be developed.

As this is a server-side deployment, an appropriate error code should be made available for servers to return to blacklisted browsers. I propose that the code 506 be designated as "506 Browser Version Not Supported". This proposed error is modeled on error "505 HTTP Version Not Supported" from section 10.5.6 of the HTTP/1.1 specification.

10.5.7 506 Browser Version Not Supported
The server does not support, or refuses to support, the browser version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other browsers are supported by that server.

Browsers should be presented with a page that explains why their request was not fulfilled, and have to option of re-directed them to a more in-depth explanation page at the Central Site.

The Listing Update

On a weekly basis, servers will be directed to retrieve the latest version of the Browser black list from a central server. The file will be plain text file that will relate the following items:

In the future, this may be deployed as an XML-based document.

The Central Voting/Explanation Site

A central server will be dedicated to the fulfillment of two rolls: voting for the members of the black list, plus distribution of the list. The site will have pages that provide:

The server that will provide this site will likely have to be located at a location that is close to a major backbone, due to the expected high volume of requests that will be fulfilled.


With the current state of affairs at the beginning of 1999, the Web is a morass of buggy, unstable, and down right dangerous browser software. This software takes it's toll on both the the web developer and the web browser, but has little direct impact on the software developer. The Browser Black List provides a mechanism by which the web development community can have a strong vote, a loud voice, on the development of new browsers. The system outlined here would essentially give the web development community the ability to tell software developers when We believe that their browsers are ready to be released to the public. The Browser Black List is a unified voice, a tool for building a better Web.

Moving Forward

If you have comments, offers to help build the system, or any kind of feedback, feel free to contact me.