HTTP 451: status code for censorship proposed

Most Internet users are familiar with the Hypertext Transfer Protocol (HTTP) status codes that tell users that something went wrong.  When it comes to ISP or government-initiated filtering, however, the existing codes are uninformative.

The 4xx class of codes signal when the end user has apparently made some mistake.  For example, the familiar code 404 Not Found, indicates that the server could be reached but that the server couldn’t locate the URL that the user entered.  In other words, 404 suggests that the user put in the wrong address.  Similarly, 403 Forbidden indicates that the server could be reached but is refusing to comply with the user’s request, presumably because they are trying to reach something they should not.  Terence Eden recently argued that using a 403 code is inappropriate for censorship, because in cases of censorship, the user is not making an error.  Additionally, Eden points out that in many instances of filtering, the server never even sees the request.

Despite the inapplicability of the 403 code to filtering, some ISPs have been using it for exactly that situation.  After the UK High Court ordered UK ISPs to block The Pirate Bay, some started using the 403 status code when users attempted to reach the site.

The lack of a censorship status code has been debated at least since 2008.  However, in the wake of the UK filtering and Eden’s discussion of potential status codes, the debate has taken on new life of late.

On Monday, the debate moved out of the theoretical world when Google employee Tim Bray submitted a proposal to create a status code specifically for censorship.  Bray submitted an Internet Draft (I-D) to the Internet Engineering Task Force (IETF), proposing HTTP  451 Unavailable for Legal Reasons.  With a nod to Ray Bradbury’s famous book about censorship, Fahrenheit 451, this new code aims to increase transparency for both web operators and users.

The proposal describes the code in the follow manner:

451 Unavailable For Legal Reasons 
This status code indicates that the server is subject to legal restrictions which prevent it servicing the request.
Since such restrictions typically apply to all operators in a legal jurisdiction, the server in question may or may not be an origin server. The restrictions typically most directly affect the operations of ISPs and search engines.
Responses using this status code SHOULD include an explanation, in the response body, of the details of the legal restriction; which legal authority is imposing it, and what class of resources it applies to.

In theory such a code could potentially provide new levels of transparency, but in practice it is unclear how frequently it would actually be used if approved by the IETF.  While the UK ISPs might be willing to use it because their filtering is compelled by a court order and was highly publicized, it is easy to think of many authorities that would not want to advertise their filtering.  Bray notes as much, stating that “it is imaginable that certain legal authorities may wish to avoid transparency, and not only forbid access to certain resources, but also disclosure that the restriction exists.”  Nevertheless, having the option available for additional transparency is useful even if few take advantage.

Regardless of how effective code 451 might be, for ISPs to use it, the IETF must first approve the draft.  For an independently submitted Internet Draft to become an IETF standard, the draft must be reviewed and edited by a number of sources.  After submission, an Internet Draft is open for community review and feedback for a period between two weeks and six months.  After the comment period, a request for consideration for publication will be sent to the RFC Editor, where the document will be checked for compliance with all IETF standards and regulations.  The RFC Editor, the author, and any other necessary reviewers will discuss necessary changes; “consensus followed by document revision is the desired outcome.” The RFC Editor has ultimate authority on publication, but “in the absence of some unusual circumstance, a preponderance of favorable reviews should lead to publication.”

Details of the full process can be found in RTC 4846.