Häufig gestellte Fragen

Warum ist diese Seite schlecht übersetzt? ⎃

Sorry, aber die aktuellen Autoren sprechen nur Englisch. Wir brauchen Hilfe bei der Übersetzung dieses Projekts in andere Sprachen. Als einfache und kostengünstige Möglichkeit, diesen Service auch Menschen zur Verfügung zu stellen, die kein Englisch sprechen, verwenden wir maschinelle Übersetzung. Die Ergebnisse sind in der Regel akzeptabel, können aber zu seltsamen Formulierungen oder sogar völlig ungenauen Informationen führen. Sie können uns helfen, das Erlebnis für alle zu verbessern – bitte reichen Sie die korrekte Übersetzung ein .

Wie sicher ist dieser Dienst?

Wir haben viele Schritte unternommen, um diesen Dienst für die beabsichtigte Verwendung sicher zu machen. Bevor wir diese Schritte durchgehen, ist es wichtig, Folgendes zu verstehen:

Unser Ziel ist es, diesen Service auf eine Weise anzubieten, die Optionen bietet, um Ihre Privatsphäre und Sicherheit zu verbessern. Hier sind einige Schritte, die wir unternommen haben, um Ihre Daten zu schützen:

Warum habe ich hier einen Link mit der Option zum Entschlüsseln einer Nachricht erhalten?

Wir entschuldigen uns, wenn diese Übersetzung Fehler enthält . Dieser Dienst leitet einfach eine verschlüsselte Nachricht von einem Punkt zum anderen weiter und Sie sind der Empfänger. Die Nachricht wird bald gelöscht. Die Betreiber dieses Dienstes haben keine Möglichkeit, den Nachrichteninhalt zu lesen. Normalerweise verwendet jemand diesen Dienst, wenn er nicht möchte, dass der Inhalt einer Nachricht in verschiedenen Datenbanken/Geräten/Diensten/Dateien/usw. verbleibt. wie es beim Senden einer E-Mail/Instant-Nachricht/Text/usw. typisch ist. Sollten Sie sich für eine Entschlüsselung entscheiden, beachten Sie bitte Folgendes:

Sie löschen alles, was an diese Site gesendet wurde?

Getreu unserem Mülleimer-Logo... wird alles kurz nach Erhalt gelöscht. Das Löschen von allem ist automatisiert - es wird in den Server geschrieben. Stellen Sie sich das so vor - es gibt zwei Arten von übermittelten Informationen:

Bei Nachrichten können Sie steuern, wann wir sie löschen, indem Sie Folgendes angeben: Standardmäßig wird alles an einer Nachricht gelöscht, nachdem sie einmal abgerufen wurde oder 1 Woche alt ist – je nachdem, was zuerst eintritt. Wenn es darum geht, alle anderen Informationen zu löschen, die mit der Übermittlung von Inhalten im Internet verbunden sind (z. B. Ihre IP-Adresse usw.), geben wir Ihnen keine Kontrolle darüber, wann oder wie sie gelöscht werden - wir löschen einfach alle 24 Stunden .

Warum diesen Dienst nutzen?

Dieser Dienst ist ein Tool, um Nachrichten, die Sie senden/empfangen, weniger dauerhaft zu machen. Das meiste, was Sie im Internet kommunizieren (Chats, SMS, E-Mails usw.) wird gespeichert und selten gelöscht. Wenn Sie etwas löschen, wird es oft nicht wirklich gelöscht, sondern als gelöscht markiert und Ihnen nicht mehr angezeigt. Ihre aggregierte Kommunikation sammelt sich Jahr für Jahr in Datenbanken und auf Geräten an, über die Sie keine Kontrolle haben. Es ist unvermeidlich, dass eine oder mehrere der Organisationen/Personen/Geräte, die Ihre Kommunikation speichern, gehackt werden und Ihre Informationen durchsickern. Dieses Problem ist so allgegenwärtig, dass es mittlerweile viele Websites gibt, die die Organisationen verfolgen, die kompromittiert und Benutzerdaten durchgesickert sind. End-to-End-verschlüsselte temporäre Nachrichten sind eine einfache Lösung, um einige Ihrer Kommunikationen weniger dauerhaft zu machen. Jede an diese Site gesendete Nachricht hat eine Gültigkeitsdauer von 1 Minute bis 2 Wochen - nach Ablauf dieser Zeit wird die Nachricht gelöscht. Darüber hinaus ist die Standardeinstellung, jede Nachricht zu löschen, sobald der Empfänger sie abgerufen hat. Darüber hinaus werden alle Nachrichten von Ihrem Gerät bis zum Gerät des Empfängers verschlüsselt. Das Hauptziel bei der Verwendung von Ende-zu-Ende-Verschlüsselung besteht darin, unsere Fähigkeit zum Lesen aller gesendeten Nachrichten zu entfernen, wodurch ein Teil der Vertrauensanforderung aufgehoben wird. Das Endergebnis ist, dass es jetzt einfach ist, eine verschlüsselte Nachricht über einen einfachen Link zu senden. Diese Nachricht wird entweder kurz nach dem Absenden oder beim Abrufen gelöscht. Sie müssen keine spezielle Software installieren/konfigurieren. Sie müssen kein Konto erstellen oder persönliche Daten angeben. Der Empfänger muss nicht in Ihren Kontakten sein oder von diesem Service wissen – die einzige Voraussetzung, dass er auf einen Link klicken kann.

Ist das ein Messaging-Dienst?

Nein. Dieser Dienst soll bestehende Messaging-Dienste wie Instant Messaging/E-Mail/Text/usw. ergänzen. durch Hinzufügen der Möglichkeit, zu verhindern, dass gesendete Nachrichten für längere Zeit gespeichert werden. Wir liefern den generierten Link nicht an den Empfänger .

Welche Anwendungsfälle sind vorgesehen?

In welchen Szenarien ist es also angebracht, diesen Dienst zu nutzen? Während jeder andere Bedürfnisse und Anforderungen an Privatsphäre und Sicherheit hat, habe ich persönlich die folgenden Szenarien als geeignete Anwendungsfälle gefunden:

Wofür sollte dieser Dienst nicht verwendet werden?

Dieser Dienst sollte aus allen in diesen FAQ erläuterten Gründen nicht für sehr sensible Informationen verwendet werden. Nachfolgend finden Sie einige Beispiele dafür, was Sie nicht tun sollten:

Warum nicht einfach PGP/Signal/OMEMO/Matrix/etc. verwenden?

Wenn Sie die Person kennen, der Sie sichere temporäre Nachrichten senden möchten, diese häufig senden, eine chatähnliche Oberfläche erwarten und/oder erwarten können, dass der Empfänger über die erforderliche Software verfügt und damit umgeht, ist diese Website wahrscheinlich nicht die richtige beste Lösung. Es gibt großartige Optionen, die Open Source sind, E2EE unterstützen, nicht webbasiert, und sogar einige wie Signal , die auch temporäre Nachrichten unterstützen. Ich persönlich benutze einen privaten XMMP-Server und OMEMO, um mit engen Freunden und Familie zu chatten. Die Nutzung dieser Site ist möglicherweise nur dann optimal, wenn Sie nicht wissen, welche Software der Empfänger verwendet, seine Telefonnummer/Kontaktnummer nicht kennen, seine technischen Fähigkeiten nicht kennen (aber davon ausgehen, dass er auf einen Link klicken kann), oder Sie ziehen es einfach vor, die von Ihnen gesendete Nachricht außerhalb des zugrunde liegenden Kommunikationstransports zu halten.

Welche Anforderungen bestehen?

Ein moderner und aktueller Webbrowser, der Standards einschließlich der Web Crypto API ordnungsgemäß implementiert, ist erforderlich. Beispiele sind: Chrome, Firefox, Edge und Safari (ca. 2020 oder später).

Kann der Empfänger eine Kopie der Nachricht erstellen?

Ja. Auch wenn sich die Nachricht beim Abrufen möglicherweise selbst löscht, kann der Empfänger die Nachricht dennoch anzeigen. Immer wenn der Empfänger die Nachricht vollständig einsehen kann, kann eine Kopie erstellt werden - dies gilt für alle Kommunikationen. Es gibt eine Option, um dem Empfänger das Anfertigen einer Kopie zu erschweren. In diesem Fall werden drei Kopierhindernisse implementiert:

Dieser Kopierschutz ist jedoch schwach, da er umgangen werden kann. Außerdem kann der Empfänger immer nur einen Screenshot oder ein Foto der Nachricht machen.

Werden personenbezogene Daten gesammelt?

Wir unterstützen keine Benutzerkonten (zB Benutzername/Passwort). Wir sammeln keine Informationen, die Sie identifizieren können (zB Name/Adresse/E-Mail/Telefon). Es ist möglich, dass die von Ihnen gesendete Nachricht einige persönliche Informationen enthält, die jedoch verschlüsselt sind und wir nicht lesen können. Bitte lesen Sie unsere Datenschutzerklärung für vollständige Details.

Welche Informationen werden protokolliert?

Unser Webserver speichert bis zu 24 Stunden im gemeinsamen Protokollformat aller Webaktivitäten. Dazu gehört die Protokollierung der vollständigen IP-Adresse von HTTP-Clients. Nach 24 Stunden werden diese protokollierten Informationen automatisch gelöscht. Alle an /api gesendeten Anfragen werden per POST gesendet, was bedeutet, dass keine nachrichtenspezifischen Informationen vom Webserver protokolliert werden. Darüber hinaus werden alle in der Datenbank gespeicherten Informationen effektiv protokolliert. Alle Einträge in der Datenbank, einschließlich anonymisierter und gehashter IP-Adressen, haben eine Ablaufzeit (TTL), nach der sie automatisch gelöscht werden. Die Ablaufzeiten der TTL variieren zwischen 1 Minute und 2 Wochen.

Was tun Sie, um die Server zu sichern?

Die Serversicherheit ist ein offensichtliches Anliegen. Es gibt zwei Hauptbereiche, auf die wir uns konzentrieren, um die Sicherheit zu gewährleisten:

Welche Sicherheitsrisiken bestehen bei der Nutzung dieser Website?

Bevor ich einige dieser Risiken speziell anspreche, denke ich, dass eine halbkurze Analogie helfen könnte, die Risiken bei der Nutzung von Internetkommunikationen zusammenzufassen. Stellen Sie sich vor, dass jedes System nur so sicher ist wie das schwächste Glied in einer Kette. Stellen Sie sich nun ein Szenario vor, in dem sich zwei Personen in einem versiegelten Raum befinden und keine Möglichkeit haben, etwas zu sehen, zu hören oder aufzuzeichnen. Einer wird eine Nachricht an den anderen weitergeben, der sie beim Lesen der Nachricht verbrennt. Wenn jemand außerhalb dieses Raums die Nachricht erhalten möchte, die bereits weitergegeben wurde, wird das schwierig. Was ist das schwächste Glied, um die Nachricht zu erhalten? Es gibt nicht so viele Glieder zur Auswahl - es ist eine ziemlich kurze Kette. Stellen Sie sich nun vor, dass, wenn Sie eine Nachricht im Internet senden, es mindestens eine Million Glieder in der Kette gibt - viele davon schwach - viele davon völlig außerhalb Ihrer Kontrolle - und das ist die Realität.

Die Verwendung von Verschlüsselung kann bei dem oben genannten Millionen-Link-Problem sehr hilfreich sein und es ist leicht zu glauben, dass gut gestaltete E2EE-Systeme die End-All-Lösung bieten. Dieses Denken kann Sie jedoch in Schwierigkeiten bringen, da ein Angreifer normalerweise nur die schwächeren Glieder im System verfolgt. Zum Beispiel ist es wahrscheinlich viel einfacher, Ihr Telefon oder Ihren Computer zu übernehmen und einen Eingabelogger einzurichten, um einfach alles zu lesen, was Sie eingeben, als verschlüsselte Nachrichten über das Kabel zu knacken. Die Quintessenz ist, dass ich, wenn ich mit der Übermittlung eines Geheimnisses von lebenswichtiger/kritischer Bedeutung beauftragt wäre, die elektronische Kommunikation nur als letztes Mittel verwenden würde.

Es gibt also Sicherheitsrisiken bei jeder Kommunikation, aber Sie verwenden immer noch einen Webbrowser für Bankgeschäfte, Einkäufe, E-Mails usw. Es ist ein akzeptiertes Risiko für die enormen Vorteile, die Sie gewonnen haben. Die Frage ist wirklich... welche Sicherheitsrisiken sind für diese Site halbspezifisch? Ein paar fallen mir ein:

Was tun Sie gegen Man-in-the-Middle-Angriffe (MITM)?

Alle Benutzer von Websites können potenziell Opfer eines MITM-Angriffs werden - diese Site unterscheidet sich in dieser Hinsicht nicht von allen anderen im Web. Ein MITM-Angriff liegt vor, wenn ein Angreifer die Kommunikation zwischen dem Browser des Benutzers und dem Webserver der Site abfangen und ändern kann. Auf diese Weise kann der Angreifer den Code/Inhalt der Site ändern, während er dem Endbenutzer immer noch als die Site erscheint, an die er gewöhnt ist. Wir ergreifen einige Maßnahmen, um einen MITM-Angriff zu erschweren:

Ein MITM-Angriff ist jedoch immer noch möglich – insbesondere wenn der Angreifer die Netzwerk-/Public-Key-Infrastruktur kontrolliert, wie dies bei großen/einflussreichen Organisationen oder Regierungen der Fall wäre. Wir bieten Browsererweiterungen an, die dazu beitragen können, einige MITM-Risiken zu mindern.

Welche Vorteile bieten die Browsererweiterungen?

Wir bieten Browsererweiterungen an, um zusätzlichen Komfort und zusätzliche Sicherheit zu bieten. Einfach gesagt... Die Erweiterungen machen das Versenden von temporären Nachrichten schneller und einfacher. Eine gewisse Sicherheit wird auch dadurch erreicht, dass der gesamte Code, der zum Verschlüsseln und Vorbereiten einer Nachricht verwendet wird, lokal in der Erweiterung gespeichert wird. Da der Code lokal gespeichert wird, bietet dies dem Absender einen gewissen Schutz vor MITM-Angriffen . Es sei jedoch darauf hingewiesen, dass die Erweiterungen zwar mehr Schutz gegen einen MITM-Angriff bieten, der den Nachrichteninhalt kompromittiert, ein MITM-Angriff jedoch dennoch effektiv sein kann (dh die IP-Adresse des Absenders zu ermitteln, wenn nicht TOR/VPN/etc. verwendet wird).

Wie kann ich sicher sein, dass alles gesendete Ende-zu-Ende verschlüsselt ist?

Im Gegensatz zu vielen anderen beliebten Ende-zu-Ende-verschlüsselten (E2EE) Chat-Clients ist es ziemlich einfach zu sehen, was genau an uns gesendet wird, wenn Sie eine Nachricht senden. Das folgende Video-Tutorial zeigt, wie Sie bestätigen können, dass wir keine Möglichkeit haben, an den Server gesendete Nachrichten zu entschlüsseln.

Auch wenn Sie darüber nachdenken, solange wir keine Geheimagentur sind, die versucht, sensible Nachrichten zu sammeln, hat es keinen Vorteil, Nachrichten zu entschlüsseln, da diese Fähigkeit uns nur Probleme bereitet. Wir wollen nicht einmal Nachrichten speichern - es ist jedoch ein notwendiges Übel, sie zu übermitteln.

Wie funktioniert die Ende-zu-Ende-Verschlüsselung auf dieser Seite?

Derzeit verwenden wir symmetrische Verschlüsselung (AES-GCM 256bit) mit Schlüsseln, die von Passwörtern abgeleitet werden (mindestens 150.000 Iterationen von PBKDF2/SHA-256). Eine asymmetrische Verschlüsselung wird nicht verwendet, weil Anforderungen bestehen für 1) Sender, der die Kommunikation initiiert, 2) Sender und Empfänger nicht gleichzeitig online sind und 3) keine Informationen über den Empfänger und 4) wir versuchen, die Dinge wirklich einfach zu halten und die Schlüsselverwaltung ist kompliziert. Die Standard-Web-Crypto-API wird für alle kryptografischen Funktionen einschließlich RNG verwendet. Im Wesentlichen passiert Folgendes:

  1. Der Endbenutzer wählt ein Passwort oder eines wird automatisch generiert
  2. Ein API-Aufruf wird durchgeführt, um die Anzahl der erforderlichen PBKDF2/SHA-256-Iterationen zu erhalten ( dieser Schritt ist für die Spam-Kontrolle erforderlich ).
  3. Es wird ein 32 Byte Salt erzeugt
  4. Aus Salt und Passwort wird ein Schlüssel abgeleitet
  5. Ein 12-Byte- Initialisierungsvektor (IV) wird erzeugt
  6. Die Nachricht wird mit dem Schlüssel + IV verschlüsselt
  7. Der Iterationszähler, Salt, IV und Chiffretext werden an den Server gesendet (zusammen mit einigen anderen Informationen wie TTL, RTL usw.)
  8. Der Server gibt eine zufällige ID zurück, die sich auf die Nachricht bezieht
  9. Der Browser präsentiert dem Endbenutzer dann einen Link, der die zurückgegebene ID und das Passwort enthält, oder einen Link ohne das Passwort (in diesem Fall muss der Empfänger das Passwort kennen und eingeben).
  10. Wenn das Passwort Teil des Links ist, befindet es sich im URL-Hash und wird daher nie an den Server gesendet, wenn der Empfänger die GET-Anfrage stellt
  11. Der Empfänger wird gefragt, ob er die Nachricht entschlüsseln und anzeigen möchte
  12. Der Browser stellt eine Anfrage unter Angabe der Nachrichten-ID
  13. Wenn der Absender verlangt, dass ein CAPTCHA ausgefüllt wird, wird der Empfänger zu einer anderen URL geleitet, um zu beweisen, dass er menschlich ist (nach dem Bestehen werden sie zurückgeleitet).
  14. Der Server sendet die verschlüsselte Nachricht und löscht die Nachricht standardmäßig an dieser Stelle, wenn die Reads-to-Live (RTL) eins ist
  15. Der Empfänger entschlüsselt die Nachricht mit dem Passwort (und wird nach dem Passwort gefragt, wenn es nicht in der URL enthalten ist).
Dieses Setup ist extrem einfach und bietet Nachrichtenverschlüsselung vom Gerät des Absenders zum Gerät des Empfängers, aber natürlich fehlt die Garantie, die asymmetrische Verschlüsselung bieten kann, da nur jemand im Besitz des privaten Schlüssels des Empfängers die Nachricht entschlüsseln kann. Jeder, der über den Link verfügt, kann die Nachricht im Standardszenario öffnen, bei dem das Passwort Teil der URL ist - dies unterstreicht die Bedeutung eines geeigneten Transports für den Link (zB E-Mail/Chat/Text/etc.) - eine Entscheidung bleibt den Absender. Bei Interesse können wir auch die Unterstützung für ein sehr einfaches asymmetrisches Schema bereitstellen, bei dem der Empfänger eine Anforderung einer Nachricht initiiert und diesen Anforderungslink an den Absender der Nachricht sendet. Dieses Setup würde die Notwendigkeit beseitigen, das Kennwort in der URL zu haben, aber auch die Möglichkeit für den Absender, zu initiieren.

Das Entschlüsselungskennwort kann in der URL enthalten sein?

Ja. Dies wirkt sich offensichtlich auf die Sicherheit aus, denn wenn die zum Senden des Links verwendete Methode unsicher ist, ist die Nachricht aufgrund der Assoziation unsicher. Alle Problemumgehungen zur Beseitigung dieses Problems führen zu zusätzlichen Schritten und Komplexitäten, die sich auf die Benutzererfahrung auswirken (dh die Dinge müssen an beiden Enden eingerichtet werden, bevor die Nachricht gesendet wird). Ein asymmetrisches Schema, bei dem der Empfänger eine Anforderung für eine Nachricht initiiert und diesen Anforderungslink sendet, könnte mit unserer Schlüsselanforderung "Alles ist vergänglich" funktionieren - dies kann implementiert werden. Letztendlich gibt es bessere Lösungen , wenn zwei Parteien einander häufig Nachrichten senden, vorausgesetzt, beide Parteien können mit diesen Lösungen umgehen.

Aber das Entschlüsselungspasswort muss nicht in der URL stehen?

Richtig. Wenn das Entschlüsselungskennwort nicht im Link enthalten ist, wird der Empfänger nach dem Kennwort gefragt. Wird dem Empfänger das Passwort sicher mitgeteilt (oder kennt er es bereits), bietet dies Abhörschutz. Nachteilig ist jedoch, dass der Empfänger das Passwort kennen und korrekt eingeben muss. Hier ist eine Möglichkeit, das Passwort an den Empfänger zu senden, die einen gewissen Schutz gegen Abhören bietet:

  1. Verschlüsseln Sie das Passwort in einer Nachricht mit den Standardeinstellungen und senden Sie diesen Link an den Empfänger.
  2. Wenn der Empfänger auf den Link klickt und die Nachricht entschlüsselt, weiß er, dass niemand vor ihm das Passwort erhalten hat, da die Nachricht mit dem Passwort beim Abrufen gelöscht wird. Wenn jedoch ein aktiver MITM-Angriff stattfindet oder Ihr Gerät oder das Gerät des Empfängers kompromittiert wurde, ist es immer noch möglich, dass eine andere Partei das Passwort erhält.
  3. Bestätigen Sie mit dem Empfänger, dass er das Passwort erfolgreich erhalten hat. Wenn der Empfänger Sie zum Beispiel darüber informiert, dass die Nachricht beim Abrufen des Passworts bereits gelöscht wurde, wissen Sie, dass eine andere Person das Passwort vor dem Empfänger erhalten hat und dass das Passwort daher kompromittiert ist und nicht verwendet werden sollte.
  4. Mit dem Passwort, das der Empfänger bestätigt hat, können Sie jetzt eine Nachricht mit demselben Passwort zur Verschlüsselung senden - teilen Sie einfach die Version des Links, die das Passwort nicht enthält.

Das ist richtig - wir generieren den Link und überlassen es dem Absender, wie er ihn am besten an den Empfänger zustellt. Das Ziel dieses Dienstes ist es, eine Option bereitzustellen, die weniger Dauerhaftigkeit in bestehenden Nachrichtentransporten wie E-Mail/Chat/Text/usw. bietet. Daher wird erwartet, dass der von uns generierte Link, der auf die temporäre Nachricht zeigt, über einen bestehenden Nachrichtentransport gesendet wird. Dies hat Auswirkungen auf die Sicherheit, die Benutzer verstehen sollten. Nehmen wir als Beispiel eine SMS-Textnachricht, da dies eine ziemlich unsichere Kommunikationsmethode ist. Wenn Sie diesen Dienst verwenden, um einen temporären Nachrichtenlink über eine Textnachricht zu senden, wenn Sie den Standardmodus verwenden, bei dem das Passwort im Link enthalten ist, kann jeder, der den Link besitzt, die Nachricht lesen und es wird kein Schutz gegen Abfangen geboten. Dieser Dienst bietet immer noch eine eher temporäre Kommunikation, die die Privatsphäre und Sicherheit verbessern kann. Darüber hinaus können Sie den Link ohne Passwort senden, um Abhörschutz zu gewährleisten.

Wie kann ich meine Privatsphäre bei der Nutzung dieses Dienstes so gut wie möglich schützen?

Wie an anderer Stelle in diesen FAQ erläutert , werden einige protokollbezogene Informationen von uns und anderen übermittelt und gesammelt , obwohl wir bereits viel für den Schutz Ihrer Privatsphäre tun und keine personenbezogenen Daten erheben, wenn Sie einen Webbrowser verwenden. Es gibt jedoch mehrere Möglichkeiten, Ihre Privatsphäre noch mehr zu schützen. Ein kostenloser Weg, der auf Open-Source-Software basiert und recht gut funktioniert, ist die Verwendung des Tor-Browsers . Dieser Browser wurde entwickelt, um Ihre Privatsphäre auf mehreren Ebenen zu schützen – einschließlich der Verwendung des Tor-Netzwerks . Unsere Site ist bereits über das Tor Onion-Netzwerk zugänglich, was bedeutet, dass der Zugriff auf unsere Site über Tor nicht die Verwendung eines Exit-Nodes erfordert, wodurch verhindert wird, dass jemand den Exit-Node-Verkehr abhört . Denken Sie jedoch daran, dass Ihr ISP auch in diesem Szenario sehen kann, dass Sie Tor verwenden - aber nicht wofür. Sie können sich sogar mit einem VPN verbinden und dann den Tor-Browser für zwei Ebenen der Anonymität starten; Beachten Sie jedoch, dass Ihr ISP in diesem Szenario immer noch sehen kann, dass Sie ein VPN verwenden - jedoch nicht wofür. Wenn Sie nicht möchten, dass Ihr ISP weiß, welche Protokolle Sie verwenden, können Sie eine Verbindung zu einem großen öffentlichen WLAN-Netzwerk wie einer Bibliothek, Schule usw. herstellen und dann den Tor-Browser verwenden.

Was ist, wenn ich den Vereinigten Staaten nicht vertraue?

Unsere Server befinden sich in den USA. Darüber hinaus ist unser CDN-Anbieter Cloudflare ein Unternehmen mit Sitz in den USA. Wir haben versucht, die Notwendigkeit zu beseitigen, uns oder dem Land, in dem sich unsere Server befinden, zu vertrauen, einfach weil wir keine personenbezogenen Daten sammeln, keine Nachrichten entschlüsseln können und alles kurz nach Erhalt gelöscht wird. Wir können jedoch ein gewisses Misstrauen verstehen, da es webbasiert ist und insbesondere wenn Sie in bestimmten Ländern leben. Wir haben einige Pläne, in Island und in der Schweiz Optionen für Menschen anzubieten, die Schwierigkeiten haben, den USA zu vertrauen. Bitte teilen Sie uns mit, ob dies auf Sie zutrifft, da wir nicht motiviert sind, Alternativen anzubieten, es sei denn, es besteht eine echte Nachfrage.

Was tun Sie, um Spam zu verhindern?

Jedes Mal, wenn Sie jemandem erlauben, eine Nachricht zu posten, die über einen Link weitergeleitet werden kann, laden Sie Spammer ein. Dieses Problem einzudämmen ist nicht ganz einfach. Wir möchten aus folgenden Gründen kein CAPTCHA eines Drittanbieters als Teil des Nachrichtenversandprozesses laden:

Wir könnten das API-Problem möglicherweise umgehen, indem wir ein API-Schlüsselsystem verwenden, aber dann müssen wir Benutzerinformationen sammeln, was wir nicht tun möchten. Und was soll Spammer davon abhalten, viele API-Schlüssel zu erhalten? Wir können Nachrichten nicht untersuchen, um auf ihre Spamizität zu schließen (was bestenfalls sehr problematisch ist), da wir außer der Verschlüsselung der Nachrichten eine Richtlinie zum Freigeben von Nachrichteninhalten haben. Angesichts dieser Anforderungen wenden wir zwei Methoden zur Verhinderung von Spam an: Wenn Sie wissen, dass Spammer diesen Dienst missbrauchen, reichen Sie bitte eine Missbrauchsmeldung ein .

Warum besteht die Möglichkeit, vom Empfänger das Ausfüllen eines CAPTCHA zu verlangen?

Es stimmt zwar, dass wir CAPTCHAs nicht mögen, aber wir erkennen an, dass sie einem Zweck dienen und eine Zeit und einen Ort haben (zumindest vorerst). Dies ist eine einfache Möglichkeit für den Absender, eine gewisse Gewissheit zu erlangen, dass der Empfänger ein Mensch ist und dass keine automatisierten Prozesse auf die Nachricht zugreifen.

Wer betreibt diesen Dienst und warum ist er kostenlos?

Wir sind nur ein paar Leute, die manchmal mit der misslichen Lage konfrontiert waren, keine guten Optionen zum Schutz unserer Privatsphäre zu haben. Dies resultierte oft aus der Kommunikation mit Freunden und Familienmitgliedern, die nicht sehr vorsichtig mit dem Umgang mit ihren Geräten und Informationen waren. Dies geschah manchmal bei der Verwendung webbasierter Foren wie Reddit oder bei der Verwendung webbasierter Supportsysteme. Wir fanden einige webbasierte temporäre Nachrichtenlösungen, aber keine bot E2EE an, was bedeutete, dass wir ihnen nicht vertrauen konnten. Also haben wir einfach unsere eigene Lösung gebaut und beschlossen, sie zu verschenken, damit andere davon profitieren können.

Wie kann ich den Antworten auf die obigen Fragen vertrauen?

Wirklich sollten Sie keiner Website vertrauen, nur weil sie bestimmte Dinge sagt - es ist normalerweise eine gute Idee, alle Behauptungen zu überprüfen. Wir haben versucht, die Verpflichtung, uns so weit wie möglich zu vertrauen, durch den Einsatz von Ende-zu-Ende-Verschlüsselung zu beseitigen. Zum Beispiel ist es ziemlich einfach zu überprüfen, dass wir keine Nachrichten lesen können, da sie verschlüsselt sind . Wir haben auch den Javascript-Code für diese Site sehr einfach gehalten, damit er leicht zu lesen und zu verstehen ist. Wenn der gesamte Code Open Source ist, können Benutzer überprüfen, was ausgeführt wird. Beachten Sie jedoch, dass es keine Möglichkeit gibt, wirklich zu überprüfen, was auf dem Server ausgeführt wird. Es stimmt zwar, dass durch die Ende-zu-Ende-Verschlüsselung ein Großteil der Vertrauensanforderung beseitigt wird, aber es ist immer noch ein Faktor, den unsere Benutzer bei der Entscheidung, diesen Dienst zu nutzen oder nicht, stark in Betracht ziehen.