Back in 2012, following on work by others, I submitted an Internet-draft proposing a new HTTP status code, 451, to signal legal blockage. As of today, the latest draft is a work item of the Hypertext Transfer Protocol Working Group of the IETF. Doesn’t mean its future is clear, but I’m still happy. I’m posting here to focus on one particular turn of phrase, and to ask for a specific flavor of feedback.
The blog post linked in the first sentence gives the history, and a prettified version of the latest draft is here.
Process · The HTTP WG having adopted it just means that they’ll think about it. They might choose not to take it forward. They might change it to something unrecognizable. It’s the nature of the IETF that what comes out of the process is different (usually better) than what went in. If it does progress, there’s now way to predict when that might happen.
An appeal for help · Mark Nottingham, the chair of the WG, has offered the opinion that if they want to improve the draft, a good thing to do would be to ask for opinion from people who are either using it already, or want to. Which sounds smart to me.
So if you’re one of those people, could you please get in touch with me or Mark or (better) just climb on the WG mailing list, and offer your input? Thanks in advance.
Legal advice · There’s one piece of wording in the draft that is subtle and deserves highlighting. That’s the phrase “legal demand”, which appears repeatedly; here’s one example: “This status code indicates that the server is denying access to the resource as a consequence of a legal demand.”
IANAL, we say, for “I am not a lawyer”, and indeed I’m not, but I consulted one. In particular, while I was working at Google I got some time with one of the policy-oriented legal pros to talk over the status code 451 idea. She didn’t really have an opinion whether this was something Google cared about, but she had specific advice.
Earlier drafts had talked about “legal obstacles” and complying with them. That could be a big problem, because lots of times, a site operator might get a legal demand, and not be convinced that the demand is fair or even legally sound, but still decide to go along with it; maybe while they’re fighting it in court. So they’re not going to want to use anything that suggests they agree; the code just asserts that there was a legal demand and they decided not to serve the data.
What should happen · I think the IETF should improve the doc and publish it as an RFC. Because one characteristic of a well-designed system is that it emits helpful, accurate diagnostics when a problem occurs. Legal demands are increasingly, a common problem impeding the flow of data on the Internet, and it deserves its own diagnostic already.
What shouldn’t happen · The number-one thing that could go wrong is that the Working Group decides to get ambitious and fine-tune the language. There’ve already been suggestions that we should distinguish between civil and criminal law, between IPR and not-IPR, and hey, why don’t we construct a universal taxonomy of the structure of legal obstacles faced by Internet publishers… on that path lies madness. And months of wrangling, leading inevitably to failure. So let’s not do that.
Thanks · To mnot and the WG people who were (quite appropriately, I think) dubious about this idea for a while, but have now decided it’s at least worth kicking around. And also to the people out there who’ve already started using 451. That’s how the Internet gets smoother and better.
Contributions
Comment feed for ongoing:
From: Graham Klyne (Apr 25 2015, at 23:34)
I've always liked this idea. I did once see a 451 in the wild for what did not appear to be a legal reason. Reading your blog I wondered if there could be conflict with NSA letters. Which leads me to suggest that, rather than fine tuning, to turn the dial in the other direction and replace "legal" with "administrative". Just a thought.
[link]
From: Joe (Apr 26 2015, at 09:13)
Legal demand sounds good... lawyers would probably say something of the effect "this resource has been modified or removed due to ongoing legal process"
to the previous commentor: a National Security Letter (NSL) is a gagged request for customer information... not anything that would require an intermediary to modify or remove something.
[link]
From: Eli (Apr 27 2015, at 08:52)
I like this idea. At a greater level of content granularity, I think it would be useful to have some way to mark redaction in HTML. None of these things will fully expose the extent of the chilling effects of various kinds of legal restrictions (since the most common form of self-censorship will still be not to publish at all), but anything that increases the visibility here is useful.
[link]
From: Tim (but not _the_ Tim) (Apr 29 2015, at 21:59)
I agree with leaving it as 'Legal Demand' and not trying to provide all of the possible reasons; if a site wants to provide that information they should provide a URL that would invoke a "451 explainer" when passed the original URL. So, if a 451 is returned, I can just accept that it's a legal demand, or (possibly a browser option could prompt for this) I could decide I really want to know and invoke the explainer... if I get a 404 from the explainer then the site decided (or was told) that I didn't need to know.
[link]
From: Ben Henick (May 08 2015, at 21:14)
Add my voice to those who believe the particulars should be few, simple, and unambiguous. "We were told by a constituted authority that we shouldn't let you have this thing, so for now we're not. The End."
Eli's comment about redaction vs. HTML is deserving of consideration, but IMO not worth the hassle of implementation when you get right down to it. The del element in tandem with a reference note is adequate to many cases; for the others I would compound that with inserting a hash (generated from a random source) in place of the redacted cleartext, maybe with color and background-color set identically, and don't forget the ARIA rules, etc.
If you've redacted something because you don't want people to see the content, then you need (is_hidden && is_unreadable), as opposed to a correction, which needs to satisfy (is_replaced && was_mistake).
An affirmation of absence is an affirmative in any event.
[link]