Vertrau uns nicht.
Prüf es nach.

AshNote ist so gebaut, dass Vertrauen überflüssig ist: Unsere Server können physisch nicht lesen, was du teilst. Hier steht exakt, warum. Und wo die Grenzen liegen.

Anatomie eines Drop-Links

ashnote.io/d/<id>/<token>#<key>
  • #key: der AES-256-Schlüssel, erzeugt in deinem Browser. URL-Fragmente (alles nach #) werden von keinem Browser an Server gesendet. Der Schlüssel existiert nur im Link selbst.
  • token: ein Zugriffstoken, das unser Server nur als SHA-256-Hash speichert. Selbst ein kompletter Datenbank-Leak gewährt Zugriff auf nichts.
  • id: eine zufällige UUID zum Auffinden des verschlüsselten Blobs.

Der Lebenslauf eines Secrets

Beim Erstellen

  1. Dein Browser erzeugt per WebCrypto einen zufälligen 32-Byte-Schlüssel und einen 16-Byte-Zugriffs-Token.
  2. Daraus wird per HKDF-SHA256 der AES-256-GCM-Schlüssel abgeleitet. Eine optionale Passphrase fließt in diese Ableitung ein: Sie verändert den Schlüssel selbst und verlässt deinen Browser nie.
  3. Das Secret (Text oder Datei, inklusive Dateiname) wird in einen Umschlag verpackt und mit frischem Zufalls-IV verschlüsselt.
  4. Hochgeladen werden nur Ciphertext, IV, der SHA-256-Hash des Tokens und die Ablauf-/Lese-Einstellungen.
  5. Der Link entsteht lokal: id und Token in den Pfad, der Schlüssel ins #Fragment.

Beim Öffnen

  1. Der Browser des Empfängers legt den Token vor; der Server vergleicht dessen Hash, gibt den Ciphertext heraus und zählt den Lese-Zähler herunter. Das letzte Lesen löscht den Drop in derselben Transaktion.
  2. Der Schlüssel aus dem Fragment (plus Passphrase, falls gesetzt) durchläuft dieselbe Ableitung, und der Umschlag wird lokal entschlüsselt.
  3. Ein falscher Schlüssel oder eine falsche Passphrase erzeugt nie Datenmüll: GCM ist authentifizierte Verschlüsselung, die Entschlüsselung schlägt schlicht fehl.

Was unsere Server sehen

  • Ciphertext (AES-256-GCM, clientseitig via WebCrypto-API des Browsers verschlüsselt)
  • Einen Initialisierungsvektor und einen Token-Hash
  • Ablaufzeit und Lese-Zähler

Das ist alles. Kein Klartext, keine Schlüssel, keine Dateinamen. Datei-Metadaten liegen im verschlüsselten Umschlag. Optionale Passphrasen werden im Browser per HKDF in den Schlüssel gemischt; eine falsche Passphrase scheitert schlicht an der kryptografischen Authentifizierung.

Die App macht außerdem keine Drittanbieter-Requests: Während du verschlüsselst, spricht dein Browser mit ashnote.io und sonst niemandem. Öffne den Netzwerk-Tab und schau zu.

Löschen heißt löschen

Das letzte Lesen löscht den Datensatz hart: in derselben Datenbank-Transaktion, atomar, sodass zwei gleichzeitige Leser nie beide einen Burn-after-read-Drop erwischen. Abgelaufene Drops werden alle 60 Sekunden entfernt. Ein verbrannter Link liefert dieselbe Antwort wie ein nie existierender.

Preview-Bots verbrennen keine Drops

Slack, Teams, Outlook und Security-Scanner rufen Links ab, um Vorschauen zu bauen. AshNote gibt ein Secret nur auf eine explizite Aktion des Lesers heraus (einen POST-Request): Automatisierte GET-Abrufe verbrauchen nie einen Read.

Ehrliche Grenzen

  • Wer den Link hat, hat das Secret. Behandle Drop-Links wie das Secret selbst, nur mit Ablaufdatum und Lesebestätigung.
  • Secrets über unseren Slack-Command passieren unseren Server einmal (Slack bietet keinen clientseitigen Verschlüsselungsweg) und werden sofort verschlüsselt, nie gespeichert oder geloggt. Web-App und Teams-Dialog sind vollständig Zero-Knowledge.
  • Das Gerät des Empfängers liegt außerhalb der Kontrolle jedes Sharing-Tools.
  • Der Vertrauensanker ist das JavaScript, das wir ausliefern: Ein kompromittierter Server könnte Code ausspielen, der Schlüssel abgreift. Zero-Knowledge schützt vor passiven Vorfällen (Datenbank-Leaks, neugierigen Betreibern, Herausgabeverlangen gespeicherter Daten), nicht vor aktiv bösartiger Code-Auslieferung. Das gilt für jede Ende-zu-Ende-verschlüsselte Web-App; unser quelloffener Client-Code ist das Gegengewicht.
  • URL-Fragmente erreichen nie einen Server, landen aber auf beiden Seiten in der Browser-History. Burn-after-read und eine optionale Passphrase (über einen zweiten Kanal geteilt) sind die Gegenmittel.

Die Client-Verschlüsselung ist quelloffen auf GitHub, sowohl die Web-App als auch die CLI: Lies sie, auditier sie, betreib sie selbst. Das komplette Protokoll ist in PROTOCOL.md dokumentiert; die CLI installierst du mit brew tap arrowhacks-org/ashnote && brew install ashnote.