Re: Reviving discussion on error code 451

FWIW I can get some idea on how some mobile operators may feel about this within the next few weeks – might provide some good support for this, maybe not. I like the idea though – allowing users to understand why content has not been displayed to them should give them the understanding as to who to complain to or how to change that particular policy if necessary. I’ll get back to the list with any findings.

Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com<mailto:nrooney@gsma.com> | +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org<mailto:nrooney@gsm.org>
Tokyo, Japan


From: Tim Bray <tbray@textuality.com<mailto:tbray@textuality.com>>
Date: Friday, January 2, 2015 at 6:41
To: James M Snell <jasnell@gmail.com<mailto:jasnell@gmail.com>>
Cc: Willy Tarreau <w@1wt.eu<mailto:w@1wt.eu>>, Niels ten Oever <lists@digitaldissidents.org<mailto:lists@digitaldissidents.org>>, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>>, Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>>, Eliot Lear <lear@cisco.com<mailto:lear@cisco.com>>, Greg Wilkins <gregw@intalio.com<mailto:gregw@intalio.com>>, IETF HTTP WG <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>, Nicolas Mailhot <nicolas.mailhot@laposte.net<mailto:nicolas.mailhot@laposte.net>>
Subject: Re: Reviving discussion on error code 451
Resent-From: IETF HTTP WG <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Resent-Date: Friday, January 2, 2015 at 6:42

There are a variety of arguments why 403 is a bad choice. To start with, the RFC [https://tools.ietf.org/html/rfc7231#section-6.5.3] says 403 “indicates that the server understood the request but refuses to authorize it.” In fact, if an ISP is under legal pressure, it’s quite likely the server never got the request, so 403 is just wrong.  There’s another less-formal issue in that 403 is regarded by many practitioners as “what happens when you respond to a 401 but the server doesn’t like the response”.

Another argument is the one I mentioned earlier, in that service providers who’ve received a legal demand may wish to refuse service without officially agreeing that the demand is in fact legally justified.  451 addresses that clearly and the word “FORBIDDEN” is unattractive in that context.

But anyhow, I’m with mnot on this one.  If there are service providers who say they would like to have a status code to signal a situation that they say is real and significant to them, and there’s little ambiguity about when to use it (”I received a legal demand”), then I think the WG needs to find a really good reason to say “no”.

451 isn't ubiquitous but it is in production here and there, I'll send some pointers to the WG in a bit.

On Wed, Dec 31, 2014 at 6:12 AM, James M Snell <jasnell@gmail.com<mailto:jasnell@gmail.com>> 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.

On Dec 31, 2014 6:00 AM, "Willy Tarreau" <w@1wt.eu<mailto:w@1wt.eu>> wrote:
Hi Greg,

On Wed, Dec 31, 2014 at 01:06:35PM +0100, Greg Wilkins wrote:
> On 19 December 2014 at 15:07, <nicolas.mailhot@laposte.net<mailto:nicolas.mailhot@laposte.net>> wrote:
>
> >  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.

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





--
- Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.