Questions fréquemment posées
- Pourquoi ce site est-il mal traduit ? ⎃
- Dans quelle mesure ce service est-il sécurisé ?
- Pourquoi ai-je reçu un lien ici avec une option pour déchiffrer un message ?
- Vous supprimez tout soumis à ce site?
- Pourquoi utiliser ce service ?
- Est-ce un service de messagerie ?
- Quels sont les cas d'utilisation prévus ?
- A quoi ne doit pas servir ce service ?
- Pourquoi ne pas simplement utiliser PGP/Signal/OMEMO/Matrix/etc. ?
- Quelles exigences existent ?
- Le destinataire peut-il faire une copie du message ?
- Des informations personnelles sont-elles collectées ?
- Quelles informations sont enregistrées ?
- Que faites-vous pour sécuriser les serveurs ?
- Quels sont les risques de sécurité présents lors de l'utilisation de ce site ?
- Que faites-vous contre les attaques de l'homme du milieu (MITM) ?
- Quels avantages offrent les extensions de navigateur ?
- Comment puis-je savoir avec certitude que tout ce qui est soumis est chiffré de bout en bout ?
- Comment fonctionne le cryptage de bout en bout sur ce site ?
- Le mot de passe de décryptage peut être dans l'URL ?
- Mais le mot de passe de déchiffrement n'a pas à être dans l'URL ?
- Ce service ne délivre pas le lien au destinataire ?
- Comment puis-je protéger au maximum ma vie privée en utilisant ce service ?
- Et si je ne fais pas confiance aux États-Unis ?
- Que faites-vous pour empêcher le spam ?
- Pourquoi existe-t-il une option pour exiger que le destinataire remplisse un CAPTCHA ?
- Qui gère ce service et pourquoi est-il gratuit ?
- Comment puis-je me fier aux réponses aux questions ci-dessus ?
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 :
- Bien que nous ne puissions pas lire votre message en raison du cryptage de bout en bout , le lien par défaut généré contient le mot de passe/clé de décryptage ; et par conséquent, toute personne en possession du lien peut lire votre message - y compris toute personne capable de l'intercepter.
- Ce service n'est qu'un outil permettant d'envoyer des communications moins permanentes (c'est-à-dire des messages cryptés qui sont supprimés lors de la récupération) via des transports traditionnels plus permanents (c'est-à-dire email/texte/messagerie instantanée/site web/etc.). Cela signifie que tous les problèmes de sécurité/confidentialité inhérents au transport choisi (c'est-à-dire l'e-mail) sont hérités lorsque vous utilisez cet outil .
- Il existe d' autres solutions disponibles qui offrent une meilleure sécurité en fonction de vos besoins et de votre environnement. Le principal avantage que ce service offre par rapport aux autres, est des exigences beaucoup plus faibles pour le destinataire (c.
- Bien que le paramètre par défaut consiste à supprimer les messages lors de la récupération, rien n'empêche le destinataire d'effectuer une copie . Gardez à l'esprit que cela s'applique à toutes les solutions de messages temporaires - si le destinataire peut voir le message, il peut être copié.
- Toutes les communications Internet peuvent compromettre votre vie privée - vous échangez une certaine sécurité pour plus de commodité.
- Le Web est un environnement difficile en matière de sécurité en raison de problèmes fondamentaux - cela s'applique à tous les sites Web. Cependant, le fait d'être basé sur le Web facilite grandement la vérification de notre affirmation selon laquelle nous ne pouvons pas lire votre message .
- Ce site Web et sa base de données sont hébergés aux États-Unis. Nous utilisons Cloudflare, une société basée aux États-Unis, comme réseau de diffusion de contenu (tout le trafic Web traverse ce réseau).
- L'utilisation du service ne nécessite aucune information personnelle (c'est-à-dire nom/email/téléphone/etc.). Il n'y a pas de système de compte (c'est-à-dire login/mot de passe/etc.); par conséquent, toute violation de données ne peut pas divulguer ces informations.
- Tout le contenu des messages est chiffré de bout en bout . En d'autres termes, la clé/mot de passe de déchiffrement ne nous est jamais envoyé. Par conséquent, nous, ou toute autre personne en possession de la base de données, n'avons aucun moyen de décrypter et d'afficher le contenu du message.
- Chaque entrée dans notre base de données a une durée de vie allant de 1 minute à 2 semaines (par défaut à 1 semaine). Passé ce délai, l'enregistrement est automatiquement supprimé. Par conséquent, toute information de notre base de données sera supprimée peu de temps après sa création .
- Nous ne conservons que les dernières 24 heures des journaux du serveur Web . Toutes les informations IP stockées dans la base de données sont hachées de manière sécurisée, ce qui rend impossible l'extraction de l'adresse IP d'origine.
- Tout le code alimentant ce service est open source et disponible pour examen. Vous pouvez facilement voir le code qui exécute le cryptage - qui est volontairement court, concis et commenté.
- Un certain nombre de précautions techniques sont prises pour aider à renforcer la sécurité, parmi lesquelles :
- L'ensemble de ce site Web autre que /api est statique et ne prend pas en charge le code serveur dans les pages (c'est-à-dire PHP/JSP/ASP/etc.)
- L' API Web Crypto , qui fait partie du navigateur, est utilisée pour crypter tout le contenu des messages.
- TLS est utilisé pour crypter les communications entre votre navigateur et nos serveurs. Cela permet de s'assurer que le code ne peut pas être intercepté ou modifié en transit. TLS 1.3 est pris en charge, mais nous prenons également en charge TLS 1.2 pour les appareils plus anciens. Les anciennes versions de TLS sont désactivées car elles ne sont pas aussi sécurisées.
- Les journaux de transparence des certificats sont surveillés pour les erreurs d'émission de certificats. De plus, nous publions une politique d'autorisation de l'autorité de certification (CAA) pour réduire le risque d'émission incorrecte de certificats involontaires ou malveillants.
- Nous utilisons HTTP Strict Transport Security (HSTS) pour garantir que les navigateurs communiquent toujours avec nos serveurs à l'aide du protocole TLS. De plus, nous incluons nos domaines dans les listes de préchargement .
- Une politique stricte de sécurité du contenu est appliquée pour empêcher les attaques de type Cross Site Scripting (XSS) .
- En utilisant une politique de ressources d' origine croisée , une politique d'intégration d'origine croisée et une politique d'ouverture d' origine croisée , nous interdisons le code d'origine croisée afin d'atténuer les attaques spéculatives par canal secondaire comme Spectre et Meltdown. Cela offre également une protection contre les demandes potentiellement malveillantes provenant d'autres origines en isolant le contexte de navigation exclusivement aux documents de même origine.
- Nous utilisons une politique d'autorisation pour empêcher le navigateur de charger des ressources qui pourraient compromettre votre vie privée, telles que votre emplacement, votre webcam, votre microphone, etc.
- DNSSEC est utilisé sur tous nos domaines pour aider à atténuer les attaques MITM basées sur DNS.
- Nous prenons un certain nombre de précautions pour sécuriser le serveur.
- Aucun code tiers n'est chargé (c'est-à-dire jQuery) et très peu de ressources sont chargées (allez-y et ouvrez l'onglet Réseau dans Dev Tools pour vérifier) - cela minimise l'effort requis pour l'audit. La seule exception est si un CAPTCHA est requis - qui charge le code tiers à partir de hCaptcha . Cependant, le code hCaptcha se charge sur sa propre URL à l'intérieur de ses propres règles CSP et n'a à aucun moment accès à quoi que ce soit ayant à voir avec un message.
- Afin de se prémunir contre les attaques MITM , des extensions de navigateur sont disponibles .
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 :
- Il est probable que le message sera supprimé immédiatement après son envoi à votre appareil pour déchiffrement. Cela signifie qu'après avoir cliqué sur le bouton pour déchiffrer le message, nous n'avons plus de copie à vous renvoyer ultérieurement.
- Nous supprimons systématiquement toutes les informations reçues. Les messages seront supprimés n'importe où entre une minute et deux semaines après leur création, que le message soit déchiffré ou non. En d'autres termes, si vous avez besoin de lire le message, n'attendez pas trop longtemps pour le déchiffrer.
- L'expéditeur pense probablement que le contenu du message doit être traité avec précaution. Ils ont peut-être même indiqué qu'ils ne voulaient pas de copies. Merci de respecter leurs souhaits.
- Si vous êtes invité à saisir un mot de passe pour déchiffrer un message, ne fermez pas la fenêtre/l'onglet du navigateur. Selon le premier point de cette liste, il est probable que nous ne puissions pas envoyer une autre copie plus tard. Laissez simplement la fenêtre/l'onglet du navigateur ouvert jusqu'à ce que vous puissiez saisir le mot de passe. Si vous entrez un mot de passe incorrect, vous serez à nouveau invité. Le mot de passe doit être saisi avec précision. Gardez à l'esprit qu'afin de répondre aux différentes exigences en matière de langues et de mots de passe, nous acceptons de nombreux caractères différents dans les mots de passe.
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 :
- Messages cryptés dont nous n'avons aucun moyen de décrypter le contenu
- D'autres informations inhérentes à la soumission de quoi que ce soit sur le Web (c'est-à-dire votre adresse IP, etc.)
- Combien de temps devons-nous conserver le message si personne ne le récupère (allant de 1 minute à 2 semaines - la valeur par défaut est 1 semaine).
- Combien de fois le message est récupéré (allant de 1 à 100 fois - la valeur par défaut est 1 fois)
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 :
- Vous avez communiqué via un forum Web local sur les sentiers de vélo de montagne dans la région et vous rencontrez parfois des personnes sur le forum pour découvrir ensemble de nouveaux sentiers. Quelqu'un du forum veut venir vous chercher chez vous pour faire du covoiturage vers un trail ce week-end. Vous ne voulez pas que votre adresse domiciliaire reste pour toujours dans cette base de données de forum de site Web. Envoyez simplement l'adresse via ce service - le lien est ce qui réside dans la base de données du forum du site Web, mais une fois lu par le destinataire, le message/l'adresse est supprimé.
- Vous devez envoyer à votre frère votre identifiant Netflix car votre nièce le rend fou à cause du verrouillage de COVID et il n'a toujours pas son propre compte. Vous ne vous souciez pas trop de cette connexion, mais votre frère est particulièrement mauvais dans ce que j'appellerai simplement "l'hygiène numérique" et a eu de nombreux essais avec des connexions compromises et des logiciels malveillants. Les tentatives ultérieures pour l'amener à nettoyer son acte et même à installer une messagerie sécurisée pour lui n'ont pas réussi. Le simple fait de l'envoyer par SMS est probablement la meilleure option (malheureusement), mais vous n'êtes pas à l'aise de voir cette connexion figurer dans l'historique de ses messages en raison de l'expérience passée. L'utilisation de ce service pour envoyer la connexion via un lien dans un message texte permet de ne pas laisser la connexion traîner pour toujours dans son historique de discussion.
- Vous travaillez parfois dans un bureau qui a de nombreux locataires partagés qui vont et viennent à toute heure. Le WiFi est disponible, mais le mot de passe change chaque semaine car il y a eu des problèmes d'abus. De nombreux locataires envoient un e-mail/un SMS pour demander le mot de passe WiFi même s'il se trouve à la réception, car la plupart n'entrent pas par l'entrée principale avant. En utilisant ce service, le responsable de bureau peut envoyer le mot de passe WiFi via un lien dans une réponse par e-mail/sms satisfait de ne pas laisser le mot de passe s'attarder, et permet également au destinataire de copier immédiatement le mot de passe via un bouton de copie qui est moins maladroit sur les appareils mobiles.
- L'un de vos fournisseurs d'hébergement vous demande des détails sur un serveur qui, selon vous, montre des signes d'un disque dur qui semble mal fonctionner. Certaines des informations dont ils ont besoin sont un peu sensibles - vous ne voulez pas qu'elles restent indéfiniment dans le système de tickets tiers qu'ils utilisent. En utilisant ce service, vous pouvez envoyer les informations aux techniciens de support sans qu'elles ne résident dans le système de tickets. Étant donné que plusieurs techniciens peuvent avoir besoin de se référer aux informations plusieurs fois, définissez des lectures en direct supérieures à 1 (c'est-à-dire peut-être 20) afin que le message ne soit pas supprimé lors de la première récupération.
- Vous devez envoyer un message privé à un autre utilisateur sur Reddit pour lui faire connaître votre numéro de téléphone afin qu'il puisse vous appeler. Reddit, comme de nombreux autres fournisseurs, a divulgué des informations sur les utilisateurs dans le passé et vous ne voulez pas que votre numéro de téléphone reste dans la base de données de Reddit pendant des années jusqu'à la prochaine fuite. Envoyez simplement votre numéro de téléphone via ce service.
- Votre conjoint vous envoie un message pendant que vous êtes au travail pour demander la connexion au service public, car son amie vient d'essayer un nouveau programme qui lui a permis d'économiser de l'argent sur sa facture d'électricité et elle veut le vérifier. Vous lui rappelez un gestionnaire de mots de passe familiaux partagés, mais elle souhaite simplement que vous lui envoyiez le login. OMEMO est utilisé pour la messagerie instantanée avec votre conjoint et vous vous sentez donc très confiant que le transport des messages est sécurisé ; cependant, l'historique de discussion lui-même est stocké non chiffré. Votre conjoint n'est pas toujours prudent avec les téléchargements, les e-mails, etc. et les factures de services publics sont un peu sensibles car elles peuvent être utilisées pour le vol d'identité afin de prouver la résidence. Vous pouvez lui envoyer les informations de connexion en utilisant ce service pour éviter qu'une copie ne soit stockée sur son ordinateur.
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 :
- N'utilisez pas ce service pour rendre "plus sûr" un transport de message inapproprié. Étant donné que le paramètre par défaut consiste à inclure le mot de passe dans l'URL qui peut lire le message, toute personne disposant du lien peut lire le message. Comme mentionné ci-dessus, tous les problèmes de sécurité/confidentialité inhérents au transport choisi (c'est-à-dire un texte) sont hérités lorsque vous utilisez cet outil. Ainsi, par exemple, si vous n'envisagez jamais d'utiliser le courrier électronique pour envoyer des informations spécifiques en raison de sa nature sensible, vous ne devez pas utiliser ce service pour « sécuriser » cette partie du courrier électronique.
- N'utilisez pas ce service pour vous assurer qu'aucune copie n'est faite du message. Ce n'est pas parce que nous supprimons notre copie du message crypté dès sa récupération et que nous le rendons plus difficile à copier, cela ne signifie pas que le message ne peut pas être copié. Et si le destinataire prenait une photo de son écran ? Et s'ils écrivaient simplement le message ? En fin de compte, si le destinataire peut lire le message, une copie peut être faite.
- N'utilisez pas ce service pour vous assurer qu'un message ne peut pas être retracé jusqu'à vous. Ce service dépend d'un autre fournisseur de transport de messages (c'est-à-dire e-mail, chat, etc.) pour acheminer le message d'un point à un autre. Le transport de message utilisé pourrait très bien retracer le message jusqu'à vous.
- N'utilisez pas ce service pour envoyer ce que vous souhaitez refuser d'envoyer. Ce n'est pas parce que le message lui-même est supprimé que le lien pointant vers le message supprimé est supprimé. Si vous envoyez un e-mail à votre ami et qu'une partie de cet e-mail contient un lien vers un message de ce service, un lecteur occasionnel saura qu'il y avait autre chose dans le message. Même si le message auquel se réfère le lien a disparu depuis longtemps, il est clair que quelque chose d'autre a été envoyé et que c'est vous qui l'avez envoyé à votre ami.
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 :
- Le bouton Copier est supprimé. Ce bouton permet par défaut au destinataire de copier l'intégralité du message dans son presse-papiers.
- Le bouton Télécharger est supprimé. Ce bouton permet par défaut au destinataire de télécharger le message sous forme de fichier texte.
- La possibilité de sélectionner du texte dans la zone de texte du message est supprimée.
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é :
- Tout d'abord, nous stockons le moins possible pendant le moins de temps possible afin que si le serveur était compromis, aucune fuite d'informations ne serait préjudiciable à nos utilisateurs. Tous les messages stockés dans la base de données sont cryptés sans aucun moyen de les décrypter. Il n'y a rien stocké reliant un message à l'un de nos utilisateurs puisque nous ne recueillons aucune information personnelle de nos utilisateurs. Tous les enregistrements de la base de données ont un délai d'expiration (TTL) allant de 1 minute à 2 semaines - une fois ce délai écoulé, l'enregistrement est automatiquement supprimé. Par conséquent, la grande majorité des informations qui ont déjà été dans la base de données ont déjà été supprimées il y a longtemps.
- Nous prenons un certain nombre de mesures pour empêcher les compromis et contenir tout compromis qui se produit :
- Le serveur Web, nginx , est exécuté dans un conteneur isolé en tant qu'utilisateur non privilégié sans accès en écriture à autre chose que les journaux. Le conteneur s'exécute dans son propre contexte SELinux, empêchant ainsi toute modification du système de fichiers ou toute évasion facile du conteneur. Il n'y a pas de support pour PHP/ASP/JSP/etc. - juste au service des ressources statiques.
- Le code exécutant /api est écrit en Go, ce qui devrait le rendre assez résistant aux vulnérabilités de débordement de tampon (un vecteur d'attaque courant). Le processus Go s'exécute également dans un conteneur isolé en tant qu'utilisateur non privilégié sans accès en écriture à autre chose que la base de données. Le conteneur s'exécute dans son propre contexte SELinux, empêchant ainsi toute modification du système de fichiers ou toute évasion facile du conteneur. La base de données, badgerdb , fait partie du processus Go (aucune dépendance/processus de base de données externe).
- Le principal danger d'une compromission de serveur est que l'attaquant pourrait modifier les fichiers d'une manière qui compromettrait la confidentialité/la sécurité de nos utilisateurs. Un processus dédié surveille tous les fichiers du site Web pour tout changement et nous alerte immédiatement en cas de changement.
- Tous les accès administratifs sont protégés et limités aux réseaux autorisés.
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 :
- Le risque le plus important et le plus unique de ce service est peut-être que nos utilisateurs ne fassent pas preuve de bon jugement lorsqu'ils discernent entre ce qui est approprié d'envoyer et ce qui ne l'est pas . Parfois, la distinction entre « Je ne suis pas à l'aise d'envoyer ces informations par e-mail - je souhaite juste que l'e-mail soit supprimé après la lecture » et « Je ne suis pas à l'aise d'envoyer ces informations par e-mail - l'e-mail est un moyen de transport inapproprié » peut être assez subtile.
- Il y a toujours la menace que les opérateurs de ce site soient en fait de mauvais acteurs incitant les gens à utiliser le service pour obtenir un objectif final sombre. Nous rencontrons un moyen plausiblement digne de confiance - rendre tout facile et gratuit - faire en sorte que de nombreuses personnes utilisent le service - tout en avec une intention sinistre. Bwhahahahaha ! Comment pourriez-vous nous faire confiance?
- Il est possible que notre code contienne des bogues ayant un impact sur la sécurité ou que nous n'ayons tout simplement pas bien réfléchi et que nos lacunes exposent maintenant nos utilisateurs à un danger inutile. Nous espérons que non, mais nous ne pouvons pas l'exclure.
- Contrairement aux titans technologiques (c'est-à-dire Google/Facebook/Whatsapp) qui ont des térabits de données cryptées qui entrent et sortent constamment de leurs énormes réseaux, où il est facile d'intégrer des communications privées à d'autres trafics, des services centralisés autonomes (c'est-à-dire Signal, Telegram, et nous) se démarquent. Il est facile pour un opérateur de réseau ou même une grande organisation/gouvernement de voir que l'adresse IP xxxx utilise le service XYZ.
- Bien qu'elles ne soient pas vraiment spécifiques à ce site, puisqu'il peut être utilisé contre n'importe quel site Web, les attaques de l'homme du milieu (MITM) sont une préoccupation valable .
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 :
- HSTS est utilisé pour forcer les navigateurs à se connecter uniquement via TLS. Notre serveur est configuré pour ignorer les communications non TLS autres que pour rediriger. Seul TLS 1.2 ou supérieur est pris en charge.
- DNSSEC est utilisé pour signer la zone de notre domaine. Cela pourrait arrêter les attaques MITM mises en œuvre par usurpation DNS si l'utilisateur utilise un résolveur récursif compatible DNSSEC.
- Nous utilisons un service pour surveiller les autorités de certification émettant des certificats TLS non autorisés faisant référence à notre domaine.
- Nous avons publié des extensions de navigateur pour prendre en charge le cryptage des messages à l'aide du code stocké sur l'appareil de l'utilisateur final.
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 :
- L'utilisateur final choisit un mot de passe ou un mot de passe est généré automatiquement
- 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 )
- Un sel de 32 octets est généré
- Une clé est dérivée du sel et du mot de passe
- Un vecteur d'initialisation de 12 octets (IV) est généré
- Le message est crypté à l'aide de la clé + IV
- 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.)
- Le serveur renvoie un identifiant aléatoire faisant référence au message
- 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)
- 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
- Le destinataire est invité s'il souhaite déchiffrer et afficher le message
- Le navigateur fait une requête en précisant l'ID du message
- 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é).
- Le serveur envoie le message crypté et supprimera par défaut le message à ce stade si le reads-to-live (RTL) est un
- 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)
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 :
- Chiffrez le mot de passe dans un message avec les paramètres par défaut et envoyez ce lien au destinataire.
- 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.
- 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é.
- 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.
Ce service ne délivre pas le lien au destinataire ?
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 détestons les CAPTCHA - ils prennent du temps et sont ennuyeux
- Le chargement de javascript tiers peut être invasif pour la confidentialité et la sécurité
- Exécuter notre propre CAPTCHA signifie que nous nous inscrivons pour un jeu sans fin de whack-a-mole
- Finalement, les gens voudront peut-être pouvoir interagir avec ce service via l'API
- Augmenter le nombre d'itérations PBKDF2/SHA-256 requises
Tous les messages ne peuvent être récupérés qu'un petit nombre de fois - un attribut peu attrayant pour les spammeurs car ils dépendent de l'envoi de beaucoup de messages. Étant donné qu'un spammeur devrait créer beaucoup de messages pour une campagne de spam donnée, nous avons choisi de rendre cette tâche si coûteuse en termes de calcul que l'abus de ce service pour le spam est une entreprise peu attrayante. Ceci est accompli en gardant une trace des réseaux postant des messages - mesurés en termes de récupérations totales possibles. Les informations du réseau elles-mêmes sont hachées de manière sécurisée afin que nous ne puissions pas déduire le réseau réel du hachage. Lorsqu'un réseau donné publie plus de messages, nous augmentons le nombre d'itérations PBKDF2/SHA-256 nécessaires pour publier le message suivant. Cela se traduit très rapidement par un temps CPU important pour publier un seul message. Espérons que cette méthode sera adéquate pour lutter contre les abus de spam et en même temps, n'affectera pas les vrais utilisateurs. - Recueillez les rapports de spam des utilisateurs lorsqu'ils récupèrent un message
Il y a un bouton "Signaler le spam" juste en dessous du message lorsqu'un utilisateur récupère un message. Si un message est un spam, nous espérons que certains prendront les 3 secondes nécessaires pour cliquer sur ce bouton. Lorsque nous recevons un rapport de spam, il nous alerte et il a également un impact sur les itérations PBKDF2/SHA-256 requises pour un réseau donné.
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.