Domovik – Un système de synchronisation pluri-navigateurs

[LinuxFR]

Sommaire

• Pourquoi Domovik ?
• Fonctionnalités
  • Onglets
  • Favoris
  • Listes de lecture
  • Partage
  • Chiffrement
• Infrastructure logicielle
  • Serveur
  • Extension
• Perspectives
• Conclusion

Cher journal,

Aujourd’hui, j’aimerais te présenter mon dernier projet, Domovik : un serveur de synchronisation pluri-navigateurs que j’ai développé durant ces derniers mois.

Pourquoi Domovik ?

Pour des raisons tant personnelles que professionnelles, j’utilise régulièrement plusieurs navigateurs répartis sur plusieurs machines, ce qui fragmente d’autant ma navigation : me souvenir sur lequel d’entre eux j’ai ouvert telle vidéo ou sauvegardé tel article est une source de tracas sans fin. « Allons donc », me direz-vous, « pourquoi diable ne pas simplement utiliser les services de synchronisation fournis par les éditeurs desdits navigateurs ? » Juste question, dont la réponse est double : d’une part, je ne tiens pas nécessairement à confier toutes mes données de navigation à des entités aux allégeances hasardeuses ; mais, et surtout, utilisant régulièrement Firefox, Vivaldi et Qutebrowser (et d’autres plus occasionnellement), aucun de ces services n’est compatible avec ce panel.

J’ai donc développé Domovik ces deux dernières années pour combler ce manque, et le confinement m’a offert le temps nécessaire pour en finaliser une première version de qualité suffisante (j’espère ?) pour l’ouvrir au public. Domovik se présente sous la forme de deux (pour le moment) logiciels : d’une part le serveur de synchronisation, d’autre part l’extension pour navigateur (actuellement disponible pour Firefox/Edge/Chrom{ium,e} et ses dérivés) ; la seconde s’accordant avec le premier pour y synchroniser les données des navigateurs sur lesquels elle est installée.

Fonctionnalités

Domovik étant avant tout développé autour de ma propre utilisation, il s’articule autour des quatre fonctions dont je ressentais particulièrement le besoin.

Onglets

La fonction clef qui m’a poussé au développement de Domovik est la synchronisation des onglets : je voulais accéder à tous les onglets de tous mes navigateurs depuis n’importe lequel d’entre eux – notamment parce que j’oublie régulièrement des pages très intéressantes sur le PC du labo, de préférence le vendredi soir. L’extension Domovik communique donc depuis le navigateur avec le serveur pour y répliquer la liste des onglets ouverts. Ceux-ci sont accessibles soit (i) directement depuis l’interface web du serveur, soit (ii) par l’extension, qui remplace la page nouvel onglet du navigateur avec un tableau de bord – une version de l’extension qui ne remplace pas celle-ci, Domovik Lite, est aussi disponible.

Favoris

La synchronisation des favoris découle naturellement de celle des onglets. Les favoris des navigateurs synchronisés sont accessibles soit depuis l’interface web du serveur, soit (comme les onglets) au travers de toute requête commençant par dom dans la barre d’URL – du moins pour les navigateurs supportant cette fonctionnalité des WebExtensions (méchant Vivaldi).

Listes de lecture

Les listes de lecture répondent à un besoin de favoris thématiques volatiles. Ces listes sont donc des listes de liens, dont la subtilité est qu’ouvrir l’un d’entre eux l’en ôte. Je les utilise avant tout pour organiser des listes de pages à lire dans un futur proche, mais dont le caractère ne justifie pas une inscription dans le marbre des favoris. Elles constituent donc une sorte de limbes entre mes barres d’onglets (par trop chargées) et mes favoris (poussiéreux). J’y range les liens relatifs à un sujet à creuser lorsque j’en aurai le temps, à des projets temporairement inactifs, etc. On y épingle une page depuis un bouton dans la barre d’outils du navigateur, et on la retrouve soit dans l’interface web du serveur, soit, par l’extension, sur la page nouvel onglet.

Partage

Enfin, las de m’envoyer par mail des liens divers et variés pour les passer d’un OS ou d’une machine à l’autre, l’extension Domovik rajoute une entrée au menu contextuel des pages web et des liens qu’elles contiennent pour envoyer ladite URL à un autre des navigateurs connectés, qui ouvrira celui-ci a la première occasion. C’est idiot, mais fichtrement pratique.

Chiffrement

Les données de navigation sont bien évidemment extrêmement intimes. Domovik utilise du chiffrement bout en bout pour toutes ces informations, et le serveur ne voit donc transiter que des flux chiffrés. L’on fait ainsi d’une pierre deux coups : les utilisateurs sont non seulement protégés d’un hébergeur par trop indélicat, mais aussi d’un putatif accès frauduleux à la base de données du serveur. La mise en œuvre est assez simple : le mot de passe de l’utilisateur est en fait une phrase de passe, de laquelle est dérivée, de façon totalement transparente, et le mot de passe d’accès au site web, et la clef de chiffrement des donnees. Avantage : c’est simple à développer et à utiliser ; inconvénient : la perte ou la modification du mot de passe implique la perte de toutes les données, alors indéchiffrables.

Infrastructure logicielle

Serveur

Le critère de choix des technologies de développement de Domovik fut extrêmement subjectif et se résuma à : « n’importe, pourvu que ça me plaise ». Le serveur est développé autour de Phoenix, un cadriciel web écrit en Elixir qui tourne sur OTP, la plateforme d’exécution développée pour Erlang. Outre ses qualités en tant qu’environnement de développement, l’ensemble offre de très bonnes performances pour une empreinte mémoire et processeur finalement modeste, ce qui ne gâte rien – et en plus, elle semble avoir d’excellentes capacités de passage à l’échelle, ce qui n’est pas très utile mais permet de fanfaronner un brin.

Le frontend des premières versions étaient en HTML/CSS purs, mais le choix d’ajouter le chiffrement bout en bout nécessita l’addition de quelques touches de JS pour déchiffrer les données retournées par le serveur. La complexité de ces fragment étant modeste, ils sont écrits en JS vanilla, la seule finesse venant de l’utilisation de Webpack pour la compilation des feuilles de style SASS, l’assemblage des divers fichiers JS et la compression du tout.

Pour l’environnement système, rien que de très commun : une base de données PostgreSQL et un proxy nginx. Ce dernier n’est pas nécessaire stricto sensu, mais comme je l’ai de toute façon pour relayer d’autres logiciels, l’occasion fait le larron. Enfin, en ce qui concerne la méthode de déploiement, c’est pour l’instant un simple cocktail à base de git et de scripts shell. Ceci dit, je suis en train de travailler à l’écriture d’un paquet Nix, ce qui permettra à tout un chacun de déployer l’ensemble bien plus sûrement et confortablement.

Extension

Grâce a la généralisation du standard des WebExtensions (ça coince encore un peu aux entournures, mais il faut savoir s’en satisfaire), développer une extension commune aux deux grands (Gecko et Blink, et même bientôt Safari) – et donc à leurs cousins (Vivaldi, Edge, Brave, …) – est relativement aisé. Les particularités propres aux uns ou aux autres sont palliées par l’utilisation de polyfills et autres artifices lors du processus de compilation.

L’extension fut d’abord développée en JS brut, puis très rapidement convertie en TypeScript quand le seuil de ma tolérance aux idiotismes de JS fut dépassée. L’on sent TypeScript limité dans ses ambitions par la rétrocompatibilité qu’il s’impose avec JS, mais il n’en demeure pas moins un indubitable plus, notamment grâce à son système de types.

Perspectives

J’ai bien entendu déjà une kyrielle d’idées pour poursuivre le développement plus avant. Pour rester sur les principales, la priorité sera donnée au développement d’applications mobiles : en effet, les navigateurs mobiles ne supportent pas les extensions – et Dieu sait que j’y ai pourtant bien des onglets à partager. Le seul moyen de les connecter à Domovik sera donc de passer par les systèmes d’échange inter-applications d’Android et iOS, ce qui requiert des applications idoines.

Ensuite, lorsque l’API sera stabilisée, je fournirai une définition OpenAPI, pour que les utilisateurs puissent facilement développer leur propres idées (à quand Domovik dans Emacs ?) – et en corollaire, l’interfacer avec des navigateurs tels que Qutebrowser ou Nyxt qui, faute de supporter les WebExtensions, offrent leur propre système d’extension.

Enfin, une API stable sera une première étape dans le développement d’un client en ligne de commande qui présenterait le système sous un jour plus enclin à l’intégration dans d’autres logiciels qu’une API web (pipes vs. requêtes HTTP).

Conclusion

Nous sommes entre libristes barbus, le logiciel est donc bien entendu libre : AGPLv3 pour le serveur et GPLv3 pour l’extension ; le tout est léger et nécessite peu de dépendances, ce qui le rend assez facilement auto-hébergeable. Bien entendu, toute question, suggestion, inévitable rapport de bug, etc. est le bienvenu ici ou sur Github. Enfin, si vous souhaitez soutenir le projet, un hébergement payant est disponible. Merci de m’avoir lu jusqu’ici, et bonne prochaine période de 12 heures !

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

https://linuxfr.org/users/lockidor/journaux/domovik-un-systeme-de-synchronisation-pluri-navigateurs

[Lilizeclik]

Bon j’ai pas tout compris en détail, dans la mesure où je ne suis pas certaine de savoir mettre en oeuvre cet outil, mais c’est super intéressant quand même ! Faudra que je fasse l’effort de le tester !