Subject: Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status

From: Alex Rousskov <[email-masked]>
Date: Thu, 1 Oct 2015 12:17:08 -0600

On 09/30/2015 11:33 PM, Mark Nottingham wrote:
>> On 1 Oct 2015, at 2:33 pm, Alex Rousskov wrote:
>> On 09/30/2015 06:59 PM, Mark Nottingham wrote:
>>> This is well-covered ground; the purpose of the status code is making
>>> it possible to track censorship and similar situations, when the
>>> party who is adhering to the legal demand wishes to say so.

>> For example, if I am censoring content (your use case!) based on my
>> religious believes, then I cannot use the proposed status code unless
>> some authority has also issued a "legal demand" for me to do so.
> 
> You misunderstand "my use case."  The introduction on the document says clearly:

Your use case was, and I quote, "making it possible to track censorship
and similar situations". The use case in the draft is a lot narrower. I
was talking about your use case (which I support), not the one in the
draft (which I find unnecessarily too narrow).

> You -- as a server operator -- imposing your beliefs upon the content
> being served doesn't qualify for 451 for exactly that reason; this
> status code is intended to capture cases when the server operator has
> been compelled to operate against their wishes by a legal demand, 

Yes, I understand that 451 *as proposed* would disqualify the use case
in the example. We need to find a balance between:

  1. Marking all censorship cases.
  2. Marking all censorship cases imposed by any external force.
  3. Marking censorship forced by an undefined term "legal demand".
  4. Marking censorship forced by some well-defined obstacle,
     one out of many such obstacles.

Needless to say, finding the right scope for the new status code is a
judgement call. IMHO, #1 and/or #2 deserve a dedicated HTTP status code
while #3 and #4 do not (for different reasons).

> not
> act as a barometer of what standards (religious, parental, whatever)
> are self-imposed by publishers around the world.

I agree that it makes sense to distinguish self-imposed and forced
censorship, and, given the apparent consensus around 451, we can focus
on the latter. My self-imposed censorship example was deficient in that
area. Sorry.

An *outside force* other than a "legal demand" may compel me to block a
resource. I speculate that most "blocked by external forces" content in
the world is blocked by external forces other than a specific "legal
demand". Should those who are forced to block by an external source

* block silently;
* violate the draft and misuse 451;
* reserve another status code for their broader(!) use case;

or should we allow them to use 451 because their use case (i.e.,
"something outside of my control is forcing me to block this") is common
and well-defined? I think we should.

> The feedback we overwhelmingly have from publishers and potential
> consumers are that the status code is useful at this granularity.

I do not think IETF should publish _protocols_ with undefined key terms,
even it that makes "publishers and potential consumers" happy. Making
the choir happy is essential but not sufficient, especially when it is a
relatively small choir.

> RFCs need to be sufficiently well-described to be interoperable; they
> don't need to defend their existence like an academic paper would.

The interoperability problems often stem from poor definitions. Your
"publishers and potential consumers" think they know what the extension
means because they have defined it or they trust your interpretation.
Those who add support for the extension in the future either need a
definition or at least an explicit disclosure that the term is left
undefined on purpose, allowing the sender and the recipient interpret it
differently.

As for justifying the existence, I hope that this WG and IETF in general
resists blessing RFCs that extend protocol without a good justification
(because there is a cost associated with every extension). In other
words, RFCs do not need this, but RFCs blessed by a WG and IETF probably do.

Cheers,

Alex.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 3 Oct 2015 20:23:19 +0200

Some feedback below:

> 1.  Introduction
>
> ...
>
>    Feedback should occur on the [email-masked] mailing list.

(This should go in the boilerplate, not the actual spec text; and yes, 
the RFC production center will catch it)

> 3.  451 Unavailable For Legal Reasons
>
> ...
>
>    The use of the 451 status code implies neither the existence nor non-
>    existence of the resource named in the request.  That is to say, it
>    is possible that if the legal demands were removed, a request for the
>    resource still might not succeed.
> ...

Might be good if we could avoid talking about existence or non-existence 
of resources.

> 4.  Identifying Blocking Entities
>
>    As noted above, when an attempt to access a resource fails with
>    status 451, the entity blocking access might or might not be the
>    origin server.  There are a variety of entities in the resource-
>    access path which could choose to deny access, for example ISPs,
>    cache providers, and DNS servers.
> ...

If the access was blocked on the DNS level, how would the status code work?

Also: the example should use the link header field.

> 5.  Security Considerations
>
> 5.1.  451 Unavailable for Legal Reasons
>
>    The 451 status code is optional; clients cannot rely upon its use.
>    It is possible that certain legal authorities might wish to avoid
>    transparency, and not only demand the restriction of access to
>    certain resources, but also avoid disclosing that the demand was
>    made.

1) We don't need a nested subsection here. 2) Avoid use of lowercased 
BCP14 terms...

> 6.  IANA Considerations
>
>    The HTTP Status Codes Registry should be updated with the following
>    entry:
>
>    o  Code: 451
>
>    o  Description: Unavailable for Legal Reasons
>
>    o  Specification: [ this document ]

We'll need the IANA considerations for the new link relation as well.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Oct 2015 11:30:45 +1100

I've raised the editorial bits as <https://github.com/httpwg/http-extensions/issues/102>.

Non-editorial feedback below:

On 4 Oct 2015, at 5:23 am, Julian Reschke <[email-masked]> wrote:

> Might be good if we could avoid talking about existence or non-existence of resources.

If you're saying that the language should align with that used for 404, I think that's reasonable:
  http://httpwg.github.io/specs/rfc7231.html#status.404
... however, that isn't terribly well-aligned with the definition of 410:
  http://httpwg.github.io/specs/rfc7231.html#status.410
so I'm not sure it's worth dwelling too closely on this.

> If the access was blocked on the DNS level, how would the status code work?

Presumably, by directing the client to a server that only returns 451s. 

Cheers,

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Oct 2015 11:33:55 +1100

Hi Amos,

I've raised the first issue here as:
  https://github.com/httpwg/http-extensions/issues/103

What do you (and others) think about Ted's suggestion?

The rest of it looks like editorial suggestions, so I'll leave them for Tim to take on board.

> On 30 Sep 2015, at 2:10 pm, Amos Jeffries <[email-masked]> wrote:
> 
> On 30/09/2015 4:29 p.m., Mark Nottingham wrote:
>> Everyone,
>> 
>> After talking with the editor and our AD, I think this document is ready to progress; the only remaining action on it is to add the registration template for the new link relation.
>> 
>> So, this is the announcement of WGLC for: 
>> https://tools.ietf.org/html/draft-ietf-httpbis-legally-restricted-status-02
>> 
>> Please review the document carefully, and comment on this list.
>> 
> 
> Section 1:
> 
> "for use when a server operator has a received a legal demand to deny
> access to a resource"
> 
> This is a lot more restrictive than what I understood was being agreed
> to. This phrasing implies that a specific-URL DMCA type notice is
> required before the status may be used.
> 
> It would be a lot more reasonable to also allow the status to be used
> when a blanket law requirement was levelled on the operator. For example
> schools following laws on porn fitering, or national level restrictions
> on categories of traffic. In cases like these operators dont receive
> per-resource demands, they often receive a one-off notice "law X applies
> to you" and are then expected to censor proactively to the best of their
> ability and face the court on overlooked URLs.
> 
> Probably this can be resolved with s/legal demand/legal requirement/.
> 
> There are other "legal demand" phrase uses elsewhere to keep in sync.
> 
> If "legal demand" is being used with a meaning other than a specific
> warrant DMCA takedown etc. Then that definitely needs to be explained.
> 
> 
> Section 1:
> 
> "This transparency s/may be/is/ beneficial"
> 
> How much benefit and in what ways is the questionable part IMHO. Not
> whether there is benefit.
> 
> 
> Section 4:
> "A human readable response body, as discussed above, is the appropriate
> location for discussion of administrative and policy issues."
> 
> This is specification document, not a discussion one. I suggest
> rephrasing along the lines of:
> 
> "A human readable response body, as defined above, is the appropriate
> location for text regarding administrative and policy issues."
> 
> and/or with a reference to section 3 instead of just "above".
> 
> 
> 
> Amos
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Oct 2015 11:41:22 +1100

Hi Alex,

> On 2 Oct 2015, at 4:17 am, Alex Rousskov <[email-masked]> wrote:
> 

I'm not hearing anyone else take up that position, and I'd note that we've already demonstrated consensus to adopt the document based upon #3.

> * reserve another status code for their broader(!) use case;

Surely that would be 403? Would it help to point this fallback out explicitly?

> and well-defined? I think we should.

[...]

> undefined on purpose, allowing the sender and the recipient interpret it

It does seem reasonable to note that the interpretation of the status code depends upon the context of the server generating it, and that the server SHOULD include as much detail as they can in the body.

We already have:

"""
Responses using this status code SHOULD include an explanation, in the response body, of the details of the legal demand: the party making it, the applicable legislation or regulation, and what classes of person and resource it applies to.
"""

So perhaps a sentence or two before that noting why this is -- i.e. that the legal context varies.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 12 Oct 2015 22:20:56 -0600

On 10/12/2015 06:41 PM, Mark Nottingham wrote:
>> On 2 Oct 2015, at 4:17 am, Alex Rousskov wrote:

> I'm not hearing anyone else take up that position, and I'd note that
> we've already demonstrated consensus to adopt the document based upon
> #3.

Yes, I acknowledge that during the WG Last Call, you should interpret
the lack of discussion about this issue as an "everything is fine"
feedback. I have nothing more of substance to add and rest my case. You
should stop reading now.

[ As for adoption, FWIW, I would have supported the adoption, but
suggested that the too-narrow scope should be adjusted. Perhaps that
would have been wrong, and you are not overreaching with the "adoption
implies agreement on scope" argument. ]

> Surely that would be 403? Would it help to point this fallback out explicitly?

No, 403 does not imply that I am being forced to block something by a
3rd party. 403 just "blocks silently", not addressing the use cases #1
and #2 in the numbered list at the top of this email.

> """ Responses using this status code SHOULD include an explanation,
> in the response body, of the details of the legal demand: the party
> making it, the applicable legislation or regulation, and what classes
> of person and resource it applies to. """

> that the legal context varies.

I do not think it would help unless you are willing to say that the
"legal context" varies so much that it may perfectly apply to blocking
reasons other than the undefined areas of "legal obstacles" and "legal
demands" :-).

Cheers,

Alex.

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 13 Oct 2015 15:58:13 +1000

On 13 October 2015 at 14:20, Alex Rousskov <[email-masked]
> wrote:

> ​[snip]​
​Sorry for chiming in cluelessly at this point, but how is 403 silent? RFC
7231 says a 403 can have a descriptive payload; and by stating that the
reason isn't necessarily auth-related and that you can use other mechanisms
to obscure access to resources it seems to imply that 403-with-payload is
intended to be explicitly not silent.

Or are you using 'silent' to mean "not easy to generate faceted
reports/statistics"? Because if so, while people clearly care about the
Ministry of Truth interfering with access to resources, at least in the
present climate, I don't know how much people care about other "outside
forces" blocking access. Is there much value in what you propose?

> reasons other than the undefined areas of "legal obstacles" and "legal
​If the obstacle or demand (explicit or implied) depends on a legal
context, is it not a legal obstacle/demand? I'm struggling to envision a
case of externally-pressured censorship that doesn't count as "legal." A
server operator who chooses not to serve content because it violates their
beliefs/ideals/etc. can just not serve that stuff. One who would otherwise
have done so, but doesn't because of external pressure... well, what does
that look like? Do they live in a highly Pastafarian region, and are afraid
of reprisal because of their insistence on using plastic colanders? Because
I think that's more of a case for a well-written 404 or 410.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 13 Oct 2015 20:24:26 +1300

> What do you (and others) think about Ted's suggestion?

Works far better than what was there before. If we cant get away from
the singular nature of "demand" this is at least a bit more flexible in
use-case coverage.

> The rest of it looks like editorial suggestions, so I'll leave them for Tim to take on board.

Ok.

Amos

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Oct 2015 09:27:04 -0600

On 10/12/2015 11:58 PM, Matthew Kerwin wrote:

> ​Sorry for chiming in cluelessly at this point, but how is 403 silent?

It is silent in the context of this discussion where the premise is that
403 is not sufficient to inform the recipient of the censorship. In
other words, 403 is presumed to be silent about the censorship, not
about the blocking. This is not my premise, this is the premise of the
draft. If you disagree with that premise, you should attack the draft,
rather than my failed attempts to allow the drafted mechanism to cover
more censorship scenarios.

> while people clearly care about the

If you assume that the "Ministry of Truth" is a well defined concept
that "people clearly care about" while "other outside forces" is not,
then my proposal adds no value, of course.

My assumption is that most people (in a non-US sense of the word, i.e.,
excluding corporations) can actually define "outside forces" and care
about them in general, rather than being interested in whether the
blocking company received a written DMCA takedown notice, was visited by
a friendly group of armed enforcers, or read an anonymous article in the
"official news paper".

> I'm struggling to envision a
> case of externally-pressured censorship that doesn't count as "legal."

Great, you should not object to removing the word "legal" from the draft
then. Saying "external censorship" should be sufficient. Why muddy the
waters by introducing precise-sounding but still undefined and very
context-dependent terms?

Cheers,

Alex.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 14 Oct 2015 06:48:02 +1000

> then my proposal adds no value, of course.

No, ​I'd say ​it's well *understood*, not necessarily well defined. Every
person, society, and culture has its own legal authority. It's the one with
the power to force things (like censorship) on people (and websites.)

> a friendly group of armed enforcers, or read an anonymous article in the

So it's an external force that has the power to coerce you to restrict
access to a resource in such a way that you feel compelled to respond to
future requests with "I would send you this thing but they made me not."
What can that force be other than a legal one? That's not a rhetorical
question, I really would like to see an example. Because...

> waters by introducing precise-sounding but still undefined and very

​​Some would argue that DMCA takedowns aren't censorship (protecting
rightful property, etc. etc.), so by making this change you're proposing to
potentially exclude or discourage what was probably the motivating -- and
likely to be the most common -- use case. "Legal" is the less restrictive
term, as I see it, especially using Ted's suggested text.

On the definition of 'legal', a
 very quick Google
​ g​
ives me
: "the system of rules which a particular country or community recognizes
as regulating the actions of its members and which it may enforce by the
imposition of penalties." Pretty much matches my definition, and the one I
assumed the draft uses.

I'd have guessed only a small subset of people would think 'legal'
​only ​
means 'issued by government or ruled by a court', and only a smaller subset
further limit it to 'DMCA.' Fortunately for those people, that's probably
the only
​restriction
 they
​'re likely to​
encounter
​ in their lives​
. People who live in other
​regions
 would likely
​encounter others, and thus ​
use 451 for other (legitimate
​, as currently written​
) reasons.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Oct 2015 11:26:35 +1100

OK, let's accept Ted's proposal then; marking the issue as editor-ready.

> On 13 Oct 2015, at 6:24 pm, Amos Jeffries <[email-masked]> wrote:
>

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 14 Oct 2015 09:31:40 -0600

On 10/13/2015 02:48 PM, Matthew Kerwin wrote:

> Every person, society, and culture has its own legal authority. It's the
> one with the power to force things (like censorship) on people (and
> websites.)

I would not equate legality with power, but that just illustrates why
the overloaded term "legal" should not be used in the first place IMO
(and yes, this goes against the opinion of a corporate lawyer who
evidently suggested to use the term "legal demand", probably based on
that what that phrase means in that lawyer's part of the world).

> future requests with "I would send you this thing but they made me not."

Right, that is the broader use case I was rooting for.

> question, I really would like to see an example.

All of the examples I have provided earlier can be used (the DMCA one
would need an additional condition):

1. A DMCA takedown notice written by an authority with no legal standing
in the recipient locality or otherwise malformed. The blocker may still
obey the invalid takedown request to ease future business expansion to
other localities/litigation/etc.

2. A visit by a friendly group of armed enforcers of an illegal drug
lord. The blocker may obey their takedown request to avoid destruction
of property/etc.

3. An anonymous article in the "official news paper". The published
opinion may have no legal standing, but the blocker may still decide it
is safer to follow the suggested blocking practices to avoid being
persecuted for unrelated and/or imaginary offences.

> rightful property, etc. etc.), so by making this change you're proposing
> to potentially exclude or discourage what was probably the motivating --
> and likely to be the most common -- use case. "Legal" is the less
> restrictive term, as I see it, especially using Ted's suggested text.

Sorry, this is just sloppy context-specific phrasing on my part. I do
not actually suggest using the word "censorship" in the draft (IIRC,
that word came from Mark's use case and was repeated for discussion
continuity sake).

The exact replacement wording is a separate [and minor] issue IMO. It is
the decision to limit the new status code to "legal" obstacles and
demands that is important here. If that decision is reversed, I am sure
we can find a more neutral and less overloaded replacement term that
addresses more use cases. The current WG decision is that the new status
code is limited to cases where the blocking is related to legal external
demands and obstacles as opposed to *all* external demands and
obstacles. That is the important distinction!

> On the definition of 'legal', a very quick Google​ g​ives me: "the
> system of rules which a particular country or community recognizes as
> regulating the actions of its members and which it may enforce by the
> imposition of penalties." Pretty much matches my definition, and the
> one I assumed the draft uses.

Yes, that matches my understanding of a "law" or "legal system" as well.

However, you should be looking up the _adjective_ "legal", not some
related noun. Then you will find things like "permitted by law" (which
may imply that serving the new status code is an agreement that the
takedown request was lawful) and "based on the law" (which does not
cover many common use cases).

> I'd have guessed only a small subset of people would think 'legal' ​
> only ​means 'issued by government or ruled by a court', and only a
> smaller subset further limit it to 'DMCA.' Fortunately for those
> people, that's probably the only ​restriction  they​'re likely to​
> encounter​ in their lives​. People who live in other ​regions would
> likely ​encounter others, and thus ​use 451 for other (legitimate​,
> as currently written​) reasons.

I think the new status code should cover illegitimate and all other
"external demand or obstacle" reasons as well. The status code should
have nothing to do with the law, legality, or lack of thereof. It should
be for any cases where blocking is done because of an external force
(legitimate, illegitimate, hard to tell, varying, unknown, etc.)

Alex.

---

From: Krzysztof Jurewicz <[email-masked]>
Date: Sat, 17 Oct 2015 10:59:25 +0200

On September the 18th I argued that this status code should be either
split into two or moved to the 5xx range (
https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0348.html
). Since no objections have been raised, I guess that this proposition
has been either considered as legitimate or overlooked?

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Oct 2015 16:40:55 +1100

Hi Krzysztof,

On 17 Oct 2015, at 7:59 pm, Krzysztof Jurewicz <[email-masked]> wrote:
> 
> On September the 18th I argued that this status code should be either split into two or moved to the 5xx range (https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0348.html ). Since no objections have been raised, I guess that this proposition has been either considered as legitimate or overlooked?

Sorry, I meant to respond to that earlier.

It isn't a good fit as a 5xx, because that implies that the fault is on the server side, and the client can reasonably retry the request in hopes of that being corrected. That doesn't align well with the semantics we've defined. That's one reason why 404 and 410 are 4xx codes, not 5xx.

4xx is a better fit, because it tells the client they need to change *something* about the request if they want to retry it (and that can include changing the legal jurisdiction they're in). It doesn't mean that a retried request will necessarily succeed, though (see again 404 and 410).

Regarding splitting it into separate status codes -- keep in mind that the point of status codes is to allow generic, automated software to take advantage of the semantics. The responses you give as examples don't enable that (without a lot more protocol extension work). Even then, I'm not seeing how making this distinction at the status code level is important -- if there's an automated way to recover from the condition, that can be denoted by the protocol extensions that enable it, not the status code.

Lastly, if we start doubling up on status codes like this (e.g., one for recoverable, one for unrecoverable), we're going to run out quickly!

Cheers,

---

From: Tim Bray <[email-masked]>
Date: Sun, 25 Oct 2015 22:47:04 -0700

Drat, I missed the deadline on -03, so it can’t be an I-D till Nov 1st.
However, it’s available online at
http://www.tbray.org/tmp/draft-ietf-httpbis-legally-restricted-status-03.html
(also the .txt and .xml are there).

On Tue, Sep 29, 2015 at 8:29 PM, Mark Nottingham <[email-masked]> wrote:

> Everyone,
>
> After talking with the editor and our AD, I think this document is ready
> to progress; the only remaining action on it is to add the registration
> template for the new link relation.
>
> WGLC will end on 15 October 2015.
>
> Cheers,
>
>
> --

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