Subject: Re: Reviving discussion on error code 451

From: [email-masked]
Date: Fri, 19 Dec 2014 15:07:46 +0100 (CET)

Proposal (another one properly generalized)
-------------------------------------------------

 451 Forbidden by a third party human authority

  The 451 (Forbidden by a third party human authority) status code indicates 
  that the equipment understood the request but is forbidden to fulfil it
  by a third party human authority. 

  The error code does not distinguish between the various reasons human
  authorities  may forbid a request. Those reasons can not be addressed 
  by automated processing.

  Responses using this status code SHOULD include an explanation, in the
  response body, of the details of the restriction: the human third party
  authority imposing the restriction, its given reasons, and the eventual
  actions humans MAY perform in response to the restriction. The web client
  SHOULD relay this explanation and inform its human operators in the most
  appropriate and effective way.

  For example:

  (example response from draft)

  If authentication credentials were provided in the request, the
  equipment considers them insufficient to overcome the restrictions. 
  The client SHOULD NOT automatically repeat the request with the same
  credentials. The client MAY repeat the request with new or different
  credentials. However, the request might be forbidden for reasons 
  unrelated to the credentials.

  If authentication credentials were not provided in the request, and
  it could have been authorized with some credentials, the equipment
  SHOULD use the appropriate code to request authentication (for example 
  511, Network Authentication Required). The 451 status code MUST NOT be 
  used to trigger authentications.

  The use of the 451 status code does not imply that the equipment will be
  able to fulfil the request once the human third party restrictions have
  been lifted. Most equipments will defer technical processing after checking 
  if they are authorized to perform it. Therefore, technical problems MAY only
  be identified once the restriction is lifted.

--------------------------------------------------------------------

(Not sure if "forbidden because we have detected malware" fits in there.
Probably yes, deciding not to test the client security with malware is 
a human decision)

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 31 Dec 2014 13:06:35 +0100

>  451 Forbidden by a third party human authority

The suggestion of various names for this code illustrate to me the
fundamental problem with 451.    Essentially this code is trying to add a
"why" or  "by whom" information to a 403 response and there are an infinite
number of such codes as there are an infinite number of situations that may
cause a forbidden response:

   - Forbidden for legal reasons: content is illegal so better get a lawyer
   son, better make it a good one
   - Forbidden for legal reasons: order from a court in the server
   jurisdiction
   - Forbidden for legal reasons: order from a court in client jurisdiction
   - Forbidden for legal reasons: we got a threatening letter from a lawyer
   and just don't want to be involved.
   - Forbidden for legal reasons: we don't know if you are over 18 or not.
   - Forbidden for political reasons: the thought police will be visiting
   your house soon
   - Forbidden for commercial reasons: we'd really like to sell our
   services to somebody that does not want you to see this content
   - Forbidden by a policy you set: Ask your mother if you can see this
   content

Fundamentally the content is forbidden and there are infinite shades of
grey between absolute legal prohibition and rather not serve it just in
case, plus there are extra dimensions of wont server it to you  and wont
server it to where you are.

Perhaps there is some benefit to following Willy's suggestion of trying to
find 3 or so classifications of why something is being forbidden, but I'm
dubious that a clean and useful classifications exists.      Why not just
define a new response header that can carry extra information about the
reasons for a 403?   Such a header could encode detailed information
regarding if the reason is legal, policy and/or precautionary, if it
because of clients jurisdiction, the servers jurisdiction or the user
identity etc.

regards

-- 
Greg Wilkins <[email-masked]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 31 Dec 2014 14:55:27 +0100

Hi Greg,

> because of clients jurisdiction, the servers jurisdiction or the user

I absolutely agree. And your examples above are the perfect illustration
of this. After all, the reasons all start by "Forbidden" which is exactly
403. No need for an extra code here, let's just normalize a header field
which will give the exact reasons.

So that's a big +1 from me.

Best regards,
Willy

---

From: James M Snell <[email-masked]>
Date: Wed, 31 Dec 2014 06:12:21 -0800

+1. 403 would seem to cover it well. The specific reason for the 403 may
make for a moderately interesting discussion topic for someone but it's
still just a 403. Not as "cool" as 451, but it's suitable.

---

From: David Morris <[email-masked]>
Date: Wed, 31 Dec 2014 08:16:55 -0800 (PST)

451 Forbidden for Policy Reasons

Covers all the cases but distinguishes itself from 403.

And add an optional new header for details ... since it surely will need
to be parsable to give end user value, we can now spend our effort
designing at least the structure of the value.

Given that 451 is already in use based on earlier reports, I think it
better at least document usage.

I also dislike adding a new header association with an existing response
code.

On Wed, 31 Dec 2014, James M Snell wrote:

>
> +1. 403 would seem to cover it well. The specific reason for the 403 may make for a moderately interesting discussion topic for someone but it's still just a 403. Not as "cool" as 451, but it's suitable.
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 31 Dec 2014 11:55:08 -0500

Hi Greg,

> On 31 Dec 2014, at 7:06 am, Greg Wilkins <[email-masked]> wrote:
> 
> 
> The suggestion of various names for this code illustrate to me the fundamental problem with 451.    Essentially this code is trying to add a "why" or  "by whom" information to a 403 response and there are an infinite number of such codes as there are an infinite number of situations that may cause a forbidden response:
> 	• Forbidden for legal reasons: content is illegal so better get a lawyer son, better make it a good one
> 	• Forbidden for legal reasons: order from a court in the server jurisdiction
> 	• Forbidden for legal reasons: order from a court in client jurisdiction
> 	• Forbidden for legal reasons: we got a threatening letter from a lawyer and just don't want to be involved.
> 	• Forbidden for legal reasons: we don't know if you are over 18 or not.
> 	• Forbidden for political reasons: the thought police will be visiting your house soon
> 	• Forbidden for commercial reasons: we'd really like to sell our services to somebody that does not want you to see this content
> 	• Forbidden by a policy you set: Ask your mother if you can see this content
> Fundamentally the content is forbidden and there are infinite shades of grey between absolute legal prohibition and rather not serve it just in case, plus there are extra dimensions of wont server it to you  and wont server it to where you are.
> 
> Perhaps there is some benefit to following Willy's suggestion of trying to find 3 or so classifications of why something is being forbidden, but I'm dubious that a clean and useful classifications exists.      Why not just define a new response header that can carry extra information about the reasons for a 403?   Such a header could encode detailed information regarding if the reason is legal, policy and/or precautionary, if it because of clients jurisdiction, the servers jurisdiction or the user identity etc.

I’m on the fence about 451 (whereas last year I was pretty firmly against it).

However, this doesn’t seem like a good argument against 451 — we could always construct arguments against a new protocol element this way. Enumerating the theoretical list of things that people *could* want to communicate is fundamentally uninteresting.

To me, the question is whether people will find the semantics of *this* status code useful enough — both as a server and a client — to get wide deployment.

For example, 429 (Too Many Requests) arguably could have been a 403 with a HTTP header; we went with a status code because there was clearly enough support for a more unambiguous semantic signal — even overcoming Twitter’s natural affinity for 420.

Likewise with many of the 4xx and 5xx series status codes; arguably many of them are purely explanatory, with minimal impact upon protocol mechanics.

So, what I’m looking for is effectively a big enough market for this. We’ve already heard at least one party say that they want to spider the Web for these things; what I’m waiting to hear is whether anyone else has serious plans, and whether any Web sites are considering producing the status code.

Because that’s somewhat of a chicken-and-egg problem (and the people who might want to express and/or consume these semantics are NOT likely to be here), I’ve started to privately ask around Web sites — especially those that “host” content for others — to see if there’s interest; so far, I’ve seen a non-trivial amount. I’m going to be encouraging those folks to participate here (or at least allow their interest to be registered publicly) in the New Year, so that we can make a decision that’s more informed.

OTOH if we can’t find a substantial audience for this, I agree it’s probably not justified. 

Cheers,

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