Subject: Re: Status code for censorship?

From: "Dereq Dereq" <[email-masked]>
Date: Tue, 10 Jul 2012 04:33:16 -0400

>The temptation to suggest 418 is strong, but 403 is essentially >correct. The entity making the authorization decision might not be >the usual or expected one, but that is the decision they are making. There are two general reasons to limit 403 to responses from the origin server. 1. As you say, the situation that you are discussing is not usual or expected. Hence it is more transparent and more helpful to highlight it explicitly. Some variation on the principle of least astonishment applies here. (For example, what if the end user getting the status code is the owner / operator of the origin server?) It is understood that in some jurisdictions use of a response code other than 403, or other than some other specified response code, may not be legal. It is also understood that some censoring entities will choose not to do the right thing. However the HTTP RFC should still specify what the correct behaviour is. If the law prevents some software from behaving correctly or some 
 other software chooses to behave incorrectly then so be it. There should still be a defined correct behaviour available for software that is willing and able to do so. That behaviour should be to be transparent about what has occurred. 451 is cute but I don't really care whether it's 451 or some other free 4xx code. 2. The actions that a user (or software) would take when 403 arises from the origin server and when censorship arises between an HTTP client and the origin server are quite different. When 403 arises from the origin server it is an indication that there is a fundamental difficulty with the request. The server that "owns" the resource is saying that it can't be accessed. The user may have to try e.g. different login credentials or e.g. contact the operator of the web server (if it's just a stuff up - or to be granted access). When censorship arises, the user will probably want to tunnel the request in some way but it is unlikely that either of the courses of actio
 n given as examples in the previous paragraph are going to make any difference.

---

From: "Dereq Dereq" <[email-masked]>
Date: Tue, 10 Jul 2012 07:13:37 -0400

>Thinking it over, the message is supposed to be sent to humans, not machines. So the correct thing would be to redirect to a
 >service-provider hosted page, that says what was blocked and why.
 The HTTP status codes are not really intended for humans.

 As internet censorship becomes more prevalent it will be important for software to be able to route around it automatically. A service-provider block page is not as useful for that purpose.

 We can't stop an ISP redirecting to a block page but that should not be the specified behaviour within the HTTP RFC.

 It is also possible to do both i.e. the HTTP response code is e.g. 451 but the response comes with an HTML body that is some kind of explanation, including a clickable link to additional information.

---

From: "Dereq Dereq" <[email-masked]>
Date: Tue, 10 Jul 2012 07:27:28 -0400

>the more I think 403 is just fine. Except for the basic problem of: whom are you going to complain to? There is nothing in the RFC that requires the response body to explain whether the problem is fundamental at the origin server or has been inserted by either an intermediate proxy server or some other device that is not a proxy server. Much better that the RFC requires this distinction at least to be expressed at its most basic level: was it censorship or is it a problem at the resource itself? It's similar to the age old "down for everyone or just me?" problem. Why would we want to contribute to that kind of confusion?

---

From: "Dereq Dereq" <[email-masked]>
Date: Tue, 10 Jul 2012 07:35:26 -0400

>Yes, but what incentives are there for censors to comply with its use? It depends on who is doing the censorship v. who wants the censorship done. In China or Iran or ... maybe the new status code wouldn't get used. In western democracies where ISPs are forced by government to censor, the ISP is more likely to want to be transparent about it - after all the ISP doesn't want to get thousands of extra support calls to its call centre - and even government may grudgingly accept the transparency of an explicit status code.