Subject: Re: Reviving discussion on error code 451

From: Tim Bray <[email-masked]>
Date: Thu, 1 Jan 2015 13:42:45 -0800

On Fri, Dec 19, 2014 at 6:07 AM, <[email-masked]> wrote:

> Proposal (another one properly generalized)
> -------------------------------------------------
>
>  451 Forbidden by a third party human authority
>

​Clever, but it doesn’t meet the service providers’ needs.  They are OK
with mentioning that they got a legal demand, but they don’t want to admit
formally that they have been “forbidden” because that would weaken their
legal position if they decide to contest the demand.​

>
>   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)
>

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

---

From: Tim Bray <[email-masked]>
Date: Thu, 1 Jan 2015 13:41:06 -0800

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 <[email-masked]> 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" <[email-masked]> wrote:
>
>> Hi Greg,
>>
>> On Wed, Dec 31, 2014 at 01:06:35PM +0100, Greg Wilkins wrote:
>> > On 19 December 2014 at 15:07, <[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 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: Natasha Rooney <[email-masked]>
Date: Fri, 2 Jan 2015 01:28:54 +0000

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 | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>
Tokyo, Japan

From: Tim Bray <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 2, 2015 at 6:41
To: James M Snell <[email-masked]<mailto:[email-masked]>>
Cc: Willy Tarreau <[email-masked]<mailto:[email-masked]>>, Niels ten Oever <[email-masked]<mailto:[email-masked]>>, Mark Nottingham <[email-masked]<mailto:[email-masked]>>, Yoav Nir <[email-masked]<mailto:[email-masked]>>, Eliot Lear <[email-masked]<mailto:[email-masked]>>, Greg Wilkins <[email-masked]<mailto:[email-masked]>>, IETF HTTP WG <[email-masked]<mailto:[email-masked]>>, Nicolas Mailhot <[email-masked]<mailto:[email-masked]>>
Subject: Re: Reviving discussion on error code 451
Resent-From: IETF HTTP WG <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

On Wed, Dec 31, 2014 at 01:06:35PM +0100, Greg Wilkins wrote:
> On 19 December 2014 at 15:07, <[email-masked]<mailto:[email-masked]>> wrote:
>
> 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
>    - Forbidden for legal reasons: content is illegal so better get a lawyer
>    - Forbidden for legal reasons: order from a court in client jurisdiction
>    - Forbidden for legal reasons: we got a threatening letter from a lawyer
>    - 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
> 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

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.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Jan 2015 08:29:40 +0100

On 2015-01-01 22:41, Tim Bray wrote:
> “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”.
> ...

That's a bit misleading. "Server" is not the same thing as "Origin 
Server", so it includes intermediaries.

Best regards, Julian

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 5 Jan 2015 10:27:40 +0100

> Hi Greg,

Hello

>> fundamental problem with 451.

> which will give the exact reasons.

I think the main differences with 403 (and I tried to make it clear in my
proposal) are that :
1. 451 is about  *human* restrictions, which may or may not be lifted by
human action, and handling them must be done in the human sphere.
2. 451 is a third-party restriction: there's no point complaining to the
site operator, he has no power to change it

That's why I think the main point of the error code should not be to
distinguish between the various human reasons (there is an infinite
spectrum of such resons) but on making http tools convey the free-form
reason to the humans that can act on them

Best regards,

-- 
Nicolas Mailhot

---

From: Benjamin Carlyle <[email-masked]>
Date: Thu, 8 Jan 2015 17:19:24 +1000

I'm not sure it is necessary to call out policy or law in the description
of this response.

451 Forbidden by intermediary
The origin server MAY permit the request but an intermediary server refused
the request.
... preferably with a populated via header that ends in the intermediary
that forbids the request, or some other identifying information for the
intermediary.

The implication to be made implicitly or explicitly is that another
communication path may not refuse the request. In an office environment
this might mean that an employee may seek to access the content at home.

The key point intended in the response I think is to differentiate between
a request being refused by the owner of the resource or being refused by an
owner of the communication path. Stronger language than that could be seen
to be offering some kind of legal or policy advice. If the intermediary
does want to provide such advice it surely could do so in the response body.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 08 Jan 2015 10:33:10 +0100

Hi,

On 1/8/15 8:19 AM, Benjamin Carlyle wrote:
>
>
> On 2 Jan 2015 07:45, "Tim Bray" <[email-masked]
> <mailto:[email-masked]>> wrote:
> > On Fri, Dec 19, 2014 at 6:07 AM, <[email-masked]
> <mailto:[email-masked]>> wrote:
> >>
> > ​Clever, but it doesn’t meet the service providers’ needs.  They are
> OK with mentioning that they got a legal demand, but they don’t want
> to admit formally that they have been “forbidden” because that would
> weaken their legal position if they decide to contest the demand.​
>
> I'm not sure it is necessary to call out policy or law in the
> description of this response.
>
> The origin server MAY permit the request but an intermediary server
> refused the request.
> ... preferably with a populated via header that ends in the
> intermediary that forbids the request, or some other identifying
> information for the intermediary.
>

I think "Forbidden" is the very word that Tim is objecting to, and
introducing intermediaries into this seems to be missing the point. 
It's NOT that intermediaries are forbidding anything but that someone
somewhere has told the site owner that material should not be made
available.

> communication path may not refuse the request. In an office
> environment this might mean that an employee may seek to access the
> content at home.
>

That implication is already there.

> The key point intended in the response I think is to differentiate
> between a request being refused by the owner of the resource or being
> refused by an owner of the communication path. Stronger language than
> that could be seen to be offering some kind of legal or policy advice.
> If the intermediary does want to provide such advice it surely could
> do so in the response body.
>

Indicating is responding to a legal demand to me doesn't seem to be
advice to anyone, but rather an explanation, and the briefest one at that.

Let's also disentangle this just a bit.  There are two different issues:

  * Some legal demand, as Tim points out (like a DMCA takedown notice,
    or a government ordering a site to take down content); or
  * an intermediary network refusing to serve content, perhaps because
    the network owner has a policy against certain content, but this
    would have nothing to do with anything regarding legality.

These are distinct.  Do they need separate error codes?

Eliot

---

From: David Krauss <[email-masked]>
Date: Thu, 8 Jan 2015 21:36:09 +0800

> On 2015–01–08, at 5:33 PM, Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I think "Forbidden" is the very word that Tim is objecting to, and introducing intermediaries into this seems to be missing the point.  It's NOT that intermediaries are forbidding anything but that someone somewhere has told the site owner that material should not be made available.

The difference between the filter residing on the same server as the origin, or in a government facility, is minor.

If information is not allowed to get from the origin to a particular user, that can be generally modeled as the behavior of an intermediary.

> Some legal demand, as Tim points out (like a DMCA takedown notice, or a government ordering a site to take down content); or
These scenarios are more likely to result in 404 than 403.
> an intermediary network refusing to serve content, perhaps because the network owner has a policy against certain content, but this would have nothing to do with anything regarding legality.

Whether a filtering policy is codified in actual law is besides the point. (But they often are.)

I think the distinction of intermediary vs. origin is spot-on. User agents can use this to display different interfaces. Users deserve to know that they’re not dealing with the origin. Whether everyone will comply by opting-in to 451 is another story, but at least it’ll be there.

---

From: Tim Bray <[email-masked]>
Date: Thu, 8 Jan 2015 07:23:59 -0800

The Tor guys have also said that the blocked-by-origin vs
blocked-by-intermediary distinction is interesting to them.  And I’m not
deeply opposed to it.

But I wonder if there are even more subtle distinctions lurking in there,
I’m a little nervous about diverting attention away from where it should be
pointed, which is what the legal demand actually is.  Maybe one status code
is still the right thing, with explanations of the details of the blockage
implementation left for human-readable text in the message body.

There are a lot of other distinctions you could try to capture - civil vs
criminal law, intellectual property vs not, temporary vs permanent.dnd we
don’t want to go down the path of designing a universal taxonomy of
blocking scenarios.

On Thu, Jan 8, 2015 at 5:36 AM, David Krauss <[email-masked]> wrote:

>
> On 2015–01–08, at 5:33 PM, Eliot Lear <[email-masked]> wrote:
>
> introducing intermediaries into this seems to be missing the point.  It's
> NOT that intermediaries are forbidding anything but that someone somewhere
> has told the site owner that material should not be made available.
>
>
> The difference between the filter residing on the same server as the
> origin, or in a government facility, is minor.
>
> If information is not allowed to get from the origin to a particular user,
> that can be generally modeled as the behavior of an intermediary.
>
>    - Some legal demand, as Tim points out (like a DMCA takedown notice,
>    - an intermediary network refusing to serve content, perhaps because
>    the network owner has a policy against certain content, but this would have
>    nothing to do with anything regarding legality.
>
> I think the distinction of intermediary vs. origin is spot-on. User agents
> can use this to display different interfaces. Users deserve to know that
> they’re not dealing with the origin. Whether everyone will comply by
> opting-in to 451 is another story, but at least it’ll be there.
>

---

From: David Morris <[email-masked]>
Date: Thu, 8 Jan 2015 08:04:06 -0800 (PST)

I still like:

  451 Forbidden for Policy Reasons

but if 'Forbidden' is a concern then either
  451 Blocked for Policy Reasons
or
  451 Access Blocked for Policy Reasons

Any of these choices indicates access not allowed
for reasons other than the wishes of the content
owner.

On Thu, 8 Jan 2015, Eliot Lear wrote:

>       > ?Clever, but it doesn?t meet the service providers? needs.  They are OK
>       with mentioning that they got a legal demand, but they don?t want to
>       admit formally that they have been ?forbidden? because that would weaken
>       their legal position if they decide to contest the demand.?
>
> I think "Forbidden" is the very word that Tim is objecting to, and introducing
> intermediaries into this seems to be missing the point.  It's NOT that
> intermediaries are forbidding anything but that someone somewhere has told the
> site owner that material should not be made available.
>
>       between a request being refused by the owner of the resource or
>       being refused by an owner of the communication path. Stronger
>       language than that could be seen to be offering some kind of legal
>       or policy advice. If the intermediary does want to provide such
>       advice it surely could do so in the response body.
>
>
> Indicating is responding to a legal demand to me doesn't seem to be advice to
> anyone, but rather an explanation, and the briefest one at that.
>
>  *  Some legal demand, as Tim points out (like a DMCA takedown notice, or a
>     government ordering a site to take down content); or
>  *  an intermediary network refusing to serve content, perhaps because the
>     network owner has a policy against certain content, but this would have

---

From: Eliot Lear <[email-masked]>
Date: Thu, 08 Jan 2015 17:43:07 +0100

David,

>   451 Access Blocked for Policy Reasons

... so that what can be done?  "Policy reasons" could mean anything from
"the administrator is *required* to block the content" to "the
administrator *wants* to block the content".  My understanding, and
again, Tim should comment more is that he is aiming more toward the
former and not the latter.  That is- there is this component of
*external* demand.

I can see the value, by the way, in having that, although I am skeptical
about how useful it will be.  But I agree with Mark Nottingham.  If
others think it will be useful, please by all means let's go ahead.

Eliot