Subject: RFC7725bis new elements

From: Tim Bray <[email-masked]>
Date: Wed, 11 Nov 2020 22:29:11 -0800

I'm unconvinced of the value of the proposed new.

Blocking Authority.
1. While it makes sense to identify the Blocking Entity with a URI -
presumably it has an online presence - the nature of the Blocking Authority
could be any of multiple levels of government or a trade association or the
operator of a building complex or almost any other imaginable entity. I
think that this is best described in textual human-readable form so as to
be actually useful to the party whose access is being blocked. 7725 already
provides a place to put this information and illustrates it with an
(admittedly whimsical) example.
2. I haven't seen much in the way of evidence to suggest that this would be
adopted if it were specified. Maybe I just missed it?

Geographical Scope of Block
1. I don't think country codes are going to do it, given that this could be
done at the regional or municipal level, or the scope might be expressed by
geofencing.
2. Same as before - what evidence do we have that this would be adopted
were it provided?

---

From: Tim Bray <[email-masked]>
Date: Wed, 11 Nov 2020 22:43:14 -0800

Urgh … unconvinced of the value of the proposed new protocol elements …

On Wed, Nov 11, 2020 at 10:29 PM Tim Bray <[email-masked]> wrote:

> 2. I haven't seen much in the way of evidence to suggest that this would
> be adopted if it were specified. Maybe I just missed it?
>
> 1. I don't think country codes are going to do it, given that this could
> be done at the regional or municipal level, or the scope might be expressed
> by geofencing.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Nov 2020 17:52:22 +1100

Speaking personally --

> On 12 Nov 2020, at 5:29 pm, Tim Bray <[email-masked]> wrote:
> 
> 1. While it makes sense to identify the Blocking Entity with a URI - presumably it has an online presence - the nature of the Blocking Authority could be any of multiple levels of government or a trade association or the operator of a building complex or almost any other imaginable entity. I think that this is best described in textual human-readable form so as to be actually useful to the party whose access is being blocked. 7725 already provides a place to put this information and illustrates it with an (admittedly whimsical) example.
> 2. I haven't seen much in the way of evidence to suggest that this would be adopted if it were specified. Maybe I just missed it?
> 
> 1. I don't think country codes are going to do it, given that this could be done at the regional or municipal level, or the scope might be expressed by geofencing.
> 2. Same as before - what evidence do we have that this would be adopted were it provided?

My feelings aren't strong on either of these, so I won't give my thoughts for now.

However, if we're going to open 7725 up, I think it *might* be interesting to have something that lets the blocker link to some more information about the block -- e.g., a page in the Lumen Database. Might be a new header field, a new link relation, or just saying that an existing link relation could be used for that.

Cheers,

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

---

From: Shivan Kaul Sahib <[email-masked]>
Date: Fri, 13 Nov 2020 00:52:54 -0800

> be adopted if it were specified. Maybe I just missed it?

This errata outlined why "blocked-by" in RFC 7725 was confusing for
implementers: https://www.rfc-editor.org/errata/eid5181.
"blocking-authority" seemed like a good idea because there is often a
distinction between the entity who mandates the block and the entity doing
the blocking, which is probably why implementations varied between the two.
https://tools.ietf.org/html/draft-irtf-pearg-censorship-04#section-4.1 goes
into some depth regarding the various points of control a censor exercises.

In terms of adoption: at the time the new protocol elements draft was
introduced, Automattic and GitHub had recently started serving 451 and the
draft incorporated informal feedback from engineers on their policy teams.
I can try to reach out to them if they'd still be interested.

> 2. Same as before - what evidence do we have that this would be adopted

The country code vs something more expressive was debated for a bit. It
seemed that most blocks were country-scoped - governments interested in
censoring often have dedicated ministries for this sort of stuff:
https://tools.ietf.org/html/draft-irtf-pearg-censorship-04#section-3. Given
that 451 is often used by service providers (at least, the largest
centralized deployments) trying to proactively provide more information,
and the fact that the implementation report (
https://tools.ietf.org/html/draft-451-imp-report-00) found that the
information provided in the status code response varied heavily in the
quality of the information provided, the decision was made to keep it
simple, if coarse. Happy to hear suggestions about this, though (for that
matter, about anything else in the draft.)

In addition, like mentioned above, one of the main implementers at the time
was Automattic, and they'd been using 451 to report country-scoped blocks
documented here: https://transparency.automattic.com/country-block-list, so
it seemed immediately useful.