Les applications décentralisées de demain fondées sur le protocole de Bitcoin

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

Image: PerfectHue/Flickr

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.

We need to make sure we don’t exchange the tyranny of large online operators for the “tyranny of code” instead.

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”…

Il est temps de prendre les réseaux “mesh” au sérieux..

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

Nets of Freedom creating mesh networks. Image: Strelka Institute / Flickr

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.

Des outils de communication pair-à-pair aux outils de fabrications numérique: les enjeux juridiques de la décentralisation

Les médias numériques ont introduit de nouvelles modalités de production collaborative et décentralisée, qui se sont progressivement étendues au monde physique. Alors que la production artistique et culturelle a longtemps été considérée comme une activité individuelle, elle est aujourd’hui réalisée par de nombreux auteurs qui collaborent à la création d’une œuvre collective ou collaborative. On observe ainsi le passage d’un modèle de production centralisé (où les moyens de production sont concentrés dans les mains d’un petit nombre d’acteurs) vers un modèle de production de plus en plus décentralisé (où un grand nombre d’acteurs contribuent, par leurs propres moyens, à la production de contenus et d’information). En commençant par les communautés du logiciel libre qui ont adopté des nouvelles modalités de production basées sur la contributions volontaires de développeurs indépendants, les modalités de production collaborative et décentralisée sont aujourd’hui employées pour la production de tout type de contenus, et cela notamment avec l’émergence des communautés de la culture libre (e.g. Creative Commons).

Aujourd’hui, suite au récent développement des FabLabs, des ElectroLabs, des Medialabs, ou des Hackerspaces, ces nouvelles modalités de production sont en train de s’établir dans le domaine de la production culturelle et artistique appliquée aux objets physiques. En favorisant une approche “do it yourself” dans le domaine de l’art et du design, ces espaces utilisent des technologies innovantes pour encourager le développement de nouvelles méthodes de production culturelle et artistique basée sur la participation et l’interaction entre pairs.

Nous nous concentrerons ici sur la technologie d’impression 3D, une technologie qui a beaucoup évolué au cours des dernières années (aussi bien au niveau de la qualité que du coût) et qui pose aujourd’hui de nombreuses questions économiques, juridiques et éthiques.

Une visite à la MakerFaire de New York nous a permis de découvrir et d’explorer le fonctionnement de scanners et

Bien que de nombreux artistes et designers bénéficient déjà des nouvelles techniques de prototypage rapide, c’est grâce à la connectivité d’Internet que leur énorme potentiel peut être correctement exploité. Au-delà des avantages matériels fournis par les techniques d’impression 3D, des bénéfices plus importants dérivent en effet de l’opportunité pour de nombreux artistes ou designers de participer et de collaborer (de manière synchrone ou asynchrone) à la production décentralisée de dessins ou de modèles industriels, et de transmettre de manière instantanée des idées, des commentaires, ou des supports pédagogiques (e.g. les instructions de fabrication ou de montage).d’imprimantes 3D extrêmement sophistiqués (telle que e.g. la Replicator de Makerbot, ou la 3DTouch de Bits from Bytes). Bien qu’actuellement limités au monde des hackers, des bricoleurs et des amateurs, ces outils seraient bientôt susceptibles d’intéresser le public au sens large, dès lors qu’ils seront capables de produire des objets utiles, fonctionnels, et de qualité élevée. En effet, avec le perfectionnement rapide et progressif de la technologie d’impression 3D et la baisse du prix des appareils au fil du temps, il est possible d’imaginer que, dans un avenir relativement proche, les imprimantes 3D seront tout aussi répandue que les imprimantes 2D, et seront ainsi utilisées pour produire la majorité des objets ménagers.

L’impression 3D devient ainsi une technologie qui pourrait révolutionner les modalités de production traditionnelles, en facilitant la production décentralisée d’objets à partir de fichiers multimédia téléchargeables sur Internet – voir notamment les sites comme instructables.com, skillshare.com, etc). Ces sites mettent à disposition du public des pages où les utilisateurs peuvent communiquer et documenter le design d’un produit, ainsi que toutes les instructions nécessaires à la production de ce produit – y compris les informations nécessaires à ce que les gens puissent facilement le modifier ou l’améliorer afin d’obtenir un produit plus personalisé. À différence des techniques de production analogique, les outils de production numérique permettent en effet aux objets d’être facilement partagés, distribuées, remixés, transformés et recyclés, sans pour cela perdre ou endommager les originaux. Ainsi, la plupart de ces designs sont mis à disposition du public sous une licence libre (e.g. les licences Creative Commons) permettant aux produits d’évoluer librement et de devenir toujours plus perfectionnés au fil du temps.

Les enjeux de la décentralisation

La possibilité de produire, reproduire, modifier et remixer des objets physiques est une opportunité exceptionnelle en ce qui concerne la production et la distribution d’objets de plus en plus sophistiqués et personalisés, bien que cela comporte cependant de nombreuses questions juridiques, notamment en ce qui concerne les droits de propriété intellectuelle.

Dans un système centralisé, il est facile d’identifier les acteurs qui effectuent des activités illicites: la production d’objets en

violation des droits de propriété intellectuelle (droit d’auteur, droit des marques, ou brevets) peut être facilement poursuivi par les autorités. Or, dans un système décentralisé, il devient difficile pour les titulaires de faire valoir leurs droits contre un grand nombre d’individus qui ne contribuent que à des infractions mineures. Cela est vrai aussi bien dans le monde numérique que dans le monde physique.

En comparant avec le piratage en ligne (en ce qui concerne notamment le téléchargement illégal de contenus protégés par le droit d’auteur), on observe que, avant l’arrivée d’internet et des ordinateurs personnels, il était relativement facile pour les

autorités de contrôler le piratage et la contrefaçon, puisque les contenus illicites étaient distribués sur des support physiques et par des canaux de distribution traditionnels. Suite au développement et au succès des outils de reproduction numérique, l’application du droit d’auteur est devenu beaucoup plus difficile à contrôler sur le réseau. L’explosion du piratage en ligne et les coûts élevés nécessaires pour poursuivre les infractions individuelles d’un très grand nombre d’internautes a poussé les titulaires de droits d’auteur à faire valoir leurs droits contre les fournisseurs de services en lignes (tels que Napster, Aimster, Grokster et autres plateformes qui encouragent ou facilitent le piratage) en invoquant les principes de responsabilité secondaire. Mais dans les cas plus extrême de décentralisation qui se retrouvent dans les réseaux de communication peer-to-peer tels que BitTorrent, l’infraction des droits d’auteur reste encore difficile à éliminer.

Par analogie, dans la mesure où les outils de fabrication numériques permettent la production et la reproduction physique d’objets numériques, obtenir le design ou la copie numérique d’un objet est devenu pratiquement équivalent à l’obtention d’un objet physique, puisque cet objet peut être facilement manufacturé avec une imprimante 3D. Or, comme pour le piratage des contenus en ligne, les titulaires de droits sur des dessins ou modèles ne sont pas en mesure de faire valoir efficacement leurs droits contre les utilisateurs finaux qui utilisent les outils d’impression 3D. Il est, en effet, tout aussi difficile de contrôler et de réglementer les communications des sites et services qui permettent l’échange d’objets virtuels en 3D.

Ainsi, bien que l’impression 3D soit encore une technologie de niche dont l’impact reste relativement limité, dès lors que ces technologies seront plus communément adoptées par le grand public, leurs conséquences sur le respect et l’application des

droits de propriété intellectuelle pourraient devenir très importantes.


Compte-rendu de la journée d’étude sur les architectures distribuées

Journée d’étude du 11 mars 2013 au CERSA

Le droit et les architectures distribuées:

Concilier libertés et contrôle dans un espace ouvert et décentralisé



François Huguet (doctorant à Telecom ParisTech), Pauline Le More (Avocate au Barreau de Paris), Melanie Dulong De Rosnay (chargée de recherche à l’ISCC, CNRS), Hervé Le Crosnier (professeur à l’Université de Caen), Felix Tréguer (doctorant à l’EHESS), Primavera De Filippi (chercheuse au CERSA, CNRS), Danièle Bourcier (directrice de recherche au CERSA, CNRS),




La journée d’étude a commencé par une présentation et une discussion autour de trois cas d’études:



Faroo (dont le nom est dérivé du phare d’Alexandrie) est un moteur de recherche entièrement fondé sur des technologies pair-à-pair totalement décentralisées. Bien que le nombre de pages indexées soit encore relativement faible (environ 2 milliards de pages), le moteur de recherche s’avère cependant prometteur. Né en 2007, Faroo est alimenté par plus de 2 millions et demi d’utilisateurs, qui font tourner le logiciel sur leurs dispositifs. Cela permet la création d’une infrastructure plus flexible et dynamique – avec un impact négligeable sur les ressources informatiques: la connexion n’est utilisée que lorsqu’il n’y a pas de transfert de paquets et la charge CPU est pratiquement inexistante.  De plus, Faroo fonctionne avec une table d’indexation distribuée (Distributed Hash Table), ce qui élimine toute possibilité de contrôle centralisé.

Nous nous sommes tout d’abord interrogés sur la question du “free-riding”: est-ce que le fait d’avoir une infrastructure distribuée peut porter au free-riding de l’infrastructure en réseau ? Dès lors que les utilisateurs agrègent leurs ressources afin de créer une infrastructure communautaire qui ensuite va exploiter la bande passante fournie par les FAIs, ces derniers risquent en effet de devoir engager des coûts supplémentaires en raison du trafic généré.

Nous avons ensuite réfléchi à la question de la qualité et la neutralité des résultats fournis. Les résultats des recherches sont en effet déterminés par un algorithme de recherche dont le fonctionnement est accessible à tous (Open Source). Cela a des répercussions importantes sur les résultats des recherches: d’une part, la transparence du fonctionnement permet d’assurer une neutralité algorithmique dans la classification des résultats de recherche, d’autre part, il devient plus difficile de se protéger contre les pratiques de “search engine optimization”. De plus, étant donné qu’il est encore en version beta et avec un nombre d’utilisateurs limité, Faroo a actuellement tendance à ne renvoyer qu’un nombre limité de réponses aux requêtes de recherche puisqu’il n’indexe que les sites que les utilisateurs de Faroo visitent. À cet égard, le fonctionnement de Faroo a été confronté avec le modèle de Seeks (un méta-moteur de recherche qui recueille et réordonne les résultats fournis par d’autres moteurs de recherche – tels que Bing ou Google – pour les re-proposer dans un nouvel ordre, issue d’un compromis entre tous les résultats proposés, l’expérience de l’utilisateur et les recommandations faites par ses pairs).

D’un point de vue juridique, de nombreuses questions ont aussi été soulevées, notamment en ce qui concerne la protection des données personnelles. A priori, Faroo semblerait être un service qui permet aux utilisateurs de préserver leur vie privée, puisque les requêtes sont stockées sur l’ordinateur des utilisateurs, et non pas sur un index centralisé contrôlé par une entreprise qui pourrait les exploiter pour des finalités commerciales ou les communiquer aux autorités de justice.

En ce qui concerne les responsabilités des internautes, Hervé Le Crosnier a questionné la possibilité de considérer Faroo comme un “service d’infrastructure” – et ce qui impliquerait que tout utilisateur contribuant à l’infrastructure serait en quelque sorte “responsable” du fonctionnement de ce service distribué. Pour ce qui en est du droit à la concurrence, nous avons analysé l’effet que Faroo pourrait avoir sur les oligopoles établis (Google, Bing, Yahoo, etc), et sur la possibilité pour une architecture décentralisée telle que Faroo de pénétrer dans le marché des moteurs de recherche, en dépit des effets de réseau existants. La notion de “facilité essentielle” (définie par la CJCE comme toute infrastructure indispensable pour assurer la liaison avec des clients et/ou permettre à des concurrents d’exercer leurs activités, mais dont la duplication est impossible ou déraisonnable, pour des raisons financières ou techniques) a aussi été abordée en ce qui concerne la relation entre concurrence industrielle et concurrence déloyale.

D’un point de vue plus strictement économique, nous nous sommes interrogés sur la soutenabilité de ce système à long terme. Puisque Faroo ne prévoit aucun mécanisme visant à encourager la contribution des utilisateurs au sein de l’architecture en réseau (tel que le système de “tit-for-tat” utilisé par le réseau BitTorent), comment s’assurer que tous ceux qui utilisent le service vont également y contribuer ? Il s’agit essentiellement de considérer le système non seulement comme une architecture répartie, mais aussi comme une plateforme collaborative et participative. En termes financiers, est-ce que Faroo prévoit d’obtenir des profits en échange de ce service ? Et comment les revenus pourraient être redistribués à la communauté de pairs qui contribuent au service – étant donné que la plupart des utilisateurs demeurent anonymes ?

Enfin, dans une perspective politique, nous avons réfléchi sur les discours politiques qui tournent autour de cette plateforme. Faroo a été conçu non seulement afin de proposer une alternative aux autres moteurs de recherche centralisés, mais aussi et surtout afin de préserver la vie privée et l’anonymat des utilisateurs. Faroo peut-il donc être considéré comme une architecture technique d’émancipation citoyenne, conçue pour protéger les internautes contre les abus de pouvoir de la part des entreprises prédatrices et des États qui censurent ou qui surveillent les citoyens sur le Net ?



Tor (The Onion Router) est un réseau distribué conçu pour faciliter la communication anonyme. Basé sur le mécanisme de routage en oignon (onion routing), Tor introduit une nouvelle couche de communication cryptographiée sur le réseau de façon à camoufler non seulement les contenus, mais aussi l’origine et la destination des communications. Le principe du routage en oignon est un mécanisme par lequel les données sont encryptées à plusieurs reprises avec des clés de cryptages différentes, pour être ensuite envoyées à plusieurs nœuds dans le réseau. Les données sont donc protégées par plusieurs couches de cryptographie, qui seront progressivement retirées par chaque nœud, jusqu’à ce qu’elles arrivent à leur destination finale où elles seront à nouveau lisibles. Afin d’assurer une communication anonyme, les données transférées sur le réseau Tor doivent passer au minimum par trois routeurs différents. L’origine des communications n’est connue que des routeurs d’entrée, et la destination des communications n’est connue que des routeurs de sortie. Les autres nœuds du réseau sont des routeurs intermédiaires qui ne connaissent ni la provenance ni la destination des paquets qu’ils transfèrent.

Nous avons commencé par analyser plus en détail le fonctionnement technique du réseau TOR. La communication au sein du réseau est fondée sur 3 couches de routage: avant de rejoindre le site de destination, chaque paquet passe par un premier nœud (qui connait l’adresse IP d’origine), un deuxième nœud (qui ne connait ni la provenance, ni la destination des paquets), et un troisième nœud (qui connait uniquement la destination des paquets). Chaque paquet est crypté avec une clef correspondant à chacun des 3 nœuds intermédiaires, afin que aucun de ces nœuds ne puisse connaître à la fois l’origine et la destination des paquets.

Nous nous sommes ensuite concentrés sur les applications de cette technologie, qui – malgré sa neutralité – est souvent utilisée pour des finalités illégales. Nous avons analysé notamment le cas de Silkroad: une place de marché sur Internet qui a pour particularité d’utiliser le réseau Tor pour assurer l’anonymat à la fois des acheteurs et des vendeurs. Un autre élément permettant l’anonymat se situe dans l’utilisation quasi-exclusive sur le site de Bitcoin, une monnaie électronique dont la possession n’est pas nominative et qui est complètement séparée du système bancaire international. Bien qu’en théorie on puisse acheter et vendre n’importe quelle marchandise sur le site, l’anonymat même relatif du service fait qu’il est utilisé essentiellement pour vendre ou acheter ce qui ne peut que difficilement être acheté ou vendu légalement, notamment desstupéfiants et des armes (voir cet article: Online drug dealers back on Silk Road after mysterious two-week outage).

Cela nous a mené à réfléchir sur les enjeux juridiques soulevés par TOR, qui présente de nombreux avantages et fonctionnalités qui ne sont pas illégales en tant que telles, mais qui entraînent cependant un besoin pour l’État de surveiller les communications qui passent sur le réseau afin de pouvoir assurer l’ordre public. En cas d’utilisation illégale, tel que par exemple le téléchargement d’images pédophiles, la police va récupérer l’adresse IP qui s’est connectée au serveur et va assumer qu’il s’agit de l’adresse du visiteur en question – bien qu’il s’agisse en fait de l’adresse du nœud de sortie. C’est pour cette raison que TOR maintient une liste de tous les nœuds de sorties disponibles à chaque instant.

Le dilemme est donc le suivant : si les nœuds de sortie ne sont pas considérés responsables pour le trafic qu’ils transfèrent, tous les criminels vont être amenés à se présenter comme nœud de sortie afin de pouvoir effectuer des activités illégales sans devoir se cacher. Inversement, si les nœuds de sorties sont considérés responsables du trafic qui leur passe à travers, plus personne ne se proposera en tant que nœud de sortie, et le réseau TOR sera donc amené à mourir.

Pour répondre à ce dilemme, il est tout d’abord nécessaire de distinguer entre le rôle actif ou passif des intermédiaires. Un intermédiaire passif (tel qu’un simple canal qui transfère tout simplement des paquets) est soumis à un régime de responsabilité limitée. Un intermédiaire engagé qui a un rôle plus actif sera par contre soumis à un régime de responsabilité plus stricte. Les architectures décentralisées telles que le réseau TOR utilisent les utilisateurs du réseau comme des simple tuyaux. Le problème c’est que en ne regardant que les logs, il est impossible de déterminer si le nœud de sortie avait un rôle actif ou passif dans la communication.

Nous nous sommes donc interrogés tout d’abord sur la question de la responsabilité juridique des FAI et des hébergeurs – pour étendre ensuite la question à l’usage des VPN et des proxys, pour savoir s’ils sont tenus responsable des activités illicites de leur utilisateurs. Tout d’abord, nous avons remarqué que, alors que – d’après la Directive Européenne sur la conservation des données – les FAIs sont soumis à l’obligation de conserver les données de leurs utilisateurs pendant plusieurs années, afin de les dévoiler aux autorités judiciaires en cas de besoin, cette obligation ne s’étend pas aux VPN qui ne sont pas soumis à la directive et qui ne sont donc a priori pas obligés de logger les communications qu’ils transfèrent. De plus, il n’y a pas actuellement d’obligation particulière de surveiller les communications pour les intermédiaires qui se comportent en tant que “mère conduits” (tel que définis par la directive eCommerce et article. L32-3-3 du Code des postes et télécoms français) – et que l’application d’une couche de chiffrement (ou déchiffrement) ne remet pas en cause ce statut qui est purement technique. Dans le cas d’un VPN, il est possible que l’opérateur du VPN soit contraint à collaborer pour faire identifier l’auteur de communications litigieuses (e.g. en demandant les logs) même si ce cas de figure n’est pas explicitement reconnu dans la Directive eCommerce. De même, un proxy d’anonymisation pourrait être visé par une action en cessation – afin de #bloquer, par exemple, certaines informations en provenance ou à destination d’une adresse IP spécifique. Le manque de jurisprudence rend la spéculation difficile, mais cela pourrait conduire à contraindre un nœud Tor de cesser complètement son activité. Enfin, en ce qui concerne le régime de responsabilité des individus qui agissent en tant qu’intermédiaires sur Internet, la situation change à selon des pays. En France, par exemple, la loi HADOPI considère que toute personne qui ne sécurise pas sa connexion commet un délit de négligence, alors qu’aux États-Unis et en Allemagne, les titulaires de connexion Internet sont exemptés de responsabilité s’ils arrivent à prouver que les activités illégales ont été commises par une autre personne.

La difficulté principale est due au fait qu’il est très difficile d’établir un compromis entre anonymat et sécurité. Il s’agit d’une dichotomie qui ne peut être résolue que par une réponse binaire: veut-on contrôler toutes les communications sur le réseau ou bien accepter la liberté de communications anonymes? Si on veut préserver l’anonymat, il faut renoncer à réguler les communications (en éliminant des lois telles que le droit d’auteur ou le loi contre la diffamation) et sauvegarder le rôle des intermédiaire passifs, au risque de faciliter l’activité de certain criminels. Si on ne veut pas autoriser l’anonymat, il faut dans ce cas responsabiliser tous les intermédiaires, détruire la structure décentralisée du réseau et établir des points de contrôle fiables et centralisés (tels que les FAIs, les hébergeurs).

Enfin, nous avons analysé la possibilité de détourner le réseau Tor, afin d’espionner les communications des utilisateurs du réseau. Il est en effet possible pour le nœud de sortie de savoir exactement à quoi les gens se connectent et quel est le contenu de leurs communications (dans la mesure où elles n’ont pas été cryptées préalablement).

Pour terminer, Hervé Le Crosnier nous a expliqué le mythe de l’utopie numérique, l’idée de pouvoir échapper à toute forme de contrôle grâce aux technologies. En combinant les technologies de cryptage, Tor, Bitcoin, etc, il est possible d’assurer un niveau très élevé d’anonymat, mais ces technologies ne vont protéger que l’émetteur, et non pas les correspondants ou les récepteurs. De plus, faut-il toujours faire confiance aux nœuds d’entrée sur le réseau Tor ? Comment éviter l’infiltration du réseau par des services secrets ou des cyberflics? S’il est vrai qu’il est souvent difficile d’appliquer les règles de droit sur un réseau de nature transnationale tel qu’Internet, la technologie à elle seule ne peut pas non plus réguler le réseau. Il faut se munir de plusieurs outils de protection, mais la sécurité ne peut être assurée que par l’utilisation pratique de ces outils dans un contexte social.

En conclusion, nous avons rappelé que la régulation du réseau ne se fait pas uniquement par des normes juridiques ou techniques, mais aussi par l’intermédiaire de normes sociales. Ces différents systèmes de normes interagissent les uns avec les autres. L’avancée des technologies numériques demande une modification des lois, mais les réformes du droit poussent aussi au développement de nouveaux outils technologiques. En effet, la production de nouvelles règles de  droit peut avoir des effets inattendus: plus elles essaient de contrôler le réseau, plus sera encouragé le développement de réseaux décentralisés visant justement à échapper à ce contrôle. En France, par exemple, la loi HADOPI a poussé de nombreux internautes à utiliser des réseaux pair à pair pour le partage des fichiers en passant par des VPN ou par le réseau TOR. Ces technologies rendent le travail de la police et des services secrets encore plus difficile, notamment lorsqu’il s’agit d’arrêter de vrais criminels ou des terroristes. Il est donc important d’introduire plus de souplesse pour les infractions les moins graves afin de ne pas encourager les infrastructures décentralisées à se développer de manière encore plus sophistiquées pour la réalisation d’infractions encore plus graves.



Commotion Wireless est un projet open source basé sur la construction d’un réseau maillé non hierarchisé (topologie mesh-network), Dans ce type de réseau (filaire ou non) tous les hôtes forment ainsi une structure en forme de filet. Chaque nœud doit recevoir, envoyer et relayer les données.  Si un hôte est hors service, ses voisins passeront par une autre route. Un réseau maillé peut relayer les données à l’instar d’un déluge ou un itinéraire, mais dans le second cas le réseau doit prévoir des connexions sans interruption ou calculer une déviation dont les communications sont cryptées, et dont l’aspect décentralisé est censé compliquer toute surveillance (y compris politique).

Contrairement aux connexions fixes, les utilisateurs n’ont pas besoin de s’engager auprès d’un FAI pour participer au réseau, et ils sont seulement identifiables par le matériel utilisé. Chaque appareil connecté au réseau est un nœud du réseau. Il émet et reçoit des informations via ondes wi-fi, et propage ainsi l’étendue du réseau. Le but de ce réseau mesh est de fournir un moyen de communication anonyme, décentralisé, sécurisé, et incontrôlable. Commotion permet de constituer des réseaux mesh autonomes à partir de terminaux fonctionnant sur les fréquences Wi-fi. Bien qu’aucune connexion à un autre réseau (internet par exemple) ne soit nécessaire, tout ordinateurs, téléphones mobiles et smartphones ou autre dispositifs connectés à Internet peuvent en faire profiter l’ensemble du réseau.  Semblable à d’autres réseaux mesh, tels que openmeshproject , Commotion se distingue par le fait qu’il a obtenu 2,3 M$ de Google et 2 M$ de l’état américain.

Ainsi, à différence des deux dispositifs présentés auparavant – qui nécessitent un point de connexion centralisé à un FAI – il s’agit ici d’une forme de décentralisation totale: non seulement au niveau logiciel ou numérique, mais aussi au niveau de l’infrastructure du réseau. Les utilisateurs du réseau mesh n’ont pas besoin de se connecter à un FAI, ils peuvent se connecter directement à leurs pairs. De plus, pour des raisons de sécurité, il est prévu qu’un système de chiffrement soit également mis en place afin d’assurer la protection et l’anonymat des données.

Ainsi, Commotion serait révélateur de cette fuite en avant pour échapper à la surveillance croissante des États. Alors qu’avec TOR, il y a toujours le risque qu’un FAI gère les communications en sortie de réseau, dans le cas du réseau mesh, les utilisateurs peuvent échapper à toute surveillance en évitant directement les FAIs. En effet, bien qu’un gateway soit nécessaire pour se connecter à Internet, il est possible de créer des sous-réseaux communautaires qui seront invisible aux internautes.

Or, en ce qui concerne les applications de Commotion, il a été jusqu’à présent utilisé essentiellement pour fournir des connections Internet dans des pays ou des quartiers pauvres, ou là où des catastrophes naturelles ont détruit les infrastructures du réseau (e.g. Fukushima, Haiti, ouragan Sandy). Commotion est utilisé aussi comme un projet communautaire avec un objectif pédagogique.

D’un point de vue technique, l’architecture mesh du réseau est en quelque sorte une reconstitution du réseau Internet tel qu’il avait été originellement conçu, comme un outil militaire qui peut se ré-organiser de manière dynamique selon des disponibilités d’infrastructures. L’avantage du réseau mesh par rapport au réseau Internet est qu’il est indépendant, plus robuste et résilient.

Nous nous sommes ensuite intéressés à l’applicabilité du droit sur ce type de réseaux. S’il n’y a plus d’entité centralisé (tel que les FAIs) qui peuvent gérer les communications, la surveillance doit se faire au niveau du dispositif. Il s’agit des technologies de trusted computing qui permettent de tracer et de déterminer la légitimité de chaque action des utilisateurs. Cela se retrouve dans la manière dont l’architecture d’Internet est en train d’évoluer, se transformant progressivement en un réseau de plus en plus intégré verticalement – avec un contrôle qui va du cloud computing au dispositif des internautes.

Pour conclure, nous prévoyons un développement rapide des réseaux mesh dans les années à venir, avec la multiplication des capteurs et des émetteurs qui peuvent être stratégiquement positionnés dans la ville, et le déploiement de dispositifs mobiles de plus en plus petits qui peuvent se transporter facilement (par ex.. wearable computing).

Le problème est que le déploiment d’un réseau mesh de grande dimension ne pourra se faire que si l’État décide de libérer les fréquences blanches (fréquences actuellement non utilisées) car les fréquences Wifi seront rapidement saturées. En parallèle avec les radios libres, la libéralisation du spectre a permis des évolutions politiques importantes, bien que aujourd’hui – 20 ans plus tard – il y a eu de nombreuses déceptions par rapport aux attentes initiales.

Felix Tréguer nous informe que, au niveau européen, il n’y a qu’une très faible prise de conscience des enjeux économiques et politiques liés à la libéralisation des fréquences radios. Alors que le Parlement est relativement sensible à l’utilisation des fréquences blanches pour réduire la fracture numérique, la Commission se place plutôt dans une logique d’ouverture orientées vers le partage des fréquences entre les grands opérateurs. Bien que la Commission soit sensible aux arguments sur la nécessité d’accroître l’accès à Internet, elle s’oriente uniquement d’un point de vue économique, dans le but de créer un grand marché numérique pour relier les internautes aux grandes plateformes commerciales. D’après lui,  le problème est lié au fait que les personnes qui s’occupent de ces questions sont des ingénieurs qui ne comprennent pas toujours suffisamment l’importance de se mobiliser au plan politique. Inversement, il est parfois difficile pour les membres de la société civile mieux insérés dans les milieux institutionnels de maîtriser l’ensemble des enjeux techniques.


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.

Giancarlo Ruffo: Sur la gouvernance des architectures décentralisées

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é.

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

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.

Architectures distribuées: du Cloud au P2P

Qu’est-ce qu’une architecture distribuée? Alors que le terme n’a pas été défini de manière officielle ni par la NIST (National Institute of Standards and Technology) ni par l’AFNOR (Association française de normalisation), nous nous sommes engagés à explorer quel est le vrai sens de ce terme.

Définie par Wikipedia comme toute architecture dont les ressources ne se trouvent pas au même endroit ou sur la même machine, le concept d’architecture distribuée (ou informatique distribuée) s’oppose habituellement à celui d’architecture centralisée représentée par les architectures traditionnelles client-serveur.

Or, une analyse plus approfondie nous a mené à penser qu’il existe plusieurs types architectures distribuées qui se distinguent selon leur nature et leur fonctions.

Il s’agit tout d’abord de distinguer entre les architectures distribuées au niveau de leur infrastructure technique – implémentée dans une optique distribuée (tel est le cas du Pair à Pair ou du Cloud Computing) et les architectures distribuées au niveau de leur contenus – produits ou développés dans une approche distribuée (tel est le cas de la plupart des plateformes de production collaboratives à la Wikipédia). Pour des raisons de clarté et de simplicité, nous avons décidé, dans le cadre de notre recherche, de nous concentrer uniquement sur les architectures distribuées au niveau de l’infrastructure.

Il s’agit ensuite d’analyser le niveau de centralisation de ces architectures – qui peuvent se situer sur un continuum entre centralisation totale – avec une gouvernance de type hiérarchique où les ressources sont contrôlées et gérées par une entité centrale (tel est le cas du Cloud Computing) et décentralisation totale – avec une gouvernance de type égalitaire où les ressources sont contrôlées et gérées par un système symétrique de pairs (tel est le cas de la plupart des réseaux P2P). Sans vouloir prendre de position immédiate – afin de ne devoir exclure a priori aucune de ces architectures de la portée de notre recherche – nous avons décidé d’analyser les enjeux sociaux-économiques, juridiques et techniques posées par chacune de ces architectures, afin de déterminer si, et comment, elles se différencient les unes par rapport aux autres.

Cloud Computing

Dans le scénario traditionnel client-serveur, les fichiers sont stockés dans un serveur central, d’où ils peuvent être téléchargés et importés par un client. Certains dispositifs sont donc chargés de fournir les données que d’autres dispositifs utilisent. Au premier abord, le Cloud Computing ressemble à un environnement traditionnel d’hébergement où un serveur central existe dans le Cloud (i.e. dans un datacenter) comme une ou plusieurs instances de serveur. En réalité, cependant, le modèle de Cloud Computing est beaucoup plus sophistiqué.

Défini par la NIST comme un service à la demande, qui comporte une mutualisation mesurable de ressources informatiques (en terme de consommation), rapidement élastiques (à selon d’une variation des besoins) et accessibles sur l’ensemble d’un réseau, lorsque l’on parle de Cloud Computing, on ne parle pas d’une technologie nouvelle, mais plutot d’une nouvelle façon de présenter des technologies qui existaient auparavant.

Le Cloud Computing, c’est tout simplement un nouveau modèle économique : une nouvelle façon de livrer des ressources informatiques (physiques ou virtuelles) fournies en tant que service. Le Cloud Computing représente ainsi une véritable révolution qui consiste en une nouvelle forme d’ « informatique à la demande » (utility computing).

Il existe, toujours selon la NIST, trois différentes catégories de services Cloud Computing:

  • Infrastructure as a Service (IaaS), pour la fourniture d’infrastructures de calcul et de stockage en ligne ;

  • Platform as a Service (PaaS), pour la fourniture de plateformes de développement en ligne dans un environnement contrôlé ;

  • Software as a Service (SaaS), pour la fourniture d’applications accessibles en ligne, sans avoir besoin d’installer aucun logiciel.

Ces ressources informatiques sont externalisées sur des serveurs distants, où elles seront  ensuite partagées et mutualisées à l’intérieur de machines virtuelles  afin de pouvoir être successivement exploitées à n’importe quel moment et sur n’importe quel ordinateur ou appareil numérique – le tout, suivant des systèmes complexes d’infogérance qui reposent sur des mécanismes d’isolement logiques pour séparer et protéger les données des différents clients.

Une caractéristique essentielle des services de Cloud Computing est l’implication de différents acteurs qui entrent en jeu pour fournir un service aux clients:

1. Les opérateurs du Cloud Computing qui fournissent des ressources aux prestataire de services ;

2. Les prestataires de services (ou Cloud brokers) qui s’appuient sur une ou plusieurs plateformes de Cloud Computing pour fournir un service aux utilisateurs finaux ;

3. Les utilisateurs finaux qui utilisent effectivement les services fournis par les prestataires de services hébergés sur des plateformes de Cloud Computing.

En termes d’enjeux, bien qu’offrant une série d’avantages aux utilisateurs du réseau, le Cloud Computing comporte cependant des risques importants dans la mesure où les ressources informatiques sont désormais détenues par des grandes entreprises qui opèrent dans une optique de marché orientée vers la maximisation des profits. Le paysage numérique se transforme ainsi en un réseau de plus en plus centralisé, où la production et la diffusion d’information sont réglementées par un très petit nombre de grandes entreprises. Alors que les ressources se déplacent vers des systèmes centralisés avec une énorme puissance de traitement et de stockage des données, les dispositifs des utilisateurs se transforment eux en de simples « terminaux » de moins en moins performants. Cela comporte des implications importantes pour les utilisateurs du réseau, qui perdent non seulement le contrôle sur leur propres données, mais aussi la possibilité de déterminer la façon dont celles-ci seront utilisées par eux-mêmes ou par d’autres.

Pair à Pair

Les technologies pair à pair se distinguent fortement du modèle traditionnel client-serveur, caracterisés par un serveur qui fournir des ressources aux clients qui les consomment. Par opposition, dans un système pair à pair (P2P), les pairs sont à la fois consommateur et le fournisseur de ressources.

Les réseaux P2P rassemblent et relient entre elles les ressources des utilisateurs connectés au réseau de façon à créer une infrastructure dynamique et performante sans aucun investissement de nature financière ou autre. Les pairs participant au réseau mettent une partie de leurs ressources à la disposition des autres pairs connectés au réseau, qui vont gérer le partage et la redistribution de ces ressources. Étant donné que ces pairs sont tous égaux entre eux, ils participent tous de la même manière au réseau : tous ont une responsabilité égale dans le traitement des données sans aucune distinction de type client / serveur.

Comme dans le cas du Cloud Computing, les dispositifs P2P mettent en place une architecture virtuelle et distribuée qui subsiste au-dessus (et indépendamment) des réseaux physiques. Plusieurs couches de virtualisation sont utilisées pour faciliter les tâches de découvertes et d’indexation des ressources (i.e. pour identifier les autres pairs connectés et pour déterminer l’emplacement des fichiers). Une fois l’emplacement des ressources identifiés, les contenus sont souvent échangés directement sur le protocole Internet sous-jacent du réseau. Les systèmes de P2P anonymes mettent en œuvre des couches supplémentaires de routage (e.g. onion routing) de manière à occulter la véritable source de ces ressources.

Néanmoins, en opposition avec le Cloud Computing où les applications sont accessibles en ligne, pour pouvoir accéder aux réseaux P2P, les utilisateurs doivent installer une application qui utilise un protocole commun de réseau afin de s’intégrer dans un réseau de pairs distribué. C’est ainsi que les utilisateurs peuvent accéder aux ressources du réseau, tout en maintenant le contrôle des fichiers et des applications installés sur leurs propres dispositifs. Dans la mesure où ils détiennent le contrôle sur l’infrastructure et les moyens de communication, ainsi que sur les contenus qui en résultent, les membres d’un réseau pair à pair sont moins susceptibles de se faire exploiter par les grands fournisseurs de services Internet. Enfin, en vue de leurs architectures décentralisées, ces systèmes facilitent le partage d’informations, tout en rendant la censure et la surveillance très difficile.

Architectures distribuées

En dépit de leurs différences substantielles, ces deux types d’architectures distribuées présentent des problématiques juridiques communes, notamment en ce qui concerne:

(1) La sécurité

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

(3) La police des communications et des contenus (droits d’auteur et autres lois assimilées)

(4) L’identification et la responsabilisation des acteurs

(5) La question de la transnationalité.

Étant donné notre désir d’étudier ces questions plus en détails, nous avons décidé de nous concentrer plus en détail sur les architectures distribuées qui sont les plus susceptibles de soulever ce genre de problématiques.

C’est ainsi que nous sommes arrivés à rédiger notre propre définition d’architecture distribuée – comme se référant à toute architecture qui ne possède pas de noeud central, dont les ressources sont réparties au sein d’un réseau, au travers duquel elles communiquent et interagissent.

Une base de données pour l’analyse des dispositifs P2P

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.

TOR: le détournement d’une technologie détournée

Tor est un réseau distribué conçu pour faciliter la communication anonyme. Il a été développé par la Marine des États-Unis pour que le gouvernement américain puisse communiquer des données en toute sécurité sur Internet. L’outil a ensuite été abandonné et mis à disposition du public sous licence open source. Alors qu’il avait été initialement adopté pour protéger les données personnelles des utilisateurs contre l’ingérence des gouvernements, le réseau Tor est aujourd’hui une technologie utilisée par certains gouvernements pour surveiller les utilisateurs sur Internet.

Communiquer sur Internet comporte des enjeux de différentes natures. Tout d’abord, Internet étant une architecture distribuée, la trajectoire des paquets ne peut pas être déterminée a priori – quel que soit le protocole utilisé. Il est donc impossible de s’assurer qu’un message envoyé par Internet ne sera pas intercepté  – ou pire modifié – par un tiers. Ensuite, tout message envoyé sur Internet comporte un transfert de paquets sur plusieurs serveurs qui sont au courant soit de la provenance, soit de la destination de ces paquets. Ces adresses (provenance et destination) sont sauvegardées sur les serveurs et peuvent être ensuite récupérées pour identifier l’identité des personnes ayant envoyé ou reçu ces paquets. Enfin, étant donné que le transfert de paquets sur Internet ne peut se faire que par l’intermédiaire des fournisseurs d’accès à Internet, ces derniers ont la possibilité de contrôler, et pourquoi pas de filtrer, tout ce qui passe sur leurs réseaux. Il n’y a donc aucune garantie qu’un message arrive effectivement à destination sans avoir été préalablement censuré.

Ces risques en matière de sécurité et de confidentialité des communications sur Internet ont amené plusieurs organisations, et notamment la Marine des États-Unis, à développer un logiciel dont l’objectif était d’assurer la sécurité des communications et l’anonymat des participants. Le réseau Tor a ainsi été conçu comme un outil destiné à protéger les communications du gouvernement américain contre toute interception ou détournement.

Si les gouvernements se soucient de protéger leurs propres communications, ils ne se soucient guère de garantir la même protection aux citoyens qui communiquent sur Internet. Bien au contraire : depuis que l’Internet s’est transformé en moyen de communication de masse, les gouvernements de tous les pays essaient de contrôler et de réglementer les communications sur Internet, sous le prétexte de protéger les utilisateurs et d’assurer l’ordre public aussi bien dans le monde physique que dans le monde numérique.

Le premier détournement

Le droit à la vie privée et la liberté d’expression sont aujourd’hui de plus en plus en danger sur Internet. Face aux nombreuses atteintes à la vie privée instaurées par des lois visant à limiter l’échange des contenus protégés par le droit d’auteur, ainsi que les différentes limitations imposées sur la diffusion de contenus illégaux (les œuvres protégées par le droit d’auteur, ou des contenus relevant de la pornographie, de la pédophilie, etc) ou diffamatoires, les utilisateurs doivent apprendre à protéger leur droits par leur propres moyens.

Alors qu’il avait été abandonné par le gouvernement des États-Unis, le développement de Tor a été repris par l’Electronic Frontier Foundation (EFF) dans le but de produire un instrument qui garantisse l’anonymat des utilisateurs. Tor a ainsi été détourné par la société civile qui a transformé un outil conçu pour aider le gouvernement à communiquer des informations à l’insu des yeux indiscrets, en un outil conçu pour la protection de la vie privée des utilisateurs et pour la défense de la liberté d’expression contre les interférences des gouvernements.

Aujourd’hui, Tor est un logiciel destiné à garantir l’anonymat des communications en ligne. Basé sur un réseau de volontaires du monde entier, Tor introduit une nouvelle couche de communication cryptographiée sur le réseau de façon à camoufler non seulement les contenus, mais aussi l’origine et la destination des communications. En ce qui concerne la vie privée, cela permet d’empêcher la surveillance des réseaux et l’analyse du trafic Internet par les fournisseurs d’accès, tout en permettant aux utilisateurs de communiquer des informations de manière anonyme. En matière de liberté d’expression, Tor est un outil qui peut également être utilisé pour contourner la censure, étant donné qu’il permet aux utilisateurs d’accéder à des serveurs bloqués par des firewalls nationaux ou institutionnels, et de communiquer des informations au public de manière anonyme, sans risque de se faire appréhender.

Le fonctionnement du réseau Tor

En règle générale, la cryptographie à elle seule ne suffit pas à garantir l’anonymat des utilisateurs, car il est toujours possible d’identifier la source et la destination des paquets circulant sur Internet. Basé sur le mécanisme de routage en oignon (onion routing), le réseau Tor a donc été construit pour empêcher quiconque de connaître à la fois l’origine et la destination des paquets.

Le principe du routage en oignon est un mécanisme par lequel les données sont encryptées à plusieurs reprises avec des clés de cryptages différentes, pour être ensuite envoyées à plusieurs nœuds dans le réseau. Les données sont donc protégées par plusieurs couches de cryptographie, qui seront progressivement retirées par chaque nœud, jusqu’à ce qu’elles arrivent à leur destination finale où elles seront à nouveau lisibles.

Afin d’assurer une communication anonyme, les données transférées sur le réseau Tor doivent passer au minimum par trois routeurs différents. L’origine des communications n’est connue que des routeurs d’entrée et la destination des communications n’est connue que des routeurs de sortie. Les autres nœuds du réseau sont des routeurs intermédiaires qui ne connaissent ni la provenance ni la destination des paquets qu’ils transfèrent.

Les routeurs d’entrée sont les nœuds auxquels l’utilisateur se connecte pour accéder au réseau Tor. Étant donné que l’adresse IP des utilisateurs est par nécessité visible, cela constitue un point faible et les utilisateurs doivent vérifier qu’ils ne se connectent pas à un nœud doté de mauvaises intentions. Tor a donc introduit une série d’annuaires officiels afin de fournir aux utilisateurs une liste de nœuds Tor certifiés auxquels l’utilisateur peut faire confiance. Dès lors qu’un utilisateur désire communiquer ou recevoir des informations de manière anonyme, le logiciel Tor construit ainsi un chemin aléatoire composé de trois nœuds différents qui s’occuperont de transférer les paquets de leur adresse d’origine jusqu’à leur destination finale – qui elle ne sera connue que par les routeurs de sortie.

Les abus du réseau Tor

L’anonymat garanti par le réseau Tor est cependant une arme à double tranchant. Puisque le trafic ne peut être tracé que jusqu’à l’adresse IP des routeurs de sortie, les utilisateurs peuvent théoriquement abuser du réseau pour accéder à des contenus de façon illicite ; par exemple pour obtenir gratuitement des œuvres protégées par le droit d’auteur, pour consulter des contenus illicites (e.g. à caractère pornographique ou pédophile), ainsi que pour publier des contenus diffamatoires ou s’impliquer dans des activités illégales telles que des opérations criminelles ou la diffusion de courriels non sollicités (spamming).

Les autorités publiques américaines cherchent donc à réglementer l’utilisation de cette technologie afin d’en limiter les abus. D’une part, il a été soutenu que chaque nœud de sortie devrait être tenu responsable pour le trafic qu’il transfère. Cette approche est susceptible de compromettre la viabilité du réseau car cela réduirait considérablement le nombre de routeurs de sortie disponibles, multipliant ainsi la congestion du réseau. De nombreuses takedown notices ont déjà été envoyés à plusieurs institutions, en s’appuyant sur les dispositions du DMCA (Digital Millennium Copyright Act) leur demandant de fermer leurs routeurs de sortie et d’empêcher les utilisateurs d’en ouvrir de nouveaux. Bien que l’EFF insiste sur le fait que les routeurs Tor relèvent des “havres de paix” (Safe Harbour) du DMCA en tant que simple routeur (mere transit), une réponse juridique définitive n’a pas encore été fournie. Si la loi n’aborde pas explicitement la question concernant la responsabilité juridique des routeurs de sortie, le réseau Tor risque de perdre en fonctionnalité suite aux effets secondaires (chilling effects) générés.

Le problème est de savoir s’il faut interdire l’anonymat au sein du réseau, en dépit des recours légitimes à cet anonymat, ou si la technologie doit être au contraire défendue, en dépit du fait que l’anonymat permet aux utilisateurs d’effectuer des opérations illégales (ou plutôt leur facilite la tâche). La question n’a toujours pas été correctement tranchée d’un point de vue législatif ou jurisprudentiel et la légalité du réseau Tor demeure jusqu’à présent incertaine.

Le deuxième détournement

Plutôt que de légiférer sur la légalité du réseau, la solution adoptée par certains gouvernements a été d’utiliser Tor, non plus dans le but de garantir l’anonymat des communications, mais, au contraire, dans le but de retourner la technologie à leur propre avantage en exploitant les failles de sécurité caractéristiques du routage en oignon. Plutôt que de combattre cette nouvelle technologie, l’idée la plus surprenante, bien que peu orthodoxe de ces gouvernements, a été d’utiliser le réseau contre lui-même afin de contrôler le trafic et de surveiller les communications des utilisateurs.

En effet, bien que le réseau Tor soit destiné à garantir l’anonymat des utilisateurs, il rencontre quelques problèmes de sécurité liés à la manière dont il a été conçu. Puisque Tor ne contrôle que ce qu’il se passe à l’intérieur du réseau, il ne peut pas protéger les utilisateurs contre le contrôle et le monitorage du trafic en entrée ou en sortie du réseau. Notamment, le trafic en sortie ne peut pas être encrypté car il ne serait alors pas compris par le serveur de destination. Ainsi, lorsque le réseau est utilisé avec des protocoles non sécurisés (tels que POP, IMAP, FTP, Telnet, etc), les routeurs de sortie peuvent analyser le trafic des utilisateurs pour identifier des informations sensibles tels que leur identifiant et leur mot de passe non cryptés. Bien que cela ne révèle pas nécessairement l’identité des utilisateurs, ces derniers doivent toutefois avoir connaissance des risques et prendre leurs précautions lorsqu’ils se connectent au réseau. Le danger est d’autant plus grand que l’utilisation d’une application tierce non sécurisée, quelle qu’elle soit, par un utilisateur du réseau Tor, peut permettre d’identifier l’adresse IP de cet utilisateur et d’associer ensuite cette même adresse IP à toutes les communications provenant de cet utilisateur (the bad apple attack).

Les routeurs de sortie peuvent également modifier le contenu des paquets qui voyagent à travers eux, afin par exemple de filtrer ou de censurer certains types d’informations, ou, pire encore, d’effectuer des attaques de type “Man In The Middle” (ou MITMune attaque qui a pour objectif d’intercepter les communications entre deux parties sans qu’aucune d’entre elle ne puisse s’en douter) dans le but d’usurper l’identité du serveur de destination.

Cette technique a été utilisée par certains contributeurs de Wikileaks, qui opéraient sur plusieurs routeurs de sortie au sein du réseau Tor dans l’espoir d’obtenir des informations confidentielles (voir Appelbaum’s lostinthenoise.net network). Julian Assange a lui-même avoué que de nombreux documents sur Wikileaks ont été obtenus en analysant le trafic de plusieurs réseaux pair-à-pair, Tor étant probablement le plus intéressant.

Mais cela ne se limite pas aux individus. Les gouvernements des États-Unis, de Chine et de Russie sont connus pour opérer sur le réseau Tor avec de nombreux nœuds de sortie, dont le nombre n’a cessé d’augmenter depuis 2007.

Bien que l’analyse du trafic sur les routeurs de sortie soit ordinairement réalisée à l’insu des utilisateurs, une telle opération a été récemment divulguée par plusieurs revues, telles Forbes et Wired. C’est le cas du projet Vigilant, un groupe de surveillance qui, paraît-il, analyse le trafic de plusieurs fournisseurs d’accès Internet aux États-Unis pour identifier les opérations (terroristes ou autres) qui pourraient nuire à la sécurité nationale.

D’après le récit de Forbes, “One of Project Vigilant’s manifold methods for gathering intelligence includes collecting information from a dozen regional U.S. Internet service providers (ISPs). Because the ISPs included a provision allowing them to share users’ Internet activities with third parties in their end user license agreements, Vigilant was able to legally gather data from those Internet carriers and use it to craft reports for federal agencies. A Vigilant press release says that the organization tracks more than 250 million IP addresses a day and can “develop portfolios on any name, screen name or IP address.”

Le projet Vigilant regroupe une communauté d’analystes bénévoles dont la mission est celle de recueillir et d’analyser un maximum de données sur le réseau Tor, afin de remettre ces informations au gouvernement fédéral. Si ce rapport a été réfuté comme largement exagéré, l’existence du projet Vigilant est, elle, bel et bien documentée : “Project Vigilant is funded by BBHC Global, an information security firm based in the Midwest, and private donations.  According to BBHC manager, Steven Ruhe, “In the fight against terror, the U.S needs all the help it can get, even if that assistance comes from unpaid volunteers. For the past 14 years, a significant volunteer group of U.S. citizens has been operating in near total secrecy to monitor and report illegal or potentially harmful activity on the Web.”

Il est difficile d’imaginer que, si Tor est en effet utilisé pour communiquer de façon anonyme et contourner les firewalls ou censures imposées par les gouvernements, ces derniers ne s’emploient pas à exploiter le réseau pour analyser le trafic et identifier les utilisateurs mal intentionnés.

Évidemment, ce risque n’existe que pour les utilisateurs qui ne prennent pas les précautions nécessaires pour protéger leurs communications. Il suffit en effet d’utiliser un protocole sécurisé lors du transfert des données pour s’assurer que personne ne peut contrôler les paquets et découvrir l’identité des utilisateurs communiquant sur le réseau Tor. C’est pour cela que ce risque ne concerne vraisemblablement que les personnes qui n’ont effectivement rien à cacher et qui n’ont donc aucun intérêt à communiquer de façon anonyme et à l’insu des gouvernements. Quoi qu’il en soit, en donnant l’impression qu’il est possible de communiquer en toute sécurité sans aucun effort, le réseau Tor est un outil qui peut potentiellement être détourné par les gouvernements afin de superviser les communications d’un grand nombre d’utilisateurs.

Le Cloud: une architecture virtualisée

Dans l’analyse des modèles d’architecture en réseau, dont l’architecture distribuée est un cas spécifique, il nous a paru intéressant d’explorer les questions de l’architecture du cloud computing qui actuellement pose des questions juridiques de grande ampleur. Nous avons donc participé à un Atelier de l’ADIJ dédié aux problèmes juridiques du Cloud, et qui s’intéresse essentiellement au Cloud d’entreprise.  La question commune d’emblée évidente est que le pair à pair et le cloud essaient de résoudre chacun de leur façon la mutualisation de ressources face aux capacités limitées. Ils ont aussi en commun l’élasticité du modèle, la modulabilité, le self-provisioning. Un deuxième aspect commun est celui du sort des données personnelles. Alors que dans le cas du pair à pair, les données personnelles des utilisateurs sont par nécessité transmises dans un réseau de pairs, dans le cas du Cloud Computing, les données personnelles sont stockés dans des data centers dont la localisation exacte est souvent inconnue aux utilisateurs et dont la sécurité est incertaine. C’est ainsi que la CNIL qui a participé à cet Atelier a aussi mis en place un Groupe de travail interne sur ce thème. Nous reprenons ici les principaux points de cet Atelier qui se rapportent à nos interrogations.

Le 3 novembre 2011, l’atelier « Cloud Computing » de l’Association pour le Développement de l’Informatique juridique (ADIJ) animé par H.F. Jul-Hansen, B. Delmasx-Linel& D. Feldman  a  terminé sa première tranche de réflexions à l’Espace Hamelin.  L’atelier, qui avait été lancé le 23 septembre 2010, a accueilli durant ses séances de nombreux avocats et représentants de sociétés leaders du Cloud Computing (tel que Microsoft, Google, IBM, WMWare, etc) qui se sont réunis tous autour d’une même table pour entreprendre une discussion ouverte et constructive sur les atouts, les risques et les enjeux juridiques du Cloud Computing. L’atelier s’est terminé avec un compte-rendu de ce qui a été dit dans les séances précédentes.

Avant même de se mettre d’accord sur une définition, le groupe était divisé sur la question : s’agit-il  ou non d’une révolution technique ? N’était ce pas plutôt une innovation (voire un coup) commerciale ? Il est dit notamment que le terme « Cloud Computing » ne veut  rien dire en soi, que  c’est un outil de marketing qui fait vendre des services, mais qui fait aussi peur aux clients. Le Cloud Computing est sans doute une révolution mais elle n’est pas technique. La virtualisation de l’architecture et la mutualisation des données permettent une plus grande élasticité et flexibilité des ressources informatiques, mais leur déplacement sur le réseau comporte une perte de maîtrise qui comporte des risques importants. Les problématiques juridiques principales concernent essentiellement le droit à la vie privée, la sécurité des données, et l’encadrement contractuel. La question est de savoir si ces problèmes sont inhérents au Cloud Computing, ou s’ils sont dus simplement à la jeunesse de ces architectures.

I.               Encadrement contractuel

La difficulté majeure est celle de formuler des contrats qui puissent prendre en compte tout problème potentiel. Alors que dans le cas des Clouds publics (versus Clouds privés), l’utilisation de contrats-type est a priori possible, la négociation des contrats pour les Clouds privés est beaucoup plus complexe. Les Clouds hybrides, eux, essaient de trouver un équilibre entre l’exportation des données en dehors de l’entreprise et le maintien de certaines opérations au sein de l’entreprise.

Le problème de fond se trouve dans l’opposition entre les utilisateurs qui exigent un maximum de garanties et les prestataires de services en amont qui ne veulent assumer aucune responsabilité. Les intermédiaires se voient donc obligés de gérer et de mettre en balance les intérêts de tous leurs partenaires. Si le contrat est déséquilibré, il y a souvent un problème au niveau de l’expression des besoins.

L’encadrement contractuel est d’autant plus difficile qu’il n y a pas de transparence entre les opérateurs. Les utilisateurs communiquent exclusivement avec un intermédiaire (e.g. Dropbox), sans connaître l’identité ni des prestataires en amont (e.g. Amazon dans le cas de Dropbox) ni des responsables de l’infogérance et de l’hypervision (e.g. Xen dans le cas d’Amazon).

II.             Sécurité des données

Les problèmes de sécurité concernent  l’accessibilité et la confidentialité des données. Bien que les mêmes problèmes existaient auparavant, les risques sont perçu comme étant beaucoup plus graves dans le cadre du Cloud à cause de la distance et de l’échelle des opérations. Des centres de données  (data centers) accumulent de plus en plus de données qui ne sont accessibles que par l’intermédiaire du service Cloud. Dès lors qu’il y a une panne, de nombreux utilisateurs en souffrent et personne ne peut faire quoi que ce soit, si ce n’est attendre que les prestataires résolvent le problème. Ceci entraine un malaise psychologique du à la perte de maitrise.

Ainsi, bien que le Cloud offre d’énormes avantages en termes de disponibilité et accessibilité des données, il comporte aussi de gros désavantages du à la perte de maitrise et au manque d’interopérabilité. Plusieurs fournisseurs de services, notamment Google et Blackberry, ont déjà été confrontés à de tels risques.

Il ne s’agit là pourtant pas d’une nouvelle ménace, mais plutôt d’une confirmation que ces risques existent toujours. Alors que le Cloud ne multiplie pas la probabilité de perte des données, il en multiplie l’ampleur. Des problèmes, aussi minimes soient-ils, risquent d’entrainer des conséquences très importantes puisque le Cloud opère sur une grande échelle. De plus, bien que ces problèmes se posent à la même fréquence dans le Cloud ou ailleurs, leur nombre est susceptible d’augmenter avec le nombre d’intermédiaires.

Pour  sécuriser les données, il est donc encore plus nécessaire d’investir en redondance, mais aussi d’éduquer les utilisateurs à sauvegarder leurs données dès lors qu’ils ne sont pas prêts à accepter les risques.

III.           Droit à la vie privée

Les problématiques liées à la protection de la vie privée des utilisateurs sont de grande actualité dans le cadre du Cloud Computing. De plus en plus de juristes travaillent sur les questions relatives au Cloud Computing et à la protection des données personnelles. Les enjeux sont essentiellement dus au fait que les règles sur le traitement des données personnelles varient énormément selon des pays. Le cadre règlementaire européen est beaucoup plus strict que celui des Etats-Unis par exemple. Alors que ces problèmes existaient bien avant l’arrivée du Cloud Computing, le Cloud en a été un révélateur efficace.  Ainsi, bien qu’il n’ait pas modifié les comportements habituels des fournisseurs de services en termes de traitement des données, il a cependant acquis une connotation négative dans l’esprit des clients.

Il devient donc nécessaire de rassurer les clients. Alors que certains fournisseurs de service ne se préoccupent pas de contrôler l’emplacement de leurs serveurs ou de leurs prestataires, d’autres se sont engagés à proposer des offres qui garantissent que tous les serveurs soient en Europe, et en font ainsi un atout concurrentiel. De plus, même si rien n’a changé d’un point de vue pratique, les contrats d’infogérance (l’externalisation de tout ou partie de la gestion et de l’exploitation du service informatique à un prestataire informatique tiers)  se voient maintenant obligés de contempler tous les problèmes liés à la sécurité et à la confidentialité des données – bien que cela aurait du être fait bien avant l’arrivée du Cloud Computing.

Ces dangers ne sont pas seulement théoriques, comme l’ont prouvé récemment Sony, Amazon, Google et Blackberry. Avant d’acheter un service, de plus en plus de clients s’interrogent pour savoir si les fournisseurs de services sont bien assurés contre les risques associés au Cloud Computing. Des instituts d’assurance ont donc été appelés à intervenir pour amortir ces nouveaux risques.

La question principale est de savoir si ce sont les prestataires de service ou les utilisateurs finaux qui doivent s’assurer contre la perte ou la fuite des données. Les clients exigent souvent que les prestataires assument tous les risques, bien que cela soit difficile à mettre en œuvre. Plutôt que d’essayer de créer un contrat qui mette les garanties entièrement sur le dos des prestataires, il serait préférable de changer le modèle adopté pour satisfaire les besoins des clients (par exemple, en passant d’un Cloud public à un Cloud hybride). Obliger les fournisseur à s’assurer contre les risques liés à la perte des données et au respect de la vie privée risque de se traduire en une forme de forfaitisation, où le coût de l’assurance est partiellement reversé sur les clients qui se voient donc obligés de payer un premium pour assurer la sécurité de leurs données. De plus, bien qu’il soit important de répartir les responsabilités sur les différents prestataires, l’utilisateur peut aussi s’assurer par ses propres moyens. Ceci permettrait des négociations plus équilibrées entre tous les acteurs qui participent au service.

Enfin, un autre point intéressant porte sur la standardisation. L’idée serait de gérer les problèmes de sécurité et de confidentialité des données en s’appuyant sur une série de normes ou de standards. OVH, par exemple, a annoncé vouloir rechercher une certification ISO pour ses offres de Cloud privé, dans le but de fournir de meilleures garanties de sécurité aux clients.

La standardisation permet aux clients de contrôler la fiabilité des prestataires par l’intermédiaire de l’audit d’un tiers. Différents types de certifications sont déjà utilisés par plusieurs fournisseurs de services Cloud, tel que la certification SAS 70 par exemple, mais la plupart ne couvrent que les aspects financiers du service. Le problème est que les certifications proviennent d’entreprises privées, et il est donc toujours nécessaire de se mettre d’accord sur les standards à utiliser.

Aujourd’hui, le développement de normes ou de standards capables de garantir l’efficacité et la sécurité d’un service n’a pas beaucoup avancé dans le cadre du Cloud Computing. Cela est probablement du au fait que l’on est encore en phase de compétition dans le secteur. La standardisation des offres arrivera probablement à une phase successive, lorsque le marché commencera à se stabiliser. Est-ce que le Cloud est architecture nouvelle qui induit de nouveaux rapports assurantiels et contractuels ?

À la fin de cet atelier, nous avons compris que le Cloud Computing et les réseaux pair à pair ont plusieurs caractéristiques en commun. Tous les deux sont basés sur la virtualisation et la mutualisation des ressources et tous les deux présentent une architecture distribuée, dynamique et élastique – bien que l’architecture du Cloud est déterminée par les besoins des clients, alors que celle des réseaux pair à pair dépend de la disponibilité des ressources. Cependant il nous semble intéressant d’analyser en quoi ces deux architectures, qui sont toutes deux distribuées, se différencient. Il nous semble que, alors que le pair à pair est une architecture distribuée décentralisé, le Cloud est lui une architecture distribuée de façon centralisé.

Danièle Bourcier et Primavera De Filippi

Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search