Centralisation du Net : quels leviers pour les organismes de standardisation ?

Les organismes de standardisation doivent-ils apprendre à travailler avec les régulateurs ? L’IETF (Internet Engineering Task Force) y voit une opportunité face aux risques de centralisation des protocoles. Elle vient de publier une réflexion à ce sujet. Pour le moment à l’état de brouillon (draft), le document pourrait devenir une recommandation.

L’IETF distingue cinq types de risques. En premier lieu, la « centralisation propriétaire ». C’est la conséquence de la création, par une entité ou un petit groupe d’entités, d’un protocole ou d’une application au rôle fixe. Les principaux services de messagerie, de visio et de réseau social reposent aujourd’hui sur ce modèle.
De tels services qui reposent « sur » internet sont souvent considérés comme plus évolutifs et plus adaptés aux besoins des utilisateurs finaux. Mais ils présentent un risque de lock-in (pas d’alternative ou bien difficile de basculer).

Deuxième risque : la « centralisation bénéfique ». Cette notion se matérialise dans des protocoles et des applications dont les finalités exigent d’introduire des fonctions centralisées. Le DNS et les certificats de sécurité sont dans ce cas : ils ont besoin d’une source de confiance (respectivement, un registre et une autorité de certification), centralisée par nature. Même chose, généralement, pour les protocoles qui gèrent la découverte mutuelle de points de terminaison pour établir une communication.
Qualifier une centralisation de « bénéfique » tient du jugement. Lorsqu’on est dans ce cas, on a principalement deux leviers pour limiter l’effet : la fédération et la gouvernance multipartite.

Extériorités, plates-formes et effet de réseau

Une fonction qui parvient à éviter la centralisation propriétaire et à limiter la centralisation bénéfique peut néanmoins être centralisée en pratique. En l’occurrence, lorsque des facteurs externes influent sur son déploiement, de sorte que peu d’entités peuvent effectivement le réaliser. On est là, selon l’IETF, dans un cas de « centralisation par concentration ».
Les facteurs en question peuvent être autant économiques que juridiques ou sociaux. Ils sont souvent liés aux effets de réseau.

Le risque de « centralisation héritée » se présente quand une fonction, sans avoir de rôle central, peut faciliter la centralisation des applications et des protocoles qui vont l’exploiter. Le réseau sur lequel s’appuie un logiciel de communication peut, par exemple, bloquer, ralentir ou modifier ces communications.
Le fait de ne disposer que d’une implémentation d’un protocole présente le même risque : ses vulnérabilités se répercuteront dans les applications qui l’utilisent. Isoler les couches, en particulier par chiffrement, peut favoriser la minimisation du risque.

Dans la nomenclature IETF, le complément de la centralisation héritée s’appelle « centralisation de plate-forme ». Ou comment un protocole non centralisé peut faciliter la création de services et d’applications décentralisés. On nous donne un exemple : HTTP.

L’IETF cherche un appui juridique

Quel rôle, dans ce contexte, pour les organismes de standardisation ? D’abord, un devoir de réalisme, assure l’IETF. Avec l’expérience, on sait, notamment, de mieux en mieux gérer le risque de centralisation bénéfique. C’est plus difficile pour ceux de concentration et de plate-forme, auxquels bien des protocoles (IP, TCP, HTTP, DNS…) sont déjà exposés.

Une solution : accompagner la décentralisation des fonctions propriétaires, en créant les spécifications adéquates. C’est pour pousser à leur implémentation qu’on cherchera un appui juridique. On constate actuellement des dynamiques dans ce sens, en particulier en matière d’interopérabilité. « Si la communauté [des standards] internet ne fait pas cet effort, les régulateurs se tourneront probablement vers d’autres sources de spécification », alerte toutefois l’IETF.

Autre solution : évaluer de nouvelles techniques de décentralisation. L’IETF donne l’exemple du calcul sécurisé multipartite (décentralisé, sans révéler les données). Non sans reconnaître que leur efficacité contre la centralisation restent hypothétiques, elle appelle à un effort d’incubation.

Face au risque de centralisation héritée, une recommandation : que les fonctions standardisées comportent comme objectif la diversité de leurs implémentations / déploiements. Pour stimuler ces implémentations, il faudra faire en sorte de limiter le coût pour passer de l’une à l’autre (la clé : là encore, l’interopérabilité).
Les objectifs d’exhaustivité et de diversité peuvent parfois être en conflit. Un standard complexe peut dissuader de multiplier les implémentations, pour des questions de coût. Au contraire, un spécification trop simple peut engendrer des extensions non interopérables.

Encadrer les extensions propriétaires

L’extensibilité, justement, peut être vue comme un mécanisme de décentralisation. Elle peut toutefois augmenter le risque de concentration de plate-forme si une entité suffisamment puissante ajoute des extensions propriétaires. Il faut donc, clame, l’IETF, s’assurer de deux choses. D’une part, que les standards aient une « valeur concrète » dès leur publication, plutôt que de faire simplement figure de frameworks. De l’autre, limiter l’extensibilité des protocoles et interdire aux extensions propriétaires de se rendre obligatoires pour l’interopérabilité.

Concernant les protocoles de consensus distribué, l’IETF relève un certain nombre de limites potentielles :

– Les implications sur la privacy (activité partagée avec d’autres parties ; parfois en public)

– Complexité qui empêche un usage véritablement efficace du réseau

– Moindre capacité de montée en charge par rapport aux protocoles internet établis ; surtout lorsqu’on s’appuie sur des tierces parties inconnues

– Difficulté à attribuer la responsabilité, qui plus est entre des parties parfois difficiles à identifier

– Le processus de recouvrement des identités en cas de perte présente un risque de centralisation