Questions fréquemment posées

Pourquoi ce site est-il mal traduit ? ⎃

Désolé, mais les auteurs actuels ne parlent que l'anglais. Nous avons besoin d'aide pour traduire ce projet dans d'autres langues. Comme moyen simple et peu coûteux de rendre ce service accessible aux personnes qui ne parlent pas anglais, nous utilisons la traduction automatique. Les résultats sont généralement acceptables, mais peuvent donner lieu à des formulations étranges ou même à des informations totalement inexactes. Vous pouvez nous aider à améliorer l'expérience pour tout le monde - veuillez soumettre la traduction correcte .

Dans quelle mesure ce service est-il sécurisé ?

Nous avons pris de nombreuses mesures pour sécuriser ce service pour l' usage auquel il est destiné . Avant de passer en revue ces étapes, il est important de comprendre ce qui suit :

Notre objectif est d'offrir ce service d'une manière qui offre des options pour améliorer votre confidentialité et votre sécurité. Voici quelques mesures que nous avons prises pour protéger vos informations :

Pourquoi ai-je reçu un lien ici avec une option pour déchiffrer un message ?

Nous nous excusons s'il y a des erreurs dans cette traduction . Ce service transmet simplement un message crypté d'un point à un autre et vous en êtes le destinataire. Le message sera bientôt supprimé. Les opérateurs de ce service n'ont aucun moyen de lire le contenu du message. Habituellement, quelqu'un utilise ce service lorsqu'il ne veut pas que le contenu d'un message reste dans diverses bases de données/périphériques/services/fichiers/etc. comme c'est généralement le cas lors de l'envoi d'un e-mail/message instantané/texte/etc. Si vous décidez de déchiffrer, veuillez garder à l'esprit ce qui suit :

Vous supprimez tout soumis à ce site?

Fidèle à notre logo de poubelle... tout est supprimé peu de temps après sa réception. La suppression de tout est automatisée - c'est écrit dans le serveur. Pensez-y de cette façon - il y a deux catégories d'informations soumises :

Dans le cas des messages, vous pouvez contrôler quand nous les supprimons en spécifiant : Par défaut, tout ce qui concerne un message est supprimé une fois qu'il a été récupéré une fois ou qu'il date d'une semaine - selon la première éventualité. Lorsqu'il s'agit de supprimer toutes les autres informations inhérentes à la soumission de quoi que ce soit sur le Web (c'est-à-dire votre adresse IP, etc.), nous ne vous donnons aucun contrôle sur le moment et la manière dont elles sont supprimées - nous les supprimons toutes toutes les 24 heures. .

Pourquoi utiliser ce service ?

Ce service est un outil pour aider à rendre les messages que vous envoyez/recevez moins permanents. La plupart de ce que vous communiquez sur Internet (chats, SMS, e-mails, etc.) est stocké et rarement supprimé. Souvent, lorsque vous supprimez quelque chose, il n'est pas réellement supprimé mais plutôt marqué comme supprimé et ne vous est plus affiché. Vos communications agrégées s'accumulent année après année dans des bases de données et sur des appareils sur lesquels vous n'avez aucun contrôle. Inévitablement, une ou plusieurs des organisations/personnes/appareils stockant vos communications sont piratées et vos informations sont divulguées. Ce problème est si répandu qu'il existe maintenant de nombreux sites Web qui suivent les organisations qui ont été compromises et qui ont divulgué des données d'utilisateurs. Les messages temporaires chiffrés de bout en bout sont une solution simple pour aider à rendre certaines de vos communications moins permanentes. Chaque message soumis à ce site a une durée de vie allant de 1 minute à 2 semaines - une fois cette durée écoulée, le message est supprimé. De plus, le paramètre par défaut consiste à supprimer tout message une fois que le destinataire l'a récupéré. De plus, tous les messages sont cryptés depuis votre appareil jusqu'à l'appareil du destinataire. L'objectif principal de l'utilisation du cryptage de bout en bout est de supprimer notre capacité à lire tous les messages soumis, supprimant ainsi une partie de l'exigence de confiance. Le résultat final est qu'il est désormais facile d'envoyer un message crypté via un simple lien. Ce message est supprimé soit peu de temps après l'envoi, soit lors de la récupération. Vous n'avez pas besoin d'installer/configurer un logiciel spécial. Vous n'avez pas besoin de créer de compte ni de fournir d'informations personnelles. Le destinataire n'a pas besoin d'être dans vos contacts ou même de connaître ce service - la seule condition pour qu'il puisse cliquer sur un lien.

Est-ce un service de messagerie ?

Non. Ce service est conçu pour compléter les services de messagerie existants comme la messagerie instantanée/e-mail/texte/etc. en ajoutant la possibilité d'empêcher les messages envoyés d'être stockés pendant une longue période. Nous ne livrons pas le lien généré au destinataire .

Quels sont les cas d'utilisation prévus ?

Alors, quels sont les scénarios dans lesquels il est approprié d'utiliser ce service ? Bien que chacun ait des besoins et des exigences différents en matière de confidentialité et de sécurité, j'ai personnellement trouvé les scénarios suivants comme cas d'utilisation appropriés :

A quoi ne doit pas servir ce service ?

Ce service ne doit pas être utilisé pour des informations très sensibles pour toutes les raisons expliquées dans cette FAQ. Voici quelques exemples de ce qu'il ne faut pas faire :

Pourquoi ne pas simplement utiliser PGP/Signal/OMEMO/Matrix/etc. ?

Si vous connaissez la personne à qui vous souhaitez envoyer des messages temporaires sécurisés, que vous l'envoyez souvent, que vous vous attendez à une interface de type chat et/ou que vous pouvez vous attendre à ce que le destinataire dispose du logiciel requis et sache comment l'utiliser, ce site Web n'est probablement pas le meilleure solution. Il existe d'excellentes options open source, prenant en charge E2EE, non basées sur le Web, et même certaines, comme Signal , prenant également en charge les messages temporaires. J'utilise personnellement un serveur XMMP privé et OMEMO pour discuter avec des amis proches et la famille. L'utilisation de ce site n'est optimale que si vous ne savez pas quel logiciel le destinataire exécute, si vous ne connaissez pas son numéro de téléphone/son pseudonyme, si vous ne connaissez pas ses compétences techniques (mais supposez qu'il peut cliquer sur un lien), ou vous préférez simplement garder le message que vous envoyez en dehors du transport de communication sous-jacent.

Quelles exigences existent ?

Un navigateur Web moderne et à jour qui implémente correctement les normes, y compris l'API Web Crypto, est requis. Les exemples incluent : Chrome, Firefox, Edge et Safari (vers 2020 ou après).

Le destinataire peut-il faire une copie du message ?

Oui. Même si le message peut se supprimer lors de la récupération, le destinataire peut toujours afficher le message. Chaque fois que le destinataire peut voir complètement le message, une copie peut être faite - ceci s'applique à toutes les communications. Il existe une option pour rendre plus difficile pour le destinataire de faire une copie. Dans ce cas, trois obstacles à la copie sont mis en œuvre :

Cependant, ces protections contre la copie sont faibles car elles peuvent être contournées. En outre, le destinataire peut toujours simplement prendre une capture d'écran ou une photo du message.

Des informations personnelles sont-elles collectées ?

Nous ne prenons pas en charge les comptes d'utilisateurs (c'est-à-dire nom d'utilisateur/mot de passe). Nous ne recueillons aucune information pouvant vous identifier (c'est-à-dire nom/adresse/e-mail/téléphone). Il est possible que certaines informations personnelles se trouvent dans le message que vous envoyez, mais elles sont cryptées et nous n'avons aucun moyen de les lire. Veuillez consulter notre politique de confidentialité pour plus de détails.

Quelles informations sont enregistrées ?

Notre serveur Web conserve jusqu'à 24 heures de format de journal commun sur toutes les activités Web. Cela inclut la journalisation de l'adresse IP complète des clients HTTP. Après 24 heures, ces informations enregistrées sont supprimées automatiquement. Toutes les requêtes envoyées à /api sont POSTées, ce qui signifie qu'aucune information spécifique au message n'est jamais enregistrée par le serveur Web. De plus, toute information enregistrée dans la base de données est effectivement enregistrée. Toutes les entrées de la base de données, y compris les adresses IP anonymisées et hachées, ont un délai d'expiration (TTL) après lequel elles sont automatiquement supprimées. Les délais d'expiration TTL varient entre 1 minute et 2 semaines.

Que faites-vous pour sécuriser les serveurs ?

La sécurité du serveur est une préoccupation évidente. Nous nous concentrons sur deux domaines principaux pour assurer sa sécurité :

Quels sont les risques de sécurité présents lors de l'utilisation de ce site ?

Avant d'aborder spécifiquement certains de ces risques, je pense qu'une analogie semi-brève pourrait aider à résumer les risques liés à l'utilisation de toute communication Internet. Visualisez que tout système n'est aussi sûr que le maillon le plus faible d'une chaîne. Imaginez maintenant un scénario où il y a deux personnes dans une pièce scellée sans aucun moyen de voir, d'entendre ou d'enregistrer tout ce qu'elles font. L'un passera un message à l'autre qui à la lecture du message le brûlera. Si quelqu'un à l'extérieur de cette pièce souhaite obtenir le message qui a déjà été transmis, cela va être difficile. Quel est le maillon faible pour obtenir le message ? Il n'y a pas beaucoup de maillons parmi lesquels choisir - c'est une chaîne assez courte. Imaginez maintenant que lorsque vous envoyez un message sur Internet, il y a au moins un million de maillons dans la chaîne - dont beaucoup sont faibles - beaucoup d'entre eux complètement hors de votre contrôle - et c'est la réalité.

L'utilisation du cryptage peut grandement aider à résoudre le problème du million de liens ci-dessus et il est facile de se laisser convaincre que les systèmes E2EE bien conçus offrent la solution ultime. Cependant, cette réflexion peut vous causer des ennuis, car un attaquant s'attaquera généralement aux maillons les plus faibles du système. Par exemple, il est probablement beaucoup plus facile de prendre en charge votre téléphone ou votre ordinateur et de configurer un enregistreur d'entrée pour simplement lire tout ce que vous tapez que de déchiffrer des messages cryptés sur le fil. L'essentiel est que si j'étais chargé de communiquer un secret d'importance vitale/critique, je n'utiliserais les communications électroniques qu'en dernier recours.

Il existe donc des risques de sécurité à l'aide de toutes les communications, mais vous utilisez toujours un navigateur Web pour effectuer des opérations bancaires, acheter des choses, envoyer des e-mails, etc. C'est un risque accepté pour les énormes commodités acquises. Vraiment la question est... quels risques de sécurité sont semi-spécifiques à ce site ? Quelques-uns me viennent à l'esprit :

Que faites-vous contre les attaques de l'homme du milieu (MITM) ?

Tous les utilisateurs de sites Web peuvent potentiellement être victimes d'une attaque MITM - ce site n'est pas différent de tous les autres sur le Web à cet égard. Une attaque MITM se produit lorsqu'un attaquant est capable d'intercepter et de modifier les communications entre le navigateur de l'utilisateur et le serveur Web du site. Cela permet à l'attaquant de modifier n'importe quel code/contenu du site tout en apparaissant toujours à l'utilisateur final comme étant le site auquel il est habitué. Nous prenons certaines mesures pour rendre une attaque MITM plus difficile :

Cependant, une attaque MITM est toujours possible, en particulier si l'attaquant contrôle l'infrastructure réseau/clé publique, comme ce serait le cas pour les grandes organisations ou les gouvernements puissants. Nous proposons des extensions de navigateur qui peuvent aider à atténuer certains risques MITM.

Quels avantages offrent les extensions de navigateur ?

Nous proposons des extensions de navigateur comme moyen de fournir une commodité et une sécurité supplémentaires. Autrement dit... Les extensions rendent l'envoi de messages temporaires plus rapide et plus facile. Une certaine sécurité est également acquise car tout le code utilisé pour crypter et préparer un message est stocké localement dans l'extension. Comme le code est stocké localement, cela offre à l'expéditeur une certaine protection contre les attaques MITM . Cependant, il convient de souligner que si les extensions offrent plus de protection contre une attaque MITM qui compromet le contenu du message, une attaque MITM pourrait toujours être efficace (c'est-à-dire pour déterminer l'adresse IP de l'expéditeur si vous n'utilisez pas TOR/VPN/etc.).

Comment puis-je savoir avec certitude que tout ce qui est soumis est chiffré de bout en bout ?

Contrairement à de nombreux autres clients de discussion cryptés de bout en bout (E2EE) populaires, il est assez simple de voir exactement ce qui nous est envoyé lorsque vous soumettez un message. Le didacticiel vidéo ci-dessous montre comment confirmer que nous n'avons aucun moyen de déchiffrer les messages envoyés au serveur.

De plus, si vous y réfléchissez, tant que nous ne sommes pas une agence secrète essayant de collecter des messages sensibles, il n'y a aucun avantage pour nous à pouvoir déchiffrer les messages car cette capacité ne fait que nous créer des problèmes. Nous ne voulons même pas stocker des messages - c'est un mal nécessaire pour les livrer cependant.

Comment fonctionne le cryptage de bout en bout sur ce site ?

À l'heure actuelle, nous utilisons un cryptage symétrique (AES-GCM 256 bits) avec des clés dérivées de mots de passe (au moins 150 000 itérations de PBKDF2/SHA-256). Le cryptage asymétrique n'est pas utilisé car des exigences existent pour 1) l'expéditeur initiant la communication 2) l'expéditeur et le destinataire ne sont pas en ligne en même temps et 3) aucune information sur le destinataire et 4) nous essayons de garder les choses vraiment simples et la gestion des clés est compliqué. L'API Web Crypto standard est utilisée pour toutes les fonctionnalités cryptographiques, y compris RNG. En gros, voici ce qui se passe :

  1. L'utilisateur final choisit un mot de passe ou un mot de passe est généré automatiquement
  2. Un appel API est effectué pour obtenir le nombre d'itérations PBKDF2/SHA-256 requis (cette étape est requise pour le contrôle du spam )
  3. Un sel de 32 octets est généré
  4. Une clé est dérivée du sel et du mot de passe
  5. Un vecteur d'initialisation de 12 octets (IV) est généré
  6. Le message est crypté à l'aide de la clé + IV
  7. Le nombre d'itérations, le sel, l'IV et le texte chiffré sont envoyés au serveur (avec d'autres informations telles que TTL, RTL, etc.)
  8. Le serveur renvoie un identifiant aléatoire faisant référence au message
  9. Le navigateur présente alors à l'utilisateur final un lien qui contient l'identifiant et le mot de passe renvoyés ou un lien sans le mot de passe (auquel cas le destinataire doit connaître et saisir le mot de passe)
  10. Si le mot de passe fait partie du lien, il est dans le hash de l'URL, et donc jamais envoyé au serveur lorsque le destinataire fait la requête GET
  11. Le destinataire est invité s'il souhaite déchiffrer et afficher le message
  12. Le navigateur fait une requête en précisant l'ID du message
  13. Si l'expéditeur exige qu'un CAPTCHA soit rempli, le destinataire est dirigé vers une autre URL pour prouver qu'il est humain (une fois qu'il a réussi, il est redirigé).
  14. Le serveur envoie le message crypté et supprimera par défaut le message à ce stade si le reads-to-live (RTL) est un
  15. Le destinataire déchiffrera le message avec le mot de passe (et sera invité à saisir le mot de passe s'il n'est pas dans l'URL)
Cette configuration est extrêmement simple et offre le cryptage des messages de l'appareil de l'expéditeur à l'appareil du destinataire, mais n'a bien sûr pas la garantie que le cryptage asymétrique peut offrir en termes de savoir que seule une personne en possession de la clé privée du destinataire peut déchiffrer le message. Toute personne disposant du lien peut ouvrir le message dans le scénario par défaut dans lequel le mot de passe fait partie de l'URL - cela souligne l'importance d'utiliser un moyen de transport approprié pour le lien (c'est-à-dire e-mail/chat/texte/etc.) - une décision laissée au expéditeur. Nous pouvons, s'il y a un intérêt, également déployer la prise en charge d'un schéma asymétrique très basique dans lequel le destinataire initie une demande de message et envoie ce lien de demande à l'expéditeur du message. Cette configuration éliminerait le besoin d'avoir le mot de passe dans l'URL, mais élimine également la possibilité pour l'expéditeur d'initier.

Le mot de passe de décryptage peut être dans l'URL ?

Oui. Cela impacte évidemment la sécurité car si la méthode utilisée pour envoyer le lien n'est pas sécurisée, le message est non sécurisé par association. Toutes les solutions de contournement pour éliminer ce problème introduisent des étapes et des complexités supplémentaires qui ont un impact sur l'expérience utilisateur (c'est-à-dire que les choses doivent être configurées aux deux extrémités avant d'envoyer le message). Un schéma asymétrique dans lequel le destinataire initie une demande de message et envoie ce lien de demande pourrait fonctionner avec notre exigence de clé "tout est éphémère" - cela peut être mis en œuvre. En fin de compte, si deux parties s'envoient fréquemment des messages, de meilleures solutions existent en supposant que les deux parties peuvent gérer en utilisant ces solutions.

Mais le mot de passe de déchiffrement n'a pas à être dans l'URL ?

Correct. Si le mot de passe de déchiffrement n'est pas inclus dans le lien, le destinataire sera invité à saisir le mot de passe. Si le mot de passe est communiqué de manière sécurisée au destinataire (ou s'il le connaît déjà), cela offre une protection contre l'interception. Cependant, l'inconvénient est que le destinataire doit connaître et saisir correctement le mot de passe. Voici une façon d'envoyer le mot de passe au destinataire qui offre une certaine protection contre l'interception :

  1. Chiffrez le mot de passe dans un message avec les paramètres par défaut et envoyez ce lien au destinataire.
  2. Lorsque le destinataire clique sur le lien et décrypte le message, il sait que personne d'autre n'a obtenu le mot de passe avant lui car le message contenant le mot de passe est supprimé lors de la récupération. Cependant, s'il y a une attaque MITM active ou si votre appareil ou l'appareil du destinataire a été compromis, il est toujours possible qu'une autre partie puisse obtenir le mot de passe.
  3. Confirmez avec le destinataire qu'il a bien obtenu le mot de passe. Par exemple, si le destinataire vous informe que lorsqu'il est allé récupérer le mot de passe, que le message avait déjà été supprimé, alors vous savez que quelqu'un d'autre a obtenu le mot de passe avant le destinataire et que le mot de passe est donc compromis et ne doit pas être utilisé.
  4. En utilisant le mot de passe que le destinataire a confirmé qu'il possède, vous pouvez maintenant envoyer un message en utilisant le même mot de passe pour le cryptage - partagez simplement la version du lien qui ne contient pas le mot de passe.

C'est correct - nous générons le lien et laissons à l'expéditeur la meilleure façon de le remettre au destinataire. L'objectif de ce service est de fournir une option offrant moins de permanence dans les transports de messages existants comme les e-mails/chat/texto/etc. Par conséquent, on s'attend à ce que le lien que nous générons qui pointe vers le message temporaire soit envoyé via un transport de message existant. Cela a des implications de sécurité que les utilisateurs doivent comprendre. Prenons l'exemple d'un SMS, car il s'agit d'une méthode de communication assez peu sûre. Lorsque vous utilisez ce service pour envoyer un lien de message temporaire via un message texte, si vous utilisez le mode par défaut où le mot de passe est inclus dans le lien, toute personne disposant du lien peut lire le message et aucune protection contre l'interception n'est offerte. Ce service fournit toujours une communication plus temporaire qui peut améliorer la confidentialité et la sécurité. De plus, vous pouvez choisir d'envoyer le lien sans mot de passe et cela fournira une protection contre l'interception.

Comment puis-je protéger au maximum ma vie privée en utilisant ce service ?

Comme discuté ailleurs dans cette FAQ, même si nous faisons déjà beaucoup pour protéger votre vie privée et même si nous ne collectons aucune information personnelle, certaines informations liées aux journaux sont soumises et collectées par nous et d'autres grâce à votre utilisation d'un navigateur Web. Cependant, il existe plusieurs façons de protéger encore plus votre vie privée. L'une des méthodes d'utilisation gratuite, basée sur un logiciel open source et qui fonctionne très bien, consiste à utiliser le navigateur Tor . Ce navigateur est conçu pour protéger votre vie privée à plusieurs niveaux, y compris en utilisant le réseau Tor . Notre site est déjà accessible via le réseau Tor onion, ce qui signifie que l'accès à notre site via Tor ne nécessite pas l'utilisation d'un nœud de sortie, ce qui empêche quelqu'un d' écouter le trafic du nœud de sortie . Cependant, gardez à l'esprit que même dans ce scénario, votre FAI peut voir que vous utilisez Tor - mais pas pour quoi. Vous pouvez même vous connecter à un VPN, puis lancer le navigateur Tor pour deux couches d'anonymat ; Cependant, gardez à l'esprit que votre FAI peut toujours voir que vous utilisez un VPN dans ce scénario - mais pas pour quoi. Si vous ne voulez pas que votre FAI sache quels protocoles vous utilisez, vous pouvez vous connecter à un grand réseau WiFi public tel qu'une bibliothèque, une école, etc., puis utiliser le navigateur Tor.

Et si je ne fais pas confiance aux États-Unis ?

Nos serveurs sont situés aux États-Unis. De plus, notre fournisseur de CDN, Cloudflare, est une société basée aux États-Unis. Nous avons essayé de supprimer le besoin de nous faire confiance ou de faire confiance au pays dans lequel nos serveurs résident simplement parce que nous ne collectons pas d'informations personnelles, ne pouvons déchiffrer aucun message et tout est supprimé peu de temps après sa réception. Cependant, on peut comprendre une certaine méfiance puisqu'il est basé sur le web et surtout si vous habitez dans certains pays. Nous prévoyons d'offrir des options en Islande et en Suisse pour les personnes qui ont du mal à faire confiance aux États-Unis. S'il vous plaît laissez-nous savoir si cela s'applique à vous, car nous ne serons pas motivés à proposer des alternatives à moins qu'il n'y ait une réelle demande.

Que faites-vous pour empêcher le spam ?

Chaque fois que vous autorisez quelqu'un à publier un message pouvant être relayé via un lien, vous invitez les spammeurs. Enrayer ce problème n'est pas tout à fait simple. Nous ne souhaitons pas charger un CAPTCHA tiers dans le cadre du processus d'envoi de message pour plusieurs raisons :

Nous pourrions éventuellement contourner le problème de l'API en utilisant un système de clé API, mais nous devons ensuite collecter des informations sur les utilisateurs, ce que nous ne voulons pas faire. De plus, qu'est-ce qui empêche les spammeurs d'obtenir beaucoup de clés API ? Nous ne pouvons pas examiner les messages pour en déduire leur caractère indésirable (ce qui est au mieux très problématique) car, outre le cryptage des messages, nous avons une politique de non-intervention sur le contenu des messages. Compte tenu de ces exigences, nous utilisons deux méthodes pour empêcher le spam : Si vous savez que des spammeurs abusent de ce service, veuillez déposer un rapport d'abus .

Pourquoi existe-t-il une option pour exiger que le destinataire remplisse un CAPTCHA ?

S'il est vrai que nous n'aimons pas les CAPTCHA, nous reconnaissons qu'ils servent un but et qu'ils ont un temps et un lieu (au moins pour le moment). C'est un moyen simple pour l'expéditeur de s'assurer que le destinataire est humain et que les processus automatisés n'accèdent pas au message.

Qui gère ce service et pourquoi est-il gratuit ?

Nous ne sommes que quelques gars qui ont parfois été confrontés à la situation difficile de ne pas avoir de bonnes options pour aider à protéger notre vie privée. Souvent, cela résultait de la communication avec des amis et des membres de la famille qui ne faisaient pas très attention à la façon dont ils géraient leurs appareils et leurs informations. D'autres fois, cela se produisait lors de l'utilisation de forums Web comme Reddit ou de l'utilisation de systèmes de support Web. Nous avons trouvé des solutions de messagerie temporaire basées sur le Web, mais aucune n'offrait E2EE, ce qui signifiait que nous ne pouvions pas leur faire confiance. Nous avons donc juste construit notre propre solution et décidé de la donner pour que d'autres puissent en bénéficier.

Comment puis-je me fier aux réponses aux questions ci-dessus ?

Vraiment, vous ne devriez pas faire confiance à un site Web simplement parce qu'il dit certaines choses - c'est généralement une bonne idée de vérifier toute affirmation. Nous avons essayé de supprimer l'exigence de nous faire confiance autant que possible en utilisant un cryptage de bout en bout. Par exemple, il est assez facile de vérifier que nous ne pouvons lire aucun message car ils sont cryptés . Nous avons également gardé le code javascript exécutant ce site très simple afin qu'il soit facile à lire et à comprendre. Rendre tout le code open source permet aux gens de vérifier ce qui fonctionne ; Cependant, gardez à l'esprit qu'il n'y a aucun moyen de vraiment vérifier ce que le serveur exécute. S'il est vrai qu'une grande partie de l'exigence de confiance est supprimée avec le cryptage de bout en bout, cela reste un facteur que nos utilisateurs pèsent beaucoup lorsqu'ils décident d'utiliser ou non ce service.