Sicherheit & Datenschutz

Keine Konten, kein Login

encrypt.click hat keine Benutzerkonten, Anmeldungen oder Profile. Du musst dich weder registrieren noch persönliche Daten angeben, um die Tools zu nutzen.

Tools im Browser

Entwickler- und Datenschutz-Tools (Hashing, Schlüsselerzeugung, Kodierung, lokale Hilfsprogramme und Ähnliches) laufen in deinem Browser mit Web Crypto und anderen lokalen APIs. Deine Eingaben werden nicht zur Verarbeitung an encrypt.click gesendet.

Wenn ein Tool auf deine Anforderung öffentliche Daten benötigt (zum Beispiel drand-Zufallswerte für die Zeitkapsel über unseren Same-Origin-Proxy), enthält die Anfrage weder Geheimnisse im Klartext noch Passwörter.

Verschlüsseltes Teilen von Nachrichten und Dateien

Encrypt & share führt AES-GCM in Ihrem Browser aus, bevor etwas hochgeladen wird. Das Passwort bleibt auf Ihrem Gerät, bis Sie es selbst kopieren oder weitergeben.

Der automatische Upload bevorzugt First-Party-Ciphertext-Speicher (upload.encrypt.click). Dieser Pfad ist begrenzt (ca. 50 MB) und die Verfügbarkeit ist etwa 24 Stunden garantiert. Schlägt er fehl, sendet der Browser nur Ciphertext an die Upload-API von encrypt.click, die serverseitig an temporäre Send-kompatible Hosts weiterleiten kann. Diese Hosts sollten Ciphertext und Server-Egress sehen - keinen direkten Browser-Upload von Klartext.

Empfänger öffnen Links auf encrypt.click (oft /u). Verschlüsseltes Material kann im URL-Fragment liegen (bei normalen Seitenaufrufen nicht an unsere Server gesendet) oder auf hochgeladenen Ciphertext zeigen. Optionales PNG-Wrapping kann den Share-Link in einem Bild für Offline-Übergabe verstecken.

Verschlüsselter Chat, Anrufe, Whiteboard und Dateien

Chat-Nachrichten, Tippindikatoren und Call-Signaling werden im Browser verschlüsselt (AES-GCM), bevor sie den PartyKit-Relay erreichen. Der Relay leitet Ciphertext weiter und speichert keine Chat-Historie.

Live-Anrufe nutzen WebRTC mit TURN-only-ICE, damit Peer-IPs nicht direkt ausgetauscht werden. Medien sind durch DTLS-SRTP zwischen Teilnehmern geschützt; TURN leitet nur verschlüsselte Pakete weiter. TURN-Credentials kommen von encrypt.click (/api/turn).

Chat-Anhänge werden clientseitig vor dem Upload verschlüsselt - gleicher Ciphertext-first-Ansatz wie Encrypt & share (First-Party-Speicher wenn möglich, sonst nur serverseitiger Relay von Ciphertext).

Ohne Raumpasswort wird der Schlüssel nur aus dem Raumnamen abgeleitet. Wer den Namen errät, kann beitreten und entschlüsseln. Relays sehen trotzdem Präsenz und Timing-Metadaten, auch wenn Payloads verschlüsselt sind.

Whiteboard-Sitzungen nutzen dieselbe Realtime-Infrastruktur für gemeinsame Striche und Zustand. Behandeln Sie den Zugang wie beim Chat: für Sensibles ein starkes Passwort verwenden.

Optionale URL-Kürzung

Wenn du einen Freigabelink kürzt, ruft dein Browser /api/shorten auf encrypt.click auf. Das Backend fragt den ausgewählten Kurzlink-Dienst anschließend serverseitig an.

Der Kurzlink-Dienst erhält die vollständige zu kürzende URL. Bei verschlüsselten Freigabelinks kann sie Metadaten der verschlüsselten Nutzlast enthalten. Verwende für sensible Links keine Kurzlink-Dienste von Drittanbietern, wenn du größtmögliche Privatsphäre möchtest.

Geteilte Kurzlinks können auf einer Domain von encrypt.click verbleiben. Beim Öffnen kann encrypt.click den Kurzlink serverseitig auflösen und zurück zu einer URL von encrypt.click weiterleiten. Der Kurzlink-Dienst sieht dadurch eher die Infrastruktur als direkt den Browser des Besuchers, kann aber dennoch protokollieren, dass ein bestimmter verschlüsselter Link aufgelöst wurde.

Cookies und lokaler Speicher

Die Website setzt keine Tracking- oder Analyse-Cookies und verwendet weder Tracker von Drittanbietern noch Werbepixel. Der Browser kann localStorage für Einstellungen (Design, Sprache) und bei Chats mit lokalem Verlauf für verschlüsselte Nachrichtenumschläge auf dem Gerät verwenden. sessionStorage kann beim Beitritt kurzzeitig das Raumpasswort speichern.

Cloudflare (Hosting) kann je nach Traffic und Browsereinstellungen Cookies für Sicherheit und Missbrauchsschutz setzen - nach Cloudflares eigenen Richtlinien.

Netzwerk- und Transport-Sicherheit

• Der gesamte Datenverkehr läuft über HTTPS mit modernem TLS.
• HTTP Strict Transport Security (HSTS) ist mit includeSubDomains und preload aktiv.
• Die Content Security Policy (CSP) beschränkt Skripte, Stylesheets, Schriftarten und Verbindungen; anstelle einer weitreichenden unsafe-inline-Freigabe für Skripte werden Hashes für Inline-Skripte verwendet.
• Die Einbettung in iframes wird durch frame-ancestors 'none' und X-Frame-Options: DENY verhindert.
• Ein clientseitiger Deployment-Integritätscheck vergleicht geladene Build-Assets mit einem veröffentlichten Manifest und - wenn erreichbar - dem neuesten GitHub-main-Commit.

Infrastruktur Dritter

Die Website läuft auf Cloudflare Pages. Echtzeit-Chat und Whiteboard verwenden PartyKit. Die Anrufweiterleitung kann Cloudflare TURN und/oder andere konfigurierte TURN-Anbieter verwenden. Temporäre Hosts für Geheimtext (Send-kompatible Instanzen) können verschlüsselte Datenblöcke erhalten, wenn der eigene Upload-Dienst nicht verfügbar ist.

encrypt.click führt keine eigene Datenbank mit deinen Tool-Eingaben. Der Schutz der API vor Missbrauch verwendet für etwa 60 Sekunden einen gesalzenen Hash der IP-Adresse im Arbeitsspeicher. Cloudflare kann nach seinen eigenen Richtlinien zusätzlich Schutzmaßnahmen gegen Bots und automatisierte Angriffe einsetzen.

Verantwortungsvolle Meldung

Wenn du glaubst, ein Sicherheits- oder Datenschutzproblem bei encrypt.click gefunden zu haben, schreibe an mail@encrypt.click. Gib genügend Einzelheiten an, um das Problem nachvollziehen zu können, und vermeide Tests, die andere Nutzer beeinträchtigen könnten.

Unverbindliche Zusammenfassung

Diese Seite fasst verständlich zusammen, wie encrypt.click im Umgang mit Daten konzipiert ist. Sie ist weder ein Vertrag noch enthält sie vollständige rechtliche Bedingungen. Vollkommene Sicherheit kann nicht garantiert werden; du verwendest die Tools auf eigenes Risiko.