Pendant que Google introduit dans Gmail de nouvelles fonctionnalités exclusives, un acteur beaucoup plus modeste s’échine à faire émerger un nouveau protocole ouvert pour l’email. Avec JMAP, FastMail propose un remplaçant moderne à l’IMAP universel mais vieillissant.

Un projet ambitieux pour un fournisseur d’email qui se démarque du lot par son histoire (acheté par Opera en 2010, FastMail a été racheté par ses employés trois ans plus tard), son modèle économique exclusivement payant et sa bonne réputation. Entretien avec le CEO de FastMail, Bron Gondwana.

MacGeneration : Le nouveau « mode confidentiel » de Gmail est-il interopérable ? Qu’est-ce qui se passe quand un utilisateur de Gmail envoie un email autodestructible à un utilisateur de FastMail ou d’un autre fournisseur de mails ?

Bron Gondwana : La fonction n’est pas interopérable. Même s’ils présentent les messages du « mode confidentiel » comme des emails standards, sous le capot ce n’en est pas. Envoyer un email en « mode confidentiel » vers un autre service que Gmail implique un lien hypertexte vers le contenu hébergé directement par Google, lien qui cessera de fonctionner au bout d’un moment et qui peut être annulé.

C’est un type de messagerie utile, mais ce n’est pas de l’email comme les gens l’entendent. Est-ce que les gens préfèrent que ce type de messages soit mélangé avec leurs emails ou bien séparé ? C’est une question intéressante. Personnellement, je trouve qu’il est plus facile de raisonner quand mes emails sont ma mémoire et que celle-ci n’est pas altérée [Bron Gondwana a publié récemment deux billets de blog sur le sujet, Email is your electronic memory & Email doesn’t disappear, ndr].

Est-ce que vous prévoyez de proposer des fonctions similaires à celles introduites dernièrement dans Gmail ?

Snooze [la mise en attente, ndr], absolument. Je suis déçu que cela nous ait pris autant de temps, mais nous étions concentrés sur la transition de nos serveurs vers la version actuelle de JMAP.

Nudge [signalement automatique d’un message en attente de réponse, ndr] et les autres fonctions liées au « cycle de vie des messages » font partie de nos plans aussi. Par exemple, il serait utile de dire « rappelle-moi ce message si je n’ai pas de réponse dans les trois jours ».

Les réponses intelligentes sont un peu plus délicates. Je vois l’intérêt, mais c’est plus complexe techniquement que les autres. Cela dit, « l’apprentissage automatique avancé » n’est pas nécessaire dans la plupart des cas. Un peu d’heuristique de base peut conduire étonnamment loin quand vous implémentez des services « intelligents ».

Un gestionnaire de droits intégré, j’en doute. S’il y avait des normes pour dire « ne pas afficher le bouton Transférer sur ce message », nous adapterions probablement notre interface et présenterions une information. Mais notre vision de l’email est que vous avez des droits sur votre copie. Les tentatives de verrouillage conduisent simplement les gens à prendre des captures d’écran, à prendre des photos avec un autre appareil ou bien encore à retaper eux-mêmes l’information. Ces restrictions n’arrêtent pas la circulation de l’information, elles font juste perdre du temps aux gens.

La plupart des nouveautés de Gmail sont propriétaires. Est-ce vous pensez que c’est préjudiciable pour l’email en général ?

Absolument. Je comprends pourquoi Gmail va de l’avant et crée ses propres fonctionnalités. Tout le monde fait ça. Parvenir à un consensus prend beaucoup plus de temps, et ces nouvelles fonctionnalités sont réclamées par les utilisateurs.

Pour notre part, nous avons créé un protocole propriétaire autour de JSON en 2010 pour permettre à notre web app, constituée d’une seule page, de communiquer avec notre serveur. Nous l’avons créé de zéro car il n’y avait aucun standard ouvert adapté. Nous nous sommes ensuite rendu compte que beaucoup d’autres sociétés fabriquaient leurs propres protocoles JSON propriétaires, de Nylas à Google en passant par Microsoft.

FastMail croit fermement aux standards ouverts et à l’interopérabilité. L’email est le premier réseau social fédéré, et en dépit de tous ses défauts, il s’agit toujours du protocole de messagerie le plus utilisé à des fins professionnelles dans le monde.

Il est nécessaire d’avoir une spécification standard pour éviter la fragmentation dans les technologies qui font « mieux que l’IMAP », de sorte que les développeurs qui sont nouveaux dans l’email puissent commencer à réaliser quelque chose sans avoir à passer une année à comprendre et réimplémenter tout IMAP et MIME. Nous sommes partis du protocole que nous avions déjà validé et déployé en interne, et l’avons rendu plus générique et plus compatible avec les autres fournisseurs de mails. Ainsi est né JMAP.

Cette fragmentation liée aux technologies propriétaires, elle concerne seulement les développeurs ? C’est peut-être exagéré, mais pensez-vous qu’un jour les services d’email ne seront plus interopérables ou nécessiteront d’utiliser une poignée d’apps officielles ?

Le problème général est le suivant : si vous avez N implémentations serveurs différentes et M implémentations clients différentes et que chaque serveur implémente le même protocole, alors tout le monde doit implémenter un protocole, ce qui donne N+M implémentations, et le coût de la création d’un nouveau client équivaut juste à l’implémentation d’un protocole.

Si chaque serveur a un protocole différent, alors vous devez créer N*(M+1) implémentations, et chaque nouveau client a le choix : implémenter N protocoles et être interopérable, ou implémenter (< N) protocoles [et ne pas prendre en charge tous les services, ndr]. Nous voyons déjà ça avec IMAP ; certains clients implémentent seulement la version de Gmail de l’IMAP, parce qu’elle est juste assez différente pour permettre d’implémenter des fonctionnalités qui ne sont pas possibles en IMAP standard.

Cette situation, c’est ce qui se passe dans la messagerie instantanée, avec par exemple Pidgin qui, malgré sa prise en charge de 12 protocoles différents, n’est pas compatible avec beaucoup de services populaires (Facebook, messages privés Twitter, Signal, WhatsApp…). Même un client qui prend en charge de nombreux protocoles de messagerie ne peut pas tout faire. Je serais très déçu si l’email empruntait la même voie.

Vous avez présenté publiquement JMAP fin 2014. Où en est le projet aujourd’hui ?

Nous avons commencé par donner des conférences et discuter avec de gros fournisseurs de mails pour valider nos pistes, puis nous avons déposé un projet de spécifications à l’IETF [l’organisation qui élabore les standards d’internet, ndr] début 2017. JMAP est en cours de développement sous la conduite d’un groupe de travail de l’IETF.

Les spécifications pour le mail sont presque terminées. Nous avons aussi un projet de spécifications pour le calendrier et les contacts qui est disponible en ligne, mais pas encore déposé à l’IETF.

Nous prévoyons de faire passer les spécifications pour le mail au statut de « Proposition de normalisation », ce qui signifie publier un RFC et des implémentations interopérables, d’ici fin 2018. Je suis l’un des responsables du groupe de travail JMAP.

Mais nous n’oublions pas non plus les standards existants. L’IETF a mis en place un groupe de travail baptisé EXTRA qui est chargé de maintenir le protocole IMAP et ses extensions. Je suis l’un des directeurs d’EXTRA. Les deux groupes travaillent étroitement ensemble et ont l’intention de garder les standards synchronisés afin que le modèle de données requis pour fournir un serveur de messagerie fonctionne avec les deux protocoles.

Est-ce que Google et les autres grosses entreprises, Apple, Microsoft, etc. ont exprimé leur intérêt pour JMAP ? Dans le cas contraire, est-ce possible de bâtir un standard sans eux ?

Nous avons discuté avec des ingénieurs de beaucoup de grosses entreprises, et avons pris en compte leurs retours pour concevoir JMAP. Nous ne pouvons pas parler des feuilles de route spécifiques à leurs produits.

C’est tout à fait possible de bâtir un nouveau standard sans les grandes entreprises, mais ce n’est pas conseillé. Ce qui est bien avec JMAP, c’est que même si personne ne l’utilise, il nous permettra toujours de fournir un super service à nos clients.

JMAP est très économe en bande passante, parcimonieux avec la batterie des terminaux mobiles, immédiat grâce à l’intégration des notifications push, facile à intégrer pour les nouveaux clients, et optimisé sur le serveur avec de bons modèles de données. Tout le monde y gagne !

Nous nous attendons donc à ce qu’une fois le standard JMAP publié, d’autres fournisseurs de mail le prennent en charge en raison de ses avantages. Nous nous sommes assurés durant sa conception qu’il soit facile à intégrer pour les gros fournisseurs.

La tendance de fond dans les messageries électroniques ces dernières années est une meilleure protection des données, notamment par l’adoption du chiffrement de bout en bout. Dans le sillon de Telegram, iMessage ou encore ProtonMail, des messageries aussi populaires que WhatsApp et Facebook Messenger s’y sont mises. En 2016, vous expliquiez dans un billet de blog pourquoi FastMail ne prenait pas en charge PGP, le protocole le plus populaire pour chiffrer des emails (pas de recherche possible, ni de consultation de mails en cas de perte de la clé, ni d’anti-spam basé sur le contenu, entre autres raisons invoquées). Est-ce que c’est toujours votre position aujourd’hui ? De nouveaux projets open source, comme Pretty Easy Privacy et OpenPGP.js, ne rendent-ils pas les choses plus simples ?

Si, ils facilitent les choses, mais ils ne changent pas l’aspect fondamental qui est que notre rôle est de vous fournir un protocole permettant de transférer les messages chiffrés, ce que nous faisons déjà [rien n’empêche en effet de chiffrer son courrier FastMail avec un client tiers, ndr].

Nous pourrions envisager une option où vous stockeriez vos clés sur nos serveurs et où nous chiffrerions vos mails à votre place, mais l’intersection est minuscule entre l’ensemble des personnes qui veulent réellement du chiffrement de bout en bout en dépit des inconvénients associés, et l’ensemble des personnes qui nous feraient confiance pour stocker leurs clés. Ce serait juste une fonctionnalité développée pour cocher une nouvelle case « sécurité », or nous ne voulons pas développer des fonctions de « sécurité » qui n’apportent pas de vrais bénéfices dans ce domaine.

ProtonMail a une approche intéressante, et il y a quelques avantages à leur marque de confidentialité absolue. Mais je me demande vraiment combien de leurs clients ont perdu leurs mails à la suite de la perte de leur clé. Et bien sûr, ProtonMail ne peut pas offrir les mêmes fonctions de recherche et de calendrier que nous, parce que le serveur doit connaître le contenu des emails.

Notre positionnement, c’est un équilibre pragmatique entre la confidentialité, la disponibilité et l’intégrité. Cela signifie que nous avons un moyen de vous redonner accès à vos emails si vous avez perdu vos informations de connexion, ce qui arrive très souvent. Nous proposons également des fonctionnalités qui nécessitent que le serveur indexe et inspecte vos emails afin de mieux vous servir.

C’est un ensemble de choix de sécurité entre un serveur qui sait beaucoup de choses sur vous (par exemple Google qui inclut dans Gmail des infos personnelles qu’il a apprises ailleurs) et un serveur qui ne sait rien de vous (c’est l’approche de Tutanota et ProtonMail consistant à ne pas faire confiance au serveur et à l’utiliser uniquement comme intermédiaire pour transférer les données chiffrées).

FastMail est dans une position intermédiaire où vous devez faire confiance à nos serveurs, parce qu’ils font beaucoup pour améliorer votre expérience, mais nous ne collaborons pas avec des tierces parties ni ne transmettons vos données. Nous sommes garants de votre vie privée, et nous continuons à améliorer nos procédures de sorte que quand notre équipe technique résout des problèmes pour vous, elle ne puisse pas voir accidentellement vos données si elle n’en pas besoin.

Ce qui est intéressant de noter, c’est que si vous envoyez un email de FastMail à Gmail, il est transféré de nos serveurs via un lien chiffré — et il y a tellement de gens qui envoient des emails entre ces deux services que vous êtes fondus dans la masse et relativement peu sensible à une analyse de trafic visant à découvrir avec qui vous échangez.

Si vous avez votre serveur privé et que vous envoyez un email à un journaliste qui a lui aussi un serveur privé, votre conversation est peut-être chiffrée de bout en bout, mais le trafic révèle avec qui vous discutez. La confidentialité ne dépend pas à 100 % du chiffrement de bout en bout !