Un article (en anglais) paru la semaine dernière sur Wired magazine:

For many, bitcoin — the distributed, worldwide, decentralized crypto-currency — is all about money … or, as recent events have shown, about who invented it. Yet the actual innovation brought about by bitcoin is not the currency itself but the platform, which is commonly referred to as the “blockchain” — a distributed cryptographic ledger shared amongst all nodes participating in the network, over which every successfully performed transaction is recorded.

And the blockchain is not limited to monetary applications. Borrowing from the same ideas (though not using the actual peer-to-peer network bitcoin runs on), a variety of new applications have adapted the bitcoin protocol to fulfill different purposes: Namecoin for distributed domain name management; Bitmessage and Twister for asynchronous communication; and, more recently,Ethereum (released only a month ago). Like many other peer-to-peer (P2P) applications, these platforms all rely on decentralized architectures to build and maintain network applications that are operated by the community for the community. (I’ve written before here in WIRED Opinion about one example, mesh networks, which can provide an internet-native model for building community and governance).

Thus, while they enable a whole new set of possibilities, blockchain-based applications also presentlegal, technical, and social challenges similar to those raised by other P2P applications that came before them, such as BitTorrent, Tor, or Freenet. But some of these challenges haven’t been seen before in the context of traditional P2P networks.

The Bitcoin Protocol Is More ‘Cloud’ Than ‘P2P’

Although all blockchain-based applications are based on a decentralized network architecture, most of these applications distinguish themselves from standard P2P applications in at least two ways:

Users’ data (including personal data) are not stored locally into users’ devices. They subsist “in the cloud”, in the sense that they are hosted in a distributed database — the blockchain in this case — that is shared amongst all users in the network. This means that data is ubiquitous: It can be accessed at anytime and from anywhere, regardless of the user’s device. But the data is also more transparent: All actions or transactions performed by users are recorded on the blockchain and thus publicly available to everyone (although the identity of users can be kept secret and the content of such transactions can of course be encrypted).

Instead of being run locally, blockchain-based applications operate globally. They are deployed on the blockchain itself and are run — in a distributed manner — by relying on the resources provided by all users connected to the network. Although each client runs locally on the user’s device, these applications are constantly available, even when individual devices are turned off (as long as there are enough resources dedicated to them).

In this sense, blockchain-based applications are — in spite of their inherently decentralized nature —more similar to cloud-based services than traditional P2P applications.

However, these applications do significantly differ from traditional cloud-computing applications in that they are autonomous and independent from any central server or authority in charge of regulating or managing the network. Applications are run through an aggregate of individual, peer-to-peer clients that contribute their own resources to the network. In addition to being autonomous, the network is also more resilient and anonymous: no single point of failure, no single point of control.

As such, the bitcoin platform (or blockchain) allows for the deployment of decentralized applications that combine the benefits of cloud computing — in terms of ubiquity and elasticity — with the benefits of P2P technologies in terms of privacy and anonymity. Even though the blockchain is inherently transparent (as every transaction is recorded on a public ledger), users can have multiple identities that don’t necessarily relate to their real persona.

Blockchain-based applications can therefore address user’s privacy through anonymity.

So What Are the Challenges?

In general, most challenges encountered by decentralized network applications are related to the limited availability of resources and the inherent difficulty of managing and coordinating them.

Long-term sustainability can only be achieved by providing an incentive for users to contribute to the network — for altruistic to selfish reasons — so that there are always a sufficient amount of resources available at any given time. In the case of decentralized applications featuring a specifically designed credit system (such as bittorrent) or assuming the function of a cryptocurrency (such as bitcoin, namecoin, and ethereum), this objective is much easier to achieve to the extent that these platforms provide an additional economic and/or utilitarian incentive for users to contribute to the overall operations of the network.

But blockchain-based applications raise important legal challenges, too. The challenges similar to those raised by traditional P2P networks is that the anonymity inherent in these networks supports or even encourages criminal behaviors and other illicit or reprehensible activities.

In previous decentralized networks, these issues were dealt with by establishing shared or distributed liability amongst all users connected to the network. Even though it’s often difficult to determine identity and assess the degree of responsibility each should be held accountable for, there are always specific individuals to blame. (Ultimately, the difficulty lies in assigning more or less responsibilities to one or more users in the network.)

So what happens when the figure of the “user” itself disappears; when the resulting P2P applications live outside a central authority? Who is liable and accountable? While we can borrow lessons learned from the world of previous P2P applications to respond to some of these challenges, it cannot be denied that blockchain-based applications raise new and important legal issues — and of a completely different kind than those found in traditional P2P architectures.

The Case of Ethereum and Applications Such as Smart Contracts and Distributed Autonomous Corporations

The case of Ethereum is particularly interesting in that its proponents envision the deployment of self-enforcing smart contracts – such as joint savings accounts, financial exchange markets, or even trust funds — as well as autonomous organizations that subsist independently of any moral or legal entity.

Ethereum is a contract validating and enforcing system based on a more sophisticated platform than other derivative cryptocurrencies (it features an internal Turing-complete scripting language that can be used to encode advanced transaction types directly into the blockchain).

As opposed to the other blockchain-based distributed applicationsdescribed above — from messaging to contracts — Ethereum can be regarded as a kind of distributed operating system: a platform allowing for new applications to be developed upon it, so as to eventually create self-validating contracts and autonomous systems that operate directly on the blockchain.

That’s the revolutionary feature of Ethereum. It’s also its potential problem.

Corporations and economic transactions are fundamentally driven by contracts. By providing the foundation to validate these contracts, Ethereum allows for the deployment of so-called distributed autonomous companies (DACs) or organizations (DAOs). These systems operate on the blockchain with an autonomy of their own. They earn money by charging users for the services they provide (in the example applications cited above, those services are DNS resolution and social networking) so that they can pay others for the resources they need (such as the processing power and bandwidth necessary to run the network).

As the name suggests, DAOs are autonomous entities that subsist independently from any legal or moral entity. After they have been created and deployed onto the internet, they no longer need (nor heed) their creators. Yes, they need to interact with their users, but they are not dependent on any one of them. Smart contracts are automatically enforced by the applications running over the blockchain.

Since operations are governed through this system of technical self-regulation, Ethereum introduces a whole new set of legal challenges regarding liability and law enforcement that haven’t been seen before in the context of traditional P2P networks. Indeed, if DAOs are independently operated — neither owned nor controlled by any given entity — who is actually in charge, responsible for, or accountable for their operations? And if their resources cannot be seized (because DAOs have full sovereignty over them), how can they be required to pay damages for their torts?

In the context of cloud computing at least, corporate authority is limited to the extent that online operators like Amazon, Google, or Facebook must abide to the basic tenets of law. In the case of Ethereum, the authority of the code cannot be questioned, nor can it be repealed by the law. In that sense these challenges are actually more similar to the issues emerging with the advent of autonomous agents – such as evolutionary software viruses or (though perhaps limited to the realm of science-fiction for now) intelligent robots with an autonomy on their own — than they are to traditional P2P applications.

Ethereum and other blockchain-based applications might well liberate us from the tyranny of large online operators. We just need to make sure that we don’t exchange that for the “tyranny of code”: rules dictated and automatically enforced by the underlying code of an online platform that only exists in the “ether”…

primaveradefilippi

More Posts

Un article (en anglais) paru la semaine dernière sur Wired magazine:

The internet is weak, yet we keep ignoring this fact. So we see the same thing over and over again, whether it’s because of natural disasters like hurricanes Sandy and Katrina, wars like Syria and Bosnia, deliberate attempts by the government to shut down the internet (most recently in Egypt and Iran), or NSA surveillance.

After Typhoon Haiyan hit the Philippines last month, several towns were cut off from humanitarian relief because delivering that aid depends on having a reliable communication network. In a country where over 90 percent of the population has access to mobile phones, the implementation of an emergency “mesh” network could have saved lives.

Compared to the “normal” internet — which is based on a few centralized access points or internet service providers (ISPs) — mesh networks have many benefits, from architectural to political. Yet they haven’t really taken off, even though they have been around for some time. I believe it’s time to reconsider their potential, and make mesh networking a reality. Not just because of its obvious benefits, but also because it provides an internet-native model for building community and governance.

But first, the basics: An ad hoc network infrastructure that can be set up by anyone, mesh networks wirelessly connect computers and devices directly to each other without passing through any central authority or centralized organization (like a phone company or an ISP). They can automatically reconfigure themselves according to the availability and proximity of bandwidth, storage, and so on; this is what makes them resistant to disaster and other interference. Dynamic connections between nodes enable packets to use multiple routes to travel through the network, which makes these networks more robust.

Compared to more centralized network architectures, the only way to shut down a mesh network is to shut down every single node in the network.

That’s the vital feature, and what makes it stronger in some ways than the regular internet.

But mesh networks aren’t just for political upheavals or natural disasters. Many have been installed as part of humanitarian programs, aimed at helping poor neighborhoods and underserved areas. For people who can’t afford to pay for an internet connection, or don’t have access to a proper communications infrastructure, mesh networks provide the basic infrastructure for connectivity.

Not only do mesh networks represent a cheap and efficient means for people to connect and communicate to a broader community, but they provide us with a choice for what kind of internet we want to have.

For these concerned about the erosion of online privacy and anonymity, mesh networking represents a way to preserve the confidentiality of online communications. Given the lack of a central regulating authority, it’s extremely difficult for anyone to assess the real identity of users connected to these networks. And because mesh networks are generally invisible to the internet, the only way to monitor mesh traffic is to be locally and directly connected to them. 

But the Real, Often Forgotten, Promise of Mesh Networks Is…

Yet beyond the benefits of costs and elasticity, little attention has been given to the real power of mesh networking: the social impact it could have on the way communities form and operate.

What’s really revolutionary about mesh networking isn’t the novel use of technology. It’s the fact that it provides a means for people to self-organize into communities and share resources amongst themselves: Mesh networks are operated by the community, for the community. Especially because the internet has become essential to our everyday life.

Instead of relying on the network infrastructure provided by third party ISPs, mesh networks rely on the infrastructure provided by a network of peers that self-organize according to a bottom-up system of governance. Such infrastructure is not owned by any single entity. To the extent that everyone contributes with their own resources to the general operation of the network, it is the community as a whole that effectively controls the infrastructure of communication. And given that the network does not require any centralized authority to operate, there is no longer any unilateral dependency between users and their ISPs.

Mesh networking therefore provides an alternative perspective to traditional governance models based on top-down regulation and centralized control.

Indeed, with mesh networking, people are building a community-grown network infrastructure: a distributed mesh of local but interconnected networks, operated by a variety of grassroots communities. Their goal is to provide a more resilient system of communication while also promoting a more democratic access to the internet.

Are We There Yet?

In recent years, different mesh network initiatives have emerged to address the above and other objectives that could be accomplished with mesh networking.

For instance, in face of the damages caused to Haiti’s communication infrastructure by the 2010 earthquake, the Serval project was launched in Australia with the objective to create a disaster-proof wireless network that relies exclusively on the connectivity of mobile devices.

Meanwhile, after the Egyptian government attempted to shut off the internet in the whole nation, the Open Mesh Project emerge with the goal of providing open and free communications to every citizen in the world regardless of national boundaries.

Finally, there is the Open Technology Institute’s (an initiative of the New America Foundation) Commotion Wireless project. Originally aimed at providing a secure and reliable platform to prevent authoritarian regimes from controlling or blocking dissident or activist communications, it has so far only been deployed in confined areas where the communication infrastructure was either damaged or missing.

So why hasn’t mesh networking already taken off?

Well, there are technical reasons of course. The complexity to set up, manage, and maintain a mesh network is one obstacle to their widespread deployment. Getting a mesh network to work properly can be harder than it seems, especially when it comes to latency. Although the technology is there, routing protocols are currently unable to scale over a few hundred nodes and network coverage is constrained by the limited range of wireless user devices.

Another barrier is perception (and marketing). Mesh networks are generally seen as an emergency tool rather than a regular means for communication. While many mesh networks have been deployed during a period of crisis (during the Boston marathon bombing for example) or after standard communication infrastructures have been damaged or destroyed (such as the Redhook initiative in Brooklyn), very few have been deployed beforehand. They’re used more as an ad hoc measure than a precautionary one that could provide an alternative and more resilient network infrastructure.

Finally, there are political and power struggles, of course. Even though mesh networking could theoretically support the government in providing internet connectivity to poor neighborhoods or undeserved areas, mesh networks cannot be easily monitored, nor properly regulated by third parties. As such, mesh networks are sometimes regarded by the state as a potential danger — one that could disrupt public order by providing a platform for criminal activities.

The same is true of the private sector. For large ICT companies (including mobile operators and ISPs) mesh networking constitutes a new competitor in the market for internet communication, which — if it were more widely deployed — could potentially jeopardize their traditional business model based on pay-per-use and monthly subscriptions. Whether nefariously or simply because of structural circumstances, these actors are all committed to maintaining the status quo of the current internet ecosystem.

* * *

The problem is that we are focusing too much on the technical and legal challenges of mesh networking as opposed to the social benefits it might bring in terms of user autonomy and community-building. Or have we not yet realized that we have finally reached a competitive point in communications where we can deploy more than one internet? Instead of trying to create one perfect network that will satisfy us all, we can, instead, choose between several networks to find the one that best suits us.

As has been done with Freifunk in Germany and GuiFi.net in Spain, more mesh networks need to be deployed on an arbitrary basis. This will help establish the basic infrastructure necessary to ensure the autonomy and long-term sustainability of a community-based network structure. One that, in any kind of situation, can connect people and even save lives.

But beyond the internet, the governance model of many community wireless networks could potentially translate into other parts of our life. By promoting a DIY approach to network communications, mesh networking represents an opportunity to realize that it can sometimes be more beneficial for us, as a community, to rely on our own resources and those of our peers than that of centralized authorities. It’s bringing the principles of the internet to our physical lives.

primaveradefilippi

More Posts

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.

primaveradefilippi

More Posts

Interview avec Giancarlo Ruffo (Università di Torino): Sur la gouvernance des architectures décentralisées

• Comment voyez-vous la relation entre gouvernance et contrôle dans les architectures décentralisées?

Il est facile d’imaginer un système de gouvernance qui ne délègue pas le contrôle à une ou plusieurs entités. Internet en est un parfait exemple : si on observe la manière dont Internet a évolué au cours des années, on remarque que de nombreux acteurs ont proposé des protocoles (adoptés au niveau local) qui ont contribué à la construction du réseau. Tout individu peut créer un nouveau réseau (ou un nouveau réseau dans le réseau) qui obéit à certaines règles dictées par un protocole donné, et qui subsiste indépendemment des règles dictées par les autres protocoles. La plupart de ces protocoles imposent leurs propres règles au sein d’architectures spécifiques, mais ne permettent à aucune entité d’exercer un contrôle totalitaire sur ces architectures.

En ce qui concerne les architectures décentralisées, il est donc important de distinguer entre “gouvernance” et “contrôle” car il s’agit de deux notions complètement différentes, bien que souvent interdépendantes. Ainsi, bien que ces architectures soient pllus difficiles à gouverner, elles sont aussi plus difficiles à contrôler. La distinction entre gouvernance et contrôle est d’autant plus pertinente dans le cas des réseaux pair-à-pair dont les protocoles établissent un système d’auto-gouvernance par l’intermédiaire de règles techniques qui opèrent de manière autonome, sans qu’aucun de ces pairs ne soit dépendant ou contrôlé par les autres.

Dans un système centralisé, la distinction s’estompe puisque c’est la même entité qui s’occupe à la fois d’établir les règles de gouvernance et de contrôler la correcte application des règles dans une architecture donnée. Ainsi, bien qu’un système de gouvernance soit relativement facile à établir dans une architecture centralisée, il se fonde souvent sur une structure hiérarchique où une ou plusieurs entités centrales contrôlent le fonctionnement de tout le dispositif et assurent la légitimité des communications. Cela entraîne des repercussions potentiellement négatives sur certains droits fondamentaux comme le droit au respect de la vie privée et à la liberté d’expression.

• Quels sont les differents modes de gouvernance qui permettent de faire appliquer des règles (légales ou autres) au sein des architectures distribuées ?

(1) Governance by design : régulation par le code (Code is law)

Une façon de réguler les architectures décentralisées est d’incorporer les règles directement au sein de l’architecture technique de réference – sur le modèle des DRM (digital rights management systems).

En effet, Internet est un réseau entièrement décentralisé, qui peut être régulé par une pluralité de mécanismes technologiques. Tout internaute a la possibilité de proposer des règles techniques – qui s’appliquent à un réseau local, ou à l’intérieur d’un système autonome – sans que cela n’empêche les autres acteurs de proposer des règles différentes.

Cela peut se faire au niveau du:

• Protocole

La conception du protocole représente l’étape fondamentale pour le développement d’un dispositif ou d’un résau pair-à-pair. Avant même de penser à l’implémentation du réseau, il faut penser au “design” du protocole qui va determiner les principes de base sur lesquels il sera ensuite possible de développer des logiciels ou des interfaces utilisateurs. La plupart des protocoles actuellement utilisés sur Internet ont été conçus et développés dans une approche pair-à-pair par l’intermédiaire des RFC (request for comments) : des documents techniques qui invitaient la communauté d’internautes à fournir des commentaires sur les protocoles proposés, afin de les améliorer au fur et à mesure.

Le protocole est important car il constitue la structure sous-jacente d’une architecture, dont les caractéristiques iront influencer la conception et le développement de nouveaux dispositifs (en termes d’anonymat, de liberté d’expression, etc). Le protocole représente ainsi le “goulot de la bouteille” (bottle neck) de l’architecture dans la mesure où les règles qui définissent un protocole prévalent invariablement sur les règles imposées par les logiciels ou les interfaces. Ainsi, si le protocole permet de faire quelque chose que l’interface ne permet pas, il sera possible de développer des interfaces alternatives qui permettront de bénéficier des fonctionalités ou d’exploiter les défaults du protocole sous-jacent.

Cela s’est produit à plusieurs reprises dans le cas des résaux pair-à-pair :

Par exemple, le protocole SMTP (le protocole traditionnellement utilisé pour envoyer des e-mails) présente plusieurs défauts de conception (dus à un manque de préoccupation à l’époque où le protocole était développé) qui permettent notamment d’envoyer des e-mails provenant de sources inexistantes. Ce problème – qui est relativement facile à résoudre dans une architecture centralisée – ne peut pas être facilement résolu dans le cas d’un protocole décentralisé.

De même, dans le cas de Gnutella (un réseau pair-à pair pour l’échange de fichiers), étant donné que l’interface officielle du résau (LimeWire) ne permettait pas le téléchargement simultané des fichiers (une fonctionnalité cependant permise au niveau du protocole), les utilisateurs du résau ont développé des logiciels plus performants – exerçant ainsi une pression indirecte sur les concepteurs de Gnutella qui ont rapidement incorporé cette fonctionalité en plus dans l’interface officielle.

• Logiciel ou interface

La conception du logiciel ou de l’interface utilisateur est une étape importante qui va déterminer l’utilisabilité d’un système, mais qui va aussi définir les contours de ce qui peut ou ne peut pas être fait sur ce système. Alors que le protocole définit les règles de base d’un réseau (les règles du jeu); des logiciels ou interfaces sont nécessaires afin de permettre aux utilisateurs de bénéficier des fonctionnalités du réseau. Ces interfaces traduisent implémentent une nouvelle couche de règles (logicielles) qui iront étoffer les règles (préliminaire) du protocole afin de fournir des outils plus fonctionnels aux utilisateurs – dans les limites des règles imposées par le protocole sous-jacent.

Pour reprendre l’exemple du protocole SMTP, il est très difficile d’établir un système de filtrage pour limiter le nombre de courriels indésidérables (spam), car il est impossible de contrôler la reception d’un message a priori : tout courriel indésidérable ne pourra être filtré que a posteriori par l’intermédiaire d’un logiciel ou d’une interface qui propose des fonctionalités additionnelles de filtrage non prévues au sein du protocole original.

De même, dans le cas des navigateurs web, bien que Internet Explorer et Google Chrome fonctionnent sur le même protocole (HTML), ces navigateurs fournissent des fonctionnalités différentes aux utilisateurs – qui pourront ainsi sélectionner le navigateur qui réponde le mieux à leurs besoins spécifiques.

La notion de “Governance by design” est donc un principe fondamental pour la gouvernance des architectures décentralisées en ligne, qui présente cependant à la fois des avantages et des désavantages.

Les avantages principaux de cette approche se retrouvent dans la transparence des règles (qui sont accessibles par le code) et l’égalité entre pairs (due à absence d’un pouvoir central fondé sur une structure hiérarchique).

Cependant, il faut faire attention à ce que les “règles techniques” ne soient pas perçues comme un inconvénient par les utilisateurs. Les technologies DRM sont une solution qui a échoué à cause de sa complexité : ces technologies n’ont pas été acceptées par les utilisateurs dans la mesure où elles rendaient leur vie plus compliquée. Il est possible d’établir des règles techniques extremement sophistiquées, mais plus le système est compliqué, plus il sera difficile pour les utilisateurs de l’utiliser.

Les désavantages résident dans le manque de flexibilité dû au fait que les règles – une fois incorporées dans le protocole – ne peuvent plus être changées. Les utilisateurs n’ont pas la possibilité de négocier ; ils sont obligés de respecter les règles du protocole afin de pouvoir interagir avec les autres pairs du réseau. Bien qu’il soit toujours possible de créer de nouveaux protocoles qui seront potentiellement supérieurs au protocole préexistant, les effets de réseaux sont tels qu’ils réduisent la probabilité que ces protocoles soient effectivement adoptés par une majorité d’internautes. Ainsi, les problèmes identifiés dans le cas d’un protocole décentralisé tel que l’SMTP ne peuvent pas être résolus sans créer des incompatibilités importantes avec les utilisateurs du réseau – même si de tels problèmes identifiés dans un système de communication centralisé (e.g. Facebook) auraient été résolu en quelques heures.

Il est aussi important de tenir compte d’un problème intrinsèque à tout système de régulation par la technique : il existe un compromis entre la manière dont les règles sont formalisées (i.e. leur degré de précision) et leur portée d’application. Ainsi, plus grande est la généralité des règles, plus grande sera leur ampleur, mais plus il sera difficile de les interpréter ; alors que plus les règles sont précises et formalisées, plus il sera facile de les interpréter par l’intermédiaire de dispositifs technologiques, mais plus il sera facile de les violer.

Par exemple, dans le cas des discours d’incitation à la haine qui sont interdits par la loi, la généralité de la règle de droit est telle qu’elle lui donne une portée très large, mais qui ne pourra être effectivement interprétée que par l’intermédiaire d’un “juge”. Cette règle sera donc appliquée au cas par cas et interprétée de façon différente selon des circonstances. Cette même règle formalisée en termes extrêmement précis afin de pouvoir être interprétée par un ordinateur (e.g. en rendant certains mots illégaux) aura une portée plus restreinte et sera aussi beaucoup plus susceptible d’être contournée.

(2) Self-governance : Social norms

Le concept de “Governance by design” ne doit pas se limiter au protocole, mais aussi aux services offerts par ce protocole. Pour assurer la bonne gouvernance d’un réseau décentralisé, il faut donc accompagner les règles techniques incorporées dans le protocole ou le logiciel avec des règles communautaires qui iront déterminer ce que les utilisateurs ont le droit de faire avec ce logiciel.

Une fois les règles du protocole établies il faut déterminer les règles de la communauté qui se construisent autour de ce dispositif. La communauté doit établir, par exemple, quels sont les comportements acceptables et quels sont les types de contenu appropriés au sein d’un réseau. La plupart de ces règles ne pourront être que partiellement implémentées par la technique. Il est impossible, par exemple, de prévenir les discours d’incitation à la haine uniquement par le biais de dispositifs technologiques. D’autres mécanismes devront donc être adoptés pour s’assurer que ces règles soient respectées par tous les membres de la communautés : l’établissement d’un mécanisme de monitorage (logging), l’introduction d’un garant qui supervise les communications, etc.

Enfin, si l’on accepte le fait que la plupart des règles techniques (protocoles ou logicielles) seront de toute façon contournées, il ne faut pas craindre de demander l’aide de la communauté pour faire appliquer les règles qui ne peuvent pas être correctement implementées par la technique. Avec le développement d’un système de réputation fondé sur le feedback des utilisateurs,  par exemple, la communauté devient ainsi responsable du fait de punir les utilisateurs qui ne respectent pas les règles ou qui se comportent mal sur le réseau.

Ce système n’est toutefois pas entièrement fiable, puisqu’il est toujours possible de tricher (par exemple en utilisant des faux identifiants ou des mécanismes qui permettent de manipuler les données) et qu’il est souvent difficile d’identifier ce genre de tricheries. De la même façon que l’on peut contourner les règles techniques par la technique, il est toujours possible de détourner les règles communautaires en s’appuyant sur certains membres de la communauté ayant des intérêts divergents. Ainsi, avant que les architecture distribuées puissent effectivement s’auto-gouverner, il faut d’abord obtenir une “masse critique” d’utilisateurs avec de bonnes intentions qui iront s’assurer que le système fonctionne correctement.

Pour assurer le fonctionnement et le respect des règles dans un réseau décentralisé, il est important que les règles du réseau soient en accord avec les objectifs des utilisateurs. Dans une société globalisée telle que la société dans laquelle nous vivons, il arrive cependant que certains utilisateurs aient des intérêts radicalement différent. C’est pour cela qu’il est parfois utile d’incorporer des mécanismes qui ameneront les utilisateurs à se comporter de manière appropriée en suivant les règles établies par la communauté en question. En effet, un système bien conçu de récompenses et de sanctions (adapté à la façon dont chaque individu utilise le réseau) peut souvent résoudre des problèmes que la technologie seule ne pourrait pas résoudre. Un système d’incentifs (économiques ou autres) peut ainsi fournir des outils supplémentaires pour faciliter l’auto-régulation de la communauté, en fournissant un feedback positif aux utilisateurs qui se comportent bien et une sanction à ceux qui ne respectent pas les règles du jeu. Ces mécanismes peuvent être incorporés directement au niveau du protocole même – tels que BitTorent qui propose un système de rationalisation des transferts afin de ne permettre aux utilisateurs de télécharger des fichiers que s’ils permettent aux autres de télécharger les leurs – mais aussi au niveau de l’interface, ou de la communauté. C’est le cas, par exemple, de Tripadvisor, qui permet aux utilisateurs de voter pour les meilleurs récensions de voyage, afin d’augmenter la réputation des auteurs qui obtiendront donc une plus grande reconnaissance au sein de la communauté.

primaveradefilippi

More Posts

Interview avec Simone Basso (NEXA):
Sur le compromis entre décentralisation et contrôle

Pensez-vous qu’il existe un compromis entre (1) le degré de décentralisation d’une architecture et (2) le degré de contrôle qui peut être exercé sur cette architecture – notamment dû au fait que de nombreuses architectures décentralisées ont été expressément conçues pour échapper au contrôle (Freenet, Tor, etc) ?

Plus grand est le degré de décentralisation d’une architecture, plus il sera difficile de la contrôler. Alors que toute architecture centralisée (e.g. cloud computing) est facilement contrôlée, toute architecture décentralisée (tels que la plupart des réseaux pair-à-pair) ne se pose pas facilement au contrôle. Cela dépend notamment du nombre d’acteurs concernés et de leur fonctions réciproques : alors que dans le premier cas, il est possible d’identifier un acteur qui est responsable et qui gouverne les activités de tous les autres, dans le second cas, il existe un très grand nombre d’acteurs qui interagissent et coopèrent de façon symétrique, sans qu’aucun d’eux ne puisse contrôler ce que font les autres.

Cette relation entre décentralisation et contrôle peut être illustrée sur un axe cartésien qui représente le degré de décentralisation sur l’axe des ordonnées et le degré de contrôle sur l’axe des absisses.

Il est cependant important de noter que ce compromis – entre décentralisation et contrôle – peut entraîner un cercle vicieux : plus une architecture est décentralisée, plus il est difficile de la contrôler ; de nouvelles méthodes sont ainsi développées afin d’assurer le contrôle de ces architectures par les autorités, ce qui poussent les communautés numériques qui ont un intérêt à échapper à ce contrôle à développer de nouveaux dispositifs encore plus décentralisés et difficiles à contrôler.

Un exemple peut illustrer ce problème : à l’origine, chaque application utilisait une porte spécifique (e.g. porte 80 pour le web, porte 20/21 pour le ftp, etc) ; il était donc possible pour les fournisseurs d’accès Internet (FAI) d’identifier  le « type » de trafic passant par leurs réseaux en analysant simplement la porte à laquelle les paquets étaient adressés. Cela rendait possible, par exemple, de bloquer tout le trafic à provenance ou à destination de certains réseaux pair-à-pair pour le partage de fichiers. Aujourd’hui, la plupart des dispositifs pair-à-pair utilisent des portes aléatoires afin de ne pas permettre aux FAI d’identifier (et de censurer) leur trafic. Les FAIs ont donc commencé à analyser le contenu des paquets avec les technologies de Deep Packet Inspection, ce qui a mené un nombre croissant d’utilisateurs à chiffrer leurs paquets pour échapper à ce contrôle. Aujourd’hui, de nouvelles techniques sont en train d’être étudiées afin d’identifier la nature du trafic en dépit du fait que les paquets soient chiffrés : l’analyse statistique des paquets sur certains protocoles a permis le développement de nouvelles techniques de data mining qui se basent sur les caractéristiques des paquets analysés (e.g. leur fréquence ou leur taille) pour en déterminer la nature. Par exemple, en analysant la proportion entre les paquets en entrée et les paquets en sortie, il est possible d’identifier s’il s’agit d’un client (lorsque le nombre de paquets en entrée est supérieur au nombre de paquets en sortie), d’un serveur (lorsque le nombre de paquets en sortie est supérieur au nombre de paquets en entrée), ou d’un dispositif pair-à-pair (lorsqu’il y a une sorte d’équilibre entre le nombre de paquets en entrée et le nombre de paquets en sortie).

*** 

Est-il possible de contrôler les opérations de ces architectures sans en modifier la structure, i.e. sans détruire une technologie qui présentent plusieurs avantages, notamment en termes de liberté d’expression et tutelle de la vie privée ?

Bien que les architectures décentralisées permettent d’échapper au « contrôle à  grande échelle » en éliminant la possibilité d’accéder à une structure centrale (ou « nœud central » qui gouverne le réseau), il est néanmoins possible de contrôler les opérations de ces architectures et les communications entre pairs à différents niveaux.

Tout d’abord, bien qu’une architecture soit décentralisée, il y a toujours un point de départ – que ce soit le « tracker » ou le « bootstrap node » – qui permet aux nouveaux utilisateurs de découvrir leurs pairs. En observant le trafic en provenance ou à destination de ces nœuds, il est possible d’identifier les pairs auxquels ils sont connectés. Bien qu’il ne soit (théoriquement) pas possible de monitorer les communications entre pairs, il est parfois possible d’intercepter ces communications par le biais d’un déguisement (i.e. en s’appropriant temporairement l’adresse IP de l’un des pairs qui prennent part à la communication).

En effet, il est important de rappeler qu’il est impossible de communiquer sur le réseau sans prendre le risque que cette communication soit interceptée. Par exemple, de nombreux réseaux pair-à-pair sont infiltrés par des « espions » qui ont pour objet d’espionner les activités de leurs pairs. Ce problème est amplifié par les externalités du réseau : plus un nœud est « connecté » (i.e. plus grand est son « swarm »), plus grands seront les risques que ce nœud soit effectivement contrôlé.

Enfin, de nombreuses autres techniques peuvent être employées pour intercepter les communications des internautes, quel que soit le type d’architecture sur lequel ils communiquent : e.g. par l’intermédiaire de virus ou de spyware installés directement sur leurs ordinateurs.

Par conséquent, un très grand nombre de variables doivent être considérées pour échapper au contrôle des autorités. La décentralisation d’une architecture est seulement un des moyens disponibles aux internautes pour rendre leur identification plus difficile – que ce soit dans le but de commettre des actes illicites ou dans le but de préserver leur vie privée et leur liberté d’expression. D’autres mécanismes fondés sur des protocoles de communication extrêmement complexes, des technologies de chiffrages et des mécanismes d’authentification extrêmement sophistiqués peuvent être utilisés, en complément ou en supplément aux architectures décentralisées.

Il s’agit, en définitive, d’établir une balance entre « paranoïa » et « efficience ». La plupart des réseaux pair-à-pair privilégient l’efficience : ils ont un intérêt à faciliter la recherche de pairs pour permettre aux utilisateurs de communiquer ou de transférer des fichiers le plus rapidement possible. D’autres réseaux utilisés pour l’échange de secrets militaires ou de documents pédophiles adopteront, eux, une architecture des plus décentralisée en combinaison avec un protocole des plus complexes – leur objectif n’étant pas le transfert efficace de fichiers mais la difficulté de se faire identifier.

***

Est-il possible d’identifier une solution qui permettrait d’échapper à cette dichotomie, afin de bénéficier des avantages fournis par les architectures décentralisées, tout en assurant un certain degré de contrôle sur leurs opérations ?

Il y a trois possibilités différentes qui permettent de contrôler une architecture décentralisée:

(1) Censure des architectures décentralisées, en interdisant le protocole ou en le modifiant afin d’assurer le contrôle de la part des autorités. Cela a cependant l’inconvénient de pousser les communautés numériques à développer des mécanismes toujours plus compliqués pour échapper au contrôle.

(2) Introduction d’une police informatique qui a pour but de superviser les opérations d’un réseau et, le cas écheant, de s’infiltrer dans le réseau afin de le démanteler.

(3) Collaboration avec les internautes qui ont un intérêt à faire appliquer les règles au sein du réseau. Par exemple, de nombreux réseaux pair-à-pair pour le partage de fichiers ont adopté des règles qui encouragent les utilisateurs à partager leur fichiers, avec des mécanismes fondés sur un équilibre entre le nombre de fichiers partagés et le nombre de fichiers téléchargés (c.f. BitTorent “tit-for-tat” fondé sur le volume d’échange). De tels mécanismes peuvent être implémentés, par analogie, à d’autres réseaux pair-à-pair dont le but n’est pas le partage de fichiers, mais la communication en ligne. Au lieu de se fonder sur le volume d’échange, ces mécanismes peuvent, par exemple, se fonder sur un système de réputation – où les utilisateurs qui proposent des contenus offensifs (e.g. pornographiques ou illicites) auront une mauvaise réputation et seront donc pénalisés. L’idée est d’incorporer la réputation des utilisateurs avec leur possibilité d’intéragir avec les pairs et de bénéficier des fonctionalités du réseau. Cela demande cependant la collaboration des autres utilisateurs du réseau (ou d’une force de police spécifique) qui auront la responsabilité de “signaler” (to flag) les utilisateurs malveillants. Ces derniers maintiennent toutefois un certain pouvoir dans la mesure où ils ont la possibilité de “tricher” (e.g. en créeant des nouvelles identités) ou tout simplement de se déplacer sur un autre réseau. L’objectif n’est pas pas celui de rendre le contrôle absolu (car ce n’est pas possible), mais tout simplement de décourager les utilisateurs à se comporter de façon non légittime (i.e. de désobéir aux règles du réseau) en pénalisant ce type de comportements.

primaveradefilippi

More Posts

L’intérêt de créer une base de données est de faire émerger des corrélations utiles entre des paramètres différents. Dans une perspective juridique, l’analyse des données brutes nous a permis d’analyser les caracteristiques des dispositifs étudiés jusqu’à présent, afin d’extraire des statistiques et de faire émerger des critères d’analyse. La conception de cette base de données a été faite en plusieurs étapes:

• Nous avons tout d’abord identifié les éléments juridiques qui peuvent être affectés par les architectures distribuées, où du moins dont la pertinence est susceptible d’être remise en question par les dispositifs étudiés : les questions de  responsabilité, les problèmes de juridiction, de propriété intellectuelle, etc.

• Nous avons ensuite créé des catégories brutes que nous estimions pertinentes pour l’analyse des conséquences ou des enjeux juridiques soulevés par ces dispositifs. Nous avons ainsi identifié plusieurs facteurs avec des répercussions juridiques, que ce soit d’un point de vue contractuel (données personnelles, contenus, technologies DRM, responsabilités, transationalité, et jurisprudence) et de l’architecture (gouvernance, monitoring, logging, sécurité, etc).

• Enfin, nous nous sommes rendu compte que pour certains dispositifs, il n’y a pas ou très peu d’information ou de matériel de nature contractuelle. C’est le cas surtout des dispositifs à architecture fortement distribuée. Nous avons donc réalisé qu’il ne suffit pas de remplir les éléments contractuels et juridiques de chaque dispositif, mais qu’il est aussi nécessaire d’identifier l’impact des caractéristiques structurelles et fonctionnelles de ces dispositifs sur les questions ou enjeux juridiques préalablement identifiés (e.g. dans le cas où les règles sont déterminés automatiquement par le protocole ou l’infrastructure technique).

Nous avons ainsi produit une grille d’analyse qui relie les attributs contractuels, structurels ou fonctionnels des dispositifs pair à pair avec leur conséquences (positives ou négatives) sur les questions de droit. Cela nous a permis, notamment, de catégoriser les dispositifs étudiés en différents types d’architectures distribuées et d’identifier les questions juridiques soulevées par chacun de ces types. Les principales problématiques identifiées sont les suivantes:

(1) Sécurité

Les technologies pair à pair (P2P) se basent sur l’interaction de « pairs » les uns avec les autres. Des risques de sécurité peuvent donc se présenter sous forme d’abus de  confiance entre pairs.

• Cybercriminalité: Les cyber-criminels sont susceptibles d’utiliser les technologies P2P pour communiquer, partager des information ou faire de la contrebande de façon entièrement anonyme.

• Attaques: De nombreuses attaques peuvent aussi être réalisées grâce aux technologies P2P. Il s’agit, notamment, d’attaques visées à entraver le fonctionnement des réseaux P2P (par la modification ou l’intoxication des indices de table de routage), des attaques de type Denial of Service (DoS), impliquant l’envoi d’un nombre massif de requêtes entre pairs afin de rendre certaines portions du réseau inutilisables ; des attaques de Spoofing, exploitant les réseaux P2P afin d’attaquer des cibles tierces, tels que des sites Web ; ou, tout simplement, de l’introduction de virus ou autres logiciels malveillants (tels que des Botnets, Zombies ou chevaux de Troie) lors du partage de fichiers à l’aide d’applications P2P – dans le but de contrôler ou de compromettre les ordinateurs des utilisateurs.

(2) Droit à la vie privée et confidentialité des données

Etant donné la facilité d’utilisation de nombreuses applications P2P, certains utilisateurs ne sont pas suffisamment informés pour réaliser les implications dérivant de l’utilisation de ces applications, facilitant ainsi les attaques à la vie privée et/ou la perte de confidentialité des données.

• Anonymat: Certains dispositifs P2P emploient des technologies de chiffrement pour toutes les communications qui passent sur le réseau et utilisent des méthodes particulières de routage (e.g. onion routing) de façon à ce que les nœuds maintiennent un fort degré d’anonymat, protégeant ainsi la vie privée des utilisateurs. Cependant, la plupart des dispositifs P2P (tel que le système de partage de fichiers BitTorrent) exposent directement l’adresse IP des utilisateurs, ce qui permet potentiellement aux autres pairs dans le réseau de connaître l’identité des pairs qui partagent ou qui téléchargent certaines ressources.

• Contrôle tiers: Dans un modèle traditionnel client-serveur, les données confidentielles ne sont jamais transmises ni exposées aux utilisateurs du réseau. Dans la plupart des systèmes P2P, par contre, les données des utilisateurs sont transmises dans un réseau de pairs qui ont un accès direct aux flux de données. Ces données peuvent donc être observées, utilisées et potentiellement compromises par tous les pairs qui participent à leur transmission dans les réseaux.

• Partage de fichiers involontaire: Certains utilisateurs ne comprennent pas la configuration des applications P2P (notamment en ce qui concerne les applications de partage de fichiers) et peuvent, par inadvertance, partager des fichiers personnels ou confidentiels résidant sur leurs disques durs. Dans une enquête concernant le dispositif P2P Kazaa, par exemple, il a été revélé que seulement une très petite minorité d’utilisateurs étaient effectivement au courant des dossiers qu’ils partageaient sur le réseau; de nombreux utilisateurs n’étaient pas au courant qu’ils partageaient, entre autre, leurs ressources financières, leurs e-mails, ou leurs données en cache Web.

(3) Police des communications et des contenus (droits d’auteur et autre lois assimiliées)

• Contenus illicites ou protégés: La plupart des pays interdisent ou censurent la publication de certains types de contenus, tels que la pédophilie ou les propos haineux. Certain pays interdisent aussi la reproduction et la diffusion de certains contenus, tels que les contenus protégés par le droit d’auteur. Ces lois sont difficilement enforceable dans le cas des dispositifs P2P anonymes et/ou dont les communications sont chiffrées – qui sont susceptible d’attirer des utilisateurs malveillants désirant partager des fichiers protégés par le droit d’auteur ou des contenus illicites. Les noeuds d’un réseau P2P pourraient ainsi recevoir (peut-être à leur insu) des fichiers dont la re-distribution pourraient les soumettre à une responsabilité civile ou pénale.

• La question de la preuve: En ligne, le moyen le plus commun de recueillir les preuves d’une infraction est par la collecte de données (e.g. par l’intermédiaire de trackers). C’est le moyen le plus simple et le plus rapide, mais il est souvent difficile de s’assurer que les résultats soient toujours exacts.  De plus, il est important de se rappeler que ces information ne sont que la preuve d’une activité, et ne constituent pas nécessairement la preuve d’une infraction. Un autre moyen de recueillir des preuves en ligne est celui d’adhérer à un réseau P2P et de monitorer les activités des pairs. En théorie, il suffit de collecter certaines informations de communication pour porter une action en justice. Le problème est que ces informations sont toujours plus difficile à obtenir en vue du nombre croissant de dispositifs P2P qui chiffrent les communications et qui protègent l’anonymité des utilisateurs.

(4) Identification et responsabilisation des acteurs

• Multiplication et délocalisation des acteurs: De nombreuses applications P2P répartissent une série de tâches entre de nombreux acteurs, dont l’identification et la localisation est de plus en plus difficile. Cela est d’autant plus vrai dans le cas des réseaux P2P anonymes, où il est devenu pratiquement impossible de déterminer l’identité des utilisateurs. L’anonymat des pairs est généralement assurée par des méthodes spécifiques de routage (onion routing) qui cachent l’emplacement physique de chaque noeud.

• Fragmentation des données: De plus, alors que la diffusion intégrale de contenus numériques pourrait entrainer la responsabilité pénale des utilisateurs, la plupart des contenus transférés dans les réseaux P2P sont fragmentés en des milliers de paquets transmis de façon plus ou moins aléatoire dans le réseau. Alors que, dans la mesure où il fournissait la localisation exacte de fichiers protégés par le droit d’auteur, le server central de Napster a été fermé par la police Américaine, la fragmentation des données (et des acteurs) pourrait empêcher que cette situation se reproduise dans la mesure où personne ne possède l’integrité des fichiers.

(5) Transnationalité

Un  problème fondamental des réseaux P2P porte sur leur extension au delà des frontières nationales. The Pirate Bay, par exemple, a déménagé ses serveurs à plusieurs reprises vers différents pays afin d’éviter l’action de la police. Le site a aussi menacé d’acheter une île («Sealand») pour établir sa propre compétence juridique, et, selon le site de TorrentFreak, il envisage maintenant d’envoyer ses serveurs sur un satellite dans l’espace.

• Contrefaçon transfrontalière: La transnationalité des réseaux P2P rend l’application des règles nationales extrèmement difficile.  L’infrastructure de ces réseaux est telle que des infractions se produisent dans plus d’un territoire à la fois. L’application du droit étatique est ainsi confrontée à de nombreux obstacles. La plupart des lois qui gouvernent la diffusion d’informations sur Internet sont des lois territoriales dont les règles sont susceptibles de varier d’une juridiction à une autre. Plusieurs procédures seraient donc nécessaires pour mettre fin à une infraction qui a lieu dans différents pays. De plus, la difficulté d’identifier les coupables, par rapport à la facilité pour ces derniers de se déplacer d’une juridiction à une autre, est telle qu’il est souvent improductif pour les autorités nationales de se mobiliser pour porter fin à ces infractions.

• Droit international: Les questions juridiques liées aux réseaux P2P sont très complexes et doivent être traitées sur une échelle internationale. Le principe de territorialité du droit s’oppose fortement aux dynamiques de ces nouvelles technologies dont la portée s’étend bien au-delà des juridictions nationales. L’application extraterritoriale des règles de droit est une opération complexe qui risque de créer des conflits avec les politiques institutionnelles des pays concernés. Dans un contexte où les normes juridiques développées dans un pays peuvent avoir un impact sur les politiques élaborées dans un autre pays, il est peut être nécessaire de se tourner vers l’établissement de normes internationales. Par exemple, alors que le principe du traitement national demeure un élément crucial pour les relations internationales en terme de propriété intellectuelle, l’adhésion formelle au principe de territorialité pourrait compromettre la protection effective des droits d’auteurs. Ainsi, les questions concernant les différentes formes de régulation du secteur numérique doivent essentiellement analysées dans un contexte international, tout en tenant compte des spécificités européennes et des opportunités en matière d’harmonisation juridique.

L’étape suivante sera de continuer à remplir les fiches et à affiner les catégories de la base de données en procédant à des aller-retour entre les données brutes collectées (les conditions d’utilisation, terms of use, et l’architecture des dispositifs) et les informations dérivées dans le but d’affiner les problématiques et les catégorie identifiées.

Cela nous permettra, plus tard, d’analyser les contenus de cette base de données afin de créer une ontologie juridique du domaine pour caractériser les différents types d’architectures distribuées, ainsi que les enjeux juridiques qu’elles soulèvent.

primaveradefilippi

More Posts