Interview avec Federica Casarosa (European University Institute)

Dans le cadre du projet ADAM, nous avons fait une serie d’interviews auprès d’experts internationaux. Nous avons notamment rencontré Federica Casarosa, juriste et chercheuse à l’Institut Universitaire Europeen à Florence, qui s’occupe de la regulation des opérateurs de télécommunication en ligne.

  • Question 1 : Quelles sont les modalités de régulation des architectures décentralisées sur Internet ?

Federica se propose d’examiner cinq mécanismes différents:

1. Régulation par la loi : avec des lois interdisant le déploiement de résaux anonymes, ou qui obligent ces réseaux à implementer certaines fonctionnalités permettant une meilleure identification des usagers. Le problème est que la plupart des réseaux décentralisés sont souvent conçus pour échaper au contrôle, et ne sont pas susceptibles de s’adapter aux règles de droits.

2. Régulation par des tiers : établissement d’une force de police pour superviser les réseaux et faire appliquer les règles ; encourager et faciliter la délation de la part des utilisateurs du réseau. L’inconvénient est que cela risque d’entraîner le développement de réseaux de plus en plus décentralisés qui échappent au contrôle des tiers.

3. Régulation par la technique : incorporer les règles directement au sein des dispositifs technologiques (au niveau du protocole ou de l’interface utilisateur): e.g. DRM, tit-for-tat, etc.  Il faut cependant tenir compte du compromis existant entre la précision des règles et la possibilité pour les utilisateurs de contourner les règles ainsi formalisées.

4. Auto-régulation de la communauté : par le biais de normes sociales ou de mécanismes réputationnels (trust mechanisms). Pour cela, il est nécessaire d’établir un système visant à encourager les usagers à respecter les règles, ou les décourager à les enfreindre. Évidemment, il y a toujours le risque que les utilisateurs “trichent” ou établissent de nouveaux réseaux avec des finalités illégales.

5. Régulation contractuelle : incorporer les règles au sein de la licence sous laquelle le protocole, le logiciel et l’interface sont mis à disposition du public. Tout internaute désirant se connecter au résaux devra ainsi accepter les termes du contrats. Ce méchanisme ne peut servir cependant que pour imposer de nouvelles règles, et non pas pour les faire appliquer.


  • Question 2 : Selon vous, quelle est la meilleure solution ?

Il n’existe pas de solution parfaite, tous présentent des avantages et des coûts qu’il faut nécessairement prendre en compte afin de créer un système intégrant ces différentes formes de régulation – dans le but de garantir un certain degré de contrôle sans toutefois porter atteinte à la vie privée des utilisateurs.

La première solution (régulation par la loi) est très dangereuse, dans la mesure elle permettrait au législateur d’interdire le développement de certaines technologies, ou d’imposer l’utilisation de logiciels avec des fonctionnalités spécifiques. Il est intéressant de voir à cet égard, la situation aux Etats-Unis, où le FBI a recemment proposé une règle visant à obliger l’introduction d’une back-door (porte de service) dans les principaux services de communication sur Internet (VoIP, réseaux sociaux, messagerie, etc) afin de faciliter les enquêtes – sans tenir compte des conséquences négatives que cela pourrait avoir sur la confidentialité des communications et sur la vie privée des utilisateurs. Une règle de telle portée risque aussi de bloquer l’innovation technologique et de rendre illégal un grand nombre de logiciels actuellement utilisés pour des finalités completement légitimes.

Le mécanisme de régulation par des tiers comporte lui aussi un certain nombres de difficultés. Notamment, l’introduction d’une force de police pour surveiller les communications des utilisateurs risque de porter atteinte à la vie privée des utilisateurs dans la mesure où ces agents ne sont pas identifiés (ou identifiable) par les utilisateurs du réseau.

Le mécanisme contractuel est souvent utilisé au sein des architectures centralisées, où l’usager doit accepter les conditions établies par le fournisseur des services en ligne (les soit-disant « Terms of Use »). La situation est plus compliquée dans le cas de services fournis par des pairs connectés à un réseau dont la structure est décentralisée.

D’un point de vue technique, toute architecture décentralisée n’implique que l’existence de deux éléments nécessaires au correct fonctionnement du réseau : un protocole (ou logiciel) qui établit les règles du réseau et un ensemble de pairs (ou utilisateurs) connectés au réseau. Puisqu’il n’y a aucun point de référence, il devient impossible d’identifier le fournisseur avec lequel les utilisateurs peuvent négocier un contrat. Il est cependant possible d’établir un contrat entre les utilisateurs et les titulaires des droits d’auteur sur le logiciel utilisé pour se connecter au réseau. En effet, puisque le logiciel est le seul élément qui « accomune » tous les utilisateurs du réseau, seul les titulaires des droits d’auteur peuvent  imposer des conditions aux utilisateurs désirant utiliser leurs logiciels. Dans le modèle des licences de logiciel libre ou des licences Creative Commons, il s’agit notamment d’intégrer les conditions et les règles établies par une certaine communauté au sein des termes de la licence appliquée au logiciel permettant d’accéder aux services offerts par cette communauté. Cela permet aux ayants-droit de déterminer ex-ante les modalités d’utilisation du logiciel. C’est le principe utilisé dans les réseaux contractuels de la sous-traitance : le responsable identifie les agents sous-traitants et leur communique les modalités d’exécution (e.g. les conditions de travail). Ces modalités sont des normes contractuelles qui doivent être respectées par tous les sous-traitants (e.g. si le responsable décide qu’il est interdit d’employer des enfants, cette règle devra être respectées par toutes les entreprises opérant dans le réseau de sous-traitance).

L’avantage de ce mécanisme est qu’il permet l’établissement de règles globales qui s’étendent au-delà de la spécificité des lois nationales et dont la légitimité subsiste indépendamment de la juridiction d’un pays. Puisque les clauses du contrats sont fondées sur le droit d’auteur, toute violation des termes de la licence équivaut à une violation des droits d’auteur : une infraction désormais reconnue pratiquement dans le monde entier. De plus, bien qu’il n’y ait pas de juridiction de référence au sein d’une architecture décentralisée dont la porté est internationale, il est possible par ce mécanisme de sélectionner une juridiction de base pour résoudre les controverses qui se créent entre les utilisateurs qui proviennent de différents pays.

Le principal inconvénient de ce mécanisme est qu’il se fonde essentiellement sur la bonne-foi des utilisateurs, dans la mesure où il ne permet pas de faire appliquer les règles. Or, si tous les utilisateurs se comportaient bien, un tel mécanisme de régulation serait inutile. Le problème se pose lorsque les utilisateurs ont un intérêt à ne pas respecter les règles, violant ainsi les termes du contrat.

Au-delà du mécanisme contractuel, il est donc souvent nécessaire d’ajouter une couche de régulation supplémentaire afin de faire appliquer les règles. Cela peut se faire aussi bien au niveau de la technologie, par l’intermédiaire d’un système de médiation automatique (formel), qu’au niveau de la communauté – avec un système de médiation ad-hoc qui se fonde sur l’intervention des pairs pour établir la légitimité d’une action donnée.

La première option (régulation par la technique) est une forme de régulation ex-ante.  A priori, dans la mesure où les règles sont  incorporées directement dans l’infrastructure technologique du réseau, il est impossible pour les utilisateurs de contourner ces règles sans en modifier le protocole ou l’interface. Or, à moins que le protocole et les logiciels ne soient disponibles qu’en un format propriétaire, il faut considérer qu’il existe inévitablement un compromis entre le degré de “généricité” des règles et leur “contournabilité” par des tiers. Par exemple, si la règle de ne pas s’insulter sur un réseau n’était implementée que par un logiciel interdisant l’utilisation de certains vocabulaires considérés offensifs, il serait extremement facile pour les utilisateurs de contourner cette règle en utilisant des vocabulaires différenets (mais synonymes) pour insulter leur pairs. Ainsi, il est pratiquement impossible d’établir un système de règles formelles qui ne seront appliquées que par l’intermédiaire de la technique. Toute régulation par la technique doit être accompagnée de mécanismes supplémentaires fondés sur la contribution de tiers ou des membres de la communauté.

La deuxième option (régulation par la communauté) est une forme de régulation ex-post qui s’impose lorsqu’un préjudice potentiel a déjà été commis. Au-delà des règles établies au niveau formel (d’un point de vue légal ou contractuel), l’application de ces règles est faite, en partie, par les membres de la communauté. Cela peut se faire, par exemple, par le biais de normes sociales et de mécanismes réputationnels, ou, pourquoi pas, par l’introduction d’un système spécifique pour la résolution des conflits au sein d’un réseau pair-à-pair, avec établissement d’une obligation pour les utilisateurs de monitorer l’activité de leurs pairs, et, le cas échéant, de sélectionner les sanctions appropriées.

L’efficacité de ce mécanisme est cependant fonction du degré de compatibilité entre les objectifs de la communauté et les finalités d’intérêt général et d’ordre public. Si la plupart des pairs dans un réseaux ont intérêt à ce que les règles soient appliquées, un système de « contrôle social » exercé par la communauté est susceptible de préserver l’intégrité du réseau. La situation se complique lorsque l’on se déplace dans une communauté où la plupart des utilisateurs ont intérêt à ce que les règles ne soient pas appliquées – et où un système de contrôle par les pairs ne peut donc pas fonctionner.

À cet égard, il est important de noter que le code peut servir de support à tout système de régulation par la communauté ou par les tiers.

Par exemple, il est possible de créer un logiciel qui supervise les communications dans le réseau et qui analyse les actions des utilisateurs qui intéragissent sur ce réseau afin d’identifier des situations potentiellement illicites (e.g. le transfert de contenus pédo-pornographiques, la publication de propos racistes ou offensifs) – et cela dans une optique purement statistique et anonyme (et donc sans porter atteinte à la vie privé des utilisateurs). Une telle analyse permettrait d’obtenir une vision globale de ce qui se passe sur le réseau afin de pouvoir determiner le type de communauté dont il est constitué (e.g. 80% des utilisateurs respectent les règles, 10% les violent, et les autres 10% utilisent des mécanimses de chiffrage). Si la communauté est composée à plus de 50% d’utilisateurs légitimes, un système de contrôle par les pairs sera probablement efficace. Inversement, si la communauté est composée à plus de 50% de criminels ou d”inconnus » aux finalités perverses, un mécanisme de régulation par des tiers sera généralement plus efficace. Cela peut se faire soit avec l’établissement d’une force de police, soit avec l’introduction d’espions qui se camouflent au sein du réseau afin de contrôler le contenu des communications entre pairs. (Nous considérons ici que l’atteinte à la vie privée des utilisateurs serait justifiée par une présomption de culpabilité – étant donné que tout utilisateur connecté à un réseau dont les finalités ne sont pas légitimites est susceptible de partager des finalités semblables.)

L’intérêt de cette approche est que les activités “suspectes” identifiées par le logiciel ne seront pas immédiatement bloquées, mais seront au contraire sauvegardées pour être ensuite communiquées aux autorités (ou aux membres de la communauté) – qui se comporteront ici en tant que “juges” afin de déterminer le degré d’intervention nécessaire et les sanctions potentielles pour toute action controverse commise dans le réseau. Un tel mécanisme peut éventuellement mener à un système de régulation par le code qui – après une phase initiale d’apprentissage – deviendrait toujours plus sophistiqué et performant grâce aux retours de la communauté (voir les mécanismes de positive feedback, machine learning, etc).

  • Question 3 :  Comment pourrait-on combiner au mieux ces modalités de régulation ?

On pourrait imaginer un système de régulation pour les architectures décentralisées composé des éléments suivants:

1. Régulation contractuelle : par le biais d’une licence qui spécifie les règles de base de l’architecture (indépendamment de la juridiction).

2. Régulation par la technique : par le biais d’un logiciel qui analyse les communications du réseau à un niveau très basique (e.g. un algorithme qui détecte des images pornographiques ou des vocabulaires offensifs) afin d’en inférer le degré de légitimité ou de licéité. Le but est d’identifier le type de communauté qui anime le réseau, afin de déterminer s’il vaut mieux utiliser un système de contrôle par les pairs (régulation par la communauté) ou un système de police (régulation par les tiers).

3.A. Auto-régulation de la communauté : par le biais de normes sociales et de mécanismes réputationnels, mais seulement lorsque la commauté est composée à plus de 50% d’utilisateurs dont les finalités sont compatibles avec les finalités d’intérêt général.

3.B. Régulation par les tiers (autorités judiciaires) : par le biais d’un mécanisme de résolution des conflits fondé sur un jury externe : lorsque la communauté est composée à plus de 50% d’utilisateurs dont les finalités vont contre les règles établies, seules les autorités publiques peuvent assurer les fonctions de “juges”.

4. Régulation par les tiers (autorités de police) : par le biais d’une force de police (cyber-patrol) qui contrôle les opérations du réseau et qui peut intervenir, le cas échéant, pour faire appliquer les règles et préserver l’ordre public au sein des communautés.

5. Régulation par les tiers (surveillance, délation) : par le biais de système de récompense (ou autre) encourageant les utilisateurs à avertir la force de police dès lors qu’ils entreraient dans un réseau aux finalités perverses.

À propos de la mort d’Aaron Swartz

Boston Wiki Meetup – CC BY-SA 2.0 Sage Ross (http://www.flickr.com/photos/ragesoss/)

Vendredi dernier, à l’age de 26 ans, Aaron Swartz se donnait la mort à New York. Celui qui passe aujourd’hui pour un prodige de l’informatique et de l’internet (fondateur de Reddit, ami de Lawrence Lessig et membre de l’équipe d’invention des flux RSS et des Creative Commons) avait piraté le site de Jstor. Il était inculpé pour cela. Lister l’ensemble des articles qui discutent du suicide de celui qui est en passe de devenir le « Martyr » du web serait difficile; néanmoins, voici une liste d’articles qui ont retenu notre attention:

Anglais:

Sa vision de l’internet comme un système-réseau complètement distribué était particulièrement intéressante, Cf. cette vidéo:

François Huguet

PhD student in Communication Studies at the Codesign Lab & Media Studies at Telecom ParisTech.

Supervisor: Annie Gentès / Co-supervisor: Jérôme Denis

More Posts - Website

Follow Me:
TwitterDelicious

Le « Meshaging »: pourquoi le décentralisé?

Commotion possède un nouveau site Internet (commotionwireless.net) depuis quelques mois seulement (nous avions même eu la chance d’assister aux réunions de pré lancement-test- du site web en août 2012 à Washington). Lors de notre exploration de cette plateforme, nous étions pourtant passés à côté de ce post très intéressant qui présente (et « justifie » dans un sens) le travail et les réflexions des ingénieurs de Commotion (projet mené par l’Open Technology Initiative au sein de la New America Foundation à Washington DC voir ce précédent billet).

Ce texte a plus d’un intérêt car il montre de quelle manière le Work Department (auteur du billet en question) du projet Commotion considère  l’utilisation d’architectures distribuées comme une plus-value. Il cherche également à expliciter le choix de développer des services distribués ET mobiles dans une ville telle que Détroit. Il montre enfin l’attention portée par ces ingénieurs à l’écologie globale dans lequel le système technique qu’ils développent prend place:

 

As we worked through other parts of the Commotion project, we brainstormed ideas for wireless mesh applications. We noticed that our ideas would often replicate existing web services — e.g. a local fileserver for music or movies, or a local message board for neighborhood discussion. We began to wonder what would make a community wireless application more appealing than using a centralized Internet-based application. We agreed that it wouldn’t be enough to offer someone the simple satisfaction of knowing their data is decentralized… there would need to be some other benefits to using a local application.

What would these benefits be? What is special about the architecture of a community wireless mesh network? In pondering these questions, we considered what is provided by these networks — earlier, I mentioned that the networks provide internet connection sharing and local file sharing, but that’s only a part of the story. These networks also provide something much grander: they become community institutions. Unlike the Comcast hardware that is bolted out of arm’s reach on a utility pole, our community wireless equipment lives on our porches, in chicken coops, in our bell towers, and next to our desks. Each piece of equipment has a story behind it. We know who held the ladder while it was being installed and who lent their hammer drill to run a cable up to it.

A community mesh wireless router’s IP address is more than a 32-bit number. It has history and meaning. How can we build applications that reflect and enhance this?

 

LIRE LE TEXTE COMPLET ICI (https://commotionwireless.net/blog/exploring-meshaging)

 

Références:

  • http://oti.newamerica.net/
  • https://commotionwireless.net/
  • http://detroitdjc.org/

 

 

François Huguet

PhD student in Communication Studies at the Codesign Lab & Media Studies at Telecom ParisTech.

Supervisor: Annie Gentès / Co-supervisor: Jérôme Denis

More Posts - Website

Follow Me:
TwitterDelicious