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

From: Mark Nottingham <[email-masked]>
Date: Wed, 30 Sep 2015 13:29:32 +1000

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.

WGLC will end on 15 October 2015.

Cheers,

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

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 30 Sep 2015 17:10:18 +1300

> 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: Tim Bray <[email-masked]>
Date: Tue, 29 Sep 2015 21:41:47 -0700

I’ll leave most of your points for others, but did want to provide
background on the specific phrase “legal demand”.  The earliest drafts said
something else, it may have actually been “legal requirement”.  At the time
I was a Google employee and consulted with a Google attorney who has
expertise in this area.  She explained that it would be wise to avoid any
phrases that suggested acknowledging the demand was justified or
legitimate, as this could be prejudicial should it come to litigation.
She recommended the use of “legal demand”, because this is just a statement
of a fact: Someone made a demand, and we decided to block access.  Thus,
the last few drafts have been careful to stick with that phrase.

On Tue, Sep 29, 2015 at 9:10 PM, Amos Jeffries <[email-masked]> wrote:

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

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 30 Sep 2015 11:41:36 -0700

> required before the status may be used.
​For what it is worth, I did not read that to mean that the legal demand
was specific to a resource, merely that it covered a resource.  So, for
example, a blanket legal demand that all images containing a picture of the
King of country X be restricted from display outside of country X could
result in this status code being used, even if country X did not specify
each resource containing such a picture by URL.

​I think the current text is right, in other words, but I wouldn't object
to making a change that clarified it.  Perhaps:

"for use whenever a server operator has received a legal demand to deny
access to a resource or to a set of resources which includes the requested
resource."

I'm honestly not sure it's needed, but I think that would be harmless to
include.

regards,

Ted Hardie
(Not speaking for anyone here)​

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 30 Sep 2015 18:37:09 -0600

>   [RFC4924] discusses the forces working against transparent operation
>    of the Internet; these clearly include legal interventions to
>    restrict access to content.  As that document notes, and as Section 4
>    of [RFC4084] states, such restrictions should be made explicit.

The above paragraph may be interpreted as a skilful attempt to justify
dedicating a special status code to denials based on "legal demands".
Neither of the two RFCs mentioned in the quoted paragraph require or
even suggest that "legal demands" require such a special treatment.

Those RFCs say that restrictions should be disclosed. Using that to
justify a new HTTP status code dedicated to a particular type of a
restriction is quite a stretch IMHO. HTTP already provides means to
satisfy those two RFCs by allowing error responses with arbitrary
content that may include all sorts of disclosures.

Please note that the above is not an argument against adding a special
status code for "legal demand" denials. It is an argument against using
those two innocent RFCs as a justification for doing so. I think that
paragraph should be deleted.

If that paragraph is removed, the only justification offered for the new
status code is:

> This status code can be used to provide transparency in circumstances
> where issues of law or public policy affect server operations.  This
> transparency may be beneficial both to these operators and to end
> users.

Since the existing HTTP error mechanisms can already be used to do all
of the above, that justification is insufficient at best.

I failed to find any other explanation why a new code dedicated to
"blocked by legal demands" responses is needed.

Moreover, the term "legal demand" is itself undefined. Could it mean a
verbal demand from XYZ legal department? A written request by a law
enforcement officer lacking jurisdiction? Does responding with this
status code constitute the responder's agreement that the demand to
block was legal??

IMHO, the draft should be revised to remove the words "legal" and
"demand". It should specify a generic mechanism to point to the blocking
entity (i.e., Section 4). Such a generic mechanism can then be used by
those who block because of "legal demands" (using their own definition
of that term) and by those who block for other reasons.

Alternatively, some serious effort should be made to define "legal
demands" and explain why they deserve a special HTTP status code.

Thank you,

Alex.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 1 Oct 2015 10:59:54 +1000

Hi Alex,

> On 1 Oct 2015, at 10:37 am, Alex Rousskov <[email-masked]> 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, Chilling Effects <https://www.chillingeffects.org/> can spider the Web for such content when such a status code is defined. There's already been pre-standardisation deployment of the status code by some sites, and interest from others.

> of that term) and by those who block for other reasons.

We've already had discussion along those lines too; see <https://github.com/httpwg/http-extensions/issues/80>. I'm very concerned about trying to over-genericise this mechanism; let's not boil an ocean we don't have to.

> Alternatively, some serious effort should be made to define "legal demands"

Defining the phrase precisely on a global scale isn't realistic. What do you have in mind?

> and explain why they deserve a special HTTP status code.

That discussion needs to happen in the WG, not *necessarily* in the draft. 

Cheers,

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 30 Sep 2015 22:33:39 -0600

On 09/30/2015 06:59 PM, Mark Nottingham wrote:

>> On 1 Oct 2015, at 10:37 am, Alex Rousskov 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.

The end result (i.e., the draft) does not reflect the goal you talk
about above. The proposed status code does not define a "Blocked By
Sensors or Similar" status code. It defines an "Unavailable For Legal
Reasons" status code (also documented as a "consequence of legal demands").

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.

> For example, Chilling Effects <https://www.chillingeffects.org/> can
> spider the Web for such content when such a status code is defined.
> There's already been pre-standardisation deployment of the status
> code by some sites, and interest from others.

Removing the words "legal" and "demand" from the draft will not break
Chilling Effects. The technical mechanism to report the HTTP agent
responsible for "blocking" the resource remains the same. The status
code remains the same.

> We've already had discussion along those lines too; see
> <https://github.com/httpwg/http-extensions/issues/80>.

Wrong link? Issue 80 is about "origin vs intermediary" distinction. I am
talking about "legal reasons vs all other blocking reasons" distinction,
and I am _not_ saying there should be another code added. One code is
more than enough!

Said that, if this draft is approved in its too-narrow form, then I sure
hope somebody submits these drafts:

* Code 452 (Unavailable For Political Reasons)
* Code 453 (Unavailable For Religious Reasons)
* Code 454 (Unavailable For Parental Reasons)
* Code 455 (Unavailable For Military Reasons)
* ...

> I'm very concerned about trying to over-genericise this mechanism;
> let's not boil an ocean we don't have to.

The mechanism is already general enough. It is the wording describing
the applicability of the mechanism that is too restrictive.

> Defining the phrase precisely on a global scale isn't realistic. What do you have in mind?

I suggest removing that phrase. IMO, that should be done for many
reasons, including the fact(?) that it is unrealistic to define its
meaning precisely enough. However, if folks disagree, then _they_ should
make the effort to define what they use. This is supposed to be a part
of a protocol specification. Definitions of key terms in protocol specs
ought to be precise.

> That discussion needs to happen in the WG, not *necessarily* in the draft. 

The result of that discussion (i.e., the final/polished explanation)
should be in the draft. If a protocol extension draft does not justify
the need for the extension (i.e., why the existing mechanisms are
insufficient), then something went wrong regardless of the preceding WG
discussion.

HTH,

Alex.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 1 Oct 2015 15:33:24 +1000

Personal opinions below.

> On 1 Oct 2015, at 2:33 pm, Alex Rousskov <[email-masked]> wrote:
> 

You misunderstand "my use case."  The introduction on the document says clearly:

"""
This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when a server operator has a received a legal demand to deny access to a resource.
"""

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

> responsible for "blocking" the resource remains the same. The status

That would introduce a lot of noise and make the status code nearly useless. 

> of a protocol specification. Definitions of key terms in protocol specs

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

> insufficient), then something went wrong regardless of the preceding WG

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

Cheers,