Re: Reviving discussion on error code 451

Hi Niels,

CC:ing Tim to make sure he sees this.

> On 17 Dec 2014, at 12:05 am, Niels ten Oever <lists@digitaldissidents.org> wrote:
> 
> Hi all,
> 
> I would like to revive the discussion around error code 451 [0].

I've been thinking about this as well, and talking to a few people, including some Web hosts that are considering using it.


> There have been objections raised that this error code would not be
> suitable because it would solely be an error code for a
> user-understandable condition.

The main objection was that there wasn't a case for making this distinction as a status code -- i.e., HTTP machinery (whether it be a cache, a user-agent, a proxy, a spider, etc.) should be able to make use of it.


> Transparency is crucial when it comes to blocking, since it would
> allow the user to understand why the site blocked , and it would
> encourage courts (or other relevant entities) to publish the blocking
> orders.
> 
> Furthermore error code 451 could also trigger a client to establish a
> connection to the website via a VPN or Tor so that the website could
> still be accessed. This would provide for automated processing in
> response to this error code (even though I think we should not mention
> this is in the draft since it might hamper adoption).

I think the cat is out of the bag :)

I also don't think that the network case is terribly compelling -- if you switch a VPN on when you see this status code, censors will learn to block or modify the status code very quickly.

However, the use case that seems more interesting is a Web site hosting content for others -- e.g., Google, Twitter, Facebook, Github -- who is forced to censor content. Giving them a status code that communicates "I've been legally required not to send this content" would allow this content to be found automatically, thereby making censorship more apparent and accountable.

Also, this use doesn't appear to have incentives that are misaligned, like the VPN case; the most a censor could do would be to legally compel a host not to use a particular status code, and that would be pretty apparent (presumably, there'd be a pretty big fuss).

As I mentioned above, I'm hearing from various folks they'd be interested in producing and consuming this status code. So, once things settle down a bit, I'm planning on doing a call for adoption of Tim's draft -- feel free to discuss beforehand, of course, I just want to get a few things off of the WG's plate first.

Cheers,


> Article19 (and others such as the Open Rights Group) would also be
> interested to push for the adoption of this error code once it would
> become a standard.
> 
> Looking forward to discuss.
> 
> Best,
> 
> Niels
> 
> 
> [0]
> http://www.tbray.org/tmp/draft-ietf-tbray-http-legally-restricted-status-05.html
> 
> --
> Niels ten Oever
> Head of Digital
> 
> Article 19
> www.article19.org
> 
> PGP fingerprint    8D9F C567 BEE4 A431 56C4
>                    678B 08B5 A0F2 636D 68E9
> 
> 

--
Mark Nottingham   https://www.mnot.net/