Je continue mes sauvegardes. Je n’utilise pas mon navigateur directement sur le serveur de sauvegarde donc je ne peux pas aller chercher manuellement dans les fichiers de profil Firefox.
Je suis toutefois connecté à mon profil Firefox en ligne et y synchronise mes données. J’ai trouvé un client en go assez simple à utiliser et installable via Homebrew.
ffsclient bookmarks list --format=json --sessionfile=ffs-session.json --output=bookmarks.json
On peut ainsi récupérer toutes les collections synchronisées : addons, adresses, favoris, formulaires, historique, mots de passe, préférences, tabs ouverts, etc. Je vais me contenter des favoris pour l’instant et considérer que le reste est volatile.
Que peut-on sécuriser là dedans ? On va essayer d’y voir clair.
Le schéma standard n’est pas très glorieux
Les transfert entre Alice, Bob et leur serveur sont quasiment toujours sécurisés aujourd’hui. À l’envoi c’est SMTP pour un client email, et HTTP pour un webmail. À la réception c’est IMAP ou POP pour un client email, et HTTP pour un webmail.
La communication entre les serveurs est généralement sécurisée mais les protocoles ne garantissent pas qu’elle le soit toujours.
Les emails transitent par contre en clair sur les deux serveurs. Si Alice et Bob laissent leurs messages sur le serveur, l’historique y est aussi en clair.
La vision historique, GPG et S/MIME
La solution historique qui ne demande aucun changement majeur sur toute la chaîne c’est d’utiliser GPG ou S/MIME.
Alice chiffre l’email avant de l’envoyer et Bob le déchiffre au moment où il le reçoit. Le réseau et les serveurs ne voient que le contenu chiffré, illisible.
Le compromis c’est celui de la lettre postale. Les tiers n’ont pas accès au contenu mais savent encore qui a écrit à qui, quand et depuis où. Même le sujet de l’email est en clair (et ça en dit parfois beaucoup).
Si vous écrivez à un avocat, à un journaliste, à un hôpital, à une personnalité ou à qui que ce soit d’intérêt, on continuera à le savoir. Ça peut révéler presque autant de chose que le contenu lui-même.
Cette vision est aujourd’hui considérée comme peu pertinente, même par ses défenseurs de l’époque. Elle est complexe à mettre en œuvre, repose sur des échanges de clés qui ne sont pas si évidents, et n’offre pas assez de confidentialité. Ça reste toutefois « l’état de l’art » sur l’échange d’email.
Il y a un effort avec Autocrypt pour automatiser PGP de manière opportuniste mais ça a son lot de complexité et de compromis de sécurité.
Agir de son côté
La solution historique repose sur le chiffrement par l’expéditeur. Si l’email n’est pas chiffré à la base, on se retrouve dans le système standard. En pratique peu le font, soit parce qu’ils ne savent pas, soit parce que c’est compliqué, soit parce que ce n’est pas proposé par leurs outils.
Dans toute la suite on va donc se concentrer un seul côté, faute de pouvoir faire changer nos interlocuteurs.
Tiers de confiance
Les emails en entrée seront toujours en clair. La seule chose qu’on peut faire c’est chercher un prestataire de confiance et s’assurer que personne d’autre que lui n’a accès au serveur.
Le prestataire de confiance c’est à vous de le choisir. Ça peut être une question d’interdire le profilage, l’exploitation statistique des données ou la publicité ciblée. Ça peut ausi être une question d’empêcher les fuites ou l’intrusion d’États.
Sur le premier point les petits prestataires sont souvent exemplaires. Sur le second point il est plus facile d’avoir confiance dans un petit acteur qu’on connait bien, mais sa sécurité et sa résistance aux pressions seront peut-être plus faibles.
Dans tous les cas, cet acteur sera soumis aux lois et aux autorités de son pays ainsi qu’à celui du pays qui héberge ses serveurs, pour ce qu’il y a de bien comme pour ce qu’il y a de mauvais.
Le choix pour nous, européens, c’est souvent de savoir si on accepte que notre serveur soit ou pas soumis aux lois de surveillance des USA. La soumissions aux USA intervient dès que l’entité qui nous héberge a une présence légale ou matérielle dans ce pays, ce qui malheureusement est le plus souvent le cas pour les acteurs internationaux.
Chiffrement du stockage
Certains services vous diront que les emails sont stockés chiffrés. C’est un chiffrement uniquement au stockage.
Le serveur continue à avoir les clés, donc la capacité de lire les emails. C’est mieux que rien, mais ça ne couvre qu’une petite partie du problème.
Chiffrement à la volée
Tant que les emails restent lisibles sur le serveur, ça peut fuiter.
Pour sécuriser les archives, Mailden — probablement via Dovecot — chiffre immédiatement l’email dès qu’il est reçu, à partir de la clé publique du destinataire. L’historique est sécurisé.
Lors que l’utilisateur se connecte avec son client email habituel, le mot de passe reçu sert aussi à accéder à la clé de déchiffrement le temps de retourner les emails. Clé privée, mot de passe et contenus en clair sont effacés une fois la connexion terminée.
L’historique est protégé mais le serveur a quand même brièvement accès à tous les emails à chaque fois qu’on se connecte.
Déchiffrement côté client
On peut faire la même chose mais avec le déchiffrement côté client, comme dans le scénario GPG décrit tout au début.
Les emails sont chiffrés dès qu’ils sont reçus, et transmis chiffrés au client. C’est le client qui s’occupera de les déchiffrer.
Attention, les métadonnées sont toujours en clair dans les archives. Ce qui est chiffré est plus en sécurité qu’avec Mailden, mais il y a moins de choses chiffrées (les métadonnées en clair peuvent révéler beaucoup).
Proton Mail fait ça, en utilisant GPG en interne et des clients emails spécifique pour interagir avec les serveurs. De ce que je comprends, toutefois, le service pourrait être soumis aux lois US. Si c’est confirmé, ça les rend pour moi beaucoup moins « de confiance ».
Chiffrement de l’enveloppe
Tuta va plus loin. Ils se sont distanciés de GPG et chiffrent tout l’email, enveloppe incluse.
En échange la recherche dans les emails se fait forcément côté client (le serveur n’a plus accès aux métadonnées nécessaires), ce qui peut être handicapant pour fouiller dans de grandes archives.
Il n’y a pas non plus à ma connaissance de solution pour gérer une sauvegarde automatique régulière de l’archive email.
Ok, je dois utiliser Tuta alors ?
C’est très loin d’être évident.
Tuta impose d’utiliser ses propres logiciels pour accéder aux emails. Impossible d’utiliser les outils habituels via POP ou IMAP. Il y a aussi des restrictions d’usage sur la recherche dans les archives. Le tout se fait aussi avec un abonnement non négligeable.
Si vous êtes sensibles aux questions de vie privée, par conviction plus que par besoin, allez-y. Jetez toutefois un œil aux compromis comme celui de Mailden, qui permet d’utiliser les protocoles et outils standards.
La réalité c’est que pour à peu près tout le monde, tout ça apporte des contraintes à l’usage ou au prix pour un gain très virtuel. Aucun humain ne va lire vos emails, et il y a peu de chances que le contenu ne fuite en public, simplement parce que ça n’intéresse personne.
Tout au plus, vue la tournure que prennent les États-Unis, si vous appartenez à une minorité, ça ne coûte pas grand chose de rapatrier vos données en territoire européen par sécurité plutôt que les laisser chez Google, Apple ou Microsoft. Si l’Europe prend le même chemin dans le futur, il sera temps de passer à Proton ou Tuta à ce moment là.
Si vous êtes quelqu’un en vue, Proton ou Tuta peuvent avoir du sens, mais presque plus parce que ces hébergeurs ont la sécurité en tête que parce que les emails y sont chiffrés. Gmail ferait tout autant l’affaire pour les mêmes raisons.
Si vous êtes réellement en danger en cas de fuite de vos emails, Tuta est peut-être ce qui ressemble le plus à une solution mais le mieux est de ne simplement pas utiliser l’email. Ce sera toujours imparfait parce que ce n’est pas prévu pour être confidentiel à la base. Il y a aujourd’hui d’autres solutions plus pertinentes.
Simple et efficace
Dans tout ça il y a quand même une solution qui n’a pas été abordée et qui mérite d’être soulignée : Récupérer ses emails très régulièrement et ne pas laisser ses archives en ligne.
Parfois le plus simple est encore le plus efficace. Tant qu’il n’y a pas besoin d’accéder aux archives en ligne ou depuis le smartphone, ça fait très bien l’affaire.
Je ne sais pas qui a dit quoi où, et je risque de laisser un message sans réponse dans les oubliettes s’il est sur une app que j’utilise peu.
Beeper semble résoudre mon problème depuis quelques jours. C’est un bête aggrégateur pour SMS, RCS, Whatsapp, Signal, Telegram, Messenger, Linkedin, Discord et quelques autres.
Ce n’est pas parfait, ça ne fait pas les appels vidéo et il on ne peut enregistrer qu’un seul compte par réseau, mais ça fait le job pour moi.
Bonus, la passerelle permet l’utilisation via une app de bureau.
Note : L’utilisation d’une passerelle implique que les serveurs de la passerelle peuvent lire vos messages. Ce n’est pas un scénario idéal, juste un compromis devant la multiplication des applications.
Before you press the volume or brightness controls, hold down the Option and Shift keys together on your keyboard. Now go ahead and make your adjustments, and you should see the onscreen indicator move forwards and backwards in smaller increments (four over each segment).
Je suis toujours dans mes sauvegardes. Je veux avoir une copie de tout dans mes sauvegarde, données des services en ligne incluses.
Je pensais faire ça facilement avec Pocket. Ils ont une API, assez simple.
En pratique je me retrouve à faire essentiellement de l’ingénierie inverse. La documentation indique des choses qui n’existent pas ou ne fonctionnent pas, et ne donne aucune information sur des éléments essentiels qu’on reçoit (genre la gestion des erreurs).
Authentification
Contrairement aux mécanismes OAuth habituels, leur authorize ne renvoie pas de code temporaire à échanger. Pour récupérer l’access_token, il faut le demander avec le request_token obtenu lors de l’échange serveur à serveur initial.
Ce request_token semble ne pas avoir de durée de vie. Il n’a en tout cas pas de refresh_token associé.
Mécanisme de régulation
L’API indique des limitations à 320 appels par heure. C’est d’autant plus important que pour télécharger mes plus de 29 0001 items par pages de 30 maximum, je vais forcément dépasser le nombre de requêtes que je peux faire en une heure.
Il y a un mécanisme automatique prévu pour la régulation mais le serveur n’envoie pas les entêtes prévues pour ça. Je sais juste qu’au bout d’un moment j’obtiens des erreurs 403 et que ça semble venir de là.
Je vais devoir gérer ça à la main. Pour l’instant je note l’heure de chaque requête dans un tableau. Quand mon tableau fait 320 éléments, je retire le premier élément et attend l’heure de cet élément + 1 heure avant de continuer.
Pagination
Le mécanisme pour la pagination est assez famélique : 30 items maximum par requête, plus un offset pour passer à la page suivante. C’est une mauvaise méthode pour itérer à travers des milliers d’items et ça ne trompe pas : Les requêtes sont effectivement de plus en plus lentes au fur et à mesure des pages. C’est visible et c’est pénible.
Le serveur prévoit de renvoyer un champ total qui permet de savoir s’il reste encore des éléments. Les réponses du serveur ne me renvoient malheureusement pas ce champ alors je vais juste itérer jusqu’à obtenir une réponse vide sans erreur.
Il y a aussi un champ since qui permet de limiter la recherche aux éléments plus récents qu’une certaine date. J’imaginais pouvoir me baser là dessus pour la pagination : Parcourir du plus vieux au plus récent, identifier la date du plus récent et repartir de là à la prochaine itération. C’est d’ailleurs la procédure recommandée pour beaucoup de services qui veulent éviter les problèmes que pose le parcours par offset. Malheureusement ça n’est pas utilisable pour la pagination : les items retournés ne sont correctement ordonnés ni par date d’ajout ni par date de modification.
Étrangement, il semble que la limite de 30 items par page ne soit pas forcée. Il semble que ça fonctionne avec beaucoup plus, mais que ça génère aussi plus d’erreurs. Le meilleur compromis semble effectivement dans les 25 à 30 items par page.
Dernière spécificité, j’ai l’impression de temps de réponse plus longs et d’erreurs plus fréquentes quand je vais du plus vieux au plus récent. Je n’ai pas vérifié cette impression avec des chiffres mais autant rester sur l’ordre par défaut : du plus récent au plus vieux.
Documentation incomplète
J’ai dit qu’il me manquait les entêtes de régulation et le champ total à la racine de la réponse. À l’opposé, j’ai quelques champs qui ne sont pas dans la documentation.
Le status semble être un entier avec, 0 pour une erreur, 1 pour OK, 2 quand il n’y a rien à afficher depuis une mise à jour. Quand status est à 0, le champ error contient le message d’erreur.
Il y a aussi un maxActions, dont je ne connais pas le sens.
Données irrécupérables sur le serveur
Pour une raison ou une autre, certaines de mes données semblent corrompues ou irrécupérables sur leur serveur (comme quoi la sauvegarde est utile ;-)..
J’ai 20 items qui provoquent systématiquement une erreur 504. Je peux récupérer ceux avant, ceux après, mais pas ceux là2. C’est vrai peu importe le sens de parcours (mais les offset ne sont logiquement pas les mêmes dans les deux sens).
Je n’ai pas plus d’explication. Je ne peux même pas connaitre les identifiants concernés pour demander leur suppression.
Potentiellement ce sont des données qui ne peuvent plus être réhydratées sur leurs serveurs, soient qu’il manque des informations essentielles, soit que leurs composants ne savent pas compléter ce qui manque (le serveur du lien sauvegardé qui répond bizarrement ?).
Erreurs aléatoires
Même avec une pagination basique, dans l’ordre par défaut, j’ai des erreurs fréquentes, aléatoires.
La plupart des 403 semblent liées à la limitation du nombre de requêtes, mais pas forcément toutes.
La plupart des 504 semblent liées à mes données irrécupérables mais il est arrivé que ça finisse pas passer quand même.
Les 502, en général il suffit de relancer la même requête, mais parfois l’erreur semble persister un moment.
Automatisation
Je parcours finalement tout par page de 30 et je mets à jour à chaque page le fichier de sauvegarde (pour les données récupérées) et le fichier de configuration (pour le nouvel offset de la prochaine requête). Si j’ai des erreurs inattendues, je pourrai relancer de là où j’en étais.
Si j’ai une page en erreur, je reprends tous les items de la page mais en allant les chercher mais 1 par 1 à partir de leur offset respectif. Parfois je ne retrouve pas l’erreur et ça permet de récupérer tout. Parfois l’erreur persiste sur un des éléments. Dans ce dernier cas l’idée c’est de pouvoir récupérer tous les bons items de la page et d’ignorer l’unique qui est en erreur.
Ça n’est pas parfait — si j’ai une erreur répétée mais temporaire sur un item, il sera ignoré silencieusement dans la sauvegarde — mais je n’ai pas mieux.
Une fois le parcours totalement fait une fois, je peux utiliser le since pour faire du différentiel.
J’ai quand même prévu de faire une requête RGPD pour demander un export de mes données. On verra s’ils arrivent à me récupérer les 20 items qui sont en erreur permanente.
Si oui, je tenterai de les effacer pour reprendre un fonctionnement sans erreur. Sinon, je tenterai peut-être de réinitialiser le compte ou migrer ailleurs.
Oui, tout ça. J’en suis moi-même étonné. J’ai tracé des usages depuis au moins fin 2010 mais je me demande si je ne l’utilisais pas au début de mon passage à Yahoo! en 2007–2008 du temps où ça s’appelait Read It Later. Ça fait une moyenne de 4 à 6 items par jour suivant la date retenue. ↩︎
Je me les note pour moi-même : aujourd’hui ce sont les offset 14053, 14481, 17689, 18291, 18629, 19389, 20363, 20815, 20996, 20999, 21512, 21923, 22275, 22283, 22346, 23386, 23841, 24189, 24414, 27441. ↩︎
Je vais étendre la liste au fur et à mesure. Il me manque encore pas mal de choses, et pas le plus simple. Au moins :
Les abonnements, listes et peut-être messages Mastodon
Les abonnements, listes et peut-être messages Bluesky
Abonnements et messages Instagram
Les messages Telegram
Les messages Whatsapp
Les messages Signal
Mes abonnements Newpipe (local Android)
Mon historique et documents Doctolib
Mes contacts Linkedin, peut-être les messages aussi
Mes historiques Spotify, Netflix, etc.
Les discussions privées Slack
Les factures et historiques d’un peu partout (boutiques en ligne, abonnements divers, edf, sncf, hôtel, internet, téléphone, etc.)
Les relevés sécu et mutuelle
Les relevés banque
Je regrette qu’on n’ait pas un vrai gros projet Open Source dont l’objectif est d’avoir des connecteurs pour tous les services en ligne de façon à rapatrier toutes nos données en local.
Cozy Cloud aurait pu faire ça mais la direction prise ne se centrait pas sur les connecteurs et le projet commercial n’a pas pu trouver sa place.
Automatisation en trois niveaux
Probablement qu’il me faudra faire évoluer mes outils. Je ne peux pas laisser les mots de passe de tout et n’importe quoi en clair.
J’imagine trois niveaux :
Les sauvegardes automatiques. J’ai des token Oauth voire des mots de passe en clair dans les fichiers de configuration. C’est valable quand les données ne sont pas sensibles et que je tiens à ce que ça sauvegarde « sans moi »
Les sauvegardes que je lancerai à la main, quand les données ou les mots de passe sont sensibles. Je pense faire des programmes qui s’interfacent directement avec le coffre Bitwarden, que je déverrouillerai dans la session pour l’occasion.
Ce qui va être une énorme galère à coder : les service en ligne sans API ouverte avec de l’offuscation sur l’authentification, ainsi que les services en ligne derrière un 2FA non automatisable ou un captcha complexe à mimer. Là j’imagine une extension navigateur qui sauvegarde ce dont j’ai besoin quand je passe sur le site.
Copie en ligne
Bon, chaque chose en son temps.
Avant tout ça il faudra déjà que je branche BorgBase ou BackBlaze pour avoir une copie chiffrée en ligne, parce que pour l’instant ça ne fait que recopier en local.
Avec dans les 3 To, ça me prendra bien un bon mois pour faire la première synchronisation. Je sais envoyer plus vite mais je doute qu’on me libère des Gb/s pour moi tout seul.
Le coffre avec tous mes mots de passe est particulier. J’ai fait le choix de le stocker en ligne pour synchroniser tous mes appareils mais perdre tous mes mots de passe n’est pas une option.
Bitwarden a effectivement une copie locale sur tous les appareils mais ça ne me couvre pas si quelque chose est supprimé sur le serveur et que la suppression se réplique alors sur tous mes appareils.
J’ai besoin d’une vraie copie locale, à moi.
Je n’ai cependant pas besoin que la copie soit en clair. Plus exactement, les données sont trop sensibles et je préfère n’avoir que la copie chiffrée. Je sais que je trouverais comment la déchiffrer à la main en cas de besoin (je l’ai déjà fait par le passé).
Je pourrais utiliser la ligne de commande officielle et synchroniser le coffre avec une clé d’API. Il n’y a pas besoin du mot de passe maitre pour ça. Je ne maitrise cependant pas où il stocke le coffre et j’avais moyennement envie de ça sur des tâches de sauvegarde.
J’ai réimplémenté ça à la main avec un programme généré par IA. Il télécharge les paramètres de login, le profil utilisateur et le coffre (chiffré).
C’est du Rust parce que j’espérais utiliser le SDK officiel. Malheureusement ils n’exportent pas les appels bas niveau que je souhaite. J’ai perdu bien trop longtemps à le comprendre et à batailler. J’ai fini par faire mon implémentation à la main.
Si j’avais su que je finirais avec juste quelques appels HTTP, ça ne serait pas en Rust. Tant pis.
Les calendriers Google c’est finalement plus simple que le reste. Dans les paramètres de chaque calendrier, tout à la fin, il y a une adresse ics privée.
Je peux me contenter de faire un appel régulièrement et sauvegarder ça.
Le plus gros calendrier fait tout juste 2 Mo. Il change tous les jours mais ça reste encore un poids acceptable.
Il faut juste bien penser à le faire pour chaque calendrier, y compris ceux que je créerai dans le futur. Ça doit pouvoir s’automatiser via les API Google Calendar mais je ne suis pas certain que ça vaille le coup pour l’instant.
Standard Notes j’ai beaucoup de choses dessus, surtout que j’y ai rapatrier mes anciennes notes de nvalt puis de Simple Note.
Il y a un mécanisme spécifique de backup dans Standard Notes, donc un qui permet d’envoyer une archive par email toutes les semaines. Chez moi ça envoyait en plusieurs exemplaires, et sans retirer le chiffrement.
Il y en a un autre qui permet de garder une trace locale. Je pourrais l’activer sur mon poste quotidien et faire en sorte que cette trace locale soit ensuite récupérée par Google Drive ou Tresorit. En pratique j’ai toujours eu des ennuis dès que je chaîne les outils de synchronisation. Je préfère éviter.
#!/bin/sh
APP=$1
OUT=$2
EMAIL=xxxx
PASS='xxxx'
SN_EMAIL=$EMAIL SN_PASSWORD=$PASS $APP get items > $OUT/standardnotes.items.json
SN_EMAIL=$EMAIL SN_PASSWORD=$PASS $APP get notes > $OUT/standardnotes.notes.json
SN_EMAIL=$EMAIL SN_PASSWORD=$PASS $APP get tags > $OUT/standardnotes.tags.json
Ça me demande de laisser mon mot de passe en clair sur le disque de sauvegarde (qui lui est chiffré). Pas idéal mais ce n’est pas un jeu de données très sensible alors ça peut passer.
Plus tard je segmenterai probablement deux types de sauvegardes, une automatique et une que je lancerai à la main qui utilisera la CLI bitwarden avec une session uniquement le temps de la sauvegarde. Ce jour là ça basculera peut-être dans mes sauvegardes à la main. Ça reste acceptable entre temps.
