Meta vient de prouver pourquoi le chiffrement ne devrait pas être optionnel

Le 8 mai, Meta a retiré le chiffrement de bout en bout des messages directs d’Instagram. La raison invoquée : trop peu d’utilisateurs avaient activé l’option.

Prenons cette explication au pied de la lettre un instant. Ils ont bâti la fonctionnalité. Ils l’ont offerte. Ils ont observé les données. Puis ils l’ont désactivée parce que pas assez de gens l’utilisaient.

On pourrait lire ça comme une histoire de mesures d’adoption. C’est en réalité une histoire sur la façon dont la confidentialité se bâtit.

La décision qui précède la décision

« Devrions-nous offrir le chiffrement? » ressemble à une question de confidentialité. En réalité, non. C’est une question de produit. La plus difficile, celle que la plupart des entreprises ne rendent jamais visible, c’est : « Pouvons-nous, en tant qu’entreprise, voir ces données? »

Quand le chiffrement de bout en bout est une fonctionnalité, la réponse est « parfois, selon vos paramètres ». L’entreprise garde la capacité d’accéder à vos données. Elle a simplement promis de ne pas le faire, pour les utilisateurs qui l’ont activée. Cette promesse peut être révisée.

Quand le chiffrement de bout en bout fait partie de l’architecture, la réponse est tout simplement « non ». L’entreprise ne peut pas voir vos données, même si elle le voulait. Il n’y a aucun interrupteur de son côté non plus. Retirer la protection signifierait reconstruire le service.

De l’extérieur, les deux cas se ressemblent. Ce sont fondamentalement deux engagements différents.

Pourquoi le « faible taux d’activation » est le problème de l’entreprise, pas le vôtre

La justification de Meta mérite un examen plus attentif. Si un paramètre qui protège quelque chose d’important reste inutilisé, c’est un échec de conception, pas un échec des utilisateurs.

Les messages directs chiffrés d’Instagram demandaient aux utilisateurs de trouver une option, de comprendre ce qu’elle faisait, et de l’activer pour chaque conversation. La plupart des gens s’inscrivent à une application de messagerie pour écrire à des gens, pas pour auditer des paramètres de sécurité. Le fait que très peu l’aient activée en dit long sur l’interface, pas sur le degré auquel les gens tiennent à la confidentialité. Nous avons déjà écrit sur le fait que les paramètres par défaut comptent plus que les fonctionnalités ; c’est le même argument vu de l’autre côté.

Quand les entreprises bâtissent la confidentialité comme une option obscure et invoquent ensuite la « faible adoption » comme prétexte pour la retirer, le calcul est bien commode. La conclusion était déjà disponible au moment où le choix de conception a été fait.

Ce que cela signifie pour tout service à qui vous confiez vos données

Le stockage infonuagique est le même problème, avec des enjeux plus élevés. Vos photos, vos documents, l’histoire de votre famille. (Nous avons expliqué le côté technique de la question dans notre article sur qui détient réellement les clés.)

Avant de demander « est-ce que ce service est chiffré en ce moment? », demandez-vous : « est-ce que l’entreprise peut déchiffrer mes données si elle le décide? ». La première porte sur aujourd’hui. La seconde porte sur chaque jour qui suit, y compris le jour où une réunion du conseil décidera que les priorités ont changé.

Un service conçu pour ne pas pouvoir déchiffrer vos fichiers prend un engagement structurel. Un service qui détient les clés fait une promesse procédurale. Les procédures changent. Les architectures, non — pas sans reconstruire le produit.

La version plus difficile de la question

Il est confortable de penser que la confidentialité est un paramètre qu’on peut configurer. Il est moins confortable de se demander si l’entreprise à qui vous faites confiance a la capacité d’en changer la réponse plus tard.

Quand vous choisissez un service pour quelque chose d’important, regardez ce que l’entreprise peut faire, pas ce qu’elle fait actuellement. Le premier point est structurel. Le second est une case à cocher.

On ne dit pas ça pour se draper de vertu. Bâtir un service qui ne peut pas déchiffrer les données de ses utilisateurs est une contrainte, pas une fonctionnalité. Ça écarte une longue liste de facilités. Nous avons accepté cette contrainte parce que l’alternative — demander aux utilisateurs de croire que les promesses d’aujourd’hui tiendront sur des décennies de pression commerciale — n’est pas un marché équitable.

Meta n’a pas trahi de garantie. L’entreprise a retiré une option, exactement comme cette option pouvait être retirée depuis le départ. C’est ça, le cœur du sujet.