Subject: [hrpc] A bunch of comments on draft-irtf-hrpc-guidelines-05

From: Bill Woodcock <[email-masked]>
Date: Thu, 28 Jan 2021 23:39:12 +0100

Sorry, these are in no particular order, and many of them regard language rather than substance, all mixed together.  I’ll try to minimize the number of ones about language, since a professional copyeditor will do a better job.  And the suggestions I’ve made are minimalist ones, intended to disrupt the surrounding sentence as little as possible; a better copyedit would often rearrange several sentences together to achieve a better result.

Anyway:

> "this is not unsurprising”

Probably the opposite of what you mean, but well illustrates the dangers of double-negatives.

> "Considering the fact that network quality and conditions vary across
> geography and time, it is also important to design protocols such
> that they are reliable even on low bandwidth and high latency
> connections. [add examples]"
> 
This brings to mind the case of downsampling intermediary image caches. For a long time, a popular use of Squid was to downsample the resolution (or increase the compression) of images before they crossed a satellite link.

That's an example of smarts in a middlebox doing something valuable for an end-user, when the end-user is in a particularly vulnerable situation.  But, however, there are also risks associated with the very existence of a middlebox in the path.

More of a recognized issue now than in the heyday of Squid.

> "other intermediary nodes that provide ‘services' besides routing)"

I would say "packet forwarding" rather than "routing."  You're not interested in the router function of a router, you're interested in the packet forwarding function of whatever happens to be there.

> Human rights threats on the Internet come in a myriad of forms.

“Many” indeed, but probably not exactly ten thousand.  There’s a fair bit of syllable-expansion-euphemism in here that should get cleaned up on the copyediting pass.  Likewise, the word “impact” is vastly overused, and never to mean “hit.”  There’s always a better word.

> A person whose communications are
> monitored may be prevented from exercising their right to freedom of
> association or participate in political processes [Penney].

…prevented OR DISSUADED from…

Chilling effects are much more prevalent than direct suppression.

> This document details several 'common' threats to human rights,

“Common” is neither a number of feet nor enclosed within another quotation.  So, those foot-marks need to go.

> Human rights reviews can take place in different parts of the
> development process of an Internet Draft.

…can take place AT different STAGES of the…

> There it might help the
> review to understand how it impacts the people that use the protocol,
> and the people whose lives are impacted by the protocol.

Where?

The word “There” at the beginning of the sentence is unnecessary and confusing.

> human rights should always be understood from the rights-holder

…human rights ARE BEST understood from the PERSPECTIVE OF the rights-holder…

> Other than reviewing a draft, this allows the reviewer to understand

BY CONTRAST WITH reviewing a draft...

> Also note that while the section uses the word, 'protocol', the
> principles identified in these questions may be applicable to other
> types of solutions (extensions to existing protocols, architecture
> or solutions to specific problems, etc.).

That’s a useful caveat, however I think there’s some fuzzy thinking going on further down in the document, where what seems to be referred to is an application, rather than a protocol.  For instance:

Does your protocol have text strings that have to be
   understood or entered by humans?

Offhand, I can’t think of any _protocols_, nor even protocol extensions or architectures, which "have text strings that have to be understood or entered by humans.”  I can think of lots of _applications_ which have that requirement, but no _protocols_.  Do you have an example?

Protocols _handle payload_ that is the process of human data-entry, and protocols should be designed to be liberal in what they accept as payload, anticipating accommodations for disability, as well as support for internationalized character sets, etc.

> 3.3.2.  Privacy

I find it useful to get people to write out the minimum necessary data, as an explicit exercise in distinguishing the data that's _necessary_ from the data that "would be nice to have.” The "would be nice to haves" often get seen by bizdev people, and suddenly become "economically necessary.” Documenting what's actually functionally necessary at the outset might help fight that kind of malevolent feature-creep.

> 3.3.6.  Censorship resistance

Probably worth some discussion of verbose error messages; meaning having a plethora of different machine-readable error message codes, which have clearly defined meanings that can be translated into the user’s language and passed through transparently.  Because when we don’t do this up-front, it invariably becomes an issue, and then we have to do dnsop-extended-error-99 or whatever.  So, distinguishing between “blocked by site administrative policy,” “blocked by carrier policy,” “blocked by regulatory policy of country CC,” “blocked because of malware threat, see https://foo for details,” “blocked because of age restriction,” “blocked by parental restriction policy,” are all useful, for instance.  Any instance of overloading identifiers creates ambiguity and fog and is problematic for users.

> 3.3.7.  Open Standards

I like everything that’s being said here, but I’m not 100% convinced that it belongs in this document.  Quite possibly it does, but a stronger case for the connection between open standards and human rights could be made…  Are proprietary or non-self-hostable things damaging in specific ways to people’s specific rights?  A case could be made, undoubtedly.  Or are closed systems an inherent challenge to people’s right to know what’s going on around them and how their data is being used and their right of participation or free association (with software products?)… That seems like a much more fundamental assertion, and a harder fight to pick, although I don’t disagree with it either.

> 3.3.8.  Heterogeneity Support
>    Impacts:
>    -  Right to freedom of expression
>    -  Right to political participation

Again, I agree with the points made, they’re good points, but I’m not sure they clearly lead to a conclusion that either rights of freedom of expression or political participation are directly affected.

> 3.3.9.  Pseudonymity

Pseudonymity, on the other hand, seems to me to be very directly related to freedom of expression.  Some things you can’t say if you have to say it publicly using your general-purpose identity.  Chilling effects, etc.  And that also impacts right to political participation.

I think the point could be more clearly made that when protocols require identifiers, they should attempt to be agnostic about the form of the identifier…  The same protocol should be able to accept a private-use identifier for use within a corporate WAN, a government-issued identifier for access to government services, a unique identifier not associated with your public persona for public communications which can be nonrepudiatably linked to other communications from the same identifier, etc.  An example of a bad protocol would be one which structurally could only accept your ham radio call-sign as an identifier, and broke if two parties tried to use the same one.

An example of good use of pseudonyms in protocol design is DANE, which allows users to generate their own certificates, and, more importantly, vastly restricts the number of other people who can generate bogus certificates claiming to be that user.  The need for DANE comes in counterpoint to CA certs, which must have seemed like a good idea to someone at the time, but had the seeds of its own failure built-in: it assumed that a single, centralized external authority would create identities and directly, publicly, pair them with state-generated identities.  But of course there’s more than one state.  And any gig that good is gonna get divvied up among multiple exploiters, not just the first one, at which point it’s a race-to-the-bottom.  All because the protocol was designed to serve the business model of a single company, rather than designed in an open process to serve the needs of users.  All avoidable, if they’d only had this invaluable guide thirty years earlier!  :-)

> Is your protocol designed to provide an enabling
> environment for people who are not able-bodied?

Accessible design is more accessible for everyone, not just the handicapped.  Re-word that to "Is your protocol designed to provide an enabling environment for all?"

Section 3.3.12 is particularly well-written.

> A system that is reliable degenerates gracefully

DEGRADES gracefully.

You might also consider the applicability of the word “resilience” which captures a lot of what you’re talking about here, and is frequently used for this purpose in network engineering discussions.

Throughout the document, but particularly in sections 3.3.1, 3.3.2, 3.3.3, 3.3.9, and 3.3.14, there are discussions of bad practices, with a warning not to do them because they’re bad, but I think this may not really get the attention of the (many) people who are doing these bad things routinely, and already hear that they’re bad, and have already excused themselves.  What I think is needed is a “wake-up call.”  Not a reminder that these things are bad, but a call for introspection and consideration: ask the protocol designer to explicitly state why each “bad” decision is technically necessary to the function of the protocol.  So many bad decisions have been justified over the last twenty years by the notion that “we might be able to do something useful with that data in the future” or “law enforcement in such-and-such-a-market-that-our-bizdev-guys-are-really-excited-about-this-week would really like this if they knew it was possible” that we really need to encourage rational minimalism.  Sometimes more data really is necessary, but it pays to think it through and discuss it in public and see if anyone has a better idea that could accomplish the same goal while collecting less data or delving less far into the headers or allowing a broader choice of identifiers.  When you ask “does your protocol do this bad thing” the person who’s designed it to do the bad thing will blow it off, because it’s a value judgement of them, of their character, if they take it seriously.  And attacking them and making them feel defensive doesn’t achieve our goal.  Instead, we need to get them to think differently, and that can only come from introspection, not from us telling them that they way they think right now is bad.

> 3.3.17.  Adaptability

It feels worthwhile to me to add some discussion here of layered models and the need to avoid layer boundary violations.  Things like DPI and NAT and DoH are what you get if you prioritize your business model over layers and forethought.

> 3.3.19.  Anonymity

I would group anonymity and pseudonymity adjacent to each other, since they’re very related discussions, with very related principles.

> 3.3.20.  Remedy and Attribution

Anybody got an example of this that they like, that doesn’t fly in the face of all the other principles?  Because as stated, it’s a little hard to reconcile with the others.  It’s a complex world, there are lots of difficult-to-reconcile situations; this just doesn’t seem to provide much guidance or insight.

All in all, great work, sorry I haven’t been able to contribute more or earlier, and my apologies if any of the above retreads already-had arguments without adding to them.

                                -Bill

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 29 Jan 2021 14:04:35 +0100

Thanks a lot for these comments Bill very much appreciated. We'll get working on them!

Best,

Niels

On 28-01-2021 23:39, Bill Woodcock wrote:
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
> 

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Postdoctoral Research Fellow - Communications Department - Texas A&M University
Research Fellow - Centre for Internet and Human Rights - European University Viadrina
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas

W: https://nielstenoever.net
E: [email-masked]
T: @nielstenoever
P/S/WA: +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

Read my dissertation 'Wired Norms' here: https://pure.uva.nl/ws/files/50781961/Thesis.pdf