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

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

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


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


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

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



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

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.


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

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

Received on Thursday, 1 October 2015 04:34:34 UTC