Assainissement et réappropriation numérique

Il y a bientôt quatre ans, je postais à propos de mes débuts dans l'auto-hébergement. Depuis ce jour, l'article en question est accessible sur mon blog, hébergé parmi de nombreux autres sites sur un Raspberry Pi. Le texte n'a pas été modifié – hormis une légère modification après la suspension du service SSL For Free – mais bien des choses autour ont changé. Je reviens ici sur les six derniers mois de transformation de mon environnement numérique.

Avertissement : cet article est le simple récit de mon expérience, dont l'objectif est principalement de marquer un point d'étape qui me servira de référence pour la suite. Ce n'est en aucun cas un manuel ou un guide pour se lancer dans l'auto-hébergement ; à la rigueur, vous pourriez être inspiré comme je l'ai été par le contenu de précédents auteurs.

Audit des comptes

Je commence chronologiquement par une remarque : que se passe-t-il si je perds mon téléphone ? Plusieurs services importants nécessitent une double authentification, et je ne sais ni exactement lesquels, ni que faire pour en récupérer l'accès en cas de perte. Aussi, c'est un peu la pagaille dans mes adresses mails, qui existent depuis longtemps et sont référencées dans de nombreuses bases de pourriels. Je décide alors de mener un « grand audit des comptes », où l'objectif sera de mettre tout ceci à plat.

Ma démarche est la suivante : lister tous les comptes possédés, puis, pour chacun, lister les méthodes d'authentification, les options de récupération et les données personnelles liées, privées ou publiques. Pour ne pas en oublier, j'ai principalement utilisé les entrées de mon gestionnaire de mot de passes. À chaque fois, j'essaye de m'authentifier – si le service existe toujours – avant d'inspecter les informations personnelles ainsi que les paramètres de sécurité et de confidentialité, et enfin reporter ceci dans un tableur. Concrètement, je note à chaque fois :

• les adresses mails et numéros de téléphone renseignés,
• la méthode de double authentification en place,
• les services ou appareils physiques dépendant du compte,
• les données personnelles enregistrées.

Ce recensement est long. Au total, mon tableur compte environ 200 lignes. Heureusement, de temps en temps, on tombe sur des pépites oubliées, qui redonnent un peu de motivation. Car il en faudra pour la seconde étape du plan : la mise à exécution des mesures de sécurité et de confidentialité.

Premièrement, supprimer tous les comptes anciens ou inutilisés. Cela est déjà un défi en soi, car certains sites ne proposent toujours pas de procédures simples pour supprimer un compte. Parfois une simple fouille dans les paramètres suffit, mais souvent la seule procédure disponible est de contacter le service client via une adresse mail également difficile à obtenir. Malheureusement, ces efforts ne payent pas toujours – au doigt mouillé, environ 50% des sites concernés ont accédé à mes demandes.

Deuxièmement, changer les adresses mails. Jusqu'alors, je disposais d'une dizaine d'adresses – dont certaines datent de plus de dix ans et se sont retrouvées dans plusieurs brèches notables – et en utilisais une ou une autre sans raison particulière. Pour clarifier cela, j'ai donc créé deux nouvelles adresses, l'une nominative et l'autre sous pseudonyme, et ai changé l'adresse principale de chaque compte recensé :

• l'adresse nominative pour les services administratifs,
• l'adresse sous pseudonyme pour les autres services, notamment commerciaux,
• mon adresse mail publique est réservée aux échanges par mail.

Je n'utilise ainsi plus que trois adresses, aux finalités précises. À l'aide d'un petit script Python, je vérifie dorénavant régulièrement leur présence dans des fuites de données depuis HaveIBeenPwned. Limiter la diffusion de l'adresse administrative permet de limiter les tentatives d'hameçonnage, notamment via une clarification du contexte : un mail administratif arrivant sur l'adresse commerciale ne saurait qu'être faux. Enfin, pour la plupart des services nécessitant une inscription même gratuite, je continue d'utiliser des services de mails temporaires pour éviter de partager des informations réelles.

Dernière mesure, renforcer la sécurité et la confidentialité des données personnelles. Tout d'abord, j'ai essayé de supprimer au maximum les informations non nécessaires – encore une fois, les sites se montrent rarement coopératifs. Puis, si ce n'était pas déjà le cas, j'ai activé la double authentification pour tous les sites disposant ou donnant accès à des données personnelles importantes, en vérifiant la procédure de récupération. Il s'agit souvent de codes de récupération à conserver, et parfois les sites ne proposent pas de les récupérer dès l'activation de la double authentification. Enfin, j'ai essayé de rapatrier au maximum mes données localement, en téléchargeant puis supprimant ce que je pouvais, et synchronisant le reste. Cela sera détaillé dans la section suivante.

J'ai également profité de cette mise à plat pour modifier les mots de passes trop anciens et repartir sur des bases saines. Par mesure de sécurité, les mots de passes les plus importants ne sont pas dans mon gestionnaire de mots de passe mais dans ma propre mémoire ; pour les y ancrer, j'ai implémenté un petit jeu local de mémorisation auquel je me teste régulièrement – à noter que les mots de passes n'y sont pas directement stockés mais vérifié via un mécanisme de preuve à divulgation nulle de connaissance.

À la fin de cette aventure, s'il y a une leçon à tirer, c'est qu'il faut toujours essayer de ne partager que le minimum d'informations, car l'exercice pratique du droit à la correction et l'effacement des données reste difficile à mettre en œuvre.

Archivage et sauvegarde

Alors, le lien avec l'auto-hébergement n'est pas encore établi, mais la démarche se poursuit. Car après avoir mis en lumière des données sensibles, il me faut pouvoir les protéger. Ainsi, l'étape d'après fut de trouver un moyen de créer des sauvegardes efficacement.

Pour faciliter les choses, j'ai commencé par réorganiser mes disques. Globalement, le système et les logiciels sont stockés sur un SSD, et toutes les données utilisateurs sont stockées sur un disque dur plus spacieux. J'ai tout rangé selon une hiérarchie aussi plate que possible : seulement quelques dossiers à la racine – projets de développements dans /code, documents généraux dans /own, etc. – puis tout est rangé de façon atomique dans un dossier nommé si possible d'une façon courte mais évocatrice. L'objectif est qu'au long terme, la hiérarchie de dossiers change le moins possible, pour pouvoir mettre en œuvre des sauvegardes itératives.

Je souhaite également faire un petit aparté sur le rangement des données en hiérarchies plates. J'ai longtemps cherché à développer une taxonomie élégante pour structurer mes dossiers, sans réel succès. Ranger un fichier, c'est un peu comme essayer de définir le genre musical d'un morceau : pour certains ce sera évident, mais souvent, il est très difficile de faire un choix clair et définitif. Une hiérarchie plate évite d'avoir à mener ces longues réflexions, et évite également de devoir tout déplacer lorsque l'on change d'avis un mois plus tard. Néanmoins, pour faciliter les recherches, un système d'étiquettes serait très appréciable : possibilité d'ajouter plusieurs étiquettes ou aucune à un dossier, recherche par étiquette, voire développement d'une taxonomie pour structurer cette recherche. Malheureusement, si MacOS et Linux peuvent proposer cette fonctionnalité, ce n'est pas le cas de Windows. À en croire une issue sur le dépôt de PowerToys, l'utilitaire de fonctionnalités expérimentales de Windows, cela n'est pas près d'arriver.

Les données locales ne sont pas les seules concernées par la sauvegarde, il faut également prendre en compte celles en-ligne. Comme mentionné dans la section précédente, pour un certains nombre de sites, je télécharge les données, ou, lorsque cela suffit, un index des données. J'ai pour cela plusieurs petits scripts pour automatiser ce processus au maximum. Par exemple, utiliser l'API d'un service de streaming musical pour garder une trace de mes playlists.

Je pratique ensuite deux types de sauvegardes :

Pour les données importantes, je copie tout sur un disque externe avec le logiciel rsync. Je suis toujours sous Windows pour le moment, aussi pour le faire fonctionner, il faut passer par le sous-système Windows pour Linux, wsl. Ce programme ouvre un shell bash où les disques locaux sont montés sur /mnt/c/, /mnt/d/, etc. On peut alors utiliser la commande rsync pour synchroniser incrémentalement les données. La première sauvegarde est assez longue, mais les suivantes sont plus rapides, du moment que la hiérarchie n'a pas changé.

La seconde sauvegarde est plutôt un disque de récupération : je fais une copie complète des disques système et utilisateur sur un disque dur externe assez large à l'aide de CloneZilla.

Enfin, pour bien faire, j'essaie de placer ces sauvegardes dans des endroits différents. Typiquement, à l'occasion des fêtes de fin d'années, j'ai pu laisser un disque dur chez ma famille, étiqueté au fond d'une armoire, en cas de problème.

Migration du serveur

Ces préliminaires terminés – cela m'aura tout de même pris plus d'un mois – je m'attaque alors à un projet d'envergure : reconstruire mon serveur, et cela pour plusieurs raisons. Déjà, le matériel : un Raspberry Pi 3B+ qui commençait à dater – l'alimentation d'origine m'avait déjà lâchée une fois – et dont les performances étaient assez limitées. Ensuite, l'environnement logiciel a beaucoup changé en quatre ans, et je préfère prendre les devants avant de ne plus pouvoir mettre à jour des composants importants faute de version compatible.

Mais surtout, débutant dans l'administration d'une telle machine, j'ai beaucoup tâtonné, installé et désinstallé de nombreux programmes, parfois en suivant des tutoriels désormais obsolètes. Ainsi, je désirais nettoyer tout ceci, en faisant une nouvelle installation toute fraîche, en gardant cette fois une trace des opérations d'installation des différents services. Je crois que Docker est une bonne solution à ce problème, mais je ne voulais rajouter aucune surcouche à un Raspberry Pi dont les performances restent modestes.

Ainsi, j'achète un tout nouveau Raspberry Pi 4 – à un prix d'or depuis la pénurie de composants électroniques – et recommence l'installation de tous les services dont j'aurais besoin, à savoir, un serveur web Apache intégrant une partie Python avec Django, un serveur mail SMTP/IMAP avec Postfix et Dovecot ainsi qu'un serveur CalDav avec Radicale.

Pour suivre ce processus à la trace, j'ai créé un nouveau dépôt git avec des scripts pour chaque étape d'installation, ainsi que des références aux fichiers de configuration créés ou modifiés. En théorie, je peux désormais ré-installer l'ensemble du serveur en une commande et une dizaine de minutes (principalement le temps de compilation des nouvelles versions de Python). La possibilité d'inclure des sous-modules dans un dépôt git m'a bien aidé à intégrer d'autres projets au dépôt principal.

Aussi, un autre script permet d'exporter toutes les données utilisateurs et nouvelles configurations dans une archive ZIP que je peux sauvegarder. Le script d'installation utilise lui-même cette archive pour restaurer ces données à leur emplacement ; dans l'idée d'une nouvelle installation, cela permet de cloner rapidement l'ancien système, ou de le restaurer depuis un point de sauvegarde plus ancien.

Ce rafraîchissement a également été l'occasion de simplifier l'architecture de mon installation, mais les principaux services n'ont pas changé. Notamment, après un déménagement et un changement d'opérateur, je craignais pour la mise en place du nouveau serveur mail, mais l'installation s'est révélée plus simple que la première fois, mon nouvel opérateur ne bloquant pas la port 25 par défaut – ces informations sont consultables sur Yunohost. La certification SSL est, comme avant, assurée par Let's Encrypt via Certbot, avec un renouvellement automatique.

Je craignais que cela prenne une grosse semaine voire plus, mais l'affaire était réglée en moins d'un week-end. Entre le meilleur matériel, la mise à jours des logiciels et la simplification de l'architecture, la différence en termes de performances dépasse largement mes attentes, ce qui ouvre de nouvelles perspectives.

Frénésie de l'auto-hébergement

Voilà que nous retombons sur nos pattes. La mise en place de ce nouveau serveur est l'occasion d'y intégrer de nouvelles fonctionnalités.

Projets divers

Premièrement, j'ai rapatrié les sites de démonstration de mes projets depuis GitHub Pages :

• cuiz : Quiz de géographie
• datamoshing : Transfert de flux optique depuis une webcam
• generative-art : Animations artistiques génératives
• halftone-palette : Utilitaire d'images en demi-teinte
• les-mysteres-perces : Index d'épisodes des Maîtres du mystère
• noise-palette : Utilitaire de bruit de Perlin
• vampire-survivors-combo-builder : Générateur de combo optimal pour Vampire Survivors
• pseudo : Générateur de pseudonyme en anagramme

S'ajoute également une myriade de petits outils ou agrégateurs personnels (météo, séances de cinéma, horaires de transports, …).

Serveur git

Mais surtout, j'ai commencé à héberger mon propre serveur git pour stocker des dépôts personnels que je ne voudrais pas partager sur GitHub. En soit, on peut tout à fait utiliser la commande git pour travailler avec un simple dossier via SSH, sans installation particulière sur le serveur. Mais, comme l'indique la documentation git, le logiciel fournit également des scripts CGI permettant de télécharger et téléverser depuis un serveur web, avec une authentification classique. Encore mieux, le logiciel fournit également une interface web Gitweb permettant de visualiser l'historique des commits et la hiérarchie des fichiers d'un dépôts depuis un navigateur web.

L'installation est très simple, il suffit de correctement paramétrer les routes pour le serveur web, comme cela est expliqué dans la documentation. Une remarque toutefois : lors de la création d'un nouveau dépôt, ne pas oublier d'activer l'option --shared (ou activer la configuration core.sharedRepository). Cela permet à l'utilisateur web (souvent www-data) et à l'utilisateur SSH de travailler sur le même dépôt, sans conflit de permissions.

En finir avec Google

Dans le premier article sur l'auto-hébergement, je définissais déjà une volonté de se défaire des services de Google. Malgré mes efforts, ce n'était pas encore – et ce n'est toujours pas – vraiment le cas.

Avant cette migration, j'utilisais beaucoup Google Sheets et Google MyMaps, malgré tout de bons outils pour gérer les données tabulaires ou géographiques. En outre, cela fait longtemps que je développe une application web Orgapy qui permet de gérer des notes, des tâches ou des projets. J'ai alors pensé à intégrer les tableaux et les cartes à cette application, afin de centraliser mes penses-bêtes, quels que soient leur formats. J'ai donc implémenté deux bibliothèques front-end sheet.js et maps.js, l'une pour interagir avec un tableau, l'autre avec une carte Leaflet. Les données sont enregistrées sur le serveur, en TSV pour les tableaux, en GeoJSON pour les cartes. Les modifications sont synchronisées avec les données du serveur. Si ces interfaces restent sommaires, elles suffisent largement à mon besoin de stocker des données sous ces formats un peu particuliers. J'ai donc pu supprimer tous mes documents depuis mon profil Google, et arrêter d'utiliser Sheets et MyMaps.

Dernière cible, et non des moindres, Google Photos. Depuis plusieurs années mon téléphone synchronisait les photos via cette application, et je m'en servais comme base pour partager des albums à des connaissances. Désireux de mettre un terme à cela, j'ai commencé par étudier les alternatives existantes, comme PhotoPrism, Piwigo, LibrePhotos, Photoview ou HomeGallery. Certaines semblent de qualité, mais aucune ne remplit exactement mes critères :

• faible utilisation de ressources (notamment, ne pas utiliser de modèles de reconnaissance d'images très lourds),
• possibilité de partager des albums à une ou plusieurs personnes facilement,
• si possible, n'utiliser que la structure de fichiers comme « base de données ».

Le site allant finalement être hébergé sur le Raspberry Pi au milieu d'autres services, je ne peux pas me permettre d'installer une application trop lourde. Ne trouvant pas chaussure à mon pied, je décide d'implémenter ma propre solution. L'idée est simple :

1. je garde ma bibliothèque de photo sur mon disque local, dont je fais déjà des sauvegardes régulières,
2. je ne mets en ligne que les albums à partager, avec un mécanisme simple de gestion d'accès.

Ni une ni deux, je m'attelle à la première étape. Je télécharge toutes les photos depuis Google Photos – ce qui représente plusieurs dizaines de gigaoctets, la plupart ayant été téléversées avant l'instauration d'une limite – et les range dans ma hiérarchie de dossiers : un dossier par année, puis un sous-dossier par jour. J'automatise cette tâche avec un script lisant les métadonnées JSON fournies par Google Photos incluant la date de prise de vue et déplaçant les fichiers en conséquence. À noter que Google Photos conserve les noms des fichiers au téléversement, mais pour éviter les doublons, ajoute des suffixes au téléchargement, sans modifier les métadonnées JSON. Ainsi, de nombreuses photos se retrouvent sans date de prise de vue, et il faut ruser pour les reclasser. Les fichiers JPG contiennent les champs EXIF donnant la date de prise de vue. Mais ce n'est pas le cas pour les PNG, GIF ou même les vidéos. Il faut donc soit extraire cette date du nom de fichier lorsqu'il s'agit d'un horodatage, ou exploiter la date de création ou de modification du fichier, si elle correspond effectivement à la prise de vue. Cette étape repose ainsi sur beaucoup de détails et est assez pénible.

Ceci fait, pour la deuxième étape, je commence par réorganiser les photos d'albums dans leurs dossiers. Malheureusement, Google ne conserve pas l'ordre des photos dans les albums téléchargés. Comme cela concerne plus d'une centaine d'albums, je ne souhaite pas tout renommer à la main : j'ai alors pour idée d'injecter un petit script JavaScript dans mon navigateur sur la page de l'album, qui en scanne le contenu est extrait la liste des fichiers dans l'ordre. Je passe ensuite cette liste à un autre programme qui préfixe les photos selon leur indice. Bien des efforts pour peu d'effets, certes, mais le résultat est tout de même plus propre. Je procède de la même façon pour récupérer automatiquement les miniatures d'albums.

Ainsi, je dispose d'une collection de dossiers, chacun contenant un fichier thumbnail.jpg et des images ou des vidéos préfixées 000 IMG_XXX.jpg, 001 VID_YYY.mp4, etc. Je copie ce dossier sur une clé USB branchée au Raspberry Pi. Un dernier script me permet de générer, pour chaque album, un fichier index.html pour l'affichage web, reposant sur deux nouvelles bibliothèques front-end développées pour l'occasion, mason.js pour gérer l'affichage en tuiles des miniatures et gallery.js pour gérer l'affichage en plein écran des photos et des vidéos. Ce script génère également, à l'aide de FFmpeg, une miniature pour chaque média, pour limiter la bande passante nécessaire au premier affichage de l'index. Une image n'est chargée que lorsque l'utilisateur l'affiche en plein écran.

Pour ce qui est de la sécurité et de la gestion des accès, je reproduis un mécanisme similaire au partage par lien des albums Google, qui est facile à implémenter et surtout à utiliser même pour des technophobes. Pour faire cela, le serveur web ne sert pas directement le dossier contenant les albums, mais un dossier miroir, contenant seulement des liens symboliques, nommés par le hachage d'une clé et des nom de dossiers. Ces noms étant longs et composés de caractères pseudo-aléatoires, ils sont difficilement devinables, et il me suffit de partager le lien avec une personne pour lui en donner l'accès.

Tout ceci en place, après un petit temps de test et une première sauvegarde des photos, j'ai procédé avec joie à la suppression des données depuis mon profil Google, désormais très spacieux ! À ma connaissance, je n'utilise plus que deux services Google, à savoir YouTube et Android. L'aventure n'est pas terminée, mais une belle étape a été franchie.

Un avenir libre et fédéré ?

Dans l'article précédent, je mentionnais quelques pistes à explorer pour la suite : installer un serveur Icecast, GitLab ou Plex. Bon, j'ai laissé tombé la diffusion d'une webradio. À la place d'un serveur GitLab assez lourd, j'ai installé un serveur git léger, mais l'idée est la même. Et enfin, j'ai également implémenté un serveur média personnel, mais hors-ligne, et sans Plex – dont le principe est absurde : pourquoi nécessiter un compte et une connexion internet globale pour communiquer avec des appareils locaux ? cela ne fait certainement pas l'unanimité – mais j'en ferai certainement un article prochainement. Finalement, ces projections sont plutôt respectées, notamment le fait que ceci prenne beaucoup de temps.

Désormais, mon objectif est plutôt de minimiser ma dépendance à des services non-libres ou, du moins, commerciaux. Si c'est déjà le cas pour la plupart des logiciels et services courants, il s'agira surtout à l'avenir de migrer mes appareils sur d'autres systèmes d'exploitation, mais cela représente à nouveau un grand chantier. Avant de m'y plonger, je vais tout de même essayer de profiter un peu de l'environnement actuel.

Aussi, une grande partie des services propriétaires que j'utilise sont les réseaux sociaux, desquels se défaire est difficile. Les approches fédérées comme Mastodon ou Peertube sont de bonnes alternatives mais encore trop peu utilisées par le grand public. En attendant de voir ce que ces plateformes vont devenir, j'essaye de centraliser mes sources d'informations sur internet, notamment via la syndication de contenu Web. À ce titre, je propose moi-même un flux RSS, regroupant mes articles de blog, mes vidéos sur YouTube, mes dépôts sur GitHub et mes posts sur Instagram.

Sur ce, meilleurs vœux 2024 !