Des pages web légères et moins gourmandes en ressources, du « low-tech » c’est plus écologique probablement, mais c’est aussi une des conditions pour rendre durables des contenus qui ont une fâcheuse tendance à se volatiliser… Jeff Huang est professeur d’informatique et dans la page que Framalang a traduite pour vous, il fait le pari que son contenu sera encore accessible dans dix ans au moins, tout en proposant 7 recommandations pour créer des pages web pérennes.

Il ne s’agit pas de solutions miracles, mais plutôt d’incitations à l’action et au débat, comme il l’écrit :

Cet article est destiné à provoquer et à susciter une action individuelle, et non à proposer une solution complète pour soigner le Web en déclin

Donc il est clair que les conseils qu’il donne sont peut-être incomplets ou critiquables. Certain⋅e⋅s (comme un de nos traducteurs) vont par exemple sursauter de lire que les polices Google peuvent être utilisées car elles sont « probablement déjà dans le cache ». D’autres vont regretter que le recours à l’archivage ne soit pas assez mis en avant comme le fait cipherbliss dans cet article… bref, n’hésitez pas à ajouter des critiques constructives.

N’hésitez pas non plus à nous dire s’il existe vraiment des contenus web qui méritent selon vous d’être maintenus dix ans ou plus, et lesquels (créations et expressions personnelles, ressources des Communs, etc.), ou bien si vous acceptez avec fatalisme ou satisfaction que les pages web, comme tout le reste, finissent par disparaître…

Les commentaires, comme toujours sur ce blog, sont ouverts et modérés.

Page originale : This Page is Designed to Last, A Manifesto for Preserving Content on the Web
Traduction Framalang : goofy, Côme, mo, wisi_eu, retrodev, tykayn

Un manifeste pour la pérennité des contenus sur le Web

Cette page est conçue pour durer

par Jeff Huang

Pour un professeur, la fin de l’année est l’occasion de faire le ménage et de se préparer pour le semestre à venir. Je me suis retrouvé à effacer de vieux marque-pages, eh oui, des marque-pages : cette fonctionnalité des navigateurs autrefois si appréciée qui paraît avoir perdu la bataille contre la « complétion automatique dans la barre d’adresse ». Mais ce geste nostalgique de nettoyage a fini par me déprimer.

Les uns après les autres, les marque-pages m’ont mené vers des liens morts. Disparus, de superbes écrits de kuroShin sur la culture technologique ainsi qu’une série de puzzles mathématiques et les discussions associées des universitaires que mon père m’avait présentés ; disparus aussi les tutoriels d’ingénierie inverse de Woodman qui datent de mes années d’étude, avec lesquels j’ai découvert le sentiment d’avoir le pouvoir sur les logiciels ; même mes plus récents marque-pages ont disparu, une série d’articles exposant sur Google+ la non-conformité des chargeurs usb-c avec les normes…

Ce n’est pas seulement une question de liens fichus, c’est le problème de la difficulté croissante de maintenir en vie des contenus indépendants sur le Web, conduisant à une dépendance à des plateformes et à des formats de publication qui s’empilent de façon chronologique (blogs, fils, tweets…)

Bien sûr j’ai moi aussi contribué au problème. Un article que j’ai publié il y a sept ans comprend un résumé initial dans lequel un lien vers une démo a été remplacé par une page de spam avec une image de citrouille. C’est en partie à cause de la flemme de devoir renouveler et de maintenir une application web fonctionnelle année après année.
J’ai recommandé à mes étudiants de publier des sites web avec Heroku et des portfolios avec Wix. Mais toute plateforme au contenu irremplaçable meurt un jour. Geocities, LiveJournal, what.cd, maintenant Yahoo Groups. Un jour, Medium, Twitter et même les services d’hébergement comme GitHub Pages seront pillés puis jetés lorsqu’ils ne pourront plus se développer ou n’auront pas trouvé de modèle économique viable.

C’est un problème de nature plurielle.
Tout d’abord, maintenir du contenu demande du travail. Le contenu peut avoir besoin d’être mis à jour pour rester pertinent et devra éventuellement être ré-hébergé. Une grande partie du contenu – ce qui était autrefois la grande majorité du contenu – a été mise en place par des individus. Mais les particuliers (peut-être vous ?) finissent par se désintéresser, si bien qu’un jour, vous ne voudrez peut-être plus vous occuper de la migration d’un site web vers un nouvel hébergeur.

Deuxièmement, le nombre croissant de bibliothèques et de frameworks rend le Web plus sophistiqué, mais également plus complexe. Il y a d’abord eu jquery, puis bootstrap, npm, angular, grunt, webpack, et bien d’autres. Si vous êtes un développeur web qui se tient au courant des dernières nouveautés, alors ce n’est pas un problème.

Mais dans le cas contraire, vous êtes peut-être programmeur de systèmes embarqués, directeur technique d’une start-up, un développeur Java d’entreprise ou un doctorant de chimie. Vous avez sans doute trouvé le moyen de mettre en place un serveur web et sa chaîne d’outils, mais continuerez-vous à le faire d’une année à l’autre, d’une décennie à l’autre ? Probablement pas ! Et lorsque, l’année suivante, vous rencontrerez un problème de dépendance à un paquet ou que vous découvrirez comment régénérer vos fichiers html, vous pourriez abandonner et zipper les fichiers pour vous en occuper « plus tard ».

Même les piles technologiques simples comme les générateurs de sites statiques (par exemple, Jekyll) nécessitent du travail et cesseront de fonctionner à un moment donné. Vous tombez dans l’enfer des dépendances aux paquets NPM, et vous oubliez la commande pour réaliser un déploiement. Et avoir un site web avec plusieurs pages html est complexe ; comment savoir comment chaque page est liée aux autres : « index.html.old », une copie de « about.html » « index.html (1) », « nav.html » ?

Troisièmement, et cela a déjà été rapporté par d’autres (et même réfuté), la disparition du Web « public » au profit du mobile et des applications web, des jardins clos (telles que les pages Facebook), du chargement en temps réel des WebSockets et de l’AMP diminue la proportion même de la toile dans la toile mondiale, qui ressemble désormais davantage à une toile continentale qu’à une « toile mondiale » (World Wide Web).

Alors, face à ces problèmes, que pouvons-nous faire ? Ce n’est pas un problème si simple qu’il puisse être résolu dans cet article. La Wayback Machine et archive.org permettent de conserver certains contenus plus longtemps. Et il arrive qu’un individu altruiste relocalise le contenu ailleurs.

Mais la solution se trouve sur plusieurs fronts. Comment créer un contenu web qui puisse durer et être maintenu pendant au moins dix ans ? Étudiant l’interaction homme-machine, je pense naturellement aux parties prenantes que nous n’aidons pas : actuellement, la mise en ligne de contenu web est optimisée soit pour le développeur web professionnel (qui utilise les derniers frameworks et flux de travail), soit pour l’utilisateur non averti (qui utilise une plateforme).

Mais je pense que nous devrions considérer à la fois 1) le « responsable » occasionnel du contenu web, quelqu’un qui ne reste pas constamment à jour avec les dernières technologies web, ce qui signifie que le site web doit avoir de faibles besoins de maintenance ; 2) et les robots d’indexation qui préservent le contenu et les archiveurs personnels, « archiveur » implique que le site web doit être facile à sauvegarder et à interpréter.

Ma proposition consiste donc en sept lignes directrices non conventionnelles sur la manière dont nous traitons les sites web conçus pour être informatifs, pour les rendre faciles à entretenir et à préserver. Ma suggestion est que le responsable de la maintenance s’efforce de maintenir le site pendant au moins 10 ans, voire 20 ou 30 ans. Il ne s’agit pas nécessairement de points de vue controversés, mais d’aspirations qui ne sont pas courantes − un manifeste pour un site web durable.

1. Revenez à du HTML/CSS « Vanilla » (NdT : le plus simple, sans JavaScript) – Je pense que nous avons atteint le point où le html/css est plus puissant et plus agréable à utiliser que jamais. Au lieu de commencer avec un modèle obèse bourré de fichiers « .js », il est maintenant possible de simplement écrire en HTML, à partir de zéro. Les CSS « Flexbox » et « Grid », le canvas, les Selectors, le box-shadow, l’élément vidéo, le filtre, etc. éliminent une grande partie du besoin de bibliothèques JavaScript. Nous pouvons éviter le jQuery et le Bootstrap, car ils deviennent de toute façon moins pertinents. Plus il y a de bibliothèques intégrées au site web, plus celui-ci devient fragile. Évitez les polyfills et les préfixes CSS, et n’utilisez que les attributs CSS qui fonctionnent sur tous les navigateurs. Et validez fréquemment votre HTML ; cela pourrait vous éviter un mal de tête à l’avenir lorsque vous rencontrez un bogue.

2. Ne réduisez pas ce HTML. Réduire (compresser) votre HTML et les CSS/JS associés vous semblera peut-être une précieuse économie de bande passante, et toutes les grandes entreprises le font. Pourquoi ne pas le faire ? Eh bien, vous n’économisez pas beaucoup parce que vos pages web doivent être compressées avant d’être envoyées sur le réseau, donc la réduction préventive de votre contenu compte probablement très peu dans l’économie de bande passante, voire pas du tout. Mais même si cela permettait d’économiser quelques octets (ce n’est après tout que du texte), vous devez maintenant avoir un processus de construction et l’ajouter à votre flux de travail, de sorte que la mise à jour d’un site web devient plus complexe. En cas de bogue ou d’incompatibilité future dans le HTML, le format minimisé est plus difficile à déboguer. De plus, il est peu convivial pour vos utilisateurs ; de nombreuses personnes commencent à utiliser le HTML en cliquant sur « Voir la source »¹, et la réduction de votre HTML empêche cet idéal d’apprentissage en regardant ce qui est fait. Réduire le HTML ne préserve pas sa qualité pédagogique, et ce qui est archivé n’est que le tas de code résultant.

3. Préférez maintenir une page plutôt que plusieurs. Plusieurs pages sont difficiles à maintenir. Vous pouvez oublier quelle page renvoient à quoi, et cela nécessite également la mise en place de modèles pour limiter les redondances. Combien de pages une personne peut-elle réellement maintenir ? Avoir un seul fichier, probablement juste un « index.html », est simple et facile à retenir. Profitez de ce défilement vertical infini. Vous n’aurez jamais besoin de fouiller dans vos fichiers ou de faire du grep pour voir où se trouve un certain contenu. Et comment gérer les multiples versions de ce fichier ? Devriez-vous utiliser git ? Les placer dans un dossier « old/ » ? J’aime l’approche simple qui consiste à nommer les anciens fichiers avec la date à laquelle ils ont été retirés, comme index.20191213.html. L’utilisation du format ISO de la date permet de trier facilement, et il n’y a pas de confusion entre les formats de date américain et européen. Si j’ai plusieurs versions en une journée, j’utiliserais un style similaire à celui qui est habituel dans les fichiers journaux, index.20191213.1.html. Un effet secondaire agréable est que vous pouvez alors accéder à une version plus ancienne du fichier si vous vous souvenez de la date, sans vous connecter à la plateforme d’hébergement web.

4. Mettez fin à toutes les formes de liaison automatique (hotlinking). Ce mot d’avertissement semble avoir disparu du vocabulaire internet, mais c’est l’une des raisons pour lesquelles j’ai vu un site web parfaitement bon s’effondrer sans raison. Cessez d’inclure directement des images provenant d’autres sites web, cessez d’« emprunter » des feuilles de style en vous contentant de créer des liens vers celles-ci, et surtout cessez de créer des liens vers des fichiers JavaScript, même ceux qui sont hébergés par les développeurs d’origine. Les liaisons automatiques sont généralement considérées comme impolies car vos visiteurs utilisent la bande passante de quelqu’un d’autre, elles ralentissent l’expérience utilisateur, permettent un autre site web de pister vos utilisateurs et, pire encore, si l’endroit auquel vous vous connectez modifie la structure de ses dossiers ou se déconnecte tout simplement, la panne se répercute également sur votre site web. Google Analytics est inutile ; stockez vos propres journaux de serveur et configurez GoAccess ou découpez-les comme vous le souhaitez, ce qui vous donnera des statistiques plus détaillées. Ne donnez pas vos journaux à Google gratuitement.

5. N’utilisez que les 13 polices de caractères adaptées au Web – nous nous concentrons d’abord sur le contenu, comprenez : les caractères décoratifs et inhabituels sont complètement inutiles. Maintenez un petit éventail et les 13 polices de caractères adaptées au Web. Peut-être avez-vous vraiment besoin d’une police de caractères néo-grotesque qui ne soit pas Arial/Helvetica, ou d’une police de caractères géométriques. Dans ce cas, utilisez le minimum nécessaire, comme Roboto (pour le néo-grotesque) et Open Sans (pour le géométrique) ; ce sont les deux polices les plus populaires de Google Fonts, il est donc probable qu’elles soient déjà en cache sur l’ordinateur de vos utilisateurs. Outre ces polices, votre objectif doit être de fournir le contenu à l’utilisateur de manière efficace et de faire en sorte que le choix de la police soit invisible, plutôt que de flatter votre ego en matière de conception. Même si vous utilisez les polices Google, elles n’ont pas besoin d’être liées automatiquement (hotlink). Téléchargez le sous-ensemble dont vous avez besoin et fournissez-les localement à partir de vos propres dossiers.

6. Compressez vos images de manière obsessionnelle. Ce sera plus rapide pour vos utilisateurs, moins gourmand en espace d’archivage et plus facile à maintenir lorsque vous n’avez pas à sauvegarder un énorme dossier. Vos images peuvent avoir la même haute qualité, mais être plus petites. Minimisez vos SVG, compressez sans perte vos PNG, générez des JPEG pour qu’ils correspondent exactement à la largeur de l’image. Cela vaut la peine de passer du temps à trouver la meilleure façon de compresser et de réduire la taille de vos images sans perte de qualité. Et une fois que WebP sera pris en charge par Safari, passez à ce format. Réduisez impitoyablement la taille totale de votre site web et gardez-la aussi petite que possible. Chaque Mo peut coûter cher à quelqu’un ; en effet mon opérateur de téléphonie mobile (Google Fi) facture un centime (de dollar) par Mo de données. Ainsi, un site web de 25 Mo, assez courant de nos jours, coûte lui-même 25 centimes, soit à peu près autant qu’un journal quand j’étais enfant.

7. Éliminez le risque de rupture d’URL. Il existe des services de contrôle qui vous indiqueront quand votre URL est en panne, ce qui vous évitera de réaliser un jour que votre page d’accueil ne charge plus depuis un mois et que les moteurs de recherche l’ont désindexée. Car 10 ans, c’est plus long que ce que la plupart des disques durs ou des systèmes d’exploitation sont censés durer. Mais pour éliminer le risque de panne totale d’une URL, mettez en place un second service de contrôle. En effet, si le premier s’arrête pour une raison quelconque (passage à un modèle payant, fermeture, oubli de renouvellement, etc.), vous recevrez toujours une notification lorsque votre URL est hors service, puis vous réaliserez que l’autre service de surveillance est hors service parce que vous n’avez pas reçu la deuxième notification. N’oubliez pas que nous essayons de maintenir un service pendant plus de 10 ans (idéalement bien plus longtemps, même 30 ans), donc beaucoup de services vont s’arrêter pendant cette période, donc deux services de surveillance, c’est plus sûr…
Après avoir fait cela, placez un texte dans le pied de page, « La page a été conçue pour durer », avec un lien vers cette page expliquant ce que cela signifie. Ces quelques mots attestent que le responsable fera de son mieux pour suivre les idées de ce manifeste.

Avant que vous ne protestiez, il est évident que cela n’est pas adapté pour les applications web. Si vous créez une application, alors créez votre application web ou mobile avec le flux de travail dont vous avez besoin. Je ne connais pas une seule application web qui ait fonctionné de manière identique pendant 10 ans (sauf le tutoriel python de Philip Guo, en raison de sa stratégie minimaliste de maintenance), donc cela semble être une cause perdue de toute façon. Ce n’est pas non plus adapté pour les sites web maintenus par une organisation comme Wikipédia ou Twitter. Vous faites votre truc, et le salaire d’une équipe informatique est probablement suffisant pour maintenir quelque chose en vie pendant un certain temps.
En fait, il n’est même pas si important de suivre strictement les 7 « règles », car ce sont plus des incitations que des règles impératives.

Mais admettons qu’une petite partie du Web commence à concevoir des sites web dont le contenu est censé durer. Que se passe-t-il alors ? Eh bien, les gens préféreront peut-être créer des liens vers ces sites car leur accès est garanti à l’avenir. Plus généralement, les gens peuvent être plus soucieux de rendre leurs pages plus permanentes. Et les utilisateurs et utilisatrices ainsi que les robots qui archivent économisent de la bande passante lorsqu’ils visitent et stockent ces pages.

Les effets sont à long terme, mais les réalisations sont progressives et peuvent être mises en œuvre par les propriétaires de sites web sans dépendre de quiconque ni attendre un effet de réseau. Vous pouvez le faire dès maintenant pour votre site web, et ce serait déjà un résultat positif. C’est comme utiliser un sac de courses recyclé au lieu d’un sac en plastique, c’est une petite action individuelle.

Cet article est destiné à provoquer et à susciter une action individuelle, et non à proposer une solution complète au déclin de la Toile. Il s’agit d’un petit pas simple pour un système sociotechnique complexe. J’aimerais donc voir cela se produire. J’ai l’intention de maintenir cette page pendant au moins 10 ans.

Merci à mes étudiants en doctorat Shaun Wallace, Nediyana Daskalova, Talie Massachi, Alexandra Papoutsaki, mes collègues James Tompkin, Stephen Bach, mon assistante d’enseignement Kathleen Chai et mon assistant de recherche Yusuf Karim pour leurs commentaires sur les versions précédentes.

Voir les discussions sur Hacker News et reddit/r/programming

Cette page est conçue pour durer.

Vous voulez sauver des chatons ? Nous aussi. Tout le monde aime les chatons. Cet article ne vous dira pas comment faire. Mais il vous apprendra (ou vous permettra d’apprendre à votre neveu) comment lire une adresse web. Ce qui est, n’en doutons pas, indispensable lorsque l’on veut sauver des chatons.

Nous avons donc décidé de piller sauvagement le blog Grise-Bouille de Gee, dessinateur libriste, chanteur yukuléliste, et framasoftien chevronné… parce qu’il a dessiné là un article d’utilité publique qui mérite d’être partagé (rappel : si vous ne le faites pas pour vous, faites-le pour les chatons !)

URL über-lue

Aujourd’hui, parlons de l’une de ces nombreuses choses auxquelles on ne prête pas d’attention parce qu’elles semblent trop compliquées… alors qu’elles peuvent nous aider énormément : l’URL.

Je précise que cet article est une introduction pour novice et qu’il ne vise pas l’exhaustivité (on ne parlera pas de protocoles FTP, de ports ou de résolution DNS). En plus, il est déjà assez long comme ça !

Bonne lecture 😉

Lien vers l’article original.

Après un mois de janvier si mouvementé qu’il nous a donné du travail jusqu’en février, nous avons pu reprendre le cap fixé par notre (modeste) Plan de Libération du Monde : Dégoogliser Internet.

À notre sens, il faut reconquérir les Internets service après service, afin de proposer au plus grand nombre des applications Libres, Ethiques, Décentralisées et Solidaires. C’est ce que nous avons fait vendredi en ouvrant notre GitLab alors que Google code ferme ses portes. C’est ce que nous poursuivons aujourd’hui en vous proposant trois services simples, efficaces, mais qui (nous l’espérons) faciliteront la vie d’un grand nombre d’internautes dans le plus grand respect de leurs libertés.

Huit.re, la perle des raccourcisseurs d’URL

Enfin un service qui ne s’appelle pas frama-machin !! (bon, OK, on y accède aussi sur frama.link :p ). Huit.re vous permettra de raccourcir vos URLs en huit petits caractères… et sera donc le mollusque qui cache la forêt de caractères qui forme souvent une troooop loooooongue adreeeeessse weeeeb.

À l’instar de bit.ly ou de goo.gl, vous pourrez l’utiliser pour gazouiller sans craindre de perdre trop des précieux 140 caractères auxquels vous avez droit. Vous pourrez enfin transmettre une adresse web par sms ou téléphone sans y passer trois heures…

Mais à la différence de ces géants du web centralisé, huit.re est basé sur LSTU (Let’s Shorten That URL), un logiciel libre que les barbu-e-s de tout poil peuvent s’empresser d’étudier, améliorer, bidouiller… Donc non seulement on sait ce qui se trouve derrière, mais en plus il est placé sur les serveurs de Framasoft. Et l’on vous rappelle qu’on s’est engagés sur une Charte respectueuse de vos libertés et vos données, ainsi que sur des conditions générales d’utilisations claires et précises.

Bref : on a enfin de quoi faire taire Pouhiou quand il clame à qui veut l’entendre que : « Les huîtres, c’est le mal » ! [1]

Framapic, le lutin qui héberge vos images les yeux fermés

Basé sur le logiciel libre LUTIm (Let’s Upload This Image), un projet perso du bouillant framasoftien Luc Didry, Framapic est un moyen simple et sécurisé de partager et publier vos images en ligne. Attention, il ne s’agit pas d’un gestionnaire de collection de photos à la Picasa… Simplement d’un hébergement d’images comme Imgur ou hostingpic, qui supporte tous les formats (même le GIF !)

Sauf qu’en plus d’être un logiciel libre, LUTIm est un logiciel qui offre bien des avantages :

• Possibilité d’autodestruction de l’image après la première vue (avec le petit lien « corbeille ») ;
• Possibilité d’effacer l’image de nos serveurs au bout d’un jour, une semaine, un mois, un an… (au choix) ;
• Intégration facilitée (et jolie) à Twitter, Facebook, etc. pour vos images (et même vos GIFs !) ;
• Téléchargement facilité (par une URL spécifique) ;
• Code ouvert et disponible sur notre GitLab pour tous ceux qui veulent y contribuer voire se l’installer sur leur serveur. ;
• Chiffrement des images sur nos serveurs.

Et le chiffrement, ça change tout. Cela signifie que nous n’avons pas la possibilité de voir vos images (pas sans la clé que vous détenez dans votre URL, et pour la récupérer il faudrait qu’on active les journaux (logs) du reverse proxy qui est devant Framapic, et ça c’est pas dans notre charte…)

Cela signifie que vos images vous appartiennent, et qu’on n’a pas à mettre nos nez dedans. Attention ! Notez bien les URL des images envoyées sur Framapic : sans elles et la clé de chiffrement qui y est, vous ne pourrez plus y accéder.

Framabin, pour partager vos secrets en mode mission impossible

Nous avons pimpé le très célèbre (et très libre) Zérobin de SebSauvage afin de le rendre assez beau pour que votre grand-père vous partage en toute sérénité le secret si bien gardé de son coin à champignons.

Framabin est un rêve de gosse nourri aux Missions Impossibles, Alias et autres James Bond : partagez un message qui s’autodétruira dès le premier accès. Ou au bout de 5, 10 minutes. Ou d’un jour, une semaine, un mois, un an…

Bien entendu, le message est chiffré, ce qui fait que nous ne pouvons pas (à aucun moment) consulter le code de la carte bleue de votre maman quand elle le partagera avec vous sur Framabin pour que vous lui achetiez un superbe T-Shirt sur EnVenteLibre…

Et le top, c’est que vous pouvez carrément utiliser Framabin comme un lieu de conversations secrètes, où chaque personne possédant le lien peut commenter ce qu’a écrit l’autre. Cela sert bien entendu pour ce bout de code qui va révolutionner les Interwebs (même qu’il y a de la coloration syntaxique), mais aussi pour bien comprendre et discuter le secret du tajine aux olives que votre cousin garde jalousement.

Libérez vous ! (même de Framasoft :p )

Tous ces services sont là pour vous (et aussi pour les Dupuis-Morizeau notre fameuse famille-témoin résidant en Normandie). Mais ils sont aussi et surtout là pour démontrer que lorsqu’on veut faire un Web et des applications respectueuses de… de nous, en fait : ben c’est possible. Le chiffrement, le logiciel libre et la confiance en l’hébergeur du service sont des piliers indispensables à ce respect.

Mais plus que tout, nous ne voulons pas devenir le « Google du libre ». C’est bien pour cela que vous retrouverez, sur notre blog Framacloud, tous les tutoriels nécessaires pour « cultiver votre jardin », c’est-à-dire pour installer vous-même ces applications sur votre propre serveur (ou celui de votre famille, votre asso, votre collectivité, votre entreprise…)

• Installer LSTU
• Installer Lutim
• Installer Zérobin

C’est en se rendant indépendants, en s’apportant nos expériences les uns aux autres et en disséminant du Libre un peu partout que nous arriverons ensemble à vraiment Dégoogliser Internet.

À vous de partager, désormais.

[1] cf. #Smartarded, p. 172.

Depuis un an ou deux une conscience floue de l’ubiquité du pistage est perceptible dans les conversations sous la forme de brèves remarques fatalistes :

— De toutes façons on est espionnés, alors…
— Ils peuvent savoir tout ce qu’on fait sur Internet, hein…

et chez les Dupuis-Morizeau :

— J’ai réservé la location moins cher avec le PC du boulot pour exactement la même chose… Faut croire que depuis qu’on fait des achats en ligne ils se figurent qu’on pourrait payer plus…

Vous qui savez, ne vous moquez pas trop vite : mieux vaut cette perception diffuse qu’une certitude naïve d’être protégé (« ah tu vois le petit s derrière http ça veut dire que c’est sécurisé ce site » hum) ou pire une ignorance dangereuse.
Certes le chemin est long encore avant de pouvoir susciter une plus large prise de conscience puis une évolution des comportements et des usages dans notre vie numérique. C’est à quoi Framasoft s’efforce de mener par étapes avec la campagne longue durée Dégooglisons Internet. Mais bien d’autres initiatives surgissent semaine après semaine, et nous sommes ravis de leur donner un écho.
Tel est le cas aujourd’hui avec le projet amiunique (non, ce n’est pas un site de rencontre pour trouver un seul ami pour la vie : Am I unique? signifie : « Suis-je unique ? »).
Nous sommes pistés, traqués, espionnés, piégés, profilés… d’accord, tout le monde en a désormais « entendu parler ». Mais que sait-on de nous au juste lorsqu’on va jeter coup d’œil sur un site web ?
Il existe déjà des moyens d’en avoir une idée, par exemple dans Firefox, de nombreux outils de développement proposent des fonctionnalités pour voir ce qui se passe sous les jupes de la connexion. Mais le site amiunique.org en facilite l’accès et explique de quoi il retourne.
On découvre ainsi que cette quantité importante d’informations permet le plus souvent de faire de vous un utilisateur « unique »
— Ah j’en vois qui se rengorgent de n’être pas comme tous les autres et qui sont tout fiers de se distinguer du supposé troupeau des internautes…^[1]
Mais ne vous réjouissez pas trop vite, écoutez un peu ce que nous dit Benoît Baudry et voyez comment tout au contraire se fondre dans une masse d’empreintes numériques similaires pourrait être un moyen de ne plus être unique, donc de risquer moins d’être pisté !

— Bonjour, pouvez-vous vous présenter brièvement ?
Je suis chercheur depuis 2004 dans le domaine du génie logiciel. J’ai beaucoup travaillé sur des outils et algorithmes pour améliorer les activités de test logiciel dans le domaine des systèmes embarqués. Cette activité s’est ensuite élargie pour traiter de problèmes d’analyse de programme. Depuis février 2013 je coordonne un projet de recherche européen (DIVERSIFY) sur le thème de la diversification du logiciel pour faire des applications web plus robustes.
Dans ce contexte, nous avons démarré une activité sur le browser fingerprinting, c’est-à-dire les empreintes, les traces numériques que laissent nos plateformes quand nous nous connectons avec nos navigateurs.
La petite équipe qui se consacre à amiunique.org et aux technologies anti-fingerprint comprend un doctorant et bénéficie du conseil scientifique et technique de deux chercheurs en sécurité et génie logiciel.

Il n’est pas si fréquent qu’un labo de recherche universitaire entame un projet qui peut toucher un assez vaste public et potentiellement l’ensemble des utilisateurs du Web. Alors pourquoi s’intéresser au fingerprinting ?
Tous nos travaux de recherche sont inspirés par des problèmes réels rencontrés lors de la construction de systèmes logiciels. La nouveauté dans ce cas tient sans doute au fait que le problème ne touche pas seulement les développeurs de logiciels, mais que tout internaute peut se sentir concerné.
Dans le cadre de DIVERSIFY, nous étudions la diversité logicielle et la manière dont elle peut être exploitée, voire amplifiée par des procédures automatiques. L’idée de ce projet c’est que l’augmentation de la diversité logicielle augmente également la résilience et la sécurité des applis webs.
Par ailleurs, nous avons découvert que dans le cas du browser fingerprinting la très grande diversité et la richesse de l’écosystème web sont devenues un problème pour la vie privée : cet écosystème très très riche permet à chacun de disposer d’une plateforme qui correspond parfaitement à ses envies et à son confort, mais c’est ce même phénomène qui rend chaque plateforme unique et donc traçable. La question qui nous a alors intéressés est la suivante :

Peut-on exploiter la diversité qui est à l’origine du problème de fingerprint pour lutter contre le traçage, en modifiant automatiquement et régulièrement la plateforme logicielle d’un internaute ?

La première étape pour répondre à cette question consiste à étudier de près la diversité des plateformes qu’on peut trouver sur le web, ce qui nous a amené à développer le site amiunique.org

Bon alors de quoi s’agit-il au juste ? Pourquoi devrais-je me demander si je suis unique ? C’est inquiétant d’être unique sur le Net ?

Une première remarque à propos de l’unicité : quand le site affiche « Êtes-vous unique ? Oui ! », ce qu’il faut comprendre c’est que la plateforme logicielle (navigateur, OS, polices, plugins, etc.) que vous avez utilisée pour aller sur le site est unique parmi toutes celles observées jusqu’à présent. 

Un clic pour essayer…

et voici le résultat :

Quand vous visitez un site web, celui-ci peut facilement récolter un grand nombre d’informations à propos de votre plateforme. Certaines de ces informations sont systématiquement fournies au site web par le navigateur (user agent et en-têtes http), et pour le reste le serveur peut interroger les interfaces Flash, JavaScript et toute autre interface offerte par le navigateur et ses plugins.

Une longue liste de données que l’on peut récolter… (cliquer pour agrandir)

Le problème d’avoir une plateforme unique c’est que les sites marchands peuvent personnaliser leur contenu en fonction de la plateforme (pratiques tarifaires en fonction des clients ou publicités ciblées). Par exemple, les sites peuvent varier les prix en fonction de la localisation de l’internaute, déduite approximativement par l’adresse IP (voyez cet exemple), ou en fonction du système d’exploitation (un autre exemple). Une étude a montré que le site de voyages Orbitz propose des prix plus élevés aux utilisateurs de Mac OS (exemple d’Orbitz).

Mais ce que vous proposez de faire, ça commence bien comme du pistage non ? Vous voulez qu’on vous donne toutes les informations sur notre navigateur pour votre recherche, vous êtes sympathique avec votre bonne tête de nerd barbu mais comment puis-je avoir confiance ? Et puis vous allez faire quoi de cette bientôt énorme base de données récoltées, mmh ? 

La politique de confidentialité d’amiunique.org établit très clairement ce qui advient des données récoltées : elles sont stockées sur une machine sécurisée et nous les utilisons à des fins d’analyse statistique. Par ailleurs, nous ne récoltons absolument aucune information qui nous permette de relier une empreinte à une personne, les donnée sont donc anonymes par construction. Les analyses statistiques d’empreintes réelles sont essentielles pour établir des procédures qui modifient automatiquement la plateforme d’un internaute de manière réaliste. Dans cet objectif, 2 défis à relever : réussir à modifier la plateforme de manière transparente, mais suffisamment pour changer l’empreinte ; modifier la plateforme tout en la faisant ressembler à une vraie plateforme pour éviter d’être repéré comme un usager qui essaie de se cacher.

Quelle est selon vous la masse critique d’empreintes collectées qui vous permettra de passer à la phase suivante du projet ?

Il est important pour nous de rassembler un maximum d’empreintes pour que le verdict que nous rendons aux visiteurs (oui / non vous êtes unique) soit vraiment significatif. À l’échelle du Web, être unique parmi quelques dizaines de milliers d’internautes, ce n’est pas forcément très impressionnant, alors qu’être unique parmi quelques millions c’est déjà plus surprenant. Pour nos travaux futurs sur le brouillage c’est surtout important de récupérer une très grande diversité d’empreintes (diversité géographique, diversité de navigateur, polices, etc.). Un échantillon étendu et diversifié nous permettra d’identifier quelles sont les caractéristiques les plus discriminantes, qui devront être la cible principale pour le brouillage.

et euh… je ne risque rien si je “triche” en envoyant finalement des données trompeuses ? C’est bien légal ça ?

Il n’y a rien d’illégal à modifier/changer/envoyer des fausses informations. Cependant, deux problèmes peuvent se poser avec les extensions de navigateurs qui renvoient de fausses informations dans le user agent (par exemple User agent switcher).
Le premier vient du fait que les informations que vous envoyez à un serveur sont censées être utilisées pour vous renvoyer une page web qui est parfaitement adaptée à votre navigateur et à sa configuration. Si vous mentez, la page web peut présenter de nombreux défauts et certaines fonctionnalités peuvent ne pas être opérationnelles.
Le second problème vient du fait que si vous mentez, il se peut que votre empreinte soit incohérente et cela vous rend tout de suite identifiable. Par exemple, sur une des empreintes récoltées sur amiunique, le navigateur annonce dans son User Agent qu’il tourne sous Windows alors que le moteur de rendu JavaScript nous indique que la machine en question est un Mac. Cette configuration qui n’est pas censée exister dans la réalité vous rend identifiable car vous serez une des seules personnes au monde à avoir cette configuration incohérente.
Ce n’est donc pas illégal de mentir, mais ça peut engendrer des problèmes à la fois liés à la navigation et au traçage par empreinte.

Par ailleurs, il n’y a rien d’illégal à modifier charger / supprimer des nouvelles polices à chaque lancement de votre navigateur ou à utiliser régulièrement une version différente d’un navigateur.
Nous pensons qu’un avantage de *modifier la plateforme* (plutôt que de renvoyer de fausses informations) c’est qu’on ne prendra pas le risque d’être identifié comme un menteur ou comme une plateforme qui tente d’envoyer des données trompeuses.

C’est astucieux tout ça mais vous ne craignez pas que ceux qui nous pistent trouvent une parade à votre dispositif ?

Certainement et c’est toute la difficulté de tout dispositif pour la vie privée : dès qu’un nouveau dispositif apparaît, il fixe également les nouvelles barrières à franchir pour ceux qui veulent nous pister. Ce que nous espérons surtout c’est que ce genre de mécanisme rende le pistage plus difficile et plus coûteux.

Est-ce qu’on peut espérer que cette expérience “de laboratoire” aura une utilité pour nous les internautes concernés par le pistage de nos empreintes ? Pour votre équipe c’est un intéressant objet de recherche, mais sous quelle forme finale pourrait aboutir votre projet pour la famille Dupuis-Morizeau^[2]  ?

Nous l’espérons vraiment. Pour l’instant, il faudrait idéalement que la famille Dupuis-Morizeau ait des PC sous Linux, et dans ce cas nous visons une solution qui puisse être téléchargée et utilisée à la place du navigateur standard. En gros, ça devrait être un conteneur qui isole le navigateur et tous les éléments de plateforme, qui est lancé à chaque fois que quelqu’un veut naviguer sur Internet. Au lancement de ce conteneur, un navigateur, des polices, des plugins, voire quelques éléments de configurations système sont sélectionné aléatoirement, assemblés et démarrés. L’internaute peut alors naviguer avec une plateforme différente de celle utilisée la dernière fois.

Distribuer l’URL pour augmenter le nombre d’empreintes c’est déjà une énorme contribution. Toute idée de forums internationaux pour augmenter la diversité des empreintes est aussi tout à fait bienvenue. Enfin, le code du site est open source et nous serions ravis d’avoir des contributions à ce projet sous forme de traduction de pages, revue de code (architecture du site, sécurité, etc.) ou toute idée pour mieux valoriser les données auprès des visiteurs.