The Internet Research Task Force has published a Request For Comments document its authors hope will mean developers of comms protocols and architectures consider the human rights implications of their efforts.

RFC 9620 - titled "Guidelines for Human Rights Protocol and Architecture Considerations" - is merely informational. It's not a standard, nor is it on track to become one.

It "outlines a set of human rights protocol considerations for protocol developers" and "provides questions that engineers should ask themselves when developing or improving protocols if they want to understand how their decisions can potentially influence the exercise of human rights on the internet."

The document explains the need for its existence as follows:

The document suggests human rights reviews be conducted during development of a draft standard.

Among the ideas to consider when conducting such reviews are:

• Decentralization: Can your protocol be implemented without a single point of control? If applicable, can your protocol be deployed in a federated manner? Does your protocol create additional centralized points of control?
• Censorship Resistance: Does your protocol architecture facilitate censorship? Does it include "choke points" that are easy to use for censorship? Does it expose identifiers that can be used to selectively block certain kinds of traffic? Could it be designed to be more censorship resistant? Does your protocol make it apparent or transparent when access to a resource is restricted and why it is restricted?
• Integrity: Does your protocol maintain, assure, and/or verify the accuracy of payload data? Does your protocol maintain and assure the consistency of data? Does your protocol in any way allow for the data to be (intentionally or unintentionally) altered?
• Content Signals: Does your protocol include explicit or implicit plaintext elements, in either the payload or the headers, that can be used for differential treatment? Is there a way to minimize leaking such data to network intermediaries? If not, is there a way for deployments of the protocol to make the differential treatment (including prioritization of certain traffic), if any, auditable for negative impacts on net neutrality?

Other matters are a little more anodyne - such as ensuring work conforms to security-related standards, doesn't rely on proprietary tech and would therefore be hard to extend, and allows confirmation of the truth of an attribute of a single piece of data or entity.

Why is this sort of document needed, beyond being a useful prompt?

One answer is that some developers of protocols have included tech that makes human rights abuses possible.

The "New IP" proposal developed by Huawei and backed by other Chinese tech giants suggested a revised Internet Protocol that the Internet Society noted was designed to enable development of a "tactile internet" and holographic communications.

But analysts from Chatham House, the Oxford Information Labs and the Oxford Internet Institute opined that New IP "would enable mass surveillance and erode anonymity online [and] interfere with the right to privacy, freedom of expression and opinion, freedom of association and assembly of network users."

Those outcomes wouldn't be universal: China favors a "ManyNets" approach to global internetworking - in which nations can run their local internet according to their own rules that still allow interoperability with other networks. But the mere existence of New IP worries some who imagine it could be adopted beyond China, spreading Beijing's values to other nations.

Russia likes the idea: in 2022 it backed a candidate for the post of secretary-general at the International Telecommunication Union who backed China's thinking.

An RFC won't stop Russia or China from trying to embed their values in standards and protocols. But this document may at least help some developers to think beyond the technical as they work. ®

https://www.theregister.com//2024/09/18/rfc_9620/