Why 451? | Hacker News Reader

Why 451?

mnot.net

245 pointstemp51 comments

I wonder about the applicability of this status code to 'friendly' blocking. In my workplace, as in many others, we have a web proxy that blocks certain requests for security or policy reasons. I would like it if the vendor implemented something like this for its capture page, as it'd make it easier to identify where requests are blocked and why in various logs. In particular, user-agents could tell the user when a request is blocked for this reason, which would be more robust than the HTML message it returns and would make help-desk operations a lot easier - "this thing doesn't work and I get a browser notice about blocking," instead of "this thing doesn't work" and then having to dig through logs.

Just a thought about applications for this beyond the obvious (but less common in the US) state censorship - it can be seen as a technical help for making sure security and policy controls are clearly communicated to machines as well as people, which makes it easier to figure out when those controls are overbroad.

Sounds like you need to switch to a different proxy vendor. The one I'm familiar creates a log with a specific policy deny status message, and other information about the request to help determine why it was blocked, like the categories it's classified under. It also provides the user with a block message, listing the site's categories.

There's also no need for them to actually use status 451 for a feature like that.

I think OPs point was not the proxy but the integration of the client. If your browser gets a 451, it can (theoretically) give a better error message.

Not every resource is HTML; this would work for images, XHR, etc too.

No amount of changing proxy servers will help you with that.

> It is possible that certain legal authorities might wish to avoid transparency, and not only demand the restriction of access to certain resources, but also avoid disclosing that the demand was made.

Speaking of "transparency" why is the political explanation for this absent? Are they trying to say current events and political opinions of authors didn't play a role in this? The code number obviously wasn't chosen for purely logical reasons.

Because, as you say, it's obvious - the code number communicates the political opinion that censorship is wrong, or at least a dangerous tool whose use should be highlighted wherever it occurs. People who hold the reverse opinion that censorship is just fine and authorities should feel free to make casual use of it whenever in their sole judgment there is justification for doing so, probably aren't going to be convinced by appending an argument to this announcement.

It's also possible that a site may misleadingly return 451 codes to indicate that they've been censored when perhaps they haven't, maybe in order to inflame a discussion or some other political maneuvering. So, not only can you not trust that a missing 451 means no censorship, you also can't trust that a present 451 means there is censorship.

Great idea but the 'Fahrenheit 451' allusion is against the HTTP spec. 400-499 is for client errors. A client requesting a resource from site that can't show it for legal reasons is not the client's fault.

It could be that the client is in a location where showing it is against censorship laws. In this case, the client is at fault.

Agreed. I think this would often be the case for returning a 451 as well.

Yes, they even talk about recommending to the user to use Onion instead, so that's definitely a case they are considering.

In particular, just as the body of a 404 or 403 response can provide information to the client about how to make the request successfully (e.g. "did you mean one of these?" or "you need to log in", respectively), the body of a 451 response could suggest what the client could do to make the request successfully (e.g. "please try again from a less broken jurisdiction or over a more secure path").

I think it's appropriate for the context. In an Orwellian society, of course it's the user who is at fault for requesting something they "shouldn't"...

RFC 2616 describes the 4xx error codes as “Client Error - The request contains bad syntax or cannot be fulfilled.”

In other words, the error has to do with the client’s request but it's not necessarily the client’s fault. For a similar example see the response code “410 Gone”:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10...

RFC2616 is obsolete, see http://httpwg.github.io/specs/rfc7231.html (and friends, as referenced).

This is a better link: https://tools.ietf.org/html/rfc7231

The IETF's HTML RFC generator makes really nice documents.

I'm sorry, you just broke my sarcasm detector :)

FWIW, the RFC Editor is working on modernising the RFC format -- we'll even have non-ASCII characters soon!

https://www.rfc-editor.org/rse/format-faq/

I expect that your sarcasm detector was already broken.

The IETF generator links to plain-text and PDF versions of the RFC, diffs between the current version and previous versions of the document, errata applicable to the RFC, and uses a fixed-width font. These are all nice properties.

Formatting output for specific presentation devices (78 char wide screens) requiring a Chrome extension or a PDF for readability isn't my personal idea of 'nice'.

Over the years, I've come to understand that -once you surpass the "comprehensibility/legibility" threshold- "readability" is no less subjective than "beauty", "pleasantness", or "good music".

So. I'm glad that you're not in charge of the IETF's HTML RFC output. :)

As the article notes, this is often replacing cases where a 403 error would instead be served.

This is because censorship is almost never global—instead, it's because something about your request (often, your country of origin) forbids you from receiving it.

In that context, 451 makes perfect sense.

That seems less likely to arise in practice, though. A server should only respect such requests from a jurisdiction that can threaten the server; thus, "we can't serve you this because your jurisdiction forbids it (but ours doesn't)" should almost never arise. The only potentially useful case there seems like "if we didn't remove this, your jurisdiction would block our entire site, eliminating the opportunity for us to tell you what has gone wrong and how to fix it".

"We can't serve you this because our jurisdiction forbids it" seems likely to arise more often.

That said, I also don't think the 4xx/5xx distinction matters as much here as the evocative implication of using 451 specifically.

> "we can't serve you this because your jurisdiction forbids it (but ours doesn't)" should almost never arise.

Uh, it happens all the time. In fact, it's by far the most frequent kind of censorship.

From TFA:

- https://en.wikipedia.org/wiki/Censorship_of_Facebook

- https://en.wikipedia.org/wiki/Censorship_by_Google

- https://en.wikipedia.org/wiki/Censorship_of_Twitter

Most major web services are based in a country with relatively lax censorship laws but still comply with censorship laws in other jurisdictions.

While this happens all the time, I would argue that it is not a good use case for HTTP 451. A better approach would be to just serve the content. If a country wants to censor your content they can do it the hard way. Don't help the bad guys.

> I would argue that it is not a good use case for HTTP 451

What is a good use case for HTTP 451 then?

Rarely does the calculus favor getting your entire site blocked because you refuse to censor one piece of content. At least by serving HTTP 451 you could also potentially offer suggestions like using Tor.

If you don't play along, the bad guys will block your whole site.

Nor it is server's fault. Do we have http status code group for reality flaws?

Status code ranges are less about fault than they are about determining whether the client can retry the request without changing it.

5xx means that the client can, because there's a chance repeating the request will succeed. 4xx means the client shouldn't, because it needs to change in some fashion before it will work.

This is so that clients that don't understand a specific status code can fall back to the more generic x00 code and still behave sensibly.

I think that in practice 4xx is (and ought to be) any error other than a fatal server side error.

I really dislike it when, e.g., Ruby HTTP client libraries treat any non 2xx-3xx response as an exception.

If I'm wrong about this usage, like, say I have a REST endpoint that, when the client doesn't send bad data, but a request fails for some reason (upstream service rejected request), what kind of code is my endpoint supposed to return?

(I would say 4xx, and leave it at that, getting rid of the "client" part of "client error", and leaving 5xx for something like ISE, fatal error "maybe ain't your fault, or at all under your control, client-man!" But I'm happy to learn more.)

Can't site operators also receive gag orders that forbid them from disclosing that they are being censored, in which case they aren't even allowed to use the 451 code, which defeats the purpose of the code?

403s are often used in place of 404s. This is even allowed by the spec. That doesn't mean 404 if worthless.

Regarding 403 instead of 404: I'd suggest rather that 403 doesn't reveal information on whether the page exists (for those who may not have permission to access).

While you are correct, you can use the stock behavior of most web servers like Apache or IIS to evade this attempt at misinformation and learn whether something really exists or not.

Lets say /admin/ is a directory that exists on the site, but I am not authorized to access it. So site returns a 403 or, if you are sneaky and don't want to reveal the existence /admin/ to unauthorized users, you configured the server to return 404.

Go ahead a send a GET request for just /admin without the trailing slash. Assuming there isn't actually a file named "admin" and admin is actually a directory, by default most versions of Apache/IIS will return a 302 direct to /admin/. This reveals the existence of the directory, regardless of what status code you get when fetching /admin/.

I'm not sure the exactly why web servers behave this way. My educated guess is that when Apache/IIS service the request, they see the named entity is actually a directory, so there is no content to return. So they redirect you into the directory, so that either the directory contents can be displayed, or a default document can be sent instead.

Years ago, I worked on a web brute forcer which used this method to detect the existence of directories. The advantage is slightly more limited now with the rise of MVC where the entire path of a URL doesn't directly map to a file system path.

Exactly.

In neither case is 404 or 451 pointless just because 403 is sometimes used to restrict access to that information.

FTA:

> In some jurisdictions, I suspect that censorious governments will disallow the use of 451, to hide what they're doing. We can't stop that (of course), but if your government does that, it sends a strong message to you as a citizen about what their intent is. That's worth knowing about, I think.

Yes, and from what I've gathered (IANAL), many fear that judges would not look kindly on things that do not specifically leak "gagged" information, but go against the spirit of gag orders (i.e. warrant canaries). The IETF's "permission" certainly doesn't supercede state or federal governments. So in practice this status code is cute, but it won't move the needle on reining in state censorship any more than before.

Exactly - judges generally don't look kindly at "technicalities"[1] and creative interpretations that are obviously created to work around a judicial order.

Often, when legal issues are discussed on places like HN some people will jump at some obvious trick to bypass the order (such as using status code 451). There is a good chance that a judge will simply say you knew the gag order forbid you from telling anyone you have a gag order, sending code 451 explicitly tells people about the gag order, so enjoy your contempt of court penalties.

The traditional warrant canaries are a genius work around as it relies upon the person potentially being gaged actively taking an action (it's a dead-man trigger). In theory, it's a lot harder to make someone lie and forge new warrant canaries as part of a gag order. Following the order and doing nothing sends the message.

There is a time and place for challenging or evading legal requirements, but it's a dangerous game to play and only with good legal advice.

[1] One exception might be legal technicalities where you can show precedent. It will probably still piss off the judge, but there is at least reasonable chance of such a technicality-based argument will work. As usual, YMMV, see a real lawyer.

You can read the original HN discussion from 2012 at https://news.ycombinator.com/item?id=4099751

(I had a small hand in creating this RFC.)

I'd love to see a Firefox add-on or Chrome extension that automatically reissues the request through a proxy (such as Tor) if the response code is 451. Change proxies and repeat until a non-451 response is received.

This probably won't work in China, but it could be useful in countries with only mild censorship, such as "right to be forgotten", porn filters, and region-locked content.

4xx errors are supposed to be client-side errors. 5xx is server-side. The purpose of the code doesn't match the spec.

Imagine a company breaks a relationship with a supplier, to then banish reference of the former supplier from the website - on strict orders from the supplier. Just to show them that orders have been followed I could set the offending pages to return 451, as an in joke rather than 301 to the home page (or even 404 which would mean they stay longer in the search results, hence 301).

Due to idiots like myself I think that signal to noise on this could be high. In other circumstances, and 'for a laugh' I could make some expired pages return 451 just to bring the novelty value of this new status code to a colleague, then forget about it and leave some URLs out there in cyberspace, forgotten about but returning 451.

Then this censorship crawler comes along, finds we have 451s for some internal joke reason (and maybe a former supplier) to not get the joke (as it is only a bot). Would the bot's owner then add an uptick in the censorship 'figures'?

I don't understand why there is a controversy at all here. This seems to at least have a logical use case, which is more than we can say for status code 418 (https://tools.ietf.org/html/rfc2324)

418 is a historical joke, so it doesn't really need a logical use case (ideally, it should be handle the way joke PEPs are handled).

451 is a technical "solution" to a political problem - you can toss logic and reason right out the window due to politics.

I wonder if China will be one of the jurisdictions to forbid the use of this status code?

I like the idea of a legal response code, but is just one granular enough?

Likely there should be:

* censorship * rights * private * right to be forgotten * geo-limited.

I think one response code is sufficient (more specific explanation of the problem is an appropriate use for the response body.)

the body section of the article is blank on chrome 47, even highlighting the text doesn't render it

Link isn't working for me anymore?

Sorry about that, the parent Apache process SEGV'd (running the experimental mod_http2). Should be back up now, having fun with the coredump now.

I'd definitely read a writeup of debugging Apache2.

Your ISP is just pre-emptively 451ing you. -[</s>]- </badjoke>

Reply on news.ycombinator.com