Compte rendu de la journée de constitution d'Upsilon (29 mars 2019)

La journée de constitution du projet Upsilon qui s'est tenue le 29 mars 2019 à l'Université Paris 8 a réuni une vingtaine de personnes. Parmi les présent·es, une petite moitié est liée directement au milieu universitaire dont deux hors informatique. Un bon nombre des présent·es sont issus des milieux associatifs et militants, principalement autour du logiciel libre, de hackerspaces, et de l'éducation populaire aux enjeux du numérique. Un des objectifs principaux d'Upsilon étant de « développer les échanges entre universitaires, associations et militant·es du libre », on peut considérer cette journée comme une réussite sur ce premier point !

Les débats de cette journée étaient organisés autour de trois grands thèmes (le programme a été élaboré collectivement sur un pad temporaire et notre équipe framateam), traités sur des temps séparés mais avec un certain nombre de recoupements dans les sujets abordés :

Enseignement supérieur critique de l'informatique

Les discussions sur cette thématique ont fait ressortir la nécessité de faire prendre conscience aux étudiant·es en informatique de leur rôle social et politique dans notre société, ce qu'on pourrait résumer par l'expression « code is law » de Lessig. Trois pistes sont évoquées pour cela, avec chaque fois l'objectif d'amener les étudiant·es à se questionner et agir.

1- D'abord, ajouter une dimension critique à certains projets réalisés par les étudiant·es. Cela prendrait la forme d'une section supplémentaire dans les rapports de projet, qui répondrait à une grille de lecture abordant notamment : l'impact du projet sur la vie privées de ses utilisateurices, l'impact écologique du projet, les dépendances logicielles / matérielles / humaines du projet et qui les contrôle / soutient, la chaîne de déploiement, l'utilisabilité du projet. Une autre possibilité (pas incompatible) et de faire réaliser aux étudiant·es de telles analyses sur des projets existants.

Agir :

2- Ensuite, généraliser les cours de développement de logiciel libre. Le but de ces cours est d'amener les étudiant·es à contribuer à un logiciel libre en corrigeant un bug ou en ajoutant une fonctionnalité a minima. Cela passe par une analyse du projet (technologies utilisées, moyens de communications, règles de contribution, conventions de code, mise en œuvre de l'environnement de développement, dépendances, etc) qui en elle même peut intéresser la communauté de ses développeurs, puis par une prise de contact avec la communauté en passant par les moyens de communications du projet (mailing-list, issue tracker, canal IRC, …), à maintenir jusqu'à une contribution effective.
Ce type de projet permet aux étudiant·es de se confronter à du code qu'illes ne maîtrisent pas de bout en bout comme c'est habituellement le cas dans leur projet de cours, et les force à utiliser des technologies (git, issue trackers, containers) qu'illes évitent parfois sinon.

Agir :

3- Enfin, impliquer les étudiant·es dans l'organisation d'événements sur les libertés numériques (ce qui fait le lien avec l'éducation populaire). Un retour d'expérience sur les cryptoparties organisées à Rennes et devenues depuis 2018 le Festival des Libertés Numériques.

Agir :

Recherche en sécurité émancipatrice

1- Les discussions sur cette thématique ont beaucoup porté sur l'utilisabilité des outils de sécurité. L'histoire montre que les produits pensés avant tout pour la sécurité et pour lesquels l'utilisabilité est vue comme secondaire sont peu adoptés (GPG est l'emblème de ce soucis). Il faut en tirer comme conclusion que l'utilisabilité fait parti intégrante de la sécurité, et qu'un soucis d'utilisabilité doit être considéré comme un bug de sécurité (c'est le cas dans le projet Tails, par exemple). Par ailleurs, il est possible de s'appuyer sur des projets utilisables et adoptés existants pour améliorer la sécurité des personnes. Par exemple, quand WhatsApp a implémenté Double Ratchet (le protocole de Signal), cela a sécurisé d'un coup les conversations de millions d'utilisateurices (modulo le fait que le logiciel soit fermé et fasse dépendre d'une entreprise, ce qui rend cette sécurité asservissante plutôt qu'émancipatrice, d'autant plus quand l'entreprise en question a pour modèle économique la collecte de données…). Un autre exemple, bien plus proche de la sécurité émancipatrice que l'on défend, est le projet Tor, qui a fait le choix judicieux de combiner le client Tor avec le navigateur Firefox pour pouvoir distribuer un outils simple d'utilisation, le Tor Browser, au grand public.

Agir :

2- La discussion sur l'autohébergement et sa définition a mis en évidence l'inexistence d'un concept universel de sécurité et donc la nécessité du modèle de menace, ce qui implique de replacer l'utilisateurice au centre du dispositif de sécurité. Les utilisateurices ont des attentes en matière de sécurité et privacy mais ne les formulent pas forcément ou ne sont pas forcément capables d'évaluer l'adéquation entre leurs attentes et le fonctionnement des outils qu'illes utilisent. L'exemple est pris du SMS : quand Alice envoie un SMS à Bob, elle s'attend a priori à ce que cela reste entre elle et lui, mais à aucun moment les outils dont elle dispose ne l'ont amené à formuler cette attente ni ne l'ont informé qu'elle ne correspondait pas à la réalité. Un second exemple est celui des journaux en ligne plein de mouchards : les lecteurices s'attendent seulement à lire le journal comme si il était au format papier, et pas à être lu par le journal…
Des projets comme Caliopen travaillent déjà sur la visualisation du niveau de confidentialité de certains canaux de communication, le problème étant qu'il faut déjà que l'utilisateurice ait fait le choix d'utiliser Caliopen pour en profiter.
Un autre souci est celui de la chaîne de distribution des outils qui peut parfois complètement tromper les attentes implicites des utilisateurices (à mettre en lien avec l'analyse des pouvoirs via les dépendances dont on parle à propos de l'évaluation critique des projets dans la partie sur l'enseignement). L'exemple est donné d'Android sur lequel Google peut distribuer via le Play Store des applications modifiées pour un·e utilisateurice spécifique.

Agir :

3- Enfin, en terme de développement il a également été évoqué la nécessité régulière de réaliser les implémentations des techniques développées pour des publications scientifiques mais jamais implémentées au delà du prototype (assez courant sur la recherche autour de Tor notamment). Cf https://research.torproject.org/ et https://tails.boum.org/blueprint/Tails_research/.

Éducation populaire

1- Les discussions sur cette thématique ont porté sur l'amélioration de la compréhension des enjeux du monde numérique par le grand public. Le problème à nos yeux est le système économique qui lie directement les intérêts financiers des groupes qui contrôlent les plateformes et infrastructures centralisées à la collecte massive de données personnelles. Corriger la cause plutôt que les symptômes passe avant tout par une prise de conscience collective. Une prise de conscience et des outils utilisables valent mieux que des outils parfaits au niveau sécurité mais inutilisables. On fait le lien avec les questions soulevées dans les parties précédentes : les attentes des utilisateurices ne sont pas alignées avec le fonctionnement réel des outils. Idéalement, il faut l'aligner, mais de toute façon, il faut aussi informer et faire prendre conscience. Impossible d'utiliser un outil de manière responsable sans comprendre son fonctionnement (nécessité d'un consentement éclairé).

Agir :

2- Les débats ont aussi largement mis en avant le format conférence gesticulée pour l'éducation populaire. Une conférence gesticulée ne s'improvise pas, il est nécessaire de se former : ça ne doit pas être excluant, ça doit avoir un objectif politique menant à l'action collective, ça doit mélanger savoirs froids et chauds (càd issus de l'expérience personnelle), ça doit utiliser des techniques de mise en scène pour faire passer le message efficacement et qu'il soit retenu. Une bonne durée est environ 1h15 (potentiellement suivi d'ateliers).

Agir :

Bilan

Les discussions ont montré que le thème de la sécurité informatique émancipatrice, qui nous a rassemblé, est très large et transverse, ce qui permet d'accueillir des participant·es en dehors du thème strict de la sécurité.
L'enseignement et l'éducation populaire peuvent mener à des initiatives rapides, tant les échanges ont été constructifs sur ces points. Les axes de recherche sont pour l'instant moins bien définis, ce qui n'est en fait pas étonnant pour un démarrage.

Nous tenons à remercier l'ensemble des participant·es, autant celleux qui sont venues le 29 mars que celleux qui ont participé à la préparation de cette journée. Nous remercions également l'Université Paris 8 pour l'accueil et le repas :).

Nous avons maintenant du pain sur la planche. Upsilon pourrait devenir une sorte de laboratoire autonome pluridisciplinaire hors-les-murs ayant pour but le développement de la sécurité informatique émancipatrice.
N'hésitez pas à nous rejoindre !