Trois ans et demi sont passés depuis le lancement d’EteSync et le projet a déjà pas mal évolué. Je ne suis pas vraiment neutre, je participe de temps en temps au projet depuis un petit bout de temps, mais je suis étonné de ne pas avoir vu d’articles passer ici. La sortie imminente d’une nouvelle version du protocole et les nombreuses intégrations système ou applicatives, déjà disponibles depuis peu ou à venir, sont une bonne occasion de changer cet état de fait.
Sommaire
EteSync
EteSync (End‑to‑end synchronization, synchronisation de bout en bout en français), est le nom de plusieurs éléments qu’il faut distinguer :
- un protocole ;
- un service en ligne (en fait, une instance payante du serveur EteSync parmi d’autres, administrée par le fondateur du projet, le service étant facilement auto‑hébergeable) ;
- certaines applications clientes.
L’ensemble a été fondé par Tom Hacohen, un ancien de chez Samsung qui a travaillé sur Enlightenment et OpenMoko entre autres choses.
Le protocole
Le protocole permet de gérer ses contacts, événements et tâches, le tout étant chiffré de bout en bout. On pourrait donc rapprocher l’utilisation de ce protocole de CalDAV et CardDAV, mais avec l’impossibilité pour le serveur distant de savoir ce qui est stocké. De plus, ce protocole est journalisé, c’est‑à‑dire que chaque action réalisée (création, modification et suppression) est enregistrée. Cela permet, par exemple, de revenir en arrière facilement (un contact supprimé, il suffit de retrouver et d’annuler l’action de suppression par exemple).
À noter que le protocole dans sa version actuelle permet déjà des utilisations intéressantes comme le partage de calendrier entre différents utilisateurs.
Comme le mentionne le titre de cet article, le protocole est en cours d’évolution. Comme l’annonce l’article du blog officiel du 12 août 2020, la version 2 utilisera la bibliothèque libsodium et sera vérifiée à l’aide de Verifpal.
Le service en ligne / serveur
Il est nécessaire de faire tourner un serveur pour que le service fonctionne. Il existe donc une instance officielle.
La FAQ mentionne quelque chose d’intéressant à mon sens :
Why should I trust you with my data?
You shouldn’t.Pourquoi devrais-je vous faire confiance pour mes données ?
Vous ne devriez pas.
Ce qui va à l’encontre du discours de nombreux fournisseurs de services en ligne en ce moment, je trouve, et mérite d’être souligné. La possibilité de mettre en place sa propre instance (mes contributions ont principalement eu lieu à ce niveau‑là, pour faciliter le déploiement) est également la bienvenue pour celles et ceux qui n’auraient vraiment pas confiance.
Pour l’instant, l’implémentation officielle est en Python et basée sur Django. Il est possible d’utiliser une base de données de type SQLite ou une back‑end géré par Django (pour ma part, j’utilise PostgreSQL sans souci).
J’ai réalisé des paquets RPM non officiels pour Fedora/CentOS et pour l’Arch Linux User Repository afin de simplifier un peu l’installation, mais n’ai pas eu beaucoup de retours pour l’instant. Je ne me suis pas attaqué aux paquets .deb, n’utilisant pas de système lié de près ou de loin à Debian. J’ai également pris la peine de mettre en place un fichier .ini pour que la configuration du serveur soit plus aisée et éviter de devoir aller éditer directement les fichiers en Python.
Les applications clientes
Client Web
Le client Web officiel peut également être auto‑hébergé à l’aide d’un simple serveur Web. Il est néanmoins à noter que l’instance officielle permet d’accéder sans problème à son propre serveur en renseignant son adresse URL dans les paramètres avancés.
Android
Il y a bien évidemment un client pour Android qui permet d’importer facilement ses contacts à partir d’une exportation en vCard, par exemple, ou directement depuis un compte déjà paramétré sur l’appareil. L’application est disponible sur F‑Droid et sur le Play Store de Google.
iOS
De la même façon, une application est disponible pour les appareils tournant sous iOS. Néanmoins, d’après ce que j’ai pu voir, l’écosystème Apple est beaucoup moins simple à appréhender, selon les retours que Tom fait sur le canal IRC. Le développement de ce client a été soutenu par NLnet.
GNOME et KDE (GSoC)
Le projet a bénéficié cette année de deux projets lors du « Summer of Code », vous pouvez les voir en détail ici.
Les réalisations sont :
- la réalisation d’un back‑end EteSync pour Akonadi (côté KDE) ;
- la réalisation d’un back‑end EteSync pour Evolution Data Server (côté GNOME).
Thunderbird
Un projet de développement est en cours pour ajouter la prise en charge du protocole EteSync au greffon TbSync. Celui‑ci est également soutenu par NLnet.
En l’absence de cette prise en charge, il est pour l’instant nécessaire d’utiliser le pont DAV/EteSync pour exploiter ses contacts et calendriers depuis Thunderbird. C’est un serveur Radicale modifié qui parle d’un côté le protocole EteSync vers le serveur, et de l’autre les protocoles CalDAV/CardDAV pour que d’autres clients ne possédant pas encore de prise en charge d’EteSync puissent s’y connecter. Cela se rapproche dans l’esprit de ce que propose ProtonMail pour pouvoir utiliser des clients de messagerie électronique traditionnels avec son service de courriel.
Tasks.org (pour les tâches uniquement)
Il est possible depuis la version 8.0 de l’application de synchroniser les tâches via le protocole EteSync. De nombreuses améliorations ont eu lieu depuis.
vdirsyncer
Il y a une prise en charge d’EteSync depuis mars 2017, selon cette demande d’intégration Git.
Venez participer !
La communauté est principalement regroupée sur le canal IRC #etesync sur Freenode, sur Matrix (pont vers IRC, en réalité) et sur Reddit.
En ce moment, les extensions pour GNOME et KDE sont en cours de test.
Le code source est librement accessible sur les dépôts GitHub.
Aller plus loin
- Site officiel (316 clics)
- Dépôts des codes source du projet (40 clics)
- FAQ officielle (répond à la majorité des questions :D) (31 clics)
- Guide d’utilisation (30 clics)
- Canal IRC via Kiwi IRC (11 clics)
# Propre instance et sécurité
Posté par Romain . Évalué à 7.
Bonjour.
c'est justement une réflexion qui m'est apparue récemment car je suis dans le cas de figure d'un auto-hébergement partagé avec plusieurs personnes avec Yunohost.
Autant sur la question de l'emplacement des données, il est clair que c'est un plus dans la maitrise de ses données personnelles et on s'offre un panel de services sur mesure.
Mais d'un point de vue sécurité, est ce que le facteur humain ne présente pas un risque dans un cadre "amateur" ?
Pour prendre un contre-exemple car étant aussi inscrit chez Zaclys, un service de ce type proposé par une association ou une entreprise apporte sur le papier des garanties pour assurer sécurité/sauvegarde etc. Donc on parle de personnes professionnelles qui sont en mesure de configurer les serveurs pour assurer les dites garanties.
Enfin est ce que l'auto-hébergement présente un facteur de découragement pour une personne malveillante du fait du potentiel de données moins important qu'un panel de serveurs gérés par une entreprise/association.
En bref ma question sur l'auto-hébergement, c'est "on sait ce qu'on gagne et mais sait-on vraiment ce qu'on perd ?"
[^] # Re: Propre instance et sécurité
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 2.
Effectivement la gestion de la sécurité et des sauvegardes est un point important à prendre en compte lorsqu'on se met à auto-héberger, néanmoins ces points peuvent rester également problématique chez les professionnels et peu d'entre eux communiquent là-dessus. Disons que c'est toujours un peu la même question qui revient lorsqu'on parle de ce sujet.
Dans mon esprit la mention de l'auto-hébergement était plus pour indiquer qu'il est possible d'installer des instances non-officielles, avec les avantages et inconvénients qui sont mentionnés habituellement. Je pense qu'il est important qu'Internet soit décentralisé (voir fédéré) mais sans forcément aller jusqu'à ce que tout le monde héberge son serveur chez soi, utiliser des instances maintenues par des gens "qui s'y connaissent" me parait déjà aller dans le bon sens. Aller plus loin reste un choix possible pour les personnes que ça intéresse, mais cela nécessite de l'investissement.
Pour la partie malveillance, je pense que cela dépend, mais j'imagine que certains veulent juste nuire sans forcément récupérer les données, dans ce cas, une instance de n'importe quelle taille est une cible intéressante.
[^] # Re: Propre instance et sécurité
Posté par PhRæD . Évalué à -4.
Bonjour,
voici un (long) avis éclairé (je pense) sur la « fausse bonne idée de l’auto-hébergement ».
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
# Vdirsyncer
Posté par gouttegd (site web personnel) . Évalué à 7.
La prise en charge d’EteSync par vdirsyncer a été retirée de la branche principale de vdirsyncer un an plus tard. :(
La dernière version publiée (0.16.8) offre toujours cette prise en charge, mais ce ne sera pas le cas de la future 0.17. Il faudra passer par le pont etesync-dav mentionné pour continuer à utiliser EteSync avec vdirsyncer.
[^] # Re: Vdirsyncer
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 4.
Ah mince, je n'avais pas suivi, pour moi c'était toujours dedans. Merci pour la précision !
# Crypté ou pas ?
Posté par kalimba . Évalué à 1.
Du coup, le serveur a accès a nos données ou non ?
[^] # Re: Crypté ou pas ?
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 1. Dernière modification le 14 septembre 2020 à 10:26.
Non, le serveur n'y a pas accès. Enfin il a accès aux données, mais chiffrées.
[^] # Re: Crypté ou pas ?
Posté par Donk . Évalué à 3. Dernière modification le 14 septembre 2020 à 10:27.
Non, mais sur un malentendu, ça peut passer.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.