Re: Possible BofF question -- I18n (was: Re: Possible OBF question -- I18n)

[Spencer Dawkins at IETF <[e-mail]>]

What follows is semi-on topic ...

On Fri, Jun 1, 2018 at 11:16 AM Niels ten Oever <[e-mail]>
wrote:

>
> On 06/01/2018 06:00 PM, Peter Saint-Andre wrote:
> > On 6/1/18 9:10 AM, Nico Williams wrote:
> >
> >> Require that documents have I18N Considerations sections, require review
> >> by an I18N directorate, and you'll see how quickly participants who used
> >> to not give a damn about I18 will come around, learn what they have to,
> >> and get their I18N work done.  Suddenly the I18N directorate will be in
> >> demand.
> >
> > This is worth considering...
> >
> > Peter
> >
>
> l18n is part of the Human Rights Considerations
>
> https://tools.ietf.org/html/rfc8280#section-6.2.5
>
> so you might want to consider joining the Human Rights Review Team and
> scope for these issues in drafts:
>
> https://www.ietf.org/mailman/listinfo/Hr-rt
>
> Best,
>
> Niels
>

To provide background on my +1, I recently received the first HR-RT review
I'd ever seen for a doc I'm editing.

The thread starts at
https://mailarchive.ietf.org/arch/msg/hr-rt/byJOPkEXzGlHcYISVEQfk_zkbug.

In particular, if you check the review, you'll see this:

 Human Rights Considerations
===========================

*Upon consideration of the draft report, no implications for*
*internationalization ([RFC8280], sec. 6.2.5), heterogeneity support*
*([RFC8280], sec. 6.2.8), accessibility ([RFC8280], sec. 6.2.11) or*
*localization ([RFC8280], sec. 6.2.12) have been found. *We will further
suppose that issues relating to Anonymity ([RFC8280], sec. 6.2.9),
Pseudonymity ([RFC8280], sec. 6.2.10) and Confidentiality ([RFC8280], sec.
6.2.16) have been sufficiently addressed in the draft as is.

In the below text, Security ([RFC8280], sec. 6.2.4), Integrity ([RFC8280],
sec. 6.2.16) and Authenticity ([RFC8280], sec. 6.2.17) are further
considered to have been addressed, or as in progress of being addressed by
the specific endeavours pointed out in the report. As such, this assessment
hopes to serve as a complement to remaining Human Rights Considerations
Guidelines which were not addressed by the MaRNEW draft.

## Privacy ([RFC8280], sec. 6.2.2)

We laud the general emphasis on considering user privacy concerns paramount
[Section 2.1.1, 2.3 etc].

In Section 3.1.1, para 1, it would be useful to emphasize that middleboxes
that are "authenticated and invoked explicitly" might not be very effective
at conserving user privacy if they lead to auto-click through. In practice,
"opted-in" middleboxes might not be much better than transparent
middleboxes. Additionally, this poses the danger of making matters worse if
users assume that because they haven't been asked for middlebox permission,
they are not going through a middlebox. For users accessing the Internet on
a browser client: if the connection is MITMed by a middlebox, the browser
would somehow need to convey this effectively and actionably to the user.
Whatever effort is expended on this should involve browser vendors.

## Connectivity ([RFC8280], sec. 6.2.1)

It is a priori obvious that a discussion with mobile network operators
would touch upon connectivity. As a general comment, the HRPC RG is not
concerned that encrypted internet traffic could create topological problems
in network deployment with respect to density of base stations. It is more
sensible to imagine that the density of base stations is kept low by
deployers to save money on infrastructure roll-out.

In the MarNEW draft report, middleboxes are brought up frequently as an
example of infrastructure rendered less useful by the ubiquitous adoption
of encryption. Middleboxes may enhance access to content for individuals,
and may also interfere with their ability to enjoy content free of
surveillance, censorship or content manipulation. The focus of the workshop
of exploring ways in which encrypted materials can benefit from the same
speed of deliverance as un-encrypted materials is therefore welcome.

## Content Agnosticism

Traffic prioritisation, whether based on technical or commercial grounds,
risks interfering with an individual's right to freedom of expression or
opinion, by restricting access or enjoy content of their own choosing. As
such, prioritisation should be made explicit and obvious, and subject to
consent from the individual, whether the motivations for deployment are
commercial or technical.

It is clear that internet filtering and blocking of content of specific
types, whether motivated by network management or regulatory concerns, does
not fulfill a content agnosticism criterion. It is the observation of HRPC
that [RFC7725] (An HTTP Status Code to Report Legal Obstacles) may assist
communication of specific filtering and blocking operations in action.

It the the impetus of the Human Rights Guidelines in RFC8280 that content
agnosticism be respected by protocols developed in the IETF, and in general
an accepted view in the global human rights community that content
agnosticism is desirable at all levels of technical infrastructure. As
such, the HRPC RG is concerned about ideas that traffic be classified
through additional headers or metadata, identifying traffic via 5-tuples,
trust models and frameworks, or heuristics.


So, with that as background and speaking only for myself, +1.

If people should be thinking about i18n for their work, HR-RT is a resource
that they might not know about.

(and thanks, again, for your review of my doc!)

Spencer