la biographie de Louis Pouzin et l’aventure Cyclades

On ne présente plus Louis Pouzin : il a été, notamment, l’un des pionniers français des réseaux informatiques, dès les années 1960 et 1970, avec le réseau Cyclades.

Sa biographie vient d’être publiée aux éditions Economica, dans la “Collection Cyberstratégie”, par Chantal Lebrument et Fabien Soyez, avec une préface du blogueur clermontois Korben.

Cette biographie couvre principalement la carrière professionnelle de Louis, mais évoque également sa jeunesse et ses études.

Le livre nous place ainsi au cœur du combat entre les réseaux informatiques et les réseaux télécoms des années 70-90, finalement remporté par les premiers. C’est de ce passé que provient l’insistance maniaque de certains informaticiens l’ayant vécu à parler de réseau informatique plutôt que de réseau de télécommunications.

Le lecteur est plongé dans les affres de la SIMCA, de la société Bull, du Plan Calcul, de l’IRIA (aujourd’hui INRIA), du CNET, et d’un certain nombre d’entités moins connues. La société Bull, notamment, a longtemps défrayé la chronique en France avec ses tentatives pas toujours couronnées de succès (euphémisme) pour populariser sa gamme de machines face à ses gros concurrents états-uniens.

À travers les citations des anciens de Cyclades, le livre évoque aussi une partie des carrières de ces derniers. Ainsi, deux d’entre eux, Michel Gien et Hubert Zimmermann, ont travaillé chez Chorus Systèmes, bien connue dans les années 1990.

On découvre également de l’intérieur l’ambivalence, encore actuelle, d’un état français se voulant stratège, prêt à financer des projets de pointe, mais esclave d’alternances politiques et de raisonnements administrativo-politiques qui ne favorisent pas les meilleurs résultats à long terme, voire produisent des gâchis purs et simples.

L’époque MIT

Après un début de carrière en France, Louis Pouzin a passé une année au MIT, travaillant sur un système d’exploitation bien connu de l’époque : Multics.

Multics fut un des premiers systèmes à “temps partagé” (timesharing) : plusieurs utilisateurs peuvent utiliser simultanément l’ordinateur, et travailler comme s’ils avaient l’ordinateur à eux seuls. Le temps partagé permet un meilleur partage des ressources informatiques, et un travail plus facile. Cela semble très banal aujourd’hui, mais auparavant, les travaux informatiques étaient réalisés par lot : chacun mettait sa tâche dans une file d’attente (souvent, un bac de cartes perforées). Les travaux étaient traités séparément, un par un. Il fallait donc attendre son tour pour voir son travail traité, puis attendre le résultat de celui-ci, le tout pouvant prendre des heures ou des jours. On n’imagine pas le développement agile dans ces conditions…

Là, Louis invente le shell : l’interpréteur de commandes, un élément encore aujourd’hui central dans tous les systèmes.

Le livre évoque cette période, ainsi que, au retour en France, l’évangélisation à travers l’Europe, pour Bull, des clients de la société au timesharing.

Les prémisses de Cyclades : les communications informatiques des années 1970

Dans les années 1970, chaque constructeur informatique avait sa propre gamme, de l’unité centrale aux périphériques, quasi totalement incompatible avec celle de la concurrence. Même les formats de données texte n’étaient pas unifiés, l’ASCII se battant avec l’EBCDIC.

Pour faire communiquer deux ordinateurs sur une longue distance, on utilisait des modems et une ligne téléphonique classique, avec un ordinateur à chaque extrémité, comme pour deux correspondants humains. Ce fonctionnement était défendable pour une utilisation humaine, mais d’une inefficacité catastrophique pour relier des machines.

Tout était donc à créer : l’architecture des réseaux, mais aussi les protocoles d’échange indépendants des architectures de machines.

Cyclades, Arpanet et RCP

Une série de recherches et d’expérimentations ont donc lieu dès la fin des années 1960, essentiellement dans les pays occidentaux, pour réaliser les premiers réseaux informatiques. Ces programmes de recherche ont donné naissance, notamment, à Arpanet, le prédécesseur états-unien d’Internet, mais aussi, côté français, à Cyclades. Il s’agit, à l’époque, d’interconnecter les rares et gros ordinateurs entre eux, et d’en donner accès à distance aux utilisateurs, pour mutualiser les ressources.

Cette période de Cyclades est la plus passionnante et représente presque la moitié du livre.

Le livre couvre en détail la genèse du projet, au sein du Plan Calcul, la constitution de l’équipe — une belle bande de geeks ne comptant pas leurs heures et leurs voyages d’évangélisation, reliés par la passion –, les échanges internationaux nombreux, notamment avec les états-unis, les conférences, les aléas politiques, la reconnaissance des idées et des réussites propres à Cyclades, mais aussi la concurrence avec RCP, le projet monté par le CNET.

Cette partie s’appuie largement sur les travaux de Valérie Schafer et Pierre Mounier-Kuhn sur les débuts de Cyclades et de l’lnternet, qui nous détaillent le processus d’apparition des concepts, attributions et partages, de publication de papiers en reprise par d’autres équipes.

Les divergences principales entre Cyclades et RCP tournent autour de la notion de “paquet”. Dans Cyclades il est transmis tel quel (on finira par l’appeler “datagramme”) ; dans les réseaux d’inspiration télécom, on préfère l’enrober dans un “circuit virtuel”, imitant le fonctionnement du réseau téléphonique (on retrouve la même divergence de culture aux USA, aux débuts d’Arpanet, avec les ingénieurs d’ATT prenant de haut les informaticiens de BBN sur la façon de construire un réseau).

Ce choix du datagramme contre le circuit virtuel a de larges ramifications : le circuit virtuel complique le réseau, le rend moins résilient aux redémarrages d’équipements. Il complique également les interconnexions entre réseaux.

Le livre décrit les tensions entre les équipes Cyclades et RCP, les interventions de la hiérarchie pour faire taire les vilains petits canards, la tentative de fusion des projets, et la décision politique, à l’élection de Valéry Giscard d’Estaing en 1974, de ne poursuivre qu’un seul projet.

Le succès de RCP, X.25, Transpac et le Minitel

C’est RCP, projet issu de l’administration des télécoms, qui, soutenu politiquement, donnera naissance à Transpac (et, en partie, au standard X.25).

Transpac sera, entre autres, utilisé comme support pour le Minitel, et sa première révolution pour l’utilisateur sera la possibilité de communiquer numériquement à travers son propre pays à un tarif indépendant de la distance.

X.25 sera handicapé par son architecture, et en pratique les échanges internationaux fondés sur celui-ci resteront marginaux, éradiqués par un Internet naissant au fonctionnement et tarification plus simples (l’ATM, lui aussi fondé sur les circuits virtuels, qui devait prendre la relève de X.25, connaîtra le même sort funeste, pour des raisons similaires).

Selon Bernard Nivelet, ancien responsable du centre de calcul de l’IRIA, cité dans le livre, “l’attitude de la DGT nous a fait perdre environ 15 ans de maîtrise industrielle”.

Cyclades et TCP/IP

Aux USA, dès 1972-1973, un certain Vinton Cerf qui travaille à la conception de TCP/IP avec Robert Kahn, a compris l’intérêt du travail réalisé sur Cyclades, et s’en inspire.

D’après le livre, c’est dans TCP version 2 (à l’époque, IP et TCP sont traités séparément) que ces idées seront intégrées. Outre l’idée du datagramme, dont Cyclades a été le premier à montrer la faisabilité en réel, TCP/IP reprendra l’idée de fenêtre glissante (qui permet d’adapter la vitesse de transmission à la capacité du réseau), mais aussi les idées sur l’interconnexion des réseaux (le catenet dans les papiers Cyclades, terme repris tel quel dans l’IEN-48 de Vint Cerf en 1978, qui cite Louis Pouzin dès l’introduction).

À leur tour, ces concepts faciliteront la transition “douce” d’Arpanet de son protocole historique vers TCP/IP version 4, par morceaux, en 1983, avant de continuer sa croissance en agrégeant de nouveaux réseaux, aboutissant à l’Internet que nous connaissons.

“Ce sont les américains qui ont sauvé le datagramme”, expose Louis Pouzin. Mais dans Cigale (le réseau physique de Cyclades), “on avait défini que l’adresse destinataire n’était pas un point fixe, hardware (une adresse IP), mais une adresse virtuelle, dans les ordinateurs des utilisateurs”.

Il faut saluer la transparence du livre, qui permet aux anciens de l’équipe Cyclades de rappeler que beaucoup des idées du projet proviennent d’un travail collectif, et s’émeuvent que les projecteurs aient été beaucoup placés sur Louis Pouzin.

L’après Cyclades

La fin du livre évoque les aventures plus récentes de Louis Pouzin : les rencontres d’Autrans, le SMSI, le FGI, RINA, l’internationalisation de l’Internet, et les alternate roots (les racines DNS ne dépendant pas de l’autorité ICANN, sujet controversé qu’il serait trop long de développer ici). Le livre est écrit là sur un ton plus militant,  pas toujours facile à suivre, citant quelques anecdotes croustillantes de clashs, notamment entre Louis et les représentants de l’ICANN. On y note une coquille répétée surprenante quoique classique, l'”IUT” pour évoquer l’UIT (ITU en anglais). On y apprend aussi que Louis Pouzin est fan du langage Perl !

Pour terminer sur une note plus personnelle, j’ai eu l’occasion de croiser Louis Pouzin à différentes occasions, la première fois lorsque je travaillais au centre de calcul de l’ENST (école nationale supérieure des télécommunications, maintenant Télécom ParisTech), rue Barrault à Paris. On peut aussi croiser Louis, qui s’intéresse à tout ce qui peut concerner un geek, lors de sessions du FGI comme lors de conférences sur Bitcoin, et il manifeste toujours avec le sourire la même gouaille et la même ardeur à refaire le monde 🙂

Le centre de calcul de l’ENST a été relié à Cyclades, comme l’évoque le livre, par l’un des anciens de l’équipe. À l’époque où j’y ai travaillé, les traces de Cyclades avaient disparu depuis longtemps. Il y aurait également eu une époque où l’école avait été reliée “de force” à RCP pendant sa phase expérimentale. Seul subsistait, au début des années 2000, un lien X.25 utilisé pour le serveur Minitel des résultats du concours Mines-Ponts.

Depuis, le centre de calcul lui même a été déplacé et les locaux totalement reconstruits, lors du désamiantage du bâtiment dans les années 2000.

La première fois que j’ai eu accès à un papier sur Cyclades, Presentation and major design aspects of the CYCLADES computer network, j’ai été frappé par la similarité entre la structure de Cyclades et celle de l’Internet :

CYCLADES uses a packet-switching sub-network, which is a transparent message carrier, completely independent of host-host conventions. While in many ways similar to ARPANET, it presents some distinctive differences in address and message handling, intended to facilitate interconnection with other networks. In particular, addresses can have variable formats, and messages are not delivered in sequence, so that they can flow out of the network through several gates toward an outside target.

Traduction : CYCLADES utilise un sous-réseau à commutation de paquets, qui est un transport transparent de messages, complètement indépendant des conventions hôte-hôte. Bien qu’à de nombreux égards similaire à ARPANET, il présente des différences notables dans la gestion des adresses et des messages, destinées à faciliter l’interconnexion avec d’autres réseaux. En particulier, les adresses peuvent avoir des formats variés, et les messages ne sont pas délivrés en séquence, afin de pouvoir sortir du réseau à travers plusieurs portes vers une cible extérieure)

Ce papier sur Cyclades n’est malheureusement pas disponible librement (on retrouve les problèmes actuels liés à la diffusion des papiers de recherche, un système passant par les fourches caudines des éditeurs de recherche, rendu caduc par Internet). Il date de janvier 1973, pour des concepts qui n’ont été réellement déployés qu’à partir de 1982-1983 dans l’Internet.

Louis Pouzin explique même dans le livre que TCP/IP ne va pas jusqu’au bout des idées de Cyclades sur l’adressage, qui étaient (de ce que j’en ai compris) destinées à permettre l’interconnexion de réseaux hétérogènes.

C’est là que s’arrêtent la plupart des travaux récents que j’ai pu lire sur ces sujets : on aimerait des détails plus techniques sur les fondamentaux de Cyclades, et notamment son format de paquet et ses protocoles élémentaires, que je n’ai réussi à retrouver nulle part à ce jour.

Un livre relatant l’histoire du côté RCP apporterait peut-être, également, un éclairage intéressant sur cette période.

En conclusion, je recommande vivement la lecture de ce livre à ceux qui veulent en savoir plus sur Louis Pouzin, mais aussi lire de belles histoires de geeks passionnés sur le réseau Cyclades, les avatars du Plan Calcul, le tout dans un contexte où l’informatique naissante était très différente de l’environnement que nous connaissons aujourd’hui, mais qui a littéralement construit les réseaux que nous utilisons maintenant quotidiennement.

Complément

On lira également avec intérêt la fiche de lecture de Laurent Bloch sur son blog, qui entre dans des explications détaillées sur le datagramme, la fenêtre glissante, ainsi que le modèle OSI, une autre contribution essentielle, dont je n’ai pas parlé ici.

Deux articles de Fabien Soyez sur Louis Pouzin, “à la base du livre” pour le citer : Louis Pouzin n’a pas inventé Internet, mais sans lui, il n’y aurait pas d’Internet partie 1 et partie 2.

Commentaire intéressant de Chantal Lebrument (co auteure), sur twitter :

Avoir trouvé un éditeur qui accepte ce livre a pris 2ans, tous ont refusé… donc bien contente qu’une maison d’édition de qualité ait décidé de porter ce projet.

 

On peut trouver le livre en ligne notamment chez :

 

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1Nb4aJWgAUAqMUCzeF2vTTDUNVNTM5ak42

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind 🙂

Article 13 of the Copyright Directive considered harmful

[this is a translation+partial update of my original post in French here]

The “directive on copyright in the Digital Single Market“,  in short “Copyright Directive”, having passed the JURI commission vote with amendments on 20 June  2018, will soon be voted in a plenary session of the European parliament, 5 July 2018.

I wrote the following text before calling some Members of the European Parliament (MEPs), thus participating in the campaign started by saveyourinternet.eu.

I would like to invite you to do the same, not before you have read some of the references quoted at the end of this page, and consulted https://juliareda.eu/2018/06/article-11-13-vote/

Two articles are especially dangerous.

  • Article 11, about referencing and quoting press articles; we will not develop this issue any further here.
  • Article 13, about so-called “upload filters” on all content sharing sites (ie all sites who have a function of sharing content, including comments/videos/photographs/audio on social networks).

The stated goal of article 13 is to protect rightholders of the entertainment industry against the hegemony of the big web sharing platforms, most notably Youtube, which alledgedly results in revenue “evasion” when rightholder’s contents are illegally uploaded and consulted on these platforms.

The proposed solution is to create a legal obligation to deploy system blacklisting protected contents, on all content sharing sites, for all types of content, even those that don’t need protection (for example, computer software source code).

We are going to examine how such systems work, why they are costly to implement, with significant collateral damage, and why the targeted platform already implement measures to satisfy the stated goal.

Content blacklist systems

They can be roughly classified in three categories :

“Exact match” detection

They are relatively cheap in terms of resources. They work on raw digital data. They don’t need to be aware of formats or media type, not even of the detailed original content to protect, thanks to the use of so-called “hashing” or “digest” algorithms.

These features make these systems very easy to implement and operate, and very cheap. The algorithms are free and open source software, or public domain (for the underlying mechanism), and they are easily adapted to any platform.

On the other hand, these systems are very easy to bypass, through minor changes in the protected file. In consequence, they constitute a very poor protection for rightholders.

Detection “by similarity”

These systems are much more sophisticated. They have a knowledge of media formats, and are able to extract characteristic elements, similar to a fingerprint of the protected content.

This process enables a much wider detection of the content, even heavily modified, for example a barely audible background sound in a family video ou amateur show.

The most famous system in this category is Content-Id, implemented by Youtube, described here by Google. A lot of comments on Article 13 refer to Content-Id as a model. Article 13 itself seems to have been written with Content-Id in mind.

Systems “by similarity” are very expensive to develop and implement. According the the Google video quoted above, Content-Id required an investment of over $100 million.

There are also no free and open source implementation of such systems, which makes it even more difficult to deploy: you need to develop a custom, in-house system, or acquire a license for an existing commercial system, if you find one.  The companies in a position to provide such specific services are rare.

Furthermore, the detection performance (false positive and false negative rates) of these systems is difficult to estimate. First, for the above mentioned reasons (proprietary systems with limited access), second, because the underlying technical processes are based on heuristics which stops them from being fully reliable.

Finally, these system present an important drawback: as explained by Google in the Content-Id presentation video, rightholders must provide the original content, or protected excerpts from the content, which is difficult to achieve on a wide scale (many works and many actors on both roles, rightholders and content sharing platforms).

“watermarking” systems

These systems are mentioned in the annex of the directive. They are only presented here for the sake of completeness. Their costs are comparable to those of similarity detection systems, but they are of limited scope, probably not reasonably usable in the context of Article 13.

Blacklist management

Black list management, independently from the above technical criteria, constitutes an issue in itself.

Article 13 does not really provide satisfactory solutions to the following issues:

  • false positive (over-blocking): blocking legitimate content.
    • erroneous blacklisting by an alleged rightholder
    • erroneous blocking of content protected by an exception (parody, memes, etc), but in which the blacklisting systems have identified protected content.
    • erroneous insertions in the blacklist for other reasons. This happened repeatedly, for example, in the French police DNS blocking systems, including by misconfigured test systems. See [FR] Google.fr bloqué pour apologie du terrorisme suite à une « erreur humaine » d’Orange.
  • false negative (under-blocking): not blocking illegitimate rightholder content. Content protection is difficult to implement, even on the rightholder side: many works have not even been digitalized by their legitimate rightholders.
  • adding new content to the blacklist may require manual, hence heavy, checks, to reduce false positives, but does not guarantee their elimination.
  • unwieldy and unreliable complaint mechanisms: all over-blocking and under-blocking issues have to be handled via human, or even judicial, intervention. But there are daily reports of abusive content removal here or there. For example, under the United States DCMA (Digital Millennium Copyright Act), some rightholders have been known to request content removal on works they didn’t own, by mere title similarity, or by claiming DMCA procedures to force removal of price lists in price comparators.
  • individuals and small companies are defenceless against abusive blocking of their content, if the site-internal reporting mechanism fails to address the issue in time. In most cases, action in court or even using an alternative dispute resolution system (13a) will be too expensive and too slow, resulting in a posteriori self-censorship.

Article 13 in its final redaction does not satisfactorily address these concerns, the last point above being the most worrisome.

The Content-Id system

Although Content-Id is owned by Google and Youtube-specific, it deserves a more thorough examination, as it seems to have been an implicit model for Article 13.

Content-Id is a “detection by similarity”. To use it, rightholders have to provide Youtube with the videos they wish to protect, or samples of these.

When a protected content is identified in a posted video, 3 options are available:

  • block the video
  • monetize the video (advertisement)
  • obtain traffic data, for example to know in which countries the video is popular.

According to Google, Content-Id has already enabled payment of several billions of dollars to rightholders, and the system includes hundreds of millions of videos.

Impact assessment of the directive

The summary of the impact assessment, as annexed to the project, is very incomplete: as compared to the full impact assessment study, it mentions only in part the impact for rightholders, limiting itself to a legal discussion in the digital single market. It doesn’t mention either the efficiency and technical feasibility of Article 13, or its consequences on Internet sites and the Internet ecosystem. It is advised to refer to the full impact assessment study.

1. Disappearance or marginalization of  contributive sites

Contributive sites based on free (Creative Commons, etc) content will not have the resources to exploit, not to mention develop or even rent/subscribe to systems similar to Content-Id.

The impact assessment study provides a real example of the subscribing costs to such a service: €900/month for a small site (5000 transactions/month, ie about €0.18/transaction; a transaction being a single check, needing to be executed for every post by a user).

The study only considers commercial sites where sharing is the main purpose. This fails to recognize the impact on high volume contributive sites, social networks, amateur or family photo sharing sites, classified advertisement, etc, for which there is no significant revenue stream as compared to the cost of monitoring posted content.

Most notably, social networks are targeted, as Article 2/4b of the directive excludes only 3 very specific types of sites from the requirements of Article 13.

  • services acting in a non-commercial purpose capacity such as online encyclopaedia
  • providers of cloud services for individual use which do not provided direct access to the public
  • open source software developing platforms
  • online market places whose main activity is the online retail of physical goods

As a consequence, this first impact on freedom of speech seems underevaluated.

2. All content types are targeted

Most content protection systems currently operated focus on contents from the entertainment industry:

  • videos and movies
  • music

On the other hand, Internet sharing applies to many other types of contents, for example photographs.

Again, the burden on Internet sites will be significant, with the same risks for abusive blocking, which also amplifies the consequences on the other listed issues.

3. Issues with respect to Freedom of Speech

As explained above and confirmed by many non-profit organizations, similarity detection systems are unable to differentiate illegal use from legal use such as a quote, a meme, a parody, etc.

It also happens frequently that works that are initially free of use are erroneously blacklisted, for example after being presented or quoted in protected TV shows or TV news.

In any case, content detection systems already result, when they are implemented, in abusive censorship. To force their generalization through the Directive can only be severely harmful to Freedom of Speech, especially on social networks, making it more difficult to exercise the above mentioned legal exceptions.

Finally, as explained, widening content detection systems to all types of contents can only make this risk more acute.

4. The proposed legal dispositions are inefficient to protect rightholders

As explained, similarity systems like Content-Id are not usable at global scale because of their cost, and exact match systems are easy to bypass.

Furthermore, similarity systems are already deployed on major sites, as explained by the impact assessment study:

In all, as content recognition technologies are already applied by the major user uploaded content services, it is likely that this option would not lead to significant increases in unjustified cases of prevented uploads compared to the current situation

In other words, Article 13 is not needed since the goals it seeks to achieve are already implemented where it matters.

5. The proposed dispositions may be harmful to cultural diversity

The impact assessment studies estimates that Article 13 will promote cultural diversity, which is assumed to be a natural byproduct of rightholder protection.

But Article 13 hampers the ability of contributive and/or non-profit sites, which without a doubt are also part of cultural diversity. Most of their contents are free of rights, hence with naturally maximized visibility and dissemination.

This is evidenced by Wikipedia’s statistics: 5th site in the world, according to the Alexa study. Furthermore, according to Wikimédia France: “platforms will prefer precaution by blocking more content than necessary, which will hamper their diversity, by preventing participation from people less accustomed to new technologies” (translated from « les plateformes opteront pour un principe de précaution en bloquant plus de contenu que nécessaire ce qui réduira la diversité de ces plateformes en empêchant les personnes peu aguerries aux nouvelles technologies d’y participer » here)

In summary, Article 13:

  • would not improve the rightholder’s situation with respect to the big platforms, since these already have deployed content detection and revenue sharing systems;
  • would not improve, either, the rightholder’s situation with respect to non-profit or low traffic platforms, which don’t have the ability to operate complex detection systems, don’t violate protected works other than accidentally thus in a limited way, and are already in position to remove illegal content.
  • represents, on the other hand, the following risks:
    • arbitrary censorship
    • reinforcement of the hegemony of big platforms by introducing significant barriers to entry
    • disappearance or marginalization of non-profit platforms, or fallback of these platforms on static content, removing the content sharing angle which is a key characteristic of the Internet;
  • represents, as well, serious risks regarding Freedom of Speech and Cultural Diversity.

For the above reasons, and as expressed by numerous organizations and renowned experts, it seems likely that Article 13, if kept in the directive, will do more harm than good on the European Internet.

A few references

The Open Letter on EP Plenary Vote, of which (as eriomem.net CEO) I am a signatory:

http://copybuzz.com/wp-content/uploads/2018/07/Copyright-Open-Letter-on-EP-Plenary-Vote-on-Negotiation-Mandate.pdf

2 articles (amongst many others) on Julia Reda’s blog :

Open letter by 70 Internet experts https://www.eff.org/files/2018/06/12/article13letter.pdf

Positions of the EFF (Electronic Frontiers Foundation) https://www.eff.org/deeplinks/2018/06/internet-luminaries-ring-alarm-eu-copyright-filtering-proposal

https://www.eff.org/deeplinks/2018/06/eus-copyright-proposal-extremely-bad-news-everyone-even-especially-wikipedia

Other sites campaigning against Article 13:

https://www.liberties.eu/en/news/delete-article-thirteen-open-letter/13194

https://saveyourinternet.eu/

Statement by the Wikimédia Foundation:

https://blog.wikimedia.org/2018/06/14/dont-force-platforms-to-replace-communities-with-algorithms/

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1Nb4aJWgAUAqMUCzeF2vTTDUNVNTM5ak42

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind 🙂

La directive copyright et le problématique article 13

La « directive sur le droit d’auteur dans le marché unique numérique », aussi appelée « directive copyright », est actuellement en cours d’examen au parlement européen ; les amendements (V6 du document) seront votés le 20 juin 2018 en commission “JURI”.

J’ai écrit le texte qui suit pour établir un argumentaire avant d’appeler quelques députés européens (pour être plus convaincant, il vaut mieux connaître son sujet), participant ainsi à la campagne lancée par le site saveyourinternet.eu.

Je vous invite à en faire autant, non sans avoir lu quelques unes des références citées en fin de page, et consulté https://juliareda.eu/2018/06/saveyourinternet/ pour connaître les partis et députés qui sont susceptibles de faire pencher la balance.

Deux articles sont particulièrement problématiques, l’article 11, qui concerne la citation d’articles de presse, mais dont nous ne parlerons pas ici, et surtout l’article 13, qui vise à mettre en œuvre des filtres sur tous les sites participatifs (c’est à dire, visant à partager du contenu, de quelque nature qu’il soit, ceci incluant donc les réseaux sociaux).

L’objectif poursuivi par l’article 13 de la directive est de protéger les ayants-droit de l’industrie du divertissement contre l’hégémonie des plateformes de partage, notamment Youtube, qui provoqueraient une “évasion” de revenus lorsque des œuvres leur appartenant sont diffusées illégalement sur ces plateformes.

La solution proposée est d’instaurer une obligation légale de systèmes de “listes noires” de contenus protégés., sur tous les sites en ligne,  et de tous les contenus, même de ceux qui n’ont pas besoin de protection (par exemple, le code source de logiciel informatique).

Nous allons voir comment de tels systèmes fonctionnent, pourquoi ils sont complexes à mettre en œuvre avec des dégâts collatéraux significatifs, et pourquoi le but recherché est déjà atteint sur les plateformes visées, rendant l’article 13 néfaste.

Les systèmes de “liste noire” de contenus

On peut les classer en trois catégories :

Les systèmes de détection “à l’identique”

Relativement peu coûteux en ressources, ils fonctionnent sur le contenu numérique des fichiers concernés, et n’ont pas besoin de connaître le format ou le type de média, ni même le détail du contenu à protéger, grâce à l’utilisation d’algorithmes de “hachage” (ou “résumé”).

Ces caractéristiques rendent ces systèmes très simples à implémenter et exploiter, et peu coûteux. Les algorithmes concernés sont des logiciels libres / open source, ou libres de droits, et faciles à adapter à toute plateforme technique.

En revanche, ces systèmes sont très faciles à contourner, par simple modification mineure du fichier concerné. Ils ont donc une utilité très limitée pour protéger les détenteurs de droits.

Les systèmes de détection “par similarité”

Ces systèmes sont beaucoup plus complexes. Ils ont la connaissance des formats employés, et en extraient des éléments “caractéristiques”, une sorte d’empreinte digitale du contenu à protéger. Ce procédé d’empreinte permet de détecter un contenu même très altéré, par exemple un fond musical à peine audible dans une vidéo de fête familiale ou de théâtre amateur.

Le plus connu, auquel font fréquemment référence les réactions à l’article 13, est Content-Id, de Youtube, décrit ici par Google.

Les systèmes “par similarité” sont très coûteux à développer et à exploiter. Google cite la somme de plus de 100 millions de dollars d’investissement pour Content-Id. Il n’en existe pas d’implémentation libre de droits, ce qui les rend d’autant plus difficiles à mettre en œuvre : il faut, ou bien développer un système “à façon”, ou bien acquérir une licence d’un système commercial existant, s’il en existe. Les sociétés en mesure de proposer de tels mécanismes très spécifiques sont rares.

Par ailleurs, la qualité des résultats (taux de faux positifs ou faux négatifs) de ces algorithmes est difficile à estimer, d’abord pour les raisons qui précèdent (systèmes propriétaires à accès limité), ensuite parce que les systèmes techniques de détection n’ont pas une fiabilité absolue.

Enfin, ces systèmes souffrent d’un autre défaut important : comme l’explique Google dans la vidéo ci-dessus, les ayants-droit doivent fournir les originaux ou des extraits des contenus à protéger, ce qui est difficile à mettre à œuvre à grande échelle (beaucoup d’œuvres et beaucoup d’acteurs).

Les systèmes par “marquage”

Ces systèmes dits de watermarking, évoqués dans les annexes de la directive, ne sont cités ici que pour mémoire. Ils ont des coûts similaires aux systèmes par similitude, mais sont d’application limitée, peu envisageables dans le cas de l’article 13.

La gestion des listes noires

La gestion des listes constitue, indépendamment des procédés techniques qui précèdent, un problème en soi.

Ni l’article 13 en sa rédaction originale, ni les amendements proposés, qui le complexifient considérablement, ne proposent de solution suffisante aux problèmes sous-jacents :

  •  risque de sur-blocage : blocage de contenus qui ne sont pas en infraction, en raison d’un enregistrement abusif par un détenteur de droit supposé, blocage de contenus bénéficiant d’une exception (mèmes, parodies, etc) dans lesquels les automates ont reconnu un contenu protégé.  Le risque existe si la liste noire est mal alimentée, ce qui a déjà été observé dans d’autres contextes, par exemple à plusieurs reprises avec le système national de blocage DNS de la police française, y compris par des systèmes de test mal configurés : voir Google.fr bloqué pour apologie du terrorisme suite à une « erreur humaine » d’Orange).
  • risque de sous-blocage : non blocage de contenus soumis à droits. L’enregistrement des contenus est lourd à mettre en œuvre ; de nombreux contenus n’ont même jamais été numérisés par leurs détenteurs légitimes
  • L’ajout en liste noire peut nécessiter une vérification manuelle, donc lourde, pour réduire les taux de faux positifs sans pour autant les faire disparaître.
  • lourdeur et manque de fiabilité des procédures de contestation : tous les cas de sur-blocage ou de sous-blocage doivent être traités par intervention humaine, voire judiciaire. Or, les cas de censure abusive sont quotidiens ; cela a été observé avec le DMCA (Digital Millenium Copyright Act) états-unien, où des détenteurs de droits ont engagé des procédures sur des œuvres qui ne leur appartenaient pas, sur similarité de titre, ou par détournement de finalité pour obtenir le retrait de listes de comparateurs de prix. L’amateur est démuni devant la lenteur et le coût d’un recours éventuel en justice en cas de blocage abusif.

Ni l’article 13 originel, ni les amendements ne répondent de manière satisfaisante à ces points, et en particulier au problème des blocages abusifs, où la solution de dernier recours proposée est une procédure en justice.

Le système Content-Id

Bien qu’appartenant à Google et spécifique à Youtube, ce système nécessite un examen plus détaillé. Il semble en effet avoir servi de modèle implicite à l’article 13.

Content-Id est un système de détection “par similarité”. Pour en bénéficier, les détenteurs de droits doivent fournir à Youtube des vidéos à protéger, ou des échantillons.

Ensuite, 3 options sont proposées en cas de détection d’un contenu “à protéger” :

  • bloquer la vidéo
  • monétiser celle-ci (publicité)
  • obtenir des données de consultation, pour savoir par exemple dans quels pays la vidéo est populaire

Selon Google, Content-Id a déjà permis le reversement de plusieurs milliards de dollars de revenus. Le système inclurait des centaines de millions de vidéos.

Impact de la directive

Le résumé de l’étude d’impact joint au projet de directive est très incomplet : en comparaison de l’étude d’impact complète, il ne parle que très partiellement de l’impact pour les détenteurs de droits, se limitant à une réflexion juridique sur le marché unique, et n’évoque pas l’efficacité et la faisabilité technique des mesures, ni l’impact sur les sites et l’écosystème Internet. Il est conseillé de se reporter à l’étude d’impact complète.

1. Disparition ou marginalisation des sites contributifs

Les sites de partage de contenus libres et sites contributifs n’auront pas les ressources financières pour exploiter,  a fortiori développer, ni même louer, des systèmes équivalents à Content-Id.

L’étude d’impact fournit un exemple de coût d’abonnement à un tel service : 900€/mois pour un petit site (5000 transactions/mois, soit 0,18€/transaction).

Mais l’étude n’en considère l’impact que pour des sites commerciaux dont le partage est la vocation principale, omettant donc l’impact négatif sur les sites participatifs et contributifs à fort volume (tels que Wikipédia), les réseaux sociaux, les sites de partage de photos amateurs ou familiales, petites annonces, etc, pour lesquels les revenus sont inexistants ou faibles en comparaison des coûts d’une vérification a priori des contenus.

Ce premier impact sur la liberté d’expression est donc minimisé.

2. Tous les contenus sont visés

Les systèmes de protection des droits d’auteur actuellement déployés s’intéressent essentiellement aux contenus qui concernent l’industrie du divertissement :

  • vidéos et films
  • musiques

Or, les partages sur Internet concernent bien d’autres types de contenus, notamment :

  • logiciels en source (logiciel libre)
  • photographies

Là encore, l’impact sur le coûts de fonctionnement des services en ligne concernés sera significatif, avec les mêmes risques de censure abusive des contenus, donc impact amplifié sur tous les autres points cités ici.

3. Dangers à l’égard de la liberté d’expression

Comme l’ont signalé de nombreuses associations, et comme expliqué ici, les systèmes par similarité sont incapables de distinguer une contrefaçon, un plagiat, une parodie, un mème, etc. Il est également fréquent que des œuvres libres de droit se retrouvent indûment répertoriées, par exemple parce qu’elles sont apparues ou ont été citées dans une œuvre soumise à droits (reportage télévisé, émission, etc).

Dans tous ces cas, les robots de détection produisent déjà, là où ils sont mis en œuvre, des censures abusives. Forcer l’extension de leur usage par la directive ne peut donc résulter qu’en des atteintes supplémentaires et sérieuses à la liberté d’expression, tout particulièrement sur les réseaux sociaux, rendant impossible ou difficile l’exercice des exceptions légales citées ci-dessus.

Enfin, comme exprimé précédemment, l’élargissement à tous les types de contenus ne peut qu’accentuer ce risque.

4. Inefficacité du dispositif pour protéger les ayants-droit

Comme on l’a vu, les systèmes de type Content-Id ne sont pas généralisables en raison de leur coût, et les systèmes de détection de contenus à l’identique sont faciles à contourner.

En outre, ces systèmes sont déjà mis en œuvre sur les grands sites, comme l’étude d’impact le reconnaît :

In all, as content recognition technologies are already applied by the major user uploaded content services, it is likely that this option would not lead to significant increases in unjustified cases of prevented uploads compared to the current situation

L’étude estime que l’article 13 ne pénalisera pas la liberté d’expression, ce qui n’est pas avéré, mais on peut dire également que l’article 13 serait d’une utilité limitée sur les plateformes visées.

5. Inefficacité du dispositif pour promouvoir la diversité culturelle

L’étude d’impact affirme que l’article 13 favorise la diversité, celle-ci étant supposée découler directement de la protection des ayants-droit.

Or,  l’article 13 défavorise les sites contributifs et/ou non lucratifs, qui font eux aussi partie de la diversité, avec des contenus souvent libres de droits, donc d’une diffusion naturellement maximale. Les statistiques d’audience de Wikipédia le démontrent : 5e site mondial d’après l’étude Alexa. De plus, selon la fondation Wikimédia France, « les plateformes opteront pour un principe de précaution en bloquant plus de contenu que nécessaire ce qui réduira la diversité de ces plateformes en empêchant les personnes peu aguerries aux nouvelles technologies d’y participer ».

En résumé, l’article 13 :

  • n’améliorerait en rien la situation des ayants-droit vis-à-vis des grandes plateformes, celles-ci ayant déjà déployé des systèmes de détection et de reversement de droits ;
  • n’améliorerait en rien, non plus, la situation des ayants-droit par rapport aux plateformes non commerciales ou de faible audience, qui n’ont pas la capacité de déployer des systèmes complexes, ne pratiquent pas de contrefaçon des œuvres protégées autre qu’accidentelle donc marginale, et sont déjà en mesure de retirer les contenus illégitimes  ;
  • présente, en revanche, de grands risques de censure arbitraire, de confortement de la position des grandes plateformes par la création de barrières significatives à l’entrée, de disparition pure et simple des plateformes non lucratives, ou de repli de celles-ci sur de la diffusion de contenus figés, sans aspect participatif ;
  • présente également des risques graves vis-à-vis de la liberté d’expression et de la diversité culturelle.

Pour toutes ces raisons, et comme l’ont également exprimé de très nombreuses associations et experts renommés, il semble préférable d’abandonner totalement l’article 13 en l’état actuel des connaissances et techniques.

Quelques références

Deux articles sur le blog de Julia Reda, la députée allemande qui a été en pointe sur la critique des articles 11 et 13 :

La lettre ouverte de 70 experts de l’Internet https://www.eff.org/files/2018/06/12/article13letter.pdf

Les avis de l’EFF (Electronic Frontiers Foundation) https://www.eff.org/deeplinks/2018/06/internet-luminaries-ring-alarm-eu-copyright-filtering-proposal

https://www.eff.org/deeplinks/2018/06/eus-copyright-proposal-extremely-bad-news-everyone-even-especially-wikipedia

D’autres sites faisant campagne contre l’article 13 :

https://www.liberties.eu/en/news/delete-article-thirteen-open-letter/13194

https://saveyourinternet.eu/

La position de la fondation Wikimédia :

https://blog.wikimedia.org/2018/06/14/dont-force-platforms-to-replace-communities-with-algorithms/

La position de Wikimédia France :

https://www.wikimedia.fr/2018/06/11/reforme-europeenne-droit-dauteur/

La position de la Quadrature du Net, plus complexe, qui a laissé perplexe bon nombre de gens (je déconseille le point 1 de l’argumentaire, non souhaitable à mon avis) :

https://www.laquadrature.net/fr/copyright_plateforme

Autres liens :

2 articles détaillés de l’indispensable nextinpact.com (abonnez-vous !) qui suit le sujet depuis longtemps :

Pourquoi les mèmes sur Internet sont en danger https://www.bfmtv.com/tech/pourquoi-les-memes-sur-internet-sont-en-danger-1468454.html

Adieu mèmes et parodies ? Pourquoi « l’article 13 » menace Internet https://usbeketrica.com/article/adieu-memes-et-parodies-pourquoi-l-article-13-menace-internet

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1Nb4aJWgAUAqMUCzeF2vTTDUNVNTM5ak42

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind 🙂

500 000 doublons sur les listes électorales françaises ; pas grave

[Ce billet étant en grande partie déductif (voire spéculatif), veuillez lire un conditionnel implicite dans tout ce que j’affirme ci-dessous ;  je suis ouvert à toute correction technique sur des erreurs que j’aurais pu éventuellement commettre sur le processus électoral]

Vous n’en avez peut-être pas entendu parler, comme moi, qui l’ai découvert par hasard hier. Je vous invite à commencer par lire cet article du Monde datant du 13 avril 2017. L’article est rempli de petits détails qui comptent :

Vote en 2017 : quelque 500 000 électeurs sont inscrits deux fois sur les listes électorales

500 000 électeurs français environ sont inscrits sur 2 listes électorales, en général suite à déménagement : une fois à leur nouvelle adresse, et une fois à leur ancienne adresse.

Lors d’un déménagement, l’électeur s’inscrit à la mairie, et c’est l’administration, plutôt que l’électeur, qui s’occupe des formalités de radiation à l’ancienne adresse. L’article explique le processus : la nouvelle mairie remonte l’information d’inscription à l’INSEE, qui se charge de transmettre une demande de radiation à l’ancienne mairie.

Or, le processus semble ne pas fonctionner correctement : les radiations ne sont pas toutes actées, pour des raisons obscures. Les mairies accusent l’INSEE, qui assure que de son côté tout est exécuté dans les règles. Le tout circule par… la poste.

Il existe donc à ce jour 500 000 radiations qui n’ont pas été effectuées et qui correspondent à autant de doublons dans les listes.

Et c’est là que la situation, déjà préoccupante en elle-même, devient de plus en plus ubuesque.

Le ministère de l’intérieur, chargé de l’organisation du scrutin et d’assurer sa “sincérité”,  semble tout simplement n’avoir aucune intention de changer quoi que ce soit avant le premier tour du 23 avril (je n’ai trouvé aucun communiqué officiel sur la question).

Si on creuse un peu (il suffit en fait de lire attentivement l’article qui précède), on s’aperçoit que le problème ne date pas de 2017. En 2012 déjà, 400 000 électeurs étaient inscrits en double.

Si on suppose que le volume d’erreur est resté relativement fixe et qu’on extrapole la période 2012-2017 au passé, on peut calculer qu’à raison d’environ 100 000 doublons supplémentaires par période de 5 ans, le problème date d’environ 25 ans, donc remonte à 1992 approximativement, et est connu de l’administration depuis au moins 5 ans — version optimiste ; au pire, 25 ans — plutôt que 2 semaines, et persiste néanmoins aujourd’hui.

Que faudrait-il faire pour y mettre fin ? C’est difficile à dire, car les détails qui filtrent sont rares ; et on nous assure que le problème est très complexe. Apparemment l’INSEE dispose d’une liste nationale (puisque c’est lui qui sait à qui communiquer les radiations), et les mairies disposent évidemment chacune des listes électorales locales, bureau par bureau (puisqu’elles réalisent les inscriptions et radiations).

Il serait possible (mais cela serait étonnant) que l’INSEE ne garde tout simplement pas trace des notifications de radiations proprement dites. Il est néanmoins très probable que l’INSEE conserve un historique des versions successives (au moins sur les années récentes ; peut-être pas sur les années plus anciennes, s’il existe des lois interdisant la conservation longue de ces données de nature très personnelle) du fichier national, dont il est facile de déduire la liste des radiations.

Quelques petites informations supplémentaires sur la procédure sont données dans les interviews de cette vidéo de LCI :

Présidentielle 2017 : 500 000 électeurs inscrits en double, le ministre de l’Intérieur sommé de “faire son boulot” pour éviter des fraudes

Le responsable électoral de la mairie de Paris 17e décrit rapidement ce que j’ai exposé plus haut.

On y entend également un avocat spécialisé en droit électoral nous expliquer que 500 000 doublons correspondent à environ 1% du corps électoral, soit 1% indûment compté en abstention ; ce qui selon lui ne serait pas très grave. Pour un premier tour de présidentielle, c’est relativement exact (hors tentatives d’exégèse du taux d’abstention) ; pour les législatives, où les candidats de second tour doivent obtenir au moins 12,5% des inscrits, cela peut changer significativement les choses.

La raison citée par la place Beauvau pour minimiser la gravité de la situation, et excuser l’absence de mesure avant le 23 avril, est que, de toute façon, la loi punit sévèrement le fait de voter en double : de 6 à 24 mois d’emprisonnement et jusqu’à 15 000 euros d’amende.

Or, retrouver les contrevenants semble quasiment impossible dans le cas général : en effet, pour cela il faudrait, d’abord, effectuer le dédoublonnage — opération dont on nous dit qu’elle est difficile, ce que semble confirmer le fait qu’elle n’ait pas été réalisée depuis 5 ans –, et, en plus, croiser le résultat avec les listes d’émargement bureau par bureau. Les listes d’émargement étant tenues de manière manuelle, puisque c’est la signature du votant qui y atteste de son vote, leur vérification a posteriori ne peut être également que manuelle.

Le plus triste à mon sens est que cette situation touchant un des éléments les plus essentiels de notre démocratie perdure depuis au moins 5 ans et soit minimisée voire ignorée par l’administration dans la plus parfaite opacité.

PS : pendant que ces trous béants persistent, les pouvoirs publics communiquent avec conviction sur les efforts déployés pour sécuriser nos élections contre les attaques informatiques provenant de puissances étrangères hostiles.

Ajout du 23 avril 2017 : on me fait remarquer dans les commentaires que la poste est supposée ne pas réexpédier les cartes d’électeur, et on me dit sur twitter que cela figure même sur l’enveloppe, ce que je n’avais pas remarqué. En effet.

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1Nb4aJWgAUAqMUCzeF2vTTDUNVNTM5ak42

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind 🙂

Bernard Cazeneuve, notre amour

Vous connaissez mon amour pour notre ex ministre de l’Intérieur maintenant promu,  Bernard Cazeneuve, et l’ensemble de son œuvre sécuritaire au gouvernement :

  • surveillance de masse
  • couverture et légalisation des agissements “a-légaux” des services de renseignement
  • censure de sites sans juge
  • pénalisation de la consultation “régulière” de sites djihadistes
  • état d’urgence prolongé ad nauseam
  • perquisitions et assignements à résidence plus ou moins ouvertement abusifs, utilisés notamment pour contrer les opposants politiques (écologistes), de l’aveu même de François Hollande
  • j’en passe et des pires… sans Bernard, nous serions fort démunis.

Eh bien Bernard a une autre fan, Alison Wheeler, qui lui a dédié cette magnifique chanson sur France Inter aujourd’hui, reçue via @kiri_kourou sur twitter, que je remercie.

Je ne peux résister à l’envie de la faire partager et d’en garder une trace ici.

Merci Alison !

Bernard “Baby” Cazeneuve – d’Alison Wheeler

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1Nb4aJWgAUAqMUCzeF2vTTDUNVNTM5ak42

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind 🙂

Retour sur l’usage de TLSv1 et DES

Suite à https://signal.eu.org/blog/2016/09/28/securite-des-serveurs-web-avec-tls-petite-toilette-dautomne-2016/, à force d’entendre des injonctions contradictoires de la part des experts TLS (“il faut désactiver TLSv1”, “il faut supprimer DES”…), j’ai voulu voir l’implication que cela aurait eu sur les accès de mon serveur, qui inclut ce blog et plusieurs autres, ainsi que nic.eu.org.

Voici donc quelques statistiques sur le trafic depuis environ un an. Le trafic n’est pas considérable mais il dépasse quand même les 820 000 accès. Je ne prétends pas que ces statistiques soient représentatives du trafic général sur le web, mais elles le sont par définition pour moi 🙂

Les différentes négociations  aboutissant à DES (en rouge) sont très minoritaires mais encore très présentes. Seul DES-CBC3-SHA n’est pas négligeable.

65,2609% ECDHE-RSA-AES128-GCM-SHA256
18,1320% ECDHE-RSA-AES256-GCM-SHA384
12,2206% ECDHE-RSA-AES256-SHA
 1,9730% DHE-RSA-AES256-SHA256
 1,9188% DES-CBC3-SHA
 0,7400% DHE-RSA-AES256-SHA
 0,5099% RC4-SHA
 0,4088% ECDHE-RSA-AES256-SHA384
 0,2353% DHE-RSA-AES256-GCM-SHA384
 0,1808% ECDHE-RSA-AES128-SHA
 0,0656% AES256-SHA
 0,0606% DHE-RSA-AES128-SHA
 0,0304% AES128-GCM-SHA256
 0,0104% ECDHE-RSA-AES128-SHA256
 0,0018% AES256-SHA256
 0,0011% AES256-GCM-SHA384
 0,0010% EDH-RSA-DES-CBC3-SHA
 0,0010% ECDHE-RSA-DES-CBC3-SHA
 0,0010% DHE-RSA-CAMELLIA256-SHA
 0,0010% DHE-RSA-CAMELLIA128-SHA
 0,0010% CAMELLIA256-SHA
 0,0010% CAMELLIA128-SHA
 0,0010% AES128-SHA
 0,0007% DHE-RSA-AES128-GCM-SHA256
 0,0004% DHE-RSA-AES128-SHA256
 0,0004% AES128-SHA256

Si TLSv1.1 et TLSv1 sont très minoritaires, ils ne sont pas inexistants pour autant. Quant à SSLv2 et SSLv3, s’ils ne sont pas visibles ci-dessous c’est parce que je les ai désactivés d’autorité, je ne peux donc pas avoir de statistiques significatives dessus.

86,5586% TLSv1.2
13,1792% TLSv1
 2,0327% TLSv1.1

Je n’en sais pour l’instant pas plus sur la nature des accès. La configuration par défaut Apache conserve trop peu d’informations.

Pour en savoir plus j’ai donc défini le format suivant, qui au format par défaut ajoute le nom d’hôte virtuel et le user-agent :

LogFormat "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b %{User-Agent}i %{Host}i" sslua
No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1Nb4aJWgAUAqMUCzeF2vTTDUNVNTM5ak42

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind 🙂

Sécurité des serveurs web avec TLS, petite toilette d’automne 2016

Résumé pour gens très pressés : ce n’est pas si difficile que cela en a l’air.

Résumé pour gens pressés : même sans être un gourou de la cryptographie, il est possible de sécuriser son site au niveau approximatif de l’état de l’art (du moment — ce n’est jamais une tâche définitive) en s’appuyant sur des sites de recommandations réalisés par des spécialistes.

Après avoir passé quelques heures à peaufiner ma configuration, je pense utile de partager ce que j’ai appris pour dispenser autour de moi un peu de bonheur artificiel par l’entremise de la sécurité cryptographique.

L. Hirlimann (@lhirlimann) m’a récemment orienté sur un excellent site de la fondation Mozilla, observatory.mozilla.org,  qui permet de vérifier la configuration sécurité basique de votre site web, à commencer par l’aujourd’hui indispensable TLS, et mutualise également (par défaut, mais c’est débrayable) les résultats des non moins excellents :

1. TLS, les algorithmes cryptographiques

Au-delà de ses origines mathématiques, la cryptographie est une affaire de paranoïaques qui n’ont pas tous exactement le même avis sur ce qui est casher ou pas à un instant donné.  Les audits rapides réalisés par les sites qui précèdent vous en convaincront rapidement.

Ainsi, après quelques premières modifications rapides sur ma configuration TLS, SSL Labs attribuait un A+ à ce site, alors que tls.imirhil.fr l’affublait d’un catastrophique F sous prétexte que l’algorithme DES n’était pas désactivé.

Bien entendu, cela évolue aussi au fil du temps, qui fait qu’un algorithme donné va passer en quelques petites décennies à peine du statut de “sûr” à celui de “passoire”, que ce soit par l’évolution des performances brutes ou par celles de la recherche en attaques cryptographiques.

Par ailleurs, vous aurez éventuellement également le plaisir de vous faire rappeler à l’ordre par ces analyses si votre implémentation TLS comporte des trous de sécurité connus. J’ai découvert qu’il est assez facile de se faire avoir, même avec un système d’exploitation que l’on pensait à jour.

Les “suites” cryptographiques recommandées varient au fil des sites spécialistes que l’on consulte.

Voici, pour ne pas vous faire languir, celle que j’ai concoctée pour satisfaire les sites cités (!) ci-dessus, et qui est certainement sujette à commentaires et critiques (attention, c’est supposé tenir sur une ligne sans retour) :

EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA
-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-S
HA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:
ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-
SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-
SHA256:AES256-SHA:AES128-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4

N’allez surtout pas croire que j’ai construit ni même analysé en détail ce qui précède : la liste provient à l’origine de https://www.digicert.com/ssl-support/ssl-enabling-perfect-forward-secrecy.htm dont l’objet est d’expliquer la configuration d’un serveur web pour éviter qu’un vol de clé privée permette le déchiffrement a posteriori des communications, une mesure à prendre suite aux révélations de l’affaire Snowden sur les capacités de la NSA, et suite également à l’affaire Lavabit.

J’ai simplement amendé la liste pour y ajouter !DES:!3DES: pour évacuer ce vieil algorithme des choix et passer chez tls.imirhil.fr d’un catastrophique F à un passable B.

Si comme moi vous utilisez Apache, cette liste est à placer dans la directive SSLCipherSuite.

Problème : l’incantation qui précède est difficile à comprendre, et donc à modifier, si on n’a pas lu la documentation. En particulier il ne suffit pas d’ajouter !DES pour se débarrasser également de 3DES. Ce n’est pas facile à découvrir rapidement en passant par les sites ci-dessus, qui pour éviter d’être surchargés ne permettent pas des accès trop fréquents (limite à 5 minutes au mieux).

J’ai donc découvert également l’excellente (tout le monde est excellent ici, vous l’aurez compris) commande :

openssl ciphers "la chaîne"

et son avatar plus bavard :

openssl ciphers -v "la chaîne"

qui permettent de tester la chaîne immédiatement en local pour voir ce qu’elle produit sans avoir à attendre la réponse d’un serveur situé à l’autre bout de la planète.

2. Sécurité “web” :  contenu et entêtes

Ce qui précède ne concerne que la partie TLS, c’est-à-dire la couche de chiffrement.

C’est ensuite que observatory.mozilla.org prend tout son sens, en complétant l’expertise cryptographique avec l’expertise web des auteurs de Firefox par le tableau suivant (exemple pour ce site au jour de la publication de ce billet) :mozJe ne vais pas entrer dans les détails ; chaque point correspond à des catégories particulières d’attaques plus ou moins pertinentes pour chaque site, et comme vous pouvez le voir je n’ai pas encore débloqué tous les trophées. On y trouve des recommandations sur :

  • HSTS (Host Strict Transport Security), permettant au site de s’engager vis-à-vis du navigateur sur la disponibilité de https.
  • Subresource Integrity, pour valider les contenus inclus (en particulier scripts) stockés sur des serveurs tiers ;
  • X-Content-Type-Options, pour interdire au navigateur d’interpréter n’importe quoi (par exemple une supposée image téléchargée par un attaquant) comme un script ;
  • X-Frame-Options, pour bloquer des attaques par détournement de clics (clickjacking) ;
  • les redirections diverses afin d’amener l’utilisateur à un site https même dans le cas où il ne s’y est pas dirigé lui-même initialement ;
  • etc

observatory.mozilla.org vous donne par les liens bleus (dont j’ai recopié certains ci-dessus) toutes les explications détaillées sur les possibilités et le sens de chaque option de configuration.

Sous Apache, cela se configure comme ci-dessous, à condition d’avoir chargé le module mod_headers.

Attention : les options pour mon site ne sont certainement pas exactement celles dont vous aurez besoin ; en particulier vous pouvez facilement vous tirer une petite balle dans le pied et vous retrouver avec Javascript désactivé sur certaines fonctions essentielles. Ce fut mon cas, ce qui m’a fait perdre temporairement l’éditeur Wysiwyg de WordPress, et le problème est encore potentiellement présent dans l’exemple qui suit.

Attention également aux sauts de ligne si vous recopiez.

  # HSTS 366 days
Header set Strict-Transport-Security "max-age=31622400"
# Prevent browsers from incorrectly detecting non-scripts as scripts
Header set X-Content-Type-Options: nosniff
# Block site from being framed
Header set X-Frame-Options "DENY"
# Do the same thing, but with Content Security Policy
# +Disable unsafe inline/eval, only allow loading of resources
# (images, fonts, scripts, etc.) over https (recommended)
Header set Content-Security-Policy "default-src https:; frame-ancestors 'none'"
# Block pages from loading when they detect reflected XSS attacks
Header set X-XSS-Protection "1; mode=block"

Ces recommandations permettent d’élucider le comportement souvent mystérieux des navigateurs en ce qui concerne le contenu sécurisé, dans le but de comprendre comment passer du cadenas https “avec avertissement” c0 au cadenas “vert”c1.

Je n’ai pas encore tout à fait réussi en ce qui concerne la page https://signal.eu.org/osm/, malgré la mise en œuvre de Subresource Integrity.

3. Les cookies

Pour les cookies, c’est encore différent, cela dépend de l’environnement (framework) web que vous utilisez. Concernant WordPress je n’ai pas encore trouvé si/où cela se gérait, pour Django voici ce que j’ai configuré dans le fichiers settings.py :

LANGUAGE_COOKIE_AGE=1209600
CSRF_COOKIE_HTTPONLY=True
CSRF_COOKIE_SECURE=True
SESSION_COOKIE_AGE=1209600
SESSION_COOKIE_HTTPONLY=True
SESSION_COOKIE_SECURE=True

4. One more thing

Enfin, vous pouvez aussi pour tout cela vous faire assister par un autre site proposé par la fondation Mozilla, le générateur de configuration pour serveur web, qui vous conseillera sur la configuration de l’agrafage (stapling) OCSP et certains des points qui précèdent :

https://mozilla.github.io/server-side-tls/ssl-config-generator/

 

 

Nul doute qu’il y a des précisions ou corrections à apporter à ce qui précède, si vous le jugez utile n’hésitez pas ci-dessous.

Mise à jour : @_eric_quinton me signale gentiment sur twitter ce document de l’ANSSI :  Le nouveau (juillet 2016) C’est très complet mais très technique, et cela mixe recommandations à destination des administrateurs de site comme à destination des développeurs de suites crypto, ce qui complique la lecture.

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1Nb4aJWgAUAqMUCzeF2vTTDUNVNTM5ak42

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind 🙂

Professions de foi et bulletins, élections régionales 2015, Île de France

Comme pour les élections européennes, voici le PDF des professions de foi reçues par la poste hier (27 novembre 2015). Le PDF inclut les papiers dans l’ordre exact à leur réception. Il y avait deux paquets séparés dans l’enveloppe, l’un commençant par les papiers de Lutte Ouvrière, l’autre commençant par ceux du FN.

Toutes les listes candidates ne sont pas dans les papiers reçus, il manque :

  • Fédération libertaire unitaire ouverte (FLUO), liée d’après son affiche, entre autres, au “Parti pirate”
  • Liste d’union citoyenne
  • Nous Citoyens (NC)
  • Parti libéral démocrate (PLD) – Génération Citoyens (GC)
  • Union des démocrates musulmans français (UDMF)
No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1Nb4aJWgAUAqMUCzeF2vTTDUNVNTM5ak42

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind 🙂

EU.org, les métadonnées et la loi renseignement

Après avoir écrit ce billet sur la surveillance de masse comparée aux écoutes téléphoniques classiques, je ressens la nécessité de revenir en détail sur le communiqué de eu.org, en particulier l’extrait ci-dessous sur ses motifs :

En effet, cette loi — dont le texte doit encore être voté définitivement à l’assemblée le 5 mai 2015, puis au sénat — instaure une surveillance légale systématique du trafic Internet par les services de renseignement français, dans des conditions d’opacité complète, sous la seule responsabilité de l’exécutif, sans contre-pouvoir.

Ce trafic inclut notamment des requêtes de résolution DNS des utilisateurs accédant aux 28 000 domaines délégués par Eu.org.

Eu.org ne peut moralement laisser en toute connaissance de cause le trafic de ses utilisateurs — incluant des sites d’activisme politique dans le monde entier — et, par ricochet, le trafic d’accès de leurs propres utilisateurs, exposé à de telles écoutes.

Ces éléments méritent d’être développés car ils ne touchent pas tout à fait aux mêmes sujets que l’hébergement web proprement dit. Ils concernent :

  • le trafic DNS, et la question de son chiffrement
  • les méta-données
  • la localisation des serveurs EU.org

Elles sont au cœur du projet de loi sur le renseignement.

Sur le trafic DNS

Tout accès à un site web commence par une résolution DNS depuis l’ordinateur du demandeur. Celui-ci demande, en général au serveur DNS du fournisseur d’accès, l’adresse IP (la seule utilisable pour effectuer la connexion) du nom de site désiré, ici par exemple signal.eu.org.

Sur Internet vont circuler des paquets contenant cette demande. D’abord de l’ordinateur initial au serveur DNS du fournisseur puis, si celui-ci ne connaît pas la réponse, du fournisseur aux serveurs de .ORG pour obtenir les adresses des serveurs EU.ORG, puis du fournisseur aux serveurs de EU.ORG pour y récupérer l’adresse de SIGNAL.EU.ORG.

Les réponses suivent le même chemin, en sens inverse.

Ce trafic circule “en clair”, que le site web finalement accédé soit protégé ou pas par du chiffrement, et est donc susceptible de révéler cette tentative d’accès à toute écoute en chemin.

Il n’existe actuellement aucun moyen de chiffrer le trafic DNS de résolution : les serveurs DNS “faisant autorité” (détenant les informations utiles) ne peuvent recevoir et répondre qu’en clair. Des travaux à l’IETF (l’organisation qui travaille à l’évolution des protocoles Internet) sont en cours pour résoudre ce problème.

Ce trafic est donc vulnérable à toute écoute et révèle des informations sur les accès à tel ou tel site, ou l’envoi de mail à tel ou tel serveur, etc. Dans le cas de EU.org, 28 000 domaines sont ainsi concernés, et un nombre inconnu mais probablement beaucoup plus élevé d’utilisateurs accédant à ces sites.

J’aurais pu développer ici également une réflexion sur les résolveurs DNS “personnels” par opposition à ceux du fournisseur, par rapport à la volonté affichée du ministère de l’Intérieur d’identifier les comportements “déviants” comme l’utilisation de chiffrement, de Tor ou de VPN, mais cela rendrait cet article trop long.

Sur les méta-données

Les méta-données sont les données techniques nécessaires à l’acheminement d’une communication.

Dans le réseau téléphonique il s’agit en particulier des numéros de l’appelant et de l’appelé.

Pour un routeur Internet ce sont les adresses IP origine et destination.

Pour un serveur d’application, ce sont les adresses IP, les numéros de port (qui permettent de savoir si la communication est un envoi de message ou un accès web) et le protocole.

Pour un site web cela peut être le nom du serveur, certaines informations sur le navigateur, le type de document consulté (texte, image), etc.

Et le trafic DNS ? Pour le routeur Internet il s’agit d’une donnée. Pour un serveur DNS, il s’agit en partie de méta-données, en partie de données. Pour le site web, il s’agit d’une méta-donnée.

Et pour le fournisseur d’accès ? Bonne question, la réponse n’est pas simple car le fournisseur d’accès gère à la fois des routeurs et des serveurs DNS de résolution.

La loi renseignement et les méta-données

Que dit la loi renseignement ? Dans son texte, rien. Elle ne parle que de données et de données de connexion. Mais ses promoteurs ont plusieurs fois affirmé, pour nous rassurer, que seules les méta-données étaient concernées.

Mais lesquelles ? Comme on l’a vu ci-dessus, la question est très floue puisque la réponse n’est pas la même suivant les équipements ou intervenants à qui on s’adresse.

Et, par ailleurs, pour reprendre un exemple très parlant, si quelqu’un sait que j’ai appelé le numéro d’un centre d’analyses médicales, puis un numéro vert d’information sur le SIDA, puis mon médecin, puis ma mutuelle, il peut avoir une idée suffisante du contenu de mes conversations sans pour autant y avoir accès.

La localisation des serveurs EU.org

Le trafic EU.org circulant en France sera donc sujet à écoute systématique et contient, comme on l’a vu, des informations sur des usages dont certains peuvent être sensibles.

Le chiffrement du trafic DNS de EU.org est actuellement impossible, et cela restera le cas à moyen terme. Même lors du déploiement des protocoles de chiffrement du DNS, leur usage ne sera pas systématique avant des années, voire jamais, comme le montrent l’exemple du web avec https, et celui du courrier électronique…

Par ailleurs, le chiffrement du trafic DNS, comme celui des sites web ou du courrier électronique, ne cacherait pas les méta-données d’acheminement du trafic.

La seule autre solution, celle choisie, est de déplacer les serveurs DNS EU.org dans des pays ne pratiquant pas l’écoute systématique légale.

Cette solution est très imparfaite : le trafic de résolution depuis des utilisateurs situés en France, ou vers des serveurs DNS situés en France, sera toujours sujet à écoute. De même, du trafic transitant par la France (peut-être entre Espagne et Allemagne, ou Royaume-Uni et Tunisie, ou d’autres pays, au gré des variations du routage d’Internet) risquera également d’être écouté.

Néanmoins, le trafic ainsi concerné sera évidemment beaucoup plus réduit que si  les serveurs DNS de EU.org sont situés en France.

Les spécificités de la loi renseignement française

La plupart des pays démocratiques pratiquent des écoutes, mais ce sont généralement des écoutes légales ciblées, sur le modèle déjà évoqué des écoutes téléphoniques, et encadrées par une décision judiciaire préalable.

En aucun cas — dans les pays démocratiques — il ne s’agit, comme le gouvernement souhaite le faire en France, d’écoutes légales et sans autorisation judiciaire a priori et systématiques (en masse), et même destinées à détecter des comportements parfaitement légaux mais “déviants”.

Je parle bien ici de la loi et non des décrets et mises en œuvre techniques, qui promettent à ce jour un cadre plus restreint que ne le permettra la loi elle-même, mais ne disent rien de mesures encore plus intrusives qui pourraient être déployées ultérieurement sans nécessité de retour au parlement.

Il peut exister parfois, n’importe où, et comme l’affaire Snowden/NSA l’a montré, des écoutes illégales ou découlant d’une interprétation très extensive de la loi, contre lesquelles il est difficile de se prémunir.

Mais mieux vaut, à mon avis, risquer ce genre d’écoute dans un pays où elles sont explicitement illégales que dans un pays où elles sont explicitement légales.

No tips yet.
Be the first to tip!

Like this post? Tip me with bitcoin!

1BWiVmrsd17LmDbPTt2SkS9zdTabjraivr

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind 🙂

Pourquoi la loi renseignement instaure une surveillance de masse

Vous avez sûrement suivi, comme moi, les débats sur la loi renseignement. Et sinon, si vous avez du temps, les vidéos (bittorrent) des débats à l’assemblée sont ici. et ici le texte (en son état actuel, à voter par l’assemblée le 5 mai).

Je voudrais revenir sur un point précis, un parmi de nombreux autres, mais l’un des plus importants.

Bernard Cazeneuve a répété de nombreuses fois que la loi renseignement n’établit pas une surveillance de masse. Il l’a dit à l’assemblée nationale, et également dans des interviews, comme celle-ci à Libération :

http://www.liberation.fr/societe/2015/04/10/parler-de-surveillance-generalisee-est-un-mensonge_1238662

Les mesures proposées ne visent nullement à instaurer une surveillance de masse ; elles cherchent au contraire à cibler les personnes qu’il faut suivre pour mieux protéger les Français. […] Parler de surveillance généralisée est un mensonge ! […] Les groupes ou les individus engagés dans des opérations terroristes ont des comportements numériques caractéristiques. C’est pour détecter leurs complices ou leurs pairs que l’algorithme est prévu.

Les passage en gras sont de mon fait, car j’y reviens ci-dessous.

Comment fonctionne une écoute téléphonique classique ?

Comment monte-t-on une écoute téléphonique ? C’est très simple. On cible une personne particulière, on pose une bretelle sur sa ligne, et on écoute ce qui passe. Autrefois c’était une dérivation électrique sur sa ligne ou au central téléphonique, de nos jours c’est une copie numérique indétectable.

Mais l’idée est similaire : 1) on cible, 2) on écoute, 3) on analyse

Comment fonctionne la « boite noire » Internet ?

Incidemment, il est amusant que le nom de « boite noire », qui provient des éléments de langage du ministère lors de la présentation de la loi pour éviter celui moins glorieux de DPI pour deep packet inspection (inspection de paquets), soit dès à présent tellement grillé lui aussi que son origine est attribuée aux opposants.

La boite noire est placée sur les flux réseau, de manière indiscriminée, et observe tout le trafic qui la traverse. Ou bien on a peu de boites noires placées en cœur de réseau, ou bien on en a beaucoup placées moins au cœur ; l’idée est la même, les boites noires doivent observer un maximum de trafic.

Que fait la boite noire ? Bernard Cazeneuve vient de l’expliquer dans l’interview qui précède et dans les nombreux débats.

Il s’agit de l’article L. 851-4 du code de la sécurité intérieure, qui va être créé par cette loi :

« Art. L. 851-4. ­ Pour les seuls besoins de la prévention du terrorisme, le Premier ministre ou l’une des personnes déléguées par lui peut, après avis de la Commission nationale de contrôle des techniques de renseignement, imposer aux opérateurs et aux personnes mentionnés à l’article L. 851-1, pour une durée de quatre mois renouvelable, la mise en oeuvre sur leurs réseaux d’un dispositif destiné à détecter une menace terroriste sur la base de traitements automatisés des seules informations ou documents mentionnés au même article L. 851-1. Dans le respect du principe de proportionnalité, l’autorisation du Premier ministre précise le champ technique de la mise en oeuvre de ces traitements. Cette dernière ne permet de procéder ni à l’identification des personnes auxquelles ces informations ou documents se rapportent, ni au recueil d’autres données que celles qui répondent aux critères de conception des traitements automatisés. Les conditions prévues à l’article L. 861-3 sont applicables aux opérations matérielles effectuées pour cette mise en oeuvre par les opérateurs et les personnes mentionnés à l’article L. 851-1. L’article L. 821-5 n’est pas applicable à cette technique de renseignement.

« Si une telle menace est ainsi révélée, le Premier ministre ou l’une des personnes déléguées par lui peut décider, après avis de la Commission nationale de contrôle des techniques de renseignement dans les conditions prévues au chapitre Ier du titre II du présent livre, de procéder à l’identification des personnes concernées et au recueil des informations ou documents afférents. Leur exploitation s’effectue alors dans les conditions prévues au chapitre II du même titre.

« La Commission nationale de contrôle des techniques de renseignement émet un avis sur le dispositif et les critères des traitements automatisés mentionnés au premier alinéa du présent article. Elle dispose d’un accès permanent à ceux-ci, est informée de toute modification apportée et peut émettre des recommandations. Lorsqu’elle estime que les suites données à ses avis ou à ses recommandations sont insuffisantes, elle peut faire application de l’article L. 821-6. » ;

La boite noire, donc : 1) écoute l’ensemble du trafic, 2) l’analyse de manière algorithmique, 3) y identifie des cibles potentiellement dangereuses pour analyse manuelle par les services.

Vous voyez la différence ? Les écoutes téléphoniques classiques n’arrivent qu’en milieu ou fin de chaîne, lorsque par d’autres moyens on a identifié un suspect, et que l’on veut obtenir des preuves plus précises contre lui.

La boite noire fait l’inverse, elle est là pour détecter des suspects dans du trafic a priori anodin.

Il s’agit donc bel et bien d’écoute en masse, surveillance généralisée, appelez-le comme vous voulez.

CQFD.

 

1 tip so far
0.01 BTC

Like this post? Tip me with bitcoin!

1AgYdomU2vD81iHXFzCNcASrjHu6qWrye

If you enjoyed reading this post, please consider tipping me using Bitcoin. Each post gets its own unique Bitcoin address so by tipping you're also telling me what you liked, in addition to contributing to the blog hardware and electricity, and perhaps a few beers if you don't mind 🙂

voie libre ou appel système