# Testrunde 5 — Rohdaten der zehn Reviews

Die Gegenprobe wurde abgebrochen und muss neu laufen; diese zehn Protokolle
sind vollstaendig und muessen NICHT wiederholt werden.

**Schnitt 4.21** aus 10 Bewertungen, 0 von 10 wuerden es nutzen.
Spanne 3.1 bis 5.4.

| Persona | Rolle | Note | nutzen |
|---|---|---|---|
| Andrea Willms | Sozialarbeiterin im ASD eines Jugendamts, 44 | 5.4 | nein |
| Jonas K. — lebt von Bug Bounties, Platz  | Bug-Bounty-Jaeger, 25 | 5.2 | nein |
| Reinhard Stellwag, ehrenamtlicher Buerge | Ehrenamtlicher Buergermeister und Zimmererme | 5.2 | nein |
| Jonas Reithmayr | Indie-Entwickler, 27, Gamestudio zu dritt | 4.4 | nein |
| Dr. Katrin Ellermann-Vosskuhl | Notarin, 49 | 4.2 | nein |
| Dr. Annika Reuther | Postdoc Humangenetik, 34 | 3.8 | nein |
| Jonas Reinhardt | Dateningenieur bei einem Rennstall, 31 | 3.6 | nein |
| Dr. Almut Rehberg-Sander | Compliance-Officer einer Regionalbank, 47 | 3.6 | nein |
| Lina, Kurzvideo-Creatorin (180.000 Follo | Content Creatorin, 23 | 3.6 | nein |
| Ursula Behrend | Rentnerin, 72, frueher Buchhalterin | 3.1 | nein |

---


## Andrea Willms — Sozialarbeiterin im ASD eines Jugendamts, 44

**Note 5.4 · wuerde nutzen: nein**

### Begruendung der Note

Handwerklich ist das eines der ehrlichsten Stuecke Software, die ich seit langem gesehen habe: null fremde Verbindungen ueber zehn Seiten hinweg gemessen, 314,6 MB in 1,6 Sekunden verschluesselt, ein ZIP mit 14 Dateien Byte fuer Byte identisch zum Original, Fehlermeldungen, die mir nicht die Schuld geben. Dafuer allein waeren es acht Punkte. Nur erledigt es fuer meine Arbeit exakt null Aufgaben: der Link oeffnet ausschliesslich im Browser, der ihn erzeugt hat — im fremden Kontext kam nach zwei Sekunden "Nothing here to open". Ich verschicke Unterlagen, ich lagere sie nicht. Dazu kommt ein Fund, der mir wirklich weh tut: ein zweiter Tab hat einen laufenden Drop geloescht, und die App hat mir trotzdem "Cloaked." und einen Link ausgegeben, der beim Herunterladen scheitert. Eine Erfolgsmeldung fuer ein kaputtes Ergebnis ist bei Kinderakten das Gegenteil von harmlos. 5,4, weil Ehrlichkeit und Sorgfalt viel wert sind, aber ein Werkzeug, das nichts transportiert, mir keine Minute abnimmt.

### Blocker

1. Kein Relay: der Link oeffnet ausschliesslich in dem Browser, der ihn erzeugt hat. Im frischen Browserkontext kam nach rund zwei Sekunden 'Nothing here to open'. Damit erledigt das Produkt fuer meinen Beruf null Arbeit — ich verschicke Unterlagen, ich lagere sie nicht.
2. Kein Zustellnachweis. Fuer eine Uebergabe ans Familiengericht muss ich belegen koennen, dass und wann etwas angekommen ist. CloakDrop kann das prinzipbedingt nicht, und mein Fax kann es.
3. Ohne Verzeichnis von Verarbeitungstaetigkeiten und ohne einen Ansprechpartner, mit dem unsere Datenschutzbeauftragte reden kann, darf ich das dienstlich nicht einsetzen. Die Limits-Seite sagt selbst: 'treat this as something to try, not something to rely on at work.' Das ist ehrlich, aber es bleibt ein Nein.
4. Der Drop lebt im Browserprofil. Unsere Rechner werden zentral verwaltet und Profile werden geleert; was dann mit einem noch nicht abgeholten Drop passiert, kann ich nicht beeinflussen (vermutet, nicht an unserem Dienstrechner geprueft — ich habe nur gemessen, dass die Daten im Browserprofil liegen).
5. Zweitbrowser-Zwang beim Empfaenger: selbst mit Relay muesste die Richterin oder der Vormund die Seite im Browser oeffnen. Bei Gerichten laufen Browser haeufig unter strengen Vorgaben; das muesste jemand vorher klaeren, nicht ich im Einzelfall.

### Was gut ankam

- Ueber zehn Seiten und mehrere hundert Megabyte Verschluesselung hinweg ging keine einzige Anfrage an ein fremdes Ziel — keine Schriftart, kein Zaehlpixel, kein CDN. Gemessen, nicht geglaubt.
- Nach dem Schliessen des Browsers habe ich das ganze Profil durchsucht: der Dateiname 'Schutzplan_Kind_Leonie' war nirgends im Klartext zu finden, weder in UTF-8 noch in UTF-16. Das Manifest ist wirklich verschluesselt.
- Tempo: Startseite in 0,37 s, 14 Dateien mit 23,1 MB in unter einer Sekunde verschluesselt, 314,6 MB in 1,6 s. Das passt in meine zwei Minuten pro Vorgang.
- Der Knopf 'alles herunterladen' liefert ein ZIP, das ich mit Python gegengeprueft habe: 14 Eintraege, CRC in Ordnung, jede einzelne Datei mit identischer Pruefsumme zum Original, Umlaute und tuerkisches S im Namen erhalten.
- Ungefragte Warnung 'One of these files is empty (0 bytes) ... That is usually not what you meant.' Genau diesen Fehler habe ich vor zwei Jahren ans Gericht gefaxt.
- Ehrlichkeit im Text: 'a link opens only on the device that made it' steht direkt im Ablagefenster, 'CloakDrop is not open source' auf der Code-Seite, 'treat this as something to try, not something to rely on at work' in der FAQ, und die Status-Seite sagt 'coming soon' statt einen gruenen Haken zu zeigen, den keiner gemessen hat.
- Fehlermeldungen, die mir nicht die Schuld geben: bei einem verdrehten Zeichen im Schluessel werden beide moeglichen Ursachen genannt statt 'Sie haben falsch kopiert'.
- Abbrechen mitten im Verschluesseln funktioniert wirklich: bei 80 % von 314,6 MB abgebrochen, danach null Datensaetze und null Bruchstuecke im Speicher — und meine Dateiauswahl stand noch da.
- Passwort-Bremse: vier Fehlversuche kosteten 0,26 / 0,81 / 1,33 / 2,30 Sekunden, wachsend. Zu kurze und sehr haeufige Passwoerter werden mit einer Begruendung abgelehnt, die man versteht.
- Beim Kurznamen-Feld steht ausdruecklich, dass es das einzige Unverschluesselte ist und man dort nicht hineinschreiben soll, worum es geht. Ich habe nachgemessen: stimmt, es liegt im Klartext in der Datenbank — sie sagen es also vorher, statt es zu verschweigen.
- Abgelaufene und abgebrochene Drops werden wirklich geloescht, nicht nur gesperrt: nach kuenstlich vorgezogener Frist und einem Neustart waren null Datensaetze und null Bruchstuecke uebrig.
- Kein Konto, kein Cookie-Banner, kein Newsletter-Fenster. Ich musste nichts wegklicken, bevor ich arbeiten konnte.

### Heutige Loesung

Fax ueber die Poststelle ans Familiengericht; fuer Eiliges ein mit 7-Zip AES-verschluesseltes Archiv per Dienstmail, Passwort per Telefon; USB-Stick mit Cryptomator fuer Hausbesuche; Threema fuer den Austausch mit Kolleginnen. WeTransfer, Dropbox, Google Drive und OneDrive sind uns schriftlich untersagt. Ich behalte das alles, weil CloakDrop heute keinen einzigen dieser Wege ersetzt — es transportiert nichts.

### Gemeldete Defekte (7)

- **Zweiter Tab loescht mitten im Verschluesseln: die App meldet trotzdem Erfolg und gibt einen Link auf ein halbes Chiffrat aus** (schwer, gemessen)  
  Ort: index.html, Zeile 3269 (Waechter laeuft nur alle 3000 ms) und Zeile 3326/3343 (die Schlusskontrolle liest einen Datensatz, den sie selbst zwei Zeilen vorher wieder angelegt hat)  
  Beleg: Gemessen: Tab 1 verschluesselt 314,6 MB. Tab 2 loescht bei 0,68 s ueber die App-eigene Uebersicht (Manage -> Delete). Tab 1 meldet bei 1,68 s 'Cloaked.', Fehlerzeile bleibt leer, Link wird ausgegeben. IndexedDB danach: Bruchstuecke 36 bis 79 vorhanden, 1 bis 35 geloescht, 44 von 79. Der Link oeffnet und zeigt '1 cloaked file · 314.6 MB · opens for 24 more hours'; erst der Download scheitert mit 'A piece is missing'. Ursache: 314 MB sind nach 1,7 s fertig, die 3-Sekunden-Lebenszeichenpruefung kommt nie dran, und die als 'letzte Kontrolle' bezeichnete Pruefung kann nach dem erneuten saveTransfer nie fehlschlagen. Skript: p5-3-h.py
- **Unfertiger Rest wird ohne Groessenangabe gefuehrt und bleibt bis zum naechsten Besuch der Seite liegen** (mittel, gemessen)  
  Ort: Uebersicht 'Stored in this browser'; Datensatzfeld bytes wird nur alle 3 s fortgeschrieben (index.html, Zeile 3269 ff.)  
  Beleg: Gemessen: Neuladen bei 20 % von 314,6 MB. IndexedDB danach: 1 Datensatz mit bytes = 0, aber 28 Bruchstuecke zu je 4 MB, also rund 112 MB auf der Platte. Die Uebersicht zeigt 'Stored in this browser · 1 drop' ohne jede Groesse und die Zeile 'Unfinished · 2026-07-31 22:13' ohne Groesse. Erst 13 s spaeter und nach erneutem Oeffnen der Seite war alles fort (0 Datensaetze, 0 Bruchstuecke). Wer die Seite nie wieder oeffnet, behaelt die 112 MB. Skript: p5-3-g.py
- **Die Uebersicht kann mehrere Drops nicht auseinanderhalten** (mittel, gemessen)  
  Ort: Ansicht st-drops, Zeilentext in index.html (dropsAnzeigen)  
  Beleg: Gemessen: die Zeile lautet ausschliesslich 'Cloaked 2026-07-31 22:09 · opens for 24 more hours' plus Groesse. Dateinamen liegen im verschluesselten Manifest, die Ansicht sagt das auch ('this list cannot show them'). Einziges Unterscheidungsmerkmal ist ein Kurzname-Feld, in das die App im selben Absatz zu schreiben verbietet, worum es geht ('not what the drop contains'). Bei sechs Vorgaengen desselben Tages bleibt nur die Uhrzeit.
- **Ein Link am Satzende (Outlook-Normalfall) wird abgewiesen** (mittel, gemessen)  
  Ort: Einfuegefeld 'Open a link', tryOpenLink in index.html  
  Beleg: Gemessen: Eingabe 'Sehr geehrte Frau Richterin, anbei die Unterlagen: <Link> Mit freundlichen Gruessen, ASD Musterstadt' fuehrt zu Zustand st-error mit 'That is not a key'. Derselbe Link mit einem Zeilenumbruch mittendrin oeffnet dagegen einwandfrei. Der Kommentar im Quelltext beschreibt genau diesen Satzende-Fall als geloest. Skript: p5-3-d.py
- **Aus der Fertig-Ansicht fuehrt kein Weg zur Uebersicht, ohne den Link zu verlieren** (klein, gemessen)  
  Ort: Ansicht st-done; die Zeile mit dem Manage-Knopf (#storeline) liegt in st-idle  
  Beleg: Gemessen: im Zustand st-done meldet #storeline hidden=true und parentHidden=true, Breite und Hoehe 0; der Knopf ist 30 s lang nicht anklickbar. Die einzigen Auswege sind 'Start a new drop' (zweimal druecken, danach ist der Link unwiederbringlich weg) und 'Delete this drop'.
- **Die gewaehlte Ablauffrist gilt nur fuer diesen einen Drop und faellt danach auf 24 Stunden zurueck** (klein, gemessen)  
  Ort: index.html, Variable expireGewaehlt (Vorgabe 24 Stunden), wird bei jedem Seitenaufbau neu gesetzt  
  Beleg: Gemessen: nach Auswahl '7 days' und einem Seitenneuaufbau standen die Optionen wieder auf aria-checked ['false','true','false'], also 24 Stunden. Es gibt keine Einstellung, die das merkt.
- **Ein reines Woerterbuchwort wird als Drop-Passwort kommentarlos angenommen** (klein, gemessen)  
  Ort: Liste PW_ZU_HAEUFIG in index.html (17 Eintraege), Pruefung in cloakAndStore  
  Beleg: Gemessen: 'abc' wird abgelehnt (zu kurz), 'Passwort' wird abgelehnt (Liste), 'jugendamt' (9 Zeichen, ein einzelnes Woerterbuchwort) wird ohne jede Bemerkung akzeptiert und der Drop erzeugt. Gegen jemanden, der den Link schon hat, ist das keine Huerde. Skript: p5-3-b.py

### Vollstaendiger Review

Ich bin Sozialarbeiterin im Allgemeinen Sozialen Dienst, seit vierzehn Jahren, und ich fange gleich mit dem Satz an, der bei mir ueber alles entscheidet: nimmt mir das Arbeit ab oder macht es welche. Ich habe pro Vorgang zwei Minuten. Ich verschicke Hilfeplaene, Stellungnahmen nach Paragraph 50 ans Familiengericht und ab und zu Fotos, die eine Wohnsituation dokumentieren. Wenn so eine Akte beim falschen Elternteil landet, ist das im schlimmsten Fall gefaehrlich fuer ein Kind, und ich bin diejenige, die das erklaeren muss. Den Link hat mir eine Kollegin aus dem Kreisjugendamt geschickt, mit dem Satz "guck dir das mal an".

Meine heutige Loesung, damit klar ist, wogegen das antritt: ans Familiengericht geht es per Fax, ueber unsere Poststelle. Unser Fachverfahren kann nichts nach aussen. Wenn es schnell gehen muss, packe ich die Anlagen mit 7-Zip in ein AES-verschluesseltes Archiv, schicke das ueber die Dienstmail und sage das Passwort am Telefon durch. Fuer Hausbesuche liegt ein USB-Stick mit Cryptomator in meiner Tasche. Fuer die Kollegin einen Flur weiter nutze ich Threema, das ist bei uns freigegeben. WeTransfer, Dropbox, Google Drive und OneDrive hat uns die Datenschutzbeauftragte schriftlich untersagt. Proton Drive und Tresorit habe ich privat angesehen, Tresorit haben die Kollegen im Nachbarkreis, und Bitwarden Send nutze ich privat fuer sowas wie WLAN-Passwoerter. Firefox Send haette gepasst, das war 2020 genau dieses Modell, Link plus Passwort, kein Konto — und wurde eingestellt, weil Erpressungsbanden es zum Malwareversand missbraucht haben. Seitdem gibt es fuer meine Situation nichts Gutes. Deshalb faxen wir.

Ich bin nicht technisch. Die Messungen unten habe ich nicht allein gemacht; unser EDV-Kollege hat mit mir zwei Nachmittage vor dem Rechner gesessen und aufgeschrieben, was wirklich passiert, statt was auf der Seite steht. Was ich hier behaupte, haben wir gesehen, nicht geglaubt.

Der erste Eindruck war gut. Die Startseite war nach 0,37 Sekunden da, eine einzige Datei mit 430 KB, kein Cookie-Banner, kein Newsletter-Fenster, kein "Jetzt Konto anlegen". Und direkt im Kasten zum Dateiablegen stand in fetten Buchstaben: "Preview: a link opens only on the device that made it". Ich habe das gelesen und erst nicht verstanden. Zwei Minuten spaeter habe ich es verstanden, und damit war die Sache fuer mich eigentlich schon entschieden. Ich lasse es trotzdem nicht dabei, weil der Rest bemerkenswert ist.

Ich habe eine echte Vorgangsmappe nachgebaut: Hilfeplan, Stellungnahme ans Amtsgericht, Gespraechsprotokoll vom Hausbesuch, Schutzplan, acht Fotos, eine Anlage mit einem sehr langen Namen samt Umlauten und tuerkischem S, dazu versehentlich eine leere Datei. Vierzehn Stueck, 23,1 MB. Alle auf einmal ins Fenster gezogen. Nach einer halben Sekunde stand da "14 files · 23.1 MB", und darunter, ungefragt: "2 of these files are empty (0 bytes) — they will be in the drop, but there is nothing in them. That is usually not what you meant." Das hat mich ehrlich gefreut. Genau so eine leere Anlage habe ich vor zwei Jahren ans Gericht gefaxt und musste hinterher telefonieren. Dass eine Software das von sich aus sagt, kenne ich nicht. Als ich drei Dateien versehentlich doppelt hinzugefuegt habe, kam "3 files were already in this drop and were not added again". Auch das: richtig.

Verschluesselt war das Ganze in unter einer Sekunde. Zum Gegentest haben wir eine 314,6-MB-Videodatei genommen: 1,6 Sekunden. Das ist schneller, als unser Fax die Deckblattseite einzieht.

Dann kam der Punkt, an dem es fuer mich vorbei war. Ich habe den Link genommen und ihn so benutzt, wie ich ihn wirklich benutzen wuerde — in einem frischen Browser, also so, wie ihn die Richterin oder die Kollegin bekaeme. Nach etwa zwei Sekunden stand da: "Nothing here to open. No drop with this address is stored in this browser." Im gleichen Browser, zweiter Tab, ging es tadellos: vierzehn Dateien sauber aufgelistet, mit Groessen, mit Downloadknopf. Aber der Empfaenger sieht nichts. Die Seite sagt das an vier Stellen selbst, in der Fertig-Ansicht sogar direkt unter dem Link ("Still this browser only. Nothing was uploaded"). Das ist ehrlich. Es aendert nur nichts daran, dass ich ein Werkzeug vor mir habe, das Dateien verschluesselt und danach in meinem eigenen Browser liegen laesst. Meine Aufgabe ist aber nicht Lagern, sondern Verschicken. Fuer meinen Arbeitsplatz ist der Nutzen heute exakt null.

Trotzdem weiter, weil ich wissen wollte, wie es gebaut ist. Das Passwort: "abc" wurde abgelehnt, mit einem Satz, der mir das erklaert statt mich zu ruegen. "Passwort" wurde abgelehnt — "That password is on every guessing list there is". Vier falsche Versuche hintereinander wurden langsam bestraft: 0,26, dann 0,81, dann 1,33, dann 2,30 Sekunden. Das ist sauber. Was durchging: "jugendamt". Neun Zeichen, ein Woerterbuchwort, und exakt das Wort, das die Haelfte meiner Kolleginnen tippen wuerde. Da haette ich mir ein Wort der Warnung gewuenscht.

Die Ablauffrist gibt es in einer Stunde, 24 Stunden, sieben Tage. Der Datensatz hatte danach exakt 60 Minuten Laufzeit, die Empfangsansicht schrieb "opens for 1 more hour". Als wir die Frist kuenstlich in die Vergangenheit gesetzt haben, kam "This link no longer opens", und beim naechsten Start war das Chiffrat wirklich weg, null Datensaetze, null Bruchstuecke. Das Loeschen von Hand braucht zwei Klicks, entschaerft sich nach vier Sekunden von selbst wieder und raeumt Datensatz und alle Bruchstuecke ab; der Link war danach tot. Der Knopf "alles herunterladen" hat mir aus vierzehn Dateien in 2,2 Sekunden ein ZIP gebaut, und die Pruefsummen waren Datei fuer Datei identisch mit meinen Originalen, Umlaute und Sonderzeichen inklusive. Nur der Dateiname des Archivs war albern: "Anlage_leer and 13 more.zip".

Kaputtmachen habe ich ernsthaft versucht. Abgeschnittener Link: "That is not a key", mit dem Hinweis, dass Chatprogramme das tun. Ein einzelnes verdrehtes Zeichen im Schluessel: "This drop did not open", und die Meldung nennt beide moeglichen Ursachen, statt mir mein Copy-Paste vorzuwerfen. Zeilenumbruch mitten im Link: oeffnete klaglos, das hatte mich am meisten interessiert, weil Outlook das staendig macht. Link mitten in einem Satz mit "Sehr geehrte Frau Richterin" davor und "Mit freundlichen Gruessen" dahinter: ging nicht, kam "That is not a key". Das ist bei uns der Normalfall und sollte gehen. Fremde Domain wurde abgewiesen, eine javascript-Adresse auch, die www-Schreibweise der eigenen Seite wurde akzeptiert. Eine 545-MB-Datei wurde mit einer klaren Ansage abgelehnt. Abbruch mitten im Verschluesseln, bei 80 Prozent von 314 MB: sofort weg, nichts blieb liegen, meine Auswahl stand noch da. Neuladen bei 20 Prozent: die App warnt vorher, und in der Uebersicht stand ehrlich "One drop below was never finished"; nach dreizehn Sekunden und einem Neustart war der Rest wirklich fort.

Und dann der Fund, wegen dem ich diesen Text ueberhaupt so lang schreibe. Zwei Tabs, wie bei mir immer. Tab 1 verschluesselt 314,6 MB. Tab 2 zeigt in der Uebersicht "1 drop" und bietet mir einen Loeschknopf an; ich habe bei 0,68 Sekunden geloescht — mit der App-eigenen Funktion, nicht mit einem Trick. Tab 1 hat bei 1,68 Sekunden gemeldet: "Cloaked.", keine Warnung, kein Wort, und mir einen Link gegeben. Der Link oeffnet und zeigt stolz "1 cloaked file · 314.6 MB · opens for 24 more hours". Erst beim Herunterladen kommt "A piece is missing". Im Speicher lagen die Bruchstuecke 36 bis 79, die ersten 35 waren weg. Der Quelltext erklaert es: die Kontrolle, ob der eigene Datensatz noch existiert, laeuft nur alle drei Sekunden — und ein 314-MB-Drop ist nach 1,7 Sekunden fertig, sie kommt also nie dran. Die "letzte Kontrolle vor der Erfolgsmeldung" prueft einen Datensatz, den sie zwei Zeilen vorher selbst wieder angelegt hat. Genau diesen Fall beschreibt der Kommentar im Code als geloest. Er ist es nicht. Fuer mich heisst das: ich haette dem Gericht einen Link geschickt, den die App als fertig ausgewiesen hat, und der drueben nichts hergibt.

Was mich positiv ueberrascht hat: waehrend all dem hat der Rechner nichts nach draussen geschickt. Ueber zehn Seiten und mehrere hundert Megabyte Verschluesselung hinweg waren die einzigen Anfragen die Seiten selbst — keine Schriftart, kein Zaehlpixel, gar nichts. Nach dem Schliessen des Browsers haben wir das Profil durchsucht: die verschluesselten Brocken liegen da, aber der Dateiname "Schutzplan_Kind_Leonie" war nirgends im Klartext zu finden, weder normal noch in der anderen Zeichenkodierung. Das ist mehr, als ich von unserem eigenen Fachverfahren behaupten kann. Und beim Kurznamen-Feld in der Uebersicht steht ausdruecklich: "It is the one thing here that is not encrypted — write what helps you tell two drops apart, not what the drop contains." Wir haben nachgesehen: stimmt, der Kurzname steht unverschluesselt in der Datenbank. Sie sagen es also vorher.

Ueberhaupt die Texte. Auf der Limits-Seite steht bei der Frage, ob man das dienstlich nutzen kann, woertlich: "treat this as something to try, not something to rely on at work." Auf der Verify-Seite steht, dass die Pruefungen den Code nicht auditieren und das Ding nicht quelloffen ist. Die Status-Seite sagt "coming soon", statt einen gruenen Haken zu zeigen, den niemand gemessen hat. Ich lese seit Jahren Herstellerprosa, die das Gegenteil macht. Das hier hat mich zweimal beim Nicken erwischt.

Was in meinem Alltag fehlt, selbst wenn es das Relay gaebe: die Uebersicht kann mir nicht sagen, welcher Drop welcher ist. Da steht "Cloaked 2026-07-31 22:09 · opens for 24 more hours" — sechsmal untereinander, fuer sechs Familien. Der einzige Unterschied ist ein Kurzname, den ich selbst tippen muss und in den ich laut der App gerade nicht schreiben soll, worum es geht. Aus der Fertig-Ansicht komme ich ausserdem nicht zur Uebersicht zurueck, ohne den Link zu opfern. Und die Frist muss ich bei jedem Drop neu von 24 Stunden auf sieben Tage stellen; das Gericht liest nicht ueber Nacht.

Fazit: Ich bleibe beim Fax und beim verschluesselten ZIP mit Passwort per Telefon. Nicht weil das gut ist — es ist erbaermlich —, sondern weil CloakDrop heute keinen einzigen Handgriff ersetzt. Wenn das Relay steht, ein Zustellnachweis dazukommt, der Zwei-Tab-Fehler behoben ist und es Rechtsangaben gibt, mit denen unsere Datenschutzbeauftragte arbeiten kann, schaue ich es mir sofort wieder an. Der Kern ist besser, als ich erwartet habe. Er transportiert nur nichts.

---

## Jonas K. — lebt von Bug Bounties, Platz ~300 auf HackerOne, sucht in jeder neuen Seite innerhalb von zwei Stunden alles, was sich melden liesse — Bug-Bounty-Jaeger, 25

**Note 5.2 · wuerde nutzen: nein**

### Begruendung der Note

Das Handwerk ist deutlich ueberdurchschnittlich: CSP mit Hashes statt unsafe-inline, connect-src 'none', kein Drittanbieter, keine Prototype Pollution, DMARC p=reject, keine haengenden Subdomains, und die AAD-Bindung haelt der Manipulation stand. 48 MB kamen bit-genau zurueck. Dagegen stehen vier belegte Defekte in genau der Funktion, an der die ganze Zusage haengt — dem Passwort. Der schwerste: acht Leerzeichen als Passwort erzeugen klaglos einen Drop OHNE Passwort, mit dem Rohschluessel im Link, ohne eine einzige Meldung. Das ist eine stille Herabstufung von "geschuetzt" auf "ungeschuetzt", und sie ist mit drei Zeilen Code verursacht. Dazu ein Zip-Slip im selbstgebauten Archiv und eine CSP-Luecke auf jeder 404-Antwort. Und das Produkt kann seine Kernfunktion nicht: ein Link oeffnet nur im Browser, der ihn erzeugt hat. Fuer eine Vorschau ist das gesagt, aber es bleibt ein Werkzeug, das nichts uebertraegt.

### Blocker

1. Ein Link oeffnet nur in dem Browser, der ihn erzeugt hat. Gemessen: im zweiten Browserkontext nach 1,53 s "Nothing here to open". Ein Werkzeug zum Dateiversand, das nicht versendet, hat fuer mich keinen Anwendungsfall — und ich bin nicht die Zielgruppe, ich verschicke ohnehin kaum Dateien.
2. Die Passwortfunktion ist an vier Stellen defekt, davon eine stille Herabstufung auf gar kein Passwort. Solange das so ist, kann ich niemandem raten, sich auf ein CloakDrop-Passwort zu verlassen.
3. Kein Repository, keine Lizenz, kein Signieren der ausgelieferten Seite. /opensource sagt selbst: "CloakDrop is not open source" und "The relay's code will not be published either". Lesbar ist nicht pruefbar — ich kann nicht feststellen, ob mir morgen dieselbe Seite ausgeliefert wird wie heute. Bei einem Zero-Knowledge-Versprechen ist das der eigentliche Vertrauensanker, und er fehlt.
4. Kein Meldeweg mit Frist und ohne Safe-Harbour-Satz. Es gibt eine security.txt und eine Adresse, aber keine Zusage, was mit einem Bericht passiert und dass Forschung erlaubt ist.

### Was gut ankam

- Die CSP ist echt und eng: default-src 'none', connect-src 'none', script-src ausschliesslich mit SHA-256-Hashes statt 'unsafe-inline', base-uri 'none', frame-ancestors 'none'. Das macht so gut wie niemand, und es hat meine DOM-XSS-Suche in zehn Minuten beendet.
- Der Netzwerk-Tab bleibt wirklich leer. Waehrend des Verschluesselns von 48 MB: null Anfragen. Insgesamt drei Anfragen fuer die ganze Sitzung, alle Dokumente von cloakdrop.com. Keine Fonts, kein Analytics, kein Service Worker, localStorage leer bis auf die Theme-Einstellung.
- 48 MB kamen bit-genau zurueck: sha256 von poc-report.md, capture.har und dem 40-MB-Video identisch zum Original.
- Die AAD-Bindung haelt der Manipulation stand. expires im Datensatz auf zehn Jahre hochgesetzt -> "This drop did not open". Genau das, was /verify verspricht.
- Prototype Pollution ueber das Fragment nicht moeglich (#__proto__=x&t=a&k=b, danach ({}).x -> sauber). Der Hash-Parser schreibt in ein Objektliteral.
- BIDI-Steuerzeichen im Dateinamen werden entfernt: "rechnung[U+202E]gpj.exe" erscheint als "rechnunggpj.exe". Angezeigter und gespeicherter Name gehen nicht auseinander.
- Voller Speicher wird sauber behandelt: nach 30,4 s ehrliche Meldung, danach transfers=[] und chunks=0 — nichts liegengeblieben.
- Neuladen mitten im Verschluesseln: der Rest taucht als "Unfinished" in der Uebersicht auf, mit Erklaerung, und ist nach 14 s selbst aufgeraeumt. Speicherbelegung 76 MB -> 48 MB, gemessen.
- Die Bremse bei falschen Passwoertern waechst wie beworben: 0,25 / 0,87 / 1,37 / 2,40 / 4,42 / 8,50 Sekunden ueber sechs Versuche.
- DNS-Hygiene ist besser als bei den meisten Programmen, die ich teste: DMARC p=reject, SPF, kein Wildcard, keine haengenden Subdomains, status.cloakdrop.com zeigt auf dieselbe Instanz. Keine Uebernahmeflaeche.
- security.txt liegt frei, auch bei stehender Zugangswand (200, waehrend /index.html 401 gibt). Der Umfangsabschnitt darin sagt praezise, welche Befunde heute ueberhaupt zaehlen koennen — das spart einem Melder eine Stunde.
- Fremde Domain, javascript: und data: im Einfuegefeld werden sauber und mit brauchbarem Text abgewiesen. Zeilenumbruch mitten im Schluessel, Klammern um den Link und Grossbuchstaben im Host werden korrekt verarbeitet.
- Die Seiten luegen nicht ueber den Zustand: /limits schreibt "Only in the browser that created the drop" in die Tabelle, /status sagt "A status page is coming" statt einen gruenen Haken zu zeigen, /opensource sagt "CloakDrop is not open source". Das ist selten und es zaehlt.

### Heutige Loesung

PoC-Material haenge ich an den Report auf HackerOne oder Bugcrowd — deren Upload, deren Aufbewahrung, deren Rechtsabteilung. Fuer grosse Artefakte (pcap, Video, Speicherabbild) croc, weil es kein Konto braucht und der Kanal ephemer ist; frueher Firefox Send, bis Mozilla es 2020 wegen Malware-Missbrauch abgeschaltet hat. Zugangsdaten und Tokens gehen ueber Bitwarden Send, gelegentlich Signal. WeTransfer und Dropbox nehme ich nicht, weil die Bytes dort lesbar ankommen. Ich behalte das alles — CloakDrop kann nichts davon ersetzen, solange ein Link nur auf meinem eigenen Rechner aufgeht.

### Gemeldete Defekte (12)

- **Acht Leerzeichen als Passwort erzeugen klaglos einen Drop OHNE Passwort** (kritisch, gemessen)  
  Ort: index.html:3127 (Laengenpruefung auf pwFeld.value) gegen index.html:3361 (var passwort = ($('pw-input').value || '').trim())  
  Beleg: Gemessen mit Playwright: Passwort "        " (8 Leerzeichen) besteht die Mindestlaenge, es erscheint keine Fehlermeldung, der Drop wird erzeugt. Der erzeugte Link lautet https://cloakdrop.com/#t=DmxzGpVSKz2e&k=8VnGGGS3nqQIrHDNiVhJ... — Pruefung "hat s= im Fragment? False". Ohne s= greift der else-Zweig in 3361ff und schreibt den ROHEN AES-256-Schluessel in den Link. Der Nutzer hat ein Passwort gesetzt und glaubt, der Link allein oeffne nichts; er oeffnet alles.
- **Mindestlaenge von 8 Zeichen mit Leerzeichen umgehbar — Drop oeffnet mit einem Zeichen** (kritisch, gemessen)  
  Ort: index.html:3127 gegen index.html:3361  
  Beleg: Passwort "       a" (7 Leerzeichen + a, Laenge 8) geht ohne Meldung durch. Erzeugter Link: #t=ioMyL2w0h10t&k=z2lAHpGnpLzKrVIrP_uf7eyg-...&s=W9kruy0clhxX5R8W8QGURA. Entsperren mit "a" -> st-receive (geoeffnet). Entsperren mit "       a" -> st-pw, "That password does not open this drop." Der Schluessel ist also mit einem 1-Zeichen-Passwort gewickelt; 600.000 PBKDF2-Runden ueber 95 Kandidaten sind in unter einer Minute durch.
- **Sperrliste haeufiger Passwoerter mit einem angehaengten Leerzeichen umgehbar** (schwer, gemessen)  
  Ort: index.html:3121 (PW_ZU_HAEUFIG.indexOf(pwWert.toLowerCase())) gegen index.html:3361  
  Beleg: Passwort "password" wird korrekt abgelehnt ("That password is on every guessing list there is."). Passwort "password " mit Leerzeichen laeuft durch bis st-done, ohne jede Meldung. Der resultierende Drop laesst sich anschliessend mit "password" oeffnen — gemessen: Entsperren mit 'password' -> st-receive.
- **Absender trimmt das Passwort, Empfaenger nicht — Absender sperrt sich selbst aus** (schwer, gemessen)  
  Ort: index.html:3361 (.trim() beim Wickeln) gegen die Entsperrmaske, die feld.value roh an schluesselAuswickeln gibt (idx_script_1.js:1288/1310)  
  Beleg: Drop mit "password " erzeugt. Entsperren mit exakt derselben Zeichenkette "password " -> "That password does not open this drop." Entsperren mit "password" -> geoeffnet. Wer sein Passwort aus einem Passwortmanager oder aus einer Chatnachricht mit anhaengendem Leerzeichen kopiert, kann seinen eigenen Drop nie wieder oeffnen — ohne Hinweis, was passiert ist.
- **Zip Slip: ZIP-Eintragsnamen werden nicht auf Pfadtrenner geprueft** (mittel, gemessen)  
  Ort: index.html, Funktion zipBauen / eindeutigerName(sicherName(f.name), vergeben) — sicherName entfernt nur BIDI-Steuerzeichen (BIDI-Regex), keine / oder \  
  Beleg: Ueber die DataTransfer-API zwei Dateien mit den Namen '../../../evil.txt' und 'C:\\Windows\\Temp\\evil2.txt' in einen Drop gelegt, Drop erzeugt, "Download all" geklickt. Ergebnis 'evil and 1 more.zip', 268 Bytes. Rohbyte-Pruefung des Archivs: b"../../../evil.txt" enthalten = True, b"C:\\Windows\\Temp\\evil2.txt" enthalten = True. Beim Einzeldownload sanitisiert der Browser (Vorschlagsname '_.._.._evil.txt') — das Archiv baut die App selbst, dort sanitisiert niemand.
- **Keine Content-Security-Policy auf 404-Antworten — also auf jeder frei waehlbaren Adresse** (mittel, gemessen)  
  Ort: _headers: es gibt Bloecke fuer /404 und /404.html, aber Cloudflare Pages gleicht Regeln gegen den angefragten Pfad ab  
  Beleg: Gemessen mit Cookie ueber die Playwright-Request-API: /nichtda12345 -> 404, Laenge 287306, Content-Type text/html; charset=utf-8, Cache-Control no-store, X-Frame-Options DENY, Content-Security-Policy: FEHLT. Gleiches Ergebnis fuer /foo/bar/baz, /index.html/ und /CONTACT.html. Zum Vergleich: / und /about liefern die volle CSP.
- **Link mit Text dahinter scheitert — genau der Fall, den der Quelltextkommentar als geloest ausgibt** (mittel, gemessen)  
  Ort: index.html:4454 (frag = frag.replace(/\s+/g, '')) gegen index.html:4455ff (feld() liest das base64url-Alphabet)  
  Beleg: Eingabe im Feld "Open a link": <Link> + " Gruesse" -> st-error, "That is not a key". Ebenso <Link> + "\nViele Gruesse\nRoman" -> "That is not a key". Ursache: der Weissraum wird VOR dem Alphabet-Scan entfernt, also klebt das Folgewort am k-Feld (43 -> 50 Zeichen). Gegenprobe: <Link> + ". Gruesse" oeffnet, <Link> in Klammern oeffnet, Umbruch mitten im Schluessel oeffnet. Der Kommentar direkt ueber der Stelle nennt den Outlook-Fall ausdruecklich als behoben.
- **Ein Wort mit Doppelpunkt vor dem Link wird als fremdes URL-Schema gemeldet** (mittel, gemessen)  
  Ort: index.html:4413 (var schema = v.match(/^([a-z][a-z0-9+.-]*):/i)) und 4415 (Meldungstext)  
  Beleg: Eingabe "Hier: https://cloakdrop.com/#t=...&k=..." -> Feldmeldung "That is a hier: address, not a CloakDrop link. Paste the link itself, or only the part starting at the #." Das englische "Link:" davor loest dasselbe aus. Die Pruefung sollte fremde Schemata abwehren (javascript:, data: — beides funktioniert korrekt), trifft aber jedes Wort vor einem Doppelpunkt am Zeilenanfang.
- **Speicherwarnung wird geschrieben, ist aber nie sichtbar** (mittel, gemessen)  
  Ort: index.html ~3170 (sendeWarnung) und ~3179 (showState('st-progress')) — die Warnung landet in #send-err, das im Panel st-list liegt und zwei Zeilen spaeter versteckt wird  
  Beleg: Quota per CDP auf 12 MB gesetzt, 40-MB-Drop gestartet, #send-err alle 200 ms abgefragt: Text vorhanden ("This browser reports about 12.6 MB free, and this drop needs 40.0 MB plus room to write it..."), is_visible() durchgehend False. Der Nutzer wartet stattdessen 30,4 Sekunden auf den Timeout und bekommt erst dann eine Meldung.
- **Die Drop-Uebersicht zeigt eine manipulierte Ablauffrist als gueltig an** (klein, gemessen)  
  Ort: idx_script_1.js:954 (restText(ablaufVon(d) - Date.now())) liest record.expires im Klartext, ohne die AAD-Pruefung, die nur beim Oeffnen greift  
  Beleg: expires im IndexedDB-Datensatz auf Date.now() + 10 Jahre gesetzt (alt 1785616608658, neu 2100890254109). Oeffnen des Links -> korrekt "This drop did not open" (AAD haelt). Die Uebersicht zeigt danach weiter "Cloaked 2026-07-31 22:36 - opens for 3650 more days". Zwei widersprechende Aussagen aus derselben App.
- **verify.html zaehlt den gespeicherten Datensatz auf und laesst das einzige Klartext-Freitextfeld weg** (klein, gemessen)  
  Ort: verify.html, Pruefung 4: "transfers holds the id, an 8-byte IV prefix, a creation timestamp, the moment the drop stops opening, its total size in bytes, and the manifest"  
  Beleg: Gemessen ueber IndexedDB: Object.keys eines Datensatzes = ['manifest','ivPrefix','created','expires','aad','kdf','bytes','id','label'], mit label: 'PoC an Vendor' im Klartext. label, aad und kdf fehlen in der Aufzaehlung. privacy.html nennt das label — verify.html, die Seite mit dem Auftrag "geh selbst nachsehen", nicht.
- **Der Changelog nennt 310.000 PBKDF2-Runden, Code und Referenzseiten 600.000** (klein, gemessen)  
  Ort: changelog.html (Eintrag Preview 0.4: "PBKDF2-SHA256 over 310,000 rounds") gegen index.html:2652 (var KDF_RUNDEN = 600000), limits.html und glossary.html (beide 600,000)  
  Beleg: grep ueber die Dateien: changelog.html enthaelt nur 310,000, glossary.html und limits.html nur 600,000, der Code KDF_RUNDEN = 600000. Es gibt keinen Changelog-Eintrag zur Erhoehung. Wer den Changelog liest, um die Krypto zu beurteilen, bekommt die veraltete Zahl.

### Vollstaendiger Review

Ich verschicke fast keine Dateien. Wenn ich einem Vendor ein PoC-Video schicke, haenge ich es an den Report auf HackerOne oder Bugcrowd — deren Upload, deren Problem. Fuer alles Groessere nehme ich croc, weil es kein Konto braucht und in zwei Zeilen fertig ist, und fuer Zugangsdaten Bitwarden Send. Firefox Send haette ich behalten; das ist 2020 gestorben, weil Malware-Verteiler gemerkt haben, dass verschluesselte, kurzlebige Links praktisch nicht zu scannen und nicht abzuschalten sind. Genau dieses Grab steht am Ende des Weges, den CloakDrop eingeschlagen hat, und keine der Seiten hier erwaehnt es. Wormhole macht heute, was CloakDrop verspricht, mit 10 GB und einem Relay, das existiert.

Ich sehe mir eine Seite so an, wie ich jede ansehe: erst security.txt, dann Kopfzeilen, dann alles, was Nutzereingaben anfasst.

Nach 40 Sekunden hatte ich die security.txt. Sie liegt frei, auch bei stehender PIN-Wand — /index.html gab mir 401, /.well-known/security.txt gab 200. Das ist richtig gemacht und die Minderheit. Inhaltlich: Contact, Expires, Preferred-Languages, Canonical. Kein Policy, kein Encryption, keine Acknowledgments, keine Frist, kein Safe Harbour. "Es gibt kein Bug-Bounty und kein Geld — aber eine Antwort." Ehrlicher als die meisten, aber "eine Antwort" ist keine Zusage, und ohne Safe-Harbour-Satz weiss ich nicht, ob mir jemand einen Anwalt schickt, wenn ich ein Byte in einer IndexedDB kippe. Der Umfangsabschnitt darunter ist dagegen der beste, den ich seit langem gelesen habe: er sagt, dass Client-Befunde zaehlen und Server-Befunde noch nicht koennen. Das spart mir eine Stunde.

Kopfzeilen: HSTS mit includeSubDomains, nosniff, no-referrer, COOP und CORP auf same-origin, X-Frame-Options DENY, eine sehr enge Permissions-Policy. Die CSP ist default-src 'none' mit Skript-Hashes statt 'unsafe-inline' — das macht so gut wie niemand, und es ist der Grund, warum ich nach DOM-XSS gar nicht erst lange suchen musste. Ich habe trotzdem gesucht: sechs innerHTML-Stellen im Hauptskript, alle mit fest verdrahteten Strings, jeder Nutzerwert geht ueber textContent. Prototype Pollution ueber das Fragment habe ich probiert — #__proto__=x&t=a&k=b, danach ({}).x, Ergebnis "sauber". Der Parser schreibt in ein Objektliteral, und ein String an __proto__ ist ein No-op. Offene Weiterleitungen: keine. DNS: DMARC p=reject, SPF vorhanden, kein Wildcard, api/relay/app/staging existieren nicht, status.cloakdrop.com zeigt auf dieselbe Pages-Instanz. Keine Subdomain-Uebernahme. Ich habe hier nichts gefunden, was ich melden koennte, und das sage ich ungern.

Dann die eine Luecke, die ich doch gefunden habe: **jede nicht existierende Adresse liefert eine 287-KB-HTML-Seite ganz ohne Content-Security-Policy.** Gemessen an /nichtda12345, /foo/bar/baz, /index.html/, /CONTACT.html — Status 404, Content-Type text/html, Cache-Control no-store, X-Frame-Options DENY, CSP: fehlt. Die Datei _headers hat Bloecke fuer /404 und /404.html, aber Cloudflare Pages gleicht die Regeln gegen den ANGEFRAGTEN Pfad ab, und den bestimmt der Angreifer. Ein Projekt, dessen gesamte Haltung auf der CSP ruht, laesst sie auf genau der Seite fallen, die man unter jeder beliebigen URL ausliefern kann. Heute folgenlos, weil die 404-Seite kein Skript mit Nutzereingaben hat. Morgen nicht mehr.

Jetzt das Produkt. Ich habe sieben echte Dateien gebaut, 48 MB, darunter ein 40-MB-Video, eine 8-MB-HAR, ein Name mit 180 Zeichen, einer mit Umlauten und Emoji, eine leere Datei und "rechnung[U+202E]gpj.exe" — der Klassiker mit dem Richtungsumkehrzeichen. Die Liste zeigte "rechnunggpj.exe". Das Steuerzeichen ist raus, angezeigter und gespeicherter Name gehen nicht auseinander. Das haben schon groessere Anbieter nicht hinbekommen.

Verschluesselt war in 0,31 Sekunden. Netzwerk-Tab waehrend des ganzen Vorgangs: drei Anfragen insgesamt, alle drei Seitenaufrufe von cloakdrop.com, keine einzige waehrend des Verschluesselns. Kein Font, kein Analytics, kein Service Worker, localStorage leer bis auf das Theme, Cookies: nur das Wand-Cookie. Die Behauptung auf /verify — "Nothing leaves. No request appears at all" — habe ich geprueft statt sie zu glauben, und sie stimmt. Das Archiv kam bit-genau zurueck: sha256 von poc-report.md, capture.har und dem 40-MB-Video identisch zum Original.

Dann habe ich den Link genommen und in einem zweiten Browserkontext geoeffnet. Nach 1,53 Sekunden: "Nothing here to open. No drop with this address is stored in this browser." Das ist das Produkt. Ein Link, der ueberall ausser auf dem Geraet des Absenders eine Fehlerseite ist. Die Seiten sagen es an fuenf Stellen, /limits sagt es in der Tabelle, /about sagt es im ersten Absatz. Trotzdem: ich habe hier ein Werkzeug getestet, das Dateien nicht uebertragen kann.

Und dann bin ich auf das Passwort losgegangen, und da faellt es auseinander.

Bei 6,38 Sekunden im ersten Durchlauf: **"password " — mit einem Leerzeichen am Ende — laeuft durch die Sperrliste** und erzeugt einen fertigen Drop. Keine Meldung. Ich habe den Link geoeffnet und mit "password " entsperrt: "That password does not open this drop." Mit "password": geoeffnet. Der Absender trimmt (index.html:3361), der Empfaenger nicht (index.html:1288 im Skript). Zwei Folgen: die Sperrliste ist mit einem Leerzeichen erledigt, und wer sein Passwort mit einem Leerzeichen aus dem Passwortmanager kopiert, sperrt sich aus dem eigenen Drop aus.

Weiter: **"       a" — sieben Leerzeichen und ein a — geht durch die Mindestlaenge von acht Zeichen.** Gewickelt wird mit "a". Ich habe den Drop mit dem Buchstaben "a" geoeffnet, mit der eingegebenen Zeichenkette nicht. 600.000 PBKDF2-Runden ueber einen Zeichenraum von 95 Kandidaten sind in einer Minute durch. Die Pruefung in Zeile 3127 liest pwFeld.value, die Verwendung in Zeile 3361 liest .trim() — dazwischen liegen 230 Zeilen, und niemand hat die beiden je nebeneinandergelegt.

Und der schlimmste: **acht Leerzeichen als Passwort erzeugen einen Drop ganz ohne Passwort.** Der getrimmte Wert ist leer, der else-Zweig greift, das Fragment enthaelt kein s= — ich habe es geprueft, "hat s= im Fragment? False" — und im Link steht der Rohschluessel. Der Nutzer hat ein Passwort eingegeben, keine Fehlermeldung bekommen, die Fertig-Ansicht zeigt ihm den Link, und er verschickt ihn im Glauben, dass der Link allein nichts oeffnet. Er oeffnet alles. Das ist keine Unschoenheit, das ist eine stille Herabstufung der einzigen Zusage, die diese Funktion macht.

Was mich versoehnt: die Bremse funktioniert. Sechs Fehlversuche hintereinander: 0,25 / 0,87 / 1,37 / 2,40 / 4,42 / 8,50 Sekunden. Und die AAD-Bindung haelt. Ich habe im IndexedDB-Datensatz expires auf zehn Jahre hochgesetzt und den Link geoeffnet: "This drop did not open". Genau das Verhalten, das /verify verspricht. Die Uebersicht zeigt allerdings weiter "opens for 3650 more days" — sie liest den unbeglaubigten Klartext, waehrend der Oeffnungsweg korrekt verweigert. Zwei Wahrheiten auf einem Bildschirm.

Kaputtmachen: fremde Domain, javascript:, data: — alle sauber abgewiesen, mit brauchbaren Meldungen. Ein Zeilenumbruch mitten im Schluessel: geoeffnet. Klammern um den Link: geoeffnet. Grossbuchstaben im Host: geoeffnet. Aber **"Link + Leerzeichen + Wort" scheitert.** Ich habe den Link plus " Gruesse" eingefuegt: "That is not a key". Mit Zeilenumbruch und Signatur dahinter: dasselbe. Der Grund steht im Quelltext: Zeile 4454 entfernt erst allen Weissraum, Zeile 4455 liest dann das base64url-Alphabet — also klebt "Gruesse" am Schluessel und der ist 50 statt 43 Zeichen lang. Der Kommentar direkt darueber beschreibt genau diesen Fall als geloest und zitiert einen Tester mit "Ein Link am Satzende ist in Outlook der Normalfall". Er ist nicht geloest, und die Meldung ist die, die derselbe Kommentar als schuldzuweisend brandmarkt. Und: "Hier: https://cloakdrop.com/#..." bringt "That is a hier: address, not a CloakDrop link." Die Schema-Erkennung in Zeile 4413 greift auf das Wort vor dem Doppelpunkt. "Link:" davor loest dasselbe aus, und das ist die haeufigste Art, einen Link in eine Mail zu schreiben.

Das Archiv baut die Seite selbst, und dort hat niemand auf Pfadtrenner geprueft. Ich habe ueber die DataTransfer-API zwei Dateien mit den Namen "../../../evil.txt" und "C:\Windows\Temp\evil2.txt" untergeschoben und das Archiv heruntergeladen: beide Namen stehen roh in den ZIP-Bytes, mit Backslashes. Klassischer Zip Slip. Beim Einzeldownload rettet der Browser die Lage — der Vorschlagsname war "_.._.._evil.txt" —, aber das Archiv baut die App, und da rettet niemand.

Speicher volllaufen lassen: Quota per CDP auf 12 MB, dann 40 MB verschluesseln. Nach 30,4 Sekunden eine ehrliche Meldung, und danach transfers: [], chunks: 0 — nichts liegengeblieben. Sehr gut. Aber die Vorabwarnung ("This browser reports about 12.6 MB free, and this drop needs 40.0 MB") wird zwar geschrieben, ist aber nie sichtbar: sie landet in einem Feld der Listenansicht, die zwei Zeilen spaeter versteckt wird. Ich habe es alle 200 ms gemessen: Text vorhanden, sichtbar=False, durchgehend. 30 Sekunden Wartezeit, die vermeidbar waren.

Neuladen mitten im Verschluesseln: der Rest taucht als "Unfinished" in der Uebersicht auf, mit Erklaerung, und ist nach 14 Sekunden von selbst weg — 76 MB runter auf 48 MB, gemessen. Das ist gute Arbeit. Nach Browserschluss liegen die 48 MB weiter da, persisted meldet False, das heisst der Browser darf sie jederzeit raeumen — waehrend die App eine Frist von bis zu sieben Tagen verspricht.

Kleinigkeit, die mich als Pruefer aergert: /verify zaehlt auf, was im Datensatz steht — id, IV-Praefix, Zeitstempel, Ablauf, Groesse, Manifest. Gemessen stehen dort ausserdem aad, kdf und label. Das label ist das einzige Klartext-Freitextfeld der ganzen App. In privacy.html steht es, auf der Seite, die "geh nachsehen" sagt, fehlt es. Und /opensource ist die Adresse einer Seite, die "CloakDrop is not open source" sagt.

Ich wuerde es nicht benutzen. Nicht wegen der Fehler — die sind alle in einer Stunde behoben —, sondern weil ich kaum Dateien verschicke und dieses Ding keine verschickt. Wenn das Relay steht, sehe ich es mir wieder an. Dann werde ich zuerst die Passwortfunktion aufmachen.

---

## Reinhard Stellwag, ehrenamtlicher Buergermeister der Gemeinde Hohenbuch (2.400 Einwohner), hauptberuflich Zimmerermeister mit eigenem Betrieb — Ehrenamtlicher Buergermeister und Zimmerermeister, 58

**Note 5.2 · wuerde nutzen: nein**

### Begruendung der Note

Alles, was die Seite behauptet, habe ich nachgemessen, und es hat gehalten: null Netzanfragen beim Verschluesseln, kein Dateiname im Klartext im Speicher, 60 von 60 Dateien Byte fuer Byte identisch zurueck. Dafuer allein waeren es acht oder neun Punkte. Aber das Ding kann die eine Sache nicht, fuer die ich es brauche: der Link geht nur in dem Browser auf, in dem er entstanden ist — im frischen Browser stand nach 3,5 Sekunden "Nothing here to open". Ein Werkzeug, das der Empfaenger nicht oeffnen kann, ist fuer mich kein Werkzeug. Dazu kommen echte Maengel an dem, was schon da ist: die Uebersicht der gespeicherten Drops schneidet auf jedem Bildschirm die Ablauffrist ab und zeigt auf dem Handy nur noch drei Puenktchen. Und es gibt kein Wort Deutsch. Deshalb Mitte statt oben.

### Blocker

1. Der Uebertrager fehlt: der Link oeffnet ausschliesslich in dem Browser, der ihn erzeugt hat. Ich verschicke an zwoelf Gemeinderaete und an das Landratsamt — ein Werkzeug, das beim Empfaenger eine leere Seite zeigt, hat fuer mich null Nutzen, egal wie gut die Verschluesselung ist.
2. Kein Impressum mit Namen und Gerichtsstand, keine belastbare Datenschutzangabe. Als Behoerde darf ich kein Werkzeug einfuehren, bei dem ich dem Gemeinderat nicht sagen kann, wer dahintersteht und nach welchem Recht. Die Seite sagt das selbst: "treat this as something to try, not something to rely on at work."
3. Kein Auftragsverarbeitungsvertrag moeglich — heute mangels Server nicht noetig, aber ab dem Tag, an dem der Uebertrager laeuft, zwingend. Ich kann kein Verfahren einfuehren, das genau in dem Moment vertragsbeduerftig wird, in dem es nutzbar wird.
4. Oberflaeche und alle Erklaerungen nur auf Englisch. Meine Verwaltungsangestellten sollen das ohne mich bedienen koennen.
5. Fuer Vergabeunterlagen im Kern ohnehin ausgeschlossen: § 7 UVgO verlangt die Bereitstellung frei, vollstaendig und direkt ueber eine in der Bekanntmachung veroeffentlichte Adresse. Das leistet nur die Vergabeplattform, und das ist kein Vorwurf an CloakDrop, sondern eine Grenze meines Anwendungsfalls.

### Was gut ankam

- Es geht nichts weg vom Geraet, und das ist nicht geglaubt, sondern nachgemessen: null Netzanfragen beim Verschluesseln von 22,4 MB, von 300 MB und von 60 Dateien. Die Kopfzeile des Servers sagt default-src 'none' und connect-src 'none' — der Browser selbst verbietet der Seite das Telefonieren. Das ist ein Riegel, kein Versprechen.
- Die Dateinamen sind wirklich mitverschluesselt. Ich habe den gespeicherten Datensatz selbst aufgemacht: das Verzeichnis liegt als 329 Byte Chiffrat da, und eine Suche ueber alles Gespeicherte nach acht Suchwoertern (Vergabeunterlagen, Niederschrift, .pdf, application/pdf, Hohenbuch, Zimmerer, PDF-1.4, .docx) hat null Treffer ergeben.
- Nach dem Schliessen des Browsers steht im ganzen Profil auf der Platte weder ein Dateiname noch ein Inhalt noch der Schluessel im Klartext. Nur die Kennung des Drops liegt in einer Protokolldatei, und die verraet nichts.
- Die Daten kommen unversehrt zurueck. 60 Dateien einer kompletten Sitzungsmappe, alle 60 Byte fuer Byte identisch mit dem Original. Ein Dateiname mit 191 Zeichen kam vollstaendig zurueck, ein Name mit Umlauten, Guillemets und Haken ebenso.
- Das Tempo ist nicht zu glauben und war es doch: 22,4 MB in 0,5 s, 300 MB in 1,4 s, 60 Dateien in 0,2 s, das Sammelarchiv in 0,4 s.
- Kaputte Links werden verstanden statt zurueckgewiesen. Zeilenumbruch mittendrin, Leerzeichen mittendrin, Link mitten in einem Anschreiben zwischen Anrede und Gruss, in spitzen Klammern wie Outlook sie setzt, http statt https, nur das Fragment — alles ging auf. Fremde Domain wurde beim Namen genannt: "That link points at cloakdrup.com, not at this site."
- Ein verbogener Schluessel gibt keine halben Daten zurueck, sondern eine klare Ansage. An drei verschiedenen Stellen ein Zeichen getauscht, dreimal derselbe saubere Abbruch mit Erklaerung, was ein Authentifizierungsmerkmal ist.
- Abbruch, Neuladen, zweiter Tab, voller Speicher, abgelaufene Frist — ich habe fuenf Wege gesucht, es kaputtzumachen, und jeder endete in einem verstaendlichen deutschen Satz, aeh, englischen Satz, aber einem, den ein Mensch geschrieben hat. Ein abgebrochener Rest wird als "never finished" benannt und war nach zwanzig Sekunden von selbst weg (49,6 MB auf 0,0 MB nachgemessen).
- Der Loeschknopf will zweimal gedrueckt werden — "Press again to delete". Mit meinen Fingern und meinen Augen ist das genau richtig, und die Bruchstuecke waren danach tatsaechlich weg (Chunks von 4 auf 3).
- Die Ehrlichkeit ist das Auffaelligste am ganzen Produkt. Auf dem Schirm, auf dem ich den Knopf druecke, steht in einem eigenen Kasten, dass der Link beim Empfaenger nichts zeigt — vor dem Klick, nicht danach. Die About-Seite listet auf, was sie nicht hat und warum. Auf meine Frage nach dem dienstlichen Einsatz antwortet die Seite mit "treat this as something to try, not something to rely on at work". So etwas habe ich in dreissig Jahren am Bau nicht erlebt.
- Null Fehler in der Konsole ueber neun Seiten und alle Ablaeufe hinweg — der einzige, den ich gesehen habe, kam von der Zugangswand davor und gehoert nicht zum Produkt.
- Die leere Datei hat die App bemerkt und mir gesagt, bevor ich verschluesselt habe. Das kann meine Mailanlage nicht.

### Heutige Loesung

Vergabeunterlagen laufen ueber die eVergabe-Plattform des Landes — das ist nach § 7 UVgO Pflicht und bleibt so, daran aendert kein Produkt etwas. Alles andere: nichtoeffentliche Sitzungsunterlagen und Protokolle packe ich in ein 7-Zip-Archiv mit AES-256, haenge es an die E-Mail und sage das Passwort telefonisch durch — bei zwoelf Gemeinderaeten sind das zwoelf Anrufe, meist erledigt die Verwaltungsangestellte sechs davon. Plaene ans Landratsamt gehen auf einem USB-Stick, weil 18 MB durch unsere Mailanlage nicht durchpassen. WeTransfer haben wir zweimal benutzt und wieder gelassen, weil ich nicht erklaeren konnte, wo die Datei zwischendurch liegt; Dropbox, Google Drive und OneDrive fallen aus demselben Grund aus. SwissTransfer und Tresorit Send habe ich mir angesehen, DRACOON kenne ich vom Landkreis her. Firefox Send war dem, was CloakDrop will, am naechsten — abgeschaltet 2020, und seitdem habe ich nichts Vergleichbares gefunden. Mein 7-Zip-Weg ist umstaendlich und haesslich, aber er laeuft seit Jahren, kostet nichts und ich kann ihn jedem im Rathaus in fuenf Minuten erklaeren. Genau deshalb behalte ich ihn vorerst.

### Gemeldete Defekte (8)

- **Der Link oeffnet nur im eigenen Browser — beim Empfaenger kommt nichts an** (kritisch, gemessen)  
  Ort: gemessen im frischen Browserkontext; index.html:2178-2181 (bindnote); limits.html Tabellenzeile "Where a link opens"  
  Beleg: Drop mit 7 Dateien (22,4 MB) angelegt, Link genommen, in einem frisch gestarteten Browserkontext geoeffnet. Nach 3,5 s: "Nothing here to open — No drop with this address is stored in this browser." Der Empfaenger bekommt nie eine Datei. Die Seite sagt das vor dem Klick ausdruecklich an, es ist also keine Luege, aber es ist der Grund, warum ich das Produkt heute nicht einsetzen kann.
- **Uebersicht der gespeicherten Drops schneidet die Ablauffrist ab, auf dem Handy den ganzen Text** (schwer, gemessen)  
  Ort: index.html, .file-name in #drops-list (text-overflow: ellipsis / overflow: hidden / white-space: nowrap); erzeugt in dropsAnzeigen(), index.html:3522-3524  
  Beleg: Gemessen bei 1440x950 und 1366x768: Volltext "Cloaked 2026-07-31 22:47 · opens for 24 more hours" braucht scrollWidth 357 px, bekommt 220 px sichtbare Breite. Lesbar bleibt "Cloaked 2026-07-31 22:47 …" — die Frist fehlt. Bei 390x844 betraegt die sichtbare Breite 10 px, die Zeile zeigt nur "…", vier gleich aussehende Zeilen sind nicht unterscheidbar (Screenshot s15-uebersicht-390.png). Das ist genau der Schirm, den die App selbst als Rettungsweg bezeichnet, wenn der Link verloren ging.
- **Name des Sammelarchivs verstuemmelt Umlaute und Sonderzeichen** (mittel, gemessen)  
  Ort: index.html:4094 — .replace(/[^\w .()-]+/g, '')  
  Beleg: \w ist in JavaScript ohne u-Flag nur [A-Za-z0-9_], die Zeichen werden ersatzlos geloescht. Gemessen: Datei "Anlage 3 – Nachtrag (Übergabe) #2 & »Straße« 100% ✓.pdf" ergibt das Archiv "Anlage 3  Nachtrag (bergabe) 2  Strae 10 and 6 more.zip". Aus Übergabe wird bergabe, aus Straße wird Strae, aus 100% wird 10. Die Dateinamen INNERHALB des Archivs sind korrekt erhalten (mit zipfile geprueft, 7/7 bzw. 60/60 Byte-gleich) — betroffen ist nur der Archivname.
- **Passwortpruefung laesst ein einzelnes Woerterbuchwort durch, ohne Hinweis** (mittel, gemessen)  
  Ort: index.html:2658 (PW_ZU_HAEUFIG, 17 Eintraege) und index.html:3121-3132  
  Beleg: Sechs Passwoerter am echten Knopf durchgespielt: "1234" abgelehnt (zu kurz), "passwort" und "geheim12" abgelehnt (Liste). Durchgelassen wurden ohne jede Warnung: "Sommer26", "Gemeinde", "hallo123". Es gibt keine Staerkeanzeige. Der Hinweistext verspricht "three or four words beat eight random characters", erzwingt oder nudgt aber nichts. Bei einem Drop ohne Passwort traegt der Link den Schluessel — das Passwort ist also das Einzige, was einen weitergeleiteten Link wertlos macht.
- **Zwei verschiedene Zahlen fuer dieselbe Passwortableitung auf der eigenen Seite** (klein, gemessen)  
  Ort: changelog.html:1826 sagt 310,000 — limits.html:1957, glossary.html:2016 und privacy.html:1869 sagen 600,000 — index.html:2652 var KDF_RUNDEN = 600000  
  Beleg: Direkt aus den Dateien abgelesen. Im Changelog kommt "600,000" kein einziges Mal vor (grep -c ergibt 0), es gibt also keinen Eintrag, der die Erhoehung festhaelt. Auch README.md:30 nennt noch 310,000. Wer die Zahl nachpruefen will — und dazu fordert die Seite ausdruecklich auf — bekommt je nach Seite eine andere Antwort.
- **Bei vollem Speicher dauert es 30 Sekunden bis zur Fehlermeldung** (klein, gemessen)  
  Ort: gemessen; Vorabpruefung in cloakAndStore, index.html ab 3143  
  Beleg: IndexedDB im Inkognito-Kontext bis 2112 von 2124 MB gefuellt (88 Bloecke a 24 MB, dann QuotaExceededError). Danach 18,9-MB-Lageplan verschluesselt: 30,2 s lang steht "Encrypting locally — nothing has left your device", erst dann kommt die Meldung. Die Meldung selbst ist richtig und der Zustand wird sauber zurueckgerollt ("This browser ran out of room, so nothing was kept — the half-written pieces are already cleared."), aber eine halbe Minute ohne Regung ist bei uns die Zeit, in der jemand den Rechner neu startet.
- **Kein Deutsch, kein Sprachumschalter** (mittel, gemessen)  
  Ort: index.html:7 <html lang="en">, kein hreflang auf keiner Seite (grep -c hreflang = 0)  
  Beleg: Alle neun geprueften Seiten sind ausschliesslich englisch. Fuer eine deutsche Kommunalverwaltung mit zwei Verwaltungsangestellten und einem 61-jaehrigen Kaemmerer ist das ein Ausschlusskriterium — nicht weil Englisch unmoeglich waere, sondern weil ich rechtlich heikle Ablaeufe nicht in einer Sprache dokumentieren kann, die meine Mitarbeiter nicht sicher lesen.
- **Ob der Schluessel im Browserverlauf des Empfaengers landet, konnte ich nicht messen** (klein, vermutet)  
  Ort: index.html:3922 — history.replaceState(null, '', location.pathname + '#geoeffnet')  
  Beleg: Die App raeumt den Schluessel beim Oeffnen aus der Adresszeile, das ist im Quelltext nachlesbar und das Verhalten habe ich bestaetigt (nach Neuladen: "The key is no longer in the address bar"). Ob Chromes dauerhafte Verlaufsdatenbank den urspruenglichen Aufruf mit dem Schluessel trotzdem behaelt, konnte ich NICHT pruefen: der Testbrowser legt im Profil gar keine History-Datei an (profil3/Default enthaelt kein History). Ich vermute, dass der Eintrag ueberschrieben wird, kann es aber nicht belegen. Auf einem gemeinsam genutzten Rathausrechner waere das die Frage, die ich vor einer Einfuehrung beantwortet haben muesste.

### Vollstaendiger Review

## Wer ich bin und was ich zu verschicken habe

Ich bin seit elf Jahren ehrenamtlicher Buergermeister von Hohenbuch, 2.400 Einwohner, und hauptberuflich habe ich eine Zimmerei mit sieben Leuten. Im Rathaus sind zwei Angestellte und ein Kaemmerer. IT-Personal haben wir keins, unser Dienstleister kommt am ersten Dienstag im Monat. Was bei mir taeglich rausgeht: Sitzungsunterlagen an zwoelf Gemeinderaete, Plaene ans Landratsamt, und bei Ausschreibungen Unterlagen, bei denen Vertraulichkeit nicht Geschmackssache ist, sondern Recht. Wenn ein Bieter das Angebot eines anderen sieht, ist das Verfahren hin und wir haften.

Einen Punkt muss ich vorweg klarstellen, weil er das ganze Urteil faerbt: Vergabeunterlagen darf ich gar nicht per Link an einzelne Bieter schicken. § 7 UVgO verlangt, dass ich sie elektronisch frei, vollstaendig und direkt ueber eine in der Bekanntmachung veroeffentlichte Internetadresse bereitstelle. Das laeuft ueber die Vergabeplattform des Landes, daran ruettelt kein Produkt der Welt. CloakDrop kann und soll das nicht ersetzen. Wo ich es wirklich braeuchte, ist die andere Haelfte meiner Arbeit: der nichtoeffentliche Teil der Niederschrift, Personalsachen, Grundstuecksangelegenheiten, die Kostenberechnung, die noch keiner sehen soll. Genau da bin ich mit meiner heutigen Loesung unzufrieden, und deshalb habe ich mir eine Stunde genommen.

## Heute mache ich es so

7-Zip, AES-256-Archiv, Passwort per Telefon durchgesagt, das Archiv als Anhang per E-Mail. Fuer die Plaene ans Landratsamt einen USB-Stick, weil 18 MB Lageplan durch unsere Mailanlage nicht durchgehen. WeTransfer haben wir zweimal benutzt und danach nicht mehr, weil ich dem Kaemmerer nicht erklaeren konnte, wo die Datei zwischendurch liegt. Dropbox und Google Drive fallen aus demselben Grund raus. SwissTransfer und Tresorit Send habe ich mir angesehen, DRACOON kenne ich vom Landkreis. Firefox Send war das, was mir am naechsten kam, und das haben sie 2020 abgeschaltet. Mein 7-Zip-Weg ist haesslich, aber er funktioniert seit Jahren und kostet nichts.

## Der Test, Schritt fuer Schritt

Ich habe mir sieben echte Dateien angelegt, wie sie bei uns anfallen: Vergabeunterlagen mit zwoelf Seiten, ein Leistungsverzeichnis mit dreissig, die Niederschrift, die Bekanntmachung, einen 18,9-MB-Lageplan, dazu bewusst eine Datei mit Umlauten und Sonderzeichen — "Anlage 3 – Nachtrag (Übergabe) #2 & »Straße« 100% ✓.pdf" — und eine mit einem 191 Zeichen langen Namen, weil unsere Verwaltung so benennt. Zusammen 22,4 MB.

Nach 2,3 Sekunden waren alle sieben drin. Was mir sofort gefallen hat: die Liste hat gemeckert, bevor ich meckern konnte. "One of these files is empty (0 bytes) — they will be in the drop, but there is nothing in them. That is usually not what you meant." Das lag an meinem eigenen Testaufbau, nicht an der Seite — ich hatte den Pfad zu lang gebaut, Windows kam nicht mehr ran. Ich habe es mit kurzem Pfad wiederholt: 11.045 Byte, Name mit allen 191 Zeichen erhalten, PDF geht auf. Kein Fehler des Produkts, aber das Produkt hat den Mist bemerkt und mir gesagt. Das kann meine Mailanlage nicht.

Dann der Knopf. 22,4 MB in 0,5 Sekunden. Ich habe es nicht geglaubt und mit 300 MB nachgemessen: 1,4 Sekunden. Und mit einer ganzen Sitzungsmappe, 60 Dateien ueber zehn Tagesordnungspunkte: eingelegt in 2,1 Sekunden, verschluesselt in 0,2, das Sammelarchiv gebaut in 0,4. Danach habe ich alle 60 Dateien Byte fuer Byte mit den Originalen verglichen. 60 von 60 gleich. Da war ich zum ersten Mal beeindruckt.

Waehrenddessen habe ich mitgeschrieben, was das Geraet verlaesst. Null Anfragen. Nicht "nur harmlose" — null. Ich habe danach in die Kopfzeilen geschaut, die der Server mitschickt, und dort steht `default-src 'none'` und `connect-src 'none'`. Auf Deutsch: der Browser selbst verbietet der Seite, ueberhaupt irgendwohin zu telefonieren. Das ist nicht dasselbe wie ein Versprechen in einer Datenschutzerklaerung. Das ist ein Riegel, den nicht die Seite vorschiebt, sondern der Browser. Dann habe ich den gespeicherten Datensatz selbst aufgemacht: das Verzeichnis der Dateinamen liegt als 329 Byte Chiffrat da. Ich habe alles Gespeicherte nach acht Suchwoertern abgesucht — "Vergabeunterlagen", "Niederschrift", ".pdf", "application/pdf", "Hohenbuch" — kein einziger Treffer. Zum Schluss habe ich den Browser zugemacht und das ganze Profil auf der Platte durchsucht. Kein Dateiname, kein Inhalt, kein Schluessel. Nur die Kennung des Drops steht in einer Protokolldatei, und die verraet nichts.

## Und dann der Punkt, an dem es aufhoert

Ich habe den Link genommen und ihn so benutzt, wie ich es wirklich taete: in einem frischen Browser, so wie er beim Bieter oder beim Gemeinderat ankaeme. Nach 3,5 Sekunden stand da: "Nothing here to open. No drop with this address is stored in this browser."

Das war es dann. Nicht kaputt, nicht falsch — nicht gebaut. Der Uebertrager, der einen Drop von einem Browser zum anderen traegt, existiert nicht. Und ich muss der Seite lassen: sie luegt mich darueber an keiner Stelle an. Auf dem Schirm, auf dem ich den Knopf druecke, steht in einem eigenen Kasten "This link will open on this device only. Nothing is uploaded, so whoever you send it to sees an empty page." Das steht *vor* dem Klick, nicht danach. Ich habe in dreissig Jahren Bau keine Firma erlebt, die auf dem Angebotsblatt schreibt, was sie nicht kann. Respekt dafuer. Aber Respekt ersetzt keine Funktion.

## Wo ich es kaputtzumachen versucht habe

Ich bin Zimmerer, ich pruefe eine Verbindung, indem ich daran ziehe. Dreizehn Arten, einen Link zu verhunzen:

Abgeschnitten: "The part after the # is not a whole AES-256 key. Links get cut off by chat apps and line breaks more often than you would think." Zeilenumbruch mittendrin: ging trotzdem auf. Leerzeichen mittendrin: ging auf. Link mitten in einem Satz, mit "Sehr geehrte Damen und Herren" davor und "Mit freundlichen Gruessen" dahinter: ging auf. In spitzen Klammern, wie Outlook es macht: ging auf. Falsche Domain: "That link points at cloakdrup.com, not at this site." Ein Zeichen im Schluessel getauscht: "This drop did not open. The authentication tag does not match, and AES-GCM checks it before it returns a single byte." Ich habe das an drei Stellen im Schluessel wiederholt, jedes Mal derselbe saubere Abbruch, nie halbe Daten.

Passwoerter: "1234" abgelehnt mit Begruendung. "passwort" abgelehnt. Falsches Passwort beim Oeffnen: klare Ansage. Richtiges: nach 0,9 Sekunden offen.

Abbruch mitten im Verschluesseln von 300 MB: sauber zurueck, nichts liegen geblieben. Neuladen mitten drin: hinterlaesst einen Rest, aber der wird benannt — "One drop below was never finished" — und ich habe nachgemessen, dass er nach zwanzig Sekunden von allein weg ist, 49,6 MB auf 0,0 MB. Zweiter Tab, waehrend ich im ersten loesche: der zweite sagt "A piece is missing. What is gone cannot be reconstructed." Speicher volllaufen lassen: ich habe 2.112 von 2.124 MB zugemuellt, dann kam nach dreissig Sekunden "This browser ran out of room, so nothing was kept — the half-written pieces are already cleared." Ablauffrist zurueckgedreht: "This link no longer opens. Ask for a fresh link", und das Chiffrat war beim naechsten Start weg. 520-MB-Datei: Knopf grau, "over the 500.0 MB preview limit".

Ich habe es nicht kaputtbekommen. In keinem einzigen Fall.

## Was mich geaergert hat

Die Uebersicht der gespeicherten Drops ist die Notbremse — die Seite sagt selbst, dass sie dafuer da ist, wenn der Link weg ist. Auf ihr steht in jeder Zeile "Cloaked 2026-07-31 22:47 · opens for 24 more hours". Nur sieht man das nicht. Ich habe nachgemessen: der Text braucht 357 Pixel, bekommt 220. Lesbar bleibt "Cloaked 2026-07-31 22:47 …". Die Frist — der einzige Grund, warum ich da hinsehe — ist abgeschnitten. Auf dem Handy sind es 10 Pixel, da steht nur noch ein Puenktchen. Vier Zeilen untereinander, alle gleich, ein Schloss und "32.1 KB". Das ist auf einem 1440er Bildschirm mit reichlich Platz daneben. Aergerlich, weil es die eine Stelle ist, an der ich unter Zeitdruck waere.

Das Sammelarchiv heisst nach dem Download "Anlage 3  Nachtrag (bergabe) 2  Strae 10 and 6 more.zip". Aus "Übergabe" wird "bergabe", aus "Straße" wird "Strae". Im Archiv drin sind die Namen richtig, nur der Deckel ist verstuemmelt. Bei uns hat fast jede zweite Datei einen Umlaut.

Das Passwort. "Gemeinde" geht durch. "hallo123" geht durch. Beides acht Zeichen, beides in jeder Wortliste. Die Seite schreibt selbst "three or four words beat eight random characters" — und dann laesst sie ein einzelnes Woerterbuchwort durch, ohne ein Wort dazu. Wenn das Passwort das Einzige ist, was zwischen einem weitergeleiteten Link und einer Personalakte steht, ist mir das zu duenn.

Und: es gibt kein Wort Deutsch. Kein Umschalter, nichts. Ich komme mit Englisch zurecht, weil ich Werkzeugkataloge lese. Meine Verwaltungsangestellte, die die Sitzungsmappe verschickt, kommt nicht zurecht. Und einen Satz wie "The authentication tag does not match, and AES-GCM checks it before it returns a single byte" kann ich im Gemeinderat nicht verteidigen. Was ich nicht selbst erklaeren kann, fuehre ich nicht ein — das ist meine Regel, und die gilt auch hier.

## Unterm Strich

Ich habe selten ein Produkt gesehen, bei dem so viel von dem stimmt, was drauf steht. Jede einzelne Behauptung, die ich nachgeprueft habe, hat gehalten, und ich habe gruendlich geprueft. Die Seite "Verify a transfer" sagt einem sogar, wie man sie widerlegt, und beim Punkt "Was das nicht beweist" wird sie ehrlicher als die meisten es beim Verkaufen sind. Auch die Antwort auf meine Frage — kann ich das dienstlich einsetzen — ist keine Marketingantwort: "Until they are, treat this as something to try, not something to rely on at work."

Genau daran halte ich mich. Ich lege den Link ab und schaue in einem halben Jahr wieder rein. Wenn der Uebertrager laeuft, wenn ein Impressum mit Namen und Gerichtsstand da ist und wenn die Oberflaeche Deutsch kann, dann verschicke ich die nichtoeffentlichen Sitzungsunterlagen damit und nicht mehr mit 7-Zip. Fuer Vergabeunterlagen bleibt es bei der Vergabeplattform, da hilft mir kein Produkt.

Heute: nein. Aber es ist das erste Mal seit Firefox Send, dass ich mir den Termin zum Wiederkommen in den Kalender schreibe.

---

## Jonas Reithmayr — Indie-Entwickler, 27, Gamestudio zu dritt

**Note 4.4 · wuerde nutzen: nein**

### Begruendung der Note

Handwerklich ist das eine der saubersten Webanwendungen, die ich dieses Jahr getestet habe: 405 MB in 4,0 Sekunden verschluesselt, alle fuenf Dateien byte-identisch zurueck, waehrend des gesamten Vorgangs null Netzwerk-Requests, und in 408 MB IndexedDB auf der Platte kein einziger lesbarer Dateiname und kein Byte Klartext. Dafuer gaebe es von mir eine 8. Nur ist das Produkt fuer mich unbrauchbar: es gibt kein Relay, ein Link oeffnet nachweislich nur im erzeugenden Browser, und die Obergrenze liegt bei 500 MB — meine Builds sind 800 MB bis 6 GB. Ein Werkzeug zum Verschicken, das nichts verschickt, loest mein Problem zu null Prozent. Dazu kommt ein gemessener Widerspruch: der Schluessel steht nach dem Oeffnen weiterhin vollstaendig in der Chrome-History, obwohl die Seite behauptet, er lebe "nur noch im Link". Zwei weitere Fehler (Rat auf einen Knopf, der nicht da ist; falsche Groessenangabe nach Abbruch) sind klein, aber real. 4,4 ist die Note fuer "exzellent gebaut, aber es tut die Sache nicht".

### Blocker

1. Kein Relay: der Link oeffnet nachweislich nur im erzeugenden Browser. Im fremden Kontext kam nach 3,0 Sekunden 'Nothing here to open'. Ein Uebergabewerkzeug, das nichts uebergibt, loest mein Problem zu null Prozent.
2. 500 MB Obergrenze pro Drop (MAX_TOTAL, index.html Zeile 2581). Meine Builds sind 800 MB bis 6 GB. Selbst mit Relay muesste ich einen 3-GB-Build in sieben Drops mit sieben Links saegen — das schickt man keinem Journalisten.
3. Keine Lizenz und kein Repository (opensource.html: 'CloakDrop is not open source'). Genau das hat Firefox Send umgebracht: als Mozilla abschaltete, gab es nichts zum Weiterbetreiben. Ich haenge unsere Presse-Auslieferung nicht an einen Dienst, den niemand ausser dem Betreiber weiterfuehren darf.
4. Der AES-Schluessel ueberlebt im Chrome-Verlauf. Solange das so ist und die Seite das Gegenteil behauptet, geht kein unangekuendigter Build durch dieses Werkzeug.

### Was gut ankam

- 101,5 MB/s beim Verschluesseln: 405 MB in 4,0 Sekunden, gemessen. Schneller, als ich bei WeTransfer die Datei ausgewaehlt habe.
- Vollstaendig verlustfreier Rundlauf: 5 Dateien à 240/120/45 MB plus zwei Textdateien, alle fuenf SHA-256-identisch zum Original. Bei 60 kleinen Dateien 60 von 60 identisch.
- Null Netzwerkverkehr, doppelt geprueft: waehrend des gesamten Verschluesselns nur die Dokument-Requests, und im Quelltext null Treffer fuer fetch(, XMLHttpRequest, WebSocket und sendBeacon.
- Echte CSP vom Server: default-src 'none'; connect-src 'none'; script-src mit SHA-256 pro Block, kein unsafe-inline. Dazu no-referrer, COOP/CORP same-origin, X-Frame-Options DENY.
- Nichts Lesbares auf der Platte: 408 MB IndexedDB durchsucht, kein einziger Dateiname im Klartext, und eine 64-Byte-Probe aus der Mitte meines 7z fand sich nirgends.
- Link-Verarbeitung genau richtig kalibriert: Zeilenumbruch mitten im Link, Link mitten in einem Satz, Leerzeichen, spitze Klammern, http statt https — alles geht auf. Fremde Domain wird beim Namen genannt und gestoppt, gekuerzter Schluessel bekommt eine eigene Fehlermeldung.
- Abbruch mitten im Verschluesseln raeumt vollstaendig auf: bei 17 geschriebenen Bruchstuecken abgebrochen, danach IndexedDB leer, 0 Bruchstuecke, Speicher zurueck auf 28 KB — und die Dateiauswahl blieb stehen.
- Speicher voll wird korrekt behandelt: der gescheiterte fuenfte Drop hinterliess keinen Waisen-Datensatz, 408 Bruchstuecke = exakt 4 × 102 der vier fertigen Drops.
- Passwortpruefung ohne Theater: zu kurz, zu haeufig, richtig, falsch — jeweils die passende Antwort, PBKDF2-SHA256 mit 600.000 Runden und der Rundenzahl im Datensatz, damit alte Drops weiter aufgehen.
- Die Ehrlichkeit der Textseiten. /verify hat einen Abschnitt 'What this does not prove' mit fuenf Punkten, darunter 'It does not audit the code you are running' und 'It does not hide how much you sent'. /opensource sagt geradeheraus 'CloakDrop is not open source'. Die Arbeitsplatz-FAQ sagt 'treat this as something to try, not something to rely on at work'. Das habe ich so noch auf keiner Produktseite gesehen.

### Heutige Loesung

Steam-Depots mit Review-Keys fuer Presse und Publisher, Google Drive fuer externe Tester. Ich behalte beides — nicht weil es gut ist (Drive verlangt ein Konto, Steam geht nur fuer Steam-Titel und ist beim Hochladen langsam), sondern weil CloakDrop heute nichts verschickt und bei 500 MB stehenbleibt. Frueher probiert und wieder verworfen: WeTransfer (keine Ende-zu-Ende-Verschluesselung, Link ist oeffentlich), croc und Wormhole (beide Seiten muessen gleichzeitig online sein — mit einem Journalisten in Kalifornien nie), Bitwarden Send (250 MB), Mega (Konto, App, Aerger), Proton Drive und Filen (gut, aber ich zahle dann fuer Cloud-Speicher, den ich nicht will). Firefox Send war das Richtige und ist seit 2020 tot.

### Gemeldete Defekte (6)

- **AES-Schluessel bleibt vollstaendig in der Chrome-History stehen, obwohl die Seite das Gegenteil behauptet** (schwer, gemessen)  
  Ort: index.html Zeile 3922 (history.replaceState) und der Text im Block #keynote, Zeilen 2272-2274  
  Beleg: Sichtbarer Chromium mit echtem Profil (p54profil3): Drop erzeugt, eigenen Link geoeffnet, Browser geschlossen. In Default/History, Tabelle urls, steht danach die Zeile 'https://cloakdrop.com/#t=FH8RrztWq-Vt&k=DpLKCZaI5JptQuuODyXh0HqsJ8iKgsR86fIoWUQXx6Q' — der komplette 32-Byte-Schluessel. SQL-Zaehlung: select count(*) from urls where url like '%&k=%' ergab 1. Die Adresszeile zeigte korrekt '#geoeffnet'. Der Text der Empfangsansicht sagt aber: 'It was sitting in your history... It lives only in the link now.' replaceState raeumt die Adresszeile, nicht die History-Datenbank; bei eingeschaltetem Chrome-Sync geht der Schluessel damit an Google.
- **Bei erschoepftem Speicher verweist die Fehlermeldung auf einen Knopf, der auf diesem Bildschirm nicht existiert** (mittel, gemessen)  
  Ort: index.html Zeilen 3257-3263 (Fehlertext) gegen Zeilen 2124-2127 (storeline/#drops-open liegt in #st-idle)  
  Beleg: Frischer Kontext, Kontingent 1,99 GB. Nach vier 405-MB-Drops scheiterte der fuenfte mit 'This browser ran out of room... delete an older drop under Manage.' Im selben Moment abgefragt: #st-idle=false, #storeline=false, #drops-open=false. Alle sichtbaren Knoepfe im Panel: Cloak files, Open a link, ×, ×, ×, + Add more, 1 hour, 24 hours, 7 days, Cloak & create link. Das Wort 'Manage' kam sichtbar genau einmal vor — im Fehlertext selbst. Erst nach dem Wegklicken aller drei Dateien wurde #drops-open sichtbar (dann war die Auswahl weg).
- **Unfertiger Drop meldet in der Uebersicht deutlich weniger Bytes, als tatsaechlich auf der Platte liegen** (klein, gemessen)  
  Ort: index.html Zeilen 3269-3295 (Lebenszeichen nur alle 3000 ms, dort wird bytes:done geschrieben)  
  Beleg: CPU 12-fach gedrosselt, 405-MB-Satz, mitten im Verschluesseln neu geladen. Danach: drops-sum zeigte '1 drop · 36.0 MB', der IndexedDB-Datensatz bytes=36000000, aber chunks=20 (20 × 4 MB = 80 MB) und navigator.storage.estimate().usage = 80.045.812 Byte. Abweichung 44 MB. Der Kommentar im Quelltext nennt genau dieses Problem als geloest ('sonst zeigt die Uebersicht 100 MB an, wo 44 liegen'), das 3-Sekunden-Raster laesst es aber weiterbestehen.
- **Kein Abgleich zwischen zwei Tabs — der erste Tab zeigt Drops des zweiten nicht an** (klein, gemessen)  
  Ort: index.html, speicherZeile() wird nur bei eigenen Aktionen gerufen; kein visibilitychange- und kein focus-Handler im ganzen Skript  
  Beleg: Tab 1 auf der App geoeffnet (0 Drops, storeline unsichtbar). In Tab 2 einen Drop erzeugt (Link erhalten). Zurueck auf Tab 1, bring_to_front, 1,5 s gewartet: '#storeline sichtbar: False'. Grep ueber index.html nach visibilitychange/addEventListener('focus' liefert keinen Treffer.
- **ZIP-Bauer kennt kein ZIP64 — 32-Bit-Groessen und -Versaetze** (klein, vermutet)  
  Ort: index.html Zeilen 4191-4250 (zipBauen: kopf.setUint32(14/18/22), zk.setUint32(16/20/24/42), Endsatz ohne ZIP64-Record)  
  Beleg: Quelltext gelesen: alle Groessen- und Versatzfelder werden als Uint32 geschrieben, es gibt keinen 'zip64 end of central directory'-Satz und keine 0xFFFFFFFF-Marker-Logik (Grep nach zip64/4294967295: null Treffer ausser den CRC-Konstanten). Bei der heutigen Grenze von 500 MB folgenlos und deshalb nicht ausloesbar; oberhalb von 4 GB — also genau in dem Bereich, den ich brauche — laufen die Felder ueber. Der Fehlerfall ist von mir NICHT gemessen, nur der Code-Befund.
- **Kurzname wird ohne ein Wort bei 40 Zeichen abgeschnitten** (klein, gemessen)  
  Ort: index.html Zeilen 3527-3546 (Feld .drop-label)  
  Beleg: 400 'X' in das Kurznamenfeld gefuellt, Feld verlassen, Seite neu geladen: im Feld standen 40 Zeichen. Keine Meldung, kein Zaehler, kein Hinweis auf die Grenze.

### Vollstaendiger Review

## Wer ich bin und warum ich hier bin

Ich bin Jonas, 27, wir bauen zu dritt ein Spiel. Jede Woche gehen ein bis drei Windows-Builds raus: an unseren Publisher-Kontakt, an drei, vier Presseleute und an eine Handvoll externer Tester. Die Dinger sind zwischen 800 MB und 6 GB gross. Bei einem befreundeten Studio ist letztes Jahr ein Build vor der Ankuendigung durchgesickert — nicht wegen eines Hacks, sondern weil ein Tester den Drive-Link in einen Discord-Server geworfen hat. Seitdem bin ich paranoid.

Heute: Presse laeuft ueber Steam-Depots mit Review-Keys (funktioniert, ist aber Steam-only und dauert beim Hochladen), der Rest ueber Google Drive. Drive nervt, weil Tester ein Konto brauchen und der Link ab einer gewissen Zahl von Zugriffen plumpsen kann. Ich habe croc und Wormhole probiert (super, aber beide Seiten muessen gleichzeitig online sein — mit einem Journalisten in Kalifornien klappt das nie), Bitwarden Send (250 MB, lachhaft fuer uns), Mega (Konto, App, Kaefer), Filen und Proton Drive (gut, aber ich bezahle dann fuer Cloud-Speicher, den ich nicht will). Firefox Send war das einzige, was sich je richtig angefuehlt hat, und Mozilla hat es 2020 abgeschaltet, weil Malware-Leute es liebten. Seitdem warte ich auf einen Nachfolger. Jemand aus unserem Discord hat mir den CloakDrop-Link geschickt mit "sieht aus wie Firefox Send, aber ohne Server".

Also habe ich mich hingesetzt und es kaputt zu machen versucht. Vier Stunden, Playwright, echte Dateien, DevTools, und ja — ich habe auch in den Quelltext geschaut, weil ich das kann und weil eine Zero-Knowledge-Behauptung, die man nicht nachlesen kann, keine ist.

## Was passiert ist, mit Uhr

Ich habe mir einen echten Presse-Satz gebaut: `NebulaDrift_Win64_v0.7.3-press.zip` (240 MB), `NebulaDrift_Data.pak` (120 MB), `presskit_screens.7z` (45 MB), dazu README und Changelog. Zusammen 405 MB — schon das war ein Kompromiss, weil unser echter Build 2,8 GB hat.

Nach 2,6 Sekunden stand die Liste: "5 files · 405.0 MB". Klick auf "Cloak & create link". Nach 4,0 Sekunden war ich fertig. **101,5 MB/s.** Das ist schneller, als ich die Datei bei WeTransfer auch nur ausgewaehlt habe. Der Fortschrittsbalken sagte dabei "ENCRYPTING LOCALLY — 244.0 MB OF 405.0 MB (60%)", was ehrlich und ueberpruefbar ist. Im Netzwerk-Mitschnitt: drei Requests insgesamt, alle drei das HTML-Dokument selbst. Null sonst. Ich habe danach im Quelltext nachgezaehlt — `fetch(`, `XMLHttpRequest`, `WebSocket`, `sendBeacon`: **null Treffer in index.html**. Und der Server schickt `content-security-policy: default-src 'none'; connect-src 'none'` mit Skript-Hashes statt `unsafe-inline`. Das ist kein Marketing, das ist gebaut.

Link zurueck: 83 Zeichen. Ich habe ihn in ein frisches Browserprofil geworfen, so wie ein Tester ihn bekaeme. Nach 3,0 Sekunden: *"Nothing here to open. No drop with this address is stored in this browser."* Genau das, was die Seite ueber der Falz ankuendigt. Kein Betrug — aber eben auch kein Produkt.

Im eigenen Browser dann die Empfangsansicht nach 2,9 Sekunden, "5 cloaked files", "405.0 MB TOTAL · OPENS FOR 7 MORE DAYS". "Download all" lieferte nach 10,7 Sekunden ein ZIP namens `NebulaDrift_Win64_v0.7.3-press and 4 more.zip`. Ich habe alle fuenf Dateien per SHA-256 gegen die Originale gehalten: **fuenfmal identisch.** Bei 60 kleinen Shader-Dateien (das ist ein Fall, den ich auch habe) dasselbe: 1,7 s Verschluesseln, 0,4 s ZIP, 60 von 60 identisch. Das ist besser als das, was Drive mir liefert, wenn ich einen Ordner als ZIP ziehe.

## Wo ich es kaputt machen wollte

Ich habe 13 Varianten des Links durchprobiert. Das Ergebnis hat mich ehrlich ueberrascht:

- Link **mit Zeilenumbruch mittendrin** — geht auf. 
- Link **mitten in einem Satz** ("Hier ist der Build: https://... — Passwort kommt per Telefon.") — geht auf.
- Mit Leerzeichen davor und dahinter, in spitzen Klammern, mit `http://` statt `https://` — geht alles auf.
- **Fremde Domain** (`cl0akdrop.net`) — Stopp: *"That link points at cl0akdrop.net, not at this site."* Nennt die Domain beim Namen. Genau richtig, das ist die Phishing-Falle.
- **Um 8 Zeichen gekuerzt** — *"That is not a key. The part after the # is not a whole AES-256 key. Links get cut off by chat apps and line breaks more often than you would think."*

Das ist toleranter als Slack und strenger als jeder Passwortmanager, den ich benutze, und zwar an den jeweils richtigen Stellen. Ich habe schon Dienste gesehen, die an einem Leerzeichen im eingefuegten Link scheitern.

Passwoerter: `kurz1` abgelehnt mit Begruendung. `12345678` und `password` abgelehnt: *"That password is on every guessing list there is."* Ein Passsatz akzeptiert, der Link traegt dann zusaetzlich `&s=` (Salt), der Schluessel liegt eingewickelt drin. PBKDF2-SHA256, im Quelltext `KDF_RUNDEN = 600000` (Zeile 2652), pro Datensatz gespeichert, damit alte Drops weiter aufgehen. Falsches Passwort: *"That password does not open this drop."*, richtiges: nach 0,8 s offen. Sauber.

Abbruch mitten im Verschluesseln (ich habe die CPU 12-fach gedrosselt, um ueberhaupt hinzukommen): bei 10 %, 17 geschriebene Bruchstuecke, Klick auf Cancel — nach 1,2 s zurueck in der Auswahl, **IndexedDB leer, 0 Bruchstuecke, Speicher wieder bei 28 KB, Dateiauswahl noch da.** Neuladen mitten drin: Chrome fragt nach, danach steht ein "Unfinished"-Eintrag mit korrektem Warnhinweis in der Uebersicht, und beim naechsten Start ist er von selbst weg. Das ist Sorgfalt, die man in diesem Preissegment (kostenlos) nicht erwartet.

Speicher volllaufen lassen: frischer Kontext, 1,99 GB Kontingent, vier 405-MB-Drops passten, der fuenfte scheiterte nach 32 s — mit exakt der richtigen Meldung und komplett aufgeraeumt (4 Datensaetze, 408 Bruchstuecke = 4 × 102, kein Waisenkind).

Und die Forensik, die mir am wichtigsten war: 390 MB IndexedDB auf der Platte, ich habe nach `NebulaDrift`, `presskit`, `README_PRESS` gegrept — **null Treffer.** Dann habe ich 64 Byte aus der Mitte meines 7z genommen und 408 MB durchsucht: **null Treffer.** Der Build liegt wirklich verschluesselt da.

## Und jetzt die Sachen, die weh tun

**Erstens, und das ist der Grund fuer meine Note: es verschickt nichts.** Die Seite sagt das offen — "Today it encrypts and stores; it does not yet send" steht ueber der Falz, im Drop-Formular, in der Fertigansicht und auf der Status-Seite. Ich nehme ihnen das nicht uebel, ich finde es sogar bemerkenswert, weil neunzig Prozent aller Preview-Seiten genau an dieser Stelle luegen wuerden. Aber Ehrlichkeit ueber ein fehlendes Feature ist kein Ersatz fuer das Feature. Fuer meinen Fall ist das hier ein sehr huebscher lokaler Verschluesselungs-Demonstrator.

**Zweitens: 500 MB.** `MAX_TOTAL = 500 * 1000 * 1000` (Zeile 2581). Mein kleinster Build ist 800 MB. Der 620-MB-Test lieferte korrekt "over the 500.0 MB preview limit" und einen deaktivierten Knopf — funktioniert also, ist aber die Wand. Selbst wenn das Relay morgen kaeme, muesste ich einen 3-GB-Build in sieben Stuecke saegen und sieben Links plus sieben Passwoerter an einen Journalisten schicken. Das macht niemand.

**Drittens, und das ist der einzige Punkt, wo ich sauer werde:** Die Empfangsansicht sagt *"The key is out of the address bar. It was sitting in your history... It lives only in the link now."* Ich habe das mit einem sichtbaren Chrome und echtem Profil gemessen. In `Default/History`, Tabelle `urls`, steht nach dem Schliessen des Browsers immer noch:

`https://cloakdrop.com/#t=FH8RrztWq-Vt&k=DpLKCZaI5JptQuuODyXh0HqsJ8iKgsR86fIoWUQXx6Q`

Der vollstaendige AES-256-Schluessel. `history.replaceState` (Zeile 3922) raeumt die Adresszeile, nicht die History-Datenbank. Bei eingeschalteter Chrome-Sync landet mein Entschluesselungsschluessel damit bei Google. Auf einer Seite, deren gesamtes Argument "wir koennten nicht hinsehen, selbst wenn wir wollten" lautet, ist eine Aussage, die nachweislich nicht stimmt, teurer als anderswo. Der Satz muesste heissen: "aus der Adresszeile, nicht aus dem Verlauf — leere den, wenn es darauf ankommt."

**Viertens, klein aber aergerlich:** Als der Speicher voll war, sagte die App *"delete an older drop under Manage"*. Der Manage-Knopf war in diesem Zustand nicht sichtbar — ich habe alle sichtbaren Knoepfe abgefragt: `Cloak files, Open a link, ×, ×, ×, + Add more, 1 hour, 24 hours, 7 days, Cloak & create link`. Das Wort "Manage" kam auf dem ganzen Bildschirm genau einmal vor: in der Fehlermeldung selbst. Um hinzukommen, musste ich alle drei Dateien einzeln aus der Auswahl klicken — und damit die Auswahl wegwerfen, die die App bei ihrer anderen Fehlermeldung ausdruecklich "is still here" nennt.

**Fuenftens:** Nach dem Neuladen mitten im Verschluesseln sagte die Uebersicht "1 drop · 36.0 MB". Auf der Platte lagen 20 Bruchstuecke, `navigator.storage.estimate().usage` = 80.045.812 Byte. **44 MB Unterschied.** Der Kommentar im Quelltext sagt genau, warum das nicht sein soll ("sonst zeigt die Uebersicht 100 MB an, wo 44 liegen") — die Absicht stimmt, das Lebenszeichen laeuft nur alle drei Sekunden.

**Sechstens:** Zweiter Tab macht einen Drop, erster Tab merkt nichts. Kein `visibilitychange`- und kein `focus`-Handler im Quelltext.

**Siebtens, vorausschauend:** Der ZIP-Bauer (ab Zeile 4191) schreibt 32-Bit-Groessen und -Versaetze, kein ZIP64. Bei 500 MB egal. Wenn sie das Limit jemals auf die Groessen anheben, die ich brauche, faellt das um.

## Was mich ueberrascht hat

Im Guten: die Fehlermeldungen. Jede einzelne nennt Ursache, Folge und naechsten Schritt. *"This browser ran out of room, so nothing was kept — the half-written pieces are already cleared."* So schreibt man das. Und die Seiten drumherum — `/verify` hat einen Abschnitt "What this does not prove" mit fuenf Punkten, darunter "It does not audit the code you are running" und "It does not hide how much you sent". Die `/opensource`-Seite sagt in aller Deutlichkeit: *"CloakDrop is not open source... What it is, is readable."* Das ist eine Position, die ich nicht teile — ohne Lizenz kein Fork, kein Selberbetreiben, und genau daran ist Firefox Send gestorben — aber sie wird wenigstens nicht als Offenheit verkleidet. Auf HN wuerde das trotzdem gefressen werden.

Im Schlechten: dass ausgerechnet der Verlaufs-Satz nicht stimmt. Und dass die 500-MB-Grenze auf der Limits-Seite als selbstverstaendlich verkauft wird ("500 MB covers ordinary handovers"), obwohl jeder in meiner Branche und jeder Videomensch bei der Zahl nur den Kopf schuettelt.

## Bleibe ich bei Steam-Depots und Drive?

Ja. Ich habe keine Wahl — CloakDrop schickt nichts. Ich habe es trotzdem als Lesezeichen behalten, was ich sonst nie mache, und das aus einem einzigen Grund: wenn das Relay kommt und die Grenze auf 5 oder 10 GB geht, ist das der erste Firefox-Send-Nachfolger, dem ich einen unangekuendigten Build anvertrauen wuerde. Die Verschluesselung ist fertig, die Sorgfalt stimmt, das Tempo stimmt, und die Leute schreiben auf, was sie nicht koennen. Das ist eine seltene Kombination.

Heute ist es fuer mich aber ein Werkzeug, das meine Datei nimmt, sie perfekt verschluesselt, und sie mir dann wieder auf denselben Rechner legt. Das kann 7-Zip mit einem Passwort auch, und danach kann ich die Datei wenigstens verschicken.

**4,4.** Acht fuer die Ausfuehrung, eins fuer den Nutzen, minus etwas fuer den History-Satz, der nicht stimmt.

---

## Dr. Katrin Ellermann-Vosskuhl — Notarin, 49

**Note 4.2 · wuerde nutzen: nein**

### Begruendung der Note

Handwerklich ist das die sauberste Verschluesselungsstrecke, die ich seit Jahren im Browser gesehen habe: 153 MB in 2,7 Sekunden, kein einziger Netzwerkaufruf, byteidentische Rueckgabe, sauberes Aufraeumen nach Abbruch und Absturz. Dafuer allein wuerde ich 8 geben. Nur: das Produkt versendet nichts. Ein Link, den ich in Firefox oeffne, sagt "Nothing here to open" - gemessen, nicht vermutet. Ein Uebermittlungswerkzeug, das nicht uebermittelt, ist fuer mich kein Werkzeug, sondern eine Demonstration. Dazu fehlt das, was fuer mich vor Verschluesselung kommt: Zustellnachweis, Protokoll, Exportierbarkeit. Ich ziehe stark ab fuer den fehlenden Kern und rechne die Ehrlichkeit der Texte und die Qualitaet der Ausfuehrung wieder an. 4,2 ist die Note fuer eine sehr gute Haelfte eines Produkts.

### Blocker

1. Kein Versand: ein Link oeffnet ausschliesslich im erzeugenden Browser - in einem zweiten Kontext und in Firefox gemessen "Nothing here to open". Damit ist der eigentliche Zweck nicht vorhanden.
2. Kein Zustellnachweis und kein exportierbares Protokoll. Fuer eine notarielle Akte ist "wer hat wann was bekommen" wichtiger als die Verschluesselung; der gespeicherte Datensatz kennt kein einziges Zugriffsfeld.
3. Kein Kanzleibetrieb moeglich: Drops haengen am Browserprofil eines einzelnen Rechners. Meine vier Mitarbeiterinnen sehen sie nicht, im Krankheitsfall kommt niemand an den Vorgang.
4. Keine belastbare Rechtsgrundlage fuer den beruflichen Einsatz - die eigene FAQ stellt fest, dass ein Auftragsverarbeitungsvertrag mangels Betreiberrolle derzeit nichts hat, woran er anknuepfen koennte, und empfiehlt ausdruecklich, das Werkzeug beruflich noch nicht einzusetzen.
5. Nur Englisch: fuer Beteiligte jenseits der 65 in meiner Mandantschaft praktisch unbenutzbar.

### Was gut ankam

- Der Netzwerkmitschnitt bleibt wirklich leer: waehrend der Verschluesselung von 153 MB null Anfragen, waehrend Empfang und Download genau eine (das Laden der Seite selbst). Zusaetzlich erzwingt der ausgelieferte Kopfzeileneintrag `connect-src 'none'` das im Browser - eine verschlossene Tuer statt einer Zusage.
- Byteidentische Rueckgabe: alle fuenf PDF aus dem ZIP mit den Originalen verglichen, identisch. Auch bei 153 MB und bei 30 Dateien auf einmal.
- Tempo: 2,9 MB in 0,5 Sekunden, 153 MB in 2,7 Sekunden, ZIP von 152,9 MB in 4,6 Sekunden gebaut. Mein beA braucht fuer denselben Vorgang drei bis fuenf Minuten.
- Aufraeumen nach Stoerung: Abbruch bei 20 Prozent von 450 MB hinterlaesst null Datensaetze und null Bruchstuecke (Speicher zurueck auf 48 KB). Neuladen mitten drin hinterlaesst einen Rest, benennt ihn in der Uebersicht als "Unfinished" mit Warnung und raeumt ihn selbsttaetig weg (184 MB auf 109 KB gemessen). Speicher volllaufen lassen liefert eine klare Meldung statt eines Haengers.
- Keine Klartextspur auf der Platte: nach Schliessen des Browsers das gesamte Profil nach "Kaufvertrag", "Grundbuch", "Vollmacht", "Sparkasse" und ".pdf" durchsucht - null Treffer. Die Dateinamen sind wirklich mitverschluesselt.
- Die Ablauffrist ist ins Chiffrat gebunden: Frist im Datensatz von einer Stunde auf zehn Jahre gesetzt, danach oeffnet der Drop nicht mehr ("The authentication tag does not match"). Das ist strenger, als die eigene FAQ zugibt.
- Loeschen loescht: zwei Klicks mit Bestaetigung ("Press again to delete"), danach schrumpft das Browserprofil von 156,9 MB auf 4,1 MB und der Link meldet "Nothing here to open".
- Passwortpruefung mit Haltung: unter acht Zeichen und Listenpasswoerter werden mit Begruendung abgelehnt, falsches Passwort liefert nach 4,1 Sekunden nichts statt etwas Falschem, 600.000 PBKDF2-Runden.
- Die Texte sagen, was das Werkzeug NICHT kann - "What this does not prove" mit fuenf Punkten, "CloakDrop is not open source", und in der FAQ zum beruflichen Einsatz woertlich "treat this as something to try, not something to rely on at work". Rechtlich die sauberste Haltung, die ich seit langem bei einem Anbieter gesehen habe.
- Fehlermeldungen benennen Ursachen statt Schuld: abgeschnittener Link, fremde Domain, unfertiger Drop, abgelaufener Drop und Schluessel-aus-der-Adresszeile bekommen je eine eigene, zutreffende Erklaerung.

### Heutige Loesung

Fuer Gerichte, Grundbuchamt und Anwaelte das besondere elektronische Notarpostfach ueber XNP: traege, Kartenanmeldung jeden Morgen, aber es erzeugt Sende- und Eingangsprotokolle, die ich in die Akte hefte - deshalb behalte ich es. Fuer Banken deren Portale oder passwortgeschuetzte PDF per Mail mit Passwort per Telefon. Fuer Mandanten PDF per Mail, bei aelteren Beteiligten schlicht Post. Fuer grosse Anlagenkonvolute notgedrungen WeTransfer, was mir jedes Mal unangenehm ist. Firefox Send hatte ich 2019 kurz im Einsatz und 2020 durch die Einstellung verloren - seither traue ich Gratisdiensten nicht mehr als Infrastruktur. Tresorit steht fuer naechstes Jahr auf der Liste, weil sie einen Auftragsverarbeitungsvertrag unterschreiben und Zustellbestaetigungen liefern. Ich wechsle nicht.

### Gemeldete Defekte (11)

- **Das Produkt kann keine Datei an einen anderen Menschen uebermitteln** (kritisch, gemessen)  
  Ort: Gesamtprodukt; Meldung in index.html Zeile 3943  
  Beleg: Link aus Chromium-Kontext A in einem zweiten, getrennten Chromium-Kontext geoeffnet: st-error, Titel "Nothing here to open", Text "... in this build a drop lives only in the browser that made it ... The relay that carries drops between browsers is being built." Gegenprobe mit einem voellig anderen Browser (Firefox, frisches Profil): identische Fehlerseite. Beide Male ueber Playwright gemessen, nicht aus dem Text der Seite abgeleitet.
- **Kein Zustellnachweis, kein Zugriffsprotokoll, nichts Exportierbares** (schwer, gemessen)  
  Ort: IndexedDB 'cloakdrop', Objektspeicher 'transfers'  
  Beleg: Datensatzfelder nach Oeffnen eines Drops ausgelesen: ['manifest','ivPrefix','created','expires','aad','kdf','bytes','id','label']. Kein Feld fuer Zugriffszeitpunkt, keins fuer Empfaenger, kein Zaehler, keine Exportfunktion in der Oberflaeche. Fuer eine notarielle Akte gibt es damit nichts, was in fuenf Jahren eine Uebergabe belegt.
- **Ein Link mit Text DAHINTER wird abgewiesen, obwohl der Code genau diesen Fall zu loesen behauptet** (mittel, gemessen)  
  Ort: index.html Zeile 4454, Funktion tryOpenLink  
  Beleg: Eingabe "https://cloakdrop.com/#t=...&k=... Das Passwort folgt telefonisch." in das Einfuegefeld: st-error, "That is not a key". Ursache im Quelltext: `frag = frag.replace(/\s+/g, '');` laeuft VOR dem Auslesen der base64url-Felder, dadurch klebt der Folgetext am k-Wert. Punkt, Klammern, ein zitierendes ">" davor und ein ganzer Satz VOR dem Link funktionieren dagegen alle - getestet, 8 Varianten. Der Kommentar unmittelbar ueber der Zeile zitiert genau diesen Outlook-Fall als geloest.
- **Kurzname wird stillschweigend auf 40 Zeichen gekappt - genau vor der Urkundenrollennummer** (mittel, gemessen)  
  Ort: index.html Zeile 3533 (namensfeld.maxLength = 40)  
  Beleg: Eingabe "Kaufvertrag Mueller ./. Schaefer, UR-Nr. 412/2026, an die Sparkasse und an das Grundbuchamt" (91 Zeichen). Gespeichert und nach Neuladen angezeigt: "Kaufvertrag Mueller ./. Schaefer, UR-Nr." - abgeschnitten, ohne Hinweis, ohne Zeichenzaehler. Die Aktenkennung, die den Eintrag ueberhaupt erst brauchbar macht, faellt weg.
- **Uebersicht verschweigt, welcher Drop passwortgeschuetzt ist** (mittel, gemessen)  
  Ort: Zustand st-drops, Liste #drops-list  
  Beleg: Drei Drops angelegt, davon einer mit Passwort. Der Text der gesamten Liste enthaelt das Wort "password" kein einziges Mal (programmatisch geprueft). Jede Zeile zeigt nur "Cloaked <Datum> - opens for N more hours", Groesse und Loeschknopf. Wer mehrere Vorgaenge am Tag anlegt, weiss spaeter nicht mehr, zu welchem er ein Passwort telefonisch durchgeben muss.
- **Aus der Uebersicht laesst sich der Link nicht wiederherstellen, und im Moment der Anzeige warnt nichts davor** (mittel, gemessen)  
  Ort: Zustand st-drops / st-done  
  Beleg: In der Drop-Liste programmatisch nach Link- oder Kopierknoepfen gesucht: 0 Treffer. Nur "Delete" ist vorhanden. Bauartbedingt richtig (der Schluessel wird nirgends gespeichert), aber der Bildschirm, auf dem der Link erscheint, sagt nicht, dass dies die einzige Kopie ist; der Hinweis steht nur in der FAQ auf limits.html.
- **Abgelaufenes Chiffrat bleibt auf der Platte liegen, bis die Seite zufaellig wieder geoeffnet wird** (klein, gemessen)  
  Ort: Browserprofil, Default/IndexedDB/https_cloakdrop.com_0.indexeddb.blob  
  Beleg: Nach Schliessen des Browsers ohne Loeschen des Drops: 156,9 MB Profil, davon 152,9 MB IndexedDB-Bruchstuecke. Nach ausdruecklichem Loeschen im anderen Profil: 4,1 MB. Klartext-Suche nach "Kaufvertrag", "Grundbuch", "Vollmacht", "Sparkasse", ".pdf": null Treffer, es bleibt also nur Chiffrat - aber es bleibt, unbegrenzt, wenn die Seite nie wieder aufgerufen wird. Die Seite raeumt es korrekt weg, sobald man sie oeffnet (184 MB auf 109 KB gemessen).
- **Nur Englisch, keine deutsche Fassung, kein Umschalter** (klein, gemessen)  
  Ort: index.html Zeile 7: <html lang="en">  
  Beleg: Browser mit locale de-DE aufgerufen, alle acht Inhaltsseiten in englischer Sprache ausgeliefert; document.documentElement.lang = "en". Kein Sprachwaehler, kein hreflang. Meine Empfaenger sind zu einem grossen Teil Privatpersonen ueber 65.
- **Fusszeile sagt "Status page - coming soon", die Statusseite existiert aber und ist aufrufbar** (klein, gemessen)  
  Ort: Fusszeile aller Seiten vs. https://cloakdrop.com/status.html  
  Beleg: status.html laedt und liefert 3597 Zeichen Inhalt; sie erklaert selbst, dass eine Statusseite noch kommt. In der Fusszeile jeder Seite steht daneben unverlinkt "Status page - coming soon". Zwei Aussagen ueber denselben Gegenstand an derselben Stelle.
- **Menuepunkt "Read the code" verspricht mehr, als die dahinterliegende Seite haelt** (klein, gemessen)  
  Ort: Hauptnavigation vs. opensource.html  
  Beleg: Der Menuepunkt steht unter "PLATFORM" gleichrangig neben "Changelog". Die Zielseite sagt woertlich: "CloakDrop is not open source: there is no repository, no licence, and no permission to redistribute it." Inhaltlich ehrlich, das Etikett im Menue ist es nicht.
- **Laengste Frist sind sieben Tage, Verlaengern ist nicht vorgesehen** (klein, gemessen)  
  Ort: index.html Zeile 2581 ff. (EXPIRE_WAHL: 1 hour / 24 hours / 7 days), limits.html  
  Beleg: In der Oberflaeche gemessen: nur drei Optionen, "1 hour", "24 hours", "7 days". limits.html: "Extend a link - Not from the app". Eine Bankpruefung eines Kaufvertragsentwurfs laeuft bei mir regelmaessig zwei bis drei Wochen; der Vorgang muesste neu erzeugt und neu versendet werden.

### Vollstaendiger Review

**Wer schreibt: Notarin, 49, eigenes Notariat, vier Mitarbeiterinnen. Ich verschicke taeglich Urkundenentwuerfe, Grundbuchauszuege, Kaufvertragsentwuerfe an Beteiligte, Banken, Grundbuchamt und Gerichte. Ein Kollege hat mir den Link geschickt mit dem Satz "Das ist was fuer dich". Ich habe drei Stunden damit verbracht. Hier ist, was ich gemessen habe.**

**Meine heutige Loesung, damit klar ist, wogegen ich vergleiche**

An Gerichte und Grundbuchamt geht alles ueber das besondere elektronische Notarpostfach ueber XNP. Das Ding ist traege, die Anmeldung mit Karte nervt jeden Morgen, aber es protokolliert. Ich bekomme ein Sendeprotokoll, ich bekomme eine Eingangsbestaetigung, und ich kann in fuenf Jahren, wenn ein Beteiligter behauptet, er habe den Entwurf nie erhalten, ein Blatt Papier aus der Akte ziehen. Das ist der Grund, warum ich es behalte. An Banken: teils deren Portale, teils passwortgeschuetzte PDF per Mail, Passwort per Telefon. An Mandanten, oft ueber siebzig: PDF per Mail oder schlicht Post. Wenn etwas gross ist, WeTransfer - was mir jedes Mal unangenehm ist, weil ich einer niederlaendischen Firma einen Kaufvertragsentwurf mit Namen, Geburtsdaten und Kaufpreis in die Hand druecke. Firefox Send habe ich 2019 kurz benutzt und 2020 wieder verloren, als Mozilla es eingestellt hat; das hat mir beigebracht, dass ich mich auf Gratisdienste nicht verlassen darf. Proton Drive und Tresorit habe ich mir angesehen, Tresorit steht auf der Liste fuer naechstes Jahr, weil sie einen Auftragsverarbeitungsvertrag unterschreiben und Zustellbestaetigungen liefern.

**Erster Eindruck, Minute eins bis drei**

Die Seite ist auf Englisch. Komplett. `<html lang="en">`, kein Umschalter, keine deutsche Fassung. Ich lese das ohne Muehe, meine Verkaeuferin, 74, aus Rosenheim nicht. Damit ist die Haelfte meiner Empfaenger schon raus, bevor irgendetwas anderes geprueft ist. Das steht nirgends als Absicht, es ist einfach so.

Was mir sofort positiv aufgefallen ist: ueber dem Falz steht "Today it encrypts and stores; it does not yet send. A link opens only in the browser that made it." Ich lese Zusagen wie Vertragsklauseln, und diese eine ist eine Selbstbeschraenkung, keine Werbung. Direkt darunter laeuft aber ein Laufband mit WhatsApp, Signal, Threema, E-Mail, Slack und der Ueberschrift "A CLOAKDROP LINK IS PLAIN TEXT, SO IT SURVIVES ANY CHANNEL YOU ALREADY USE" - und erst dahinter der Halbsatz "Not yet, though". Das ist die einzige Stelle, an der die Seite sich anders anhoert als sie ist. Wer scrollt, sieht zehn Logos und nicht die Einschraenkung.

**Der Test, auf den es ankommt - Minute vier bis zwanzig**

Ich habe eine echte Akte nachgebaut: Kaufvertrag_Entwurf_URNr_412-2026.pdf (1,84 MB), Grundbuchauszug_Blatt_2841.pdf (635 KB), Auflassungsvormerkung.pdf, Finanzierungsbestaetigung_Sparkasse.pdf, Vollmacht_Beteiligte_zu_2.pdf. Zusammen 2,9 MB. Die Seite meldete korrekt "5 files - 2.9 MB".

Passwort zu kurz ("abc"): abgelehnt, mit dem Satz "That password is too short - 8 characters at the least. It is the only thing standing between the link and the files, so a short one is worse than none." Passwort "passwort": abgelehnt mit "That password is on every guessing list there is." Beides genau richtig und beides in einem Ton, den ich meinen Mandanten vorlesen koennte, wenn er auf Deutsch waere.

Frist auf 7 Tage gestellt, ordentliches Passwort gesetzt, geklickt. **Nach 0,5 Sekunden war der Link da.** Ich habe zweimal hingesehen, weil ich es nicht geglaubt habe. Spaeter mit 153 MB: 2,7 Sekunden. Zum Vergleich - derselbe Vorgang ueber unser beA dauert bei mir, ehrlich gemessen, drei bis fuenf Minuten inklusive Kartenanmeldung.

**Und dann, nach etwa 40 Sekunden, der Moment, an dem das Produkt fuer mich zu Ende war.**

Ich habe den Link genommen und ihn so benutzt, wie ich es wirklich taete: in einem voellig getrennten Browserprofil, also der Situation "die Sachbearbeiterin bei der Sparkasse klickt". Ergebnis: eine Fehlerseite. Wortlaut: "Nothing here to open - No drop with this address is stored in this browser. Either it was created somewhere else - in this build a drop lives only in the browser that made it - or it was deleted, or it expired and was cleared. The relay that carries drops between browsers is being built." Zur Gegenprobe dasselbe in Firefox, einem ganz anderen Programm: identische Fehlerseite. Im Quelltext steht der Satz in index.html, Zeile 3943.

Das ist kein Fehler im technischen Sinn. Es ist der ausdrueckliche Stand. Aber ich muss es beim Namen nennen: **das Produkt kann heute keine Datei an einen anderen Menschen uebermitteln.** Alles, was es kann, ist, Dateien im eigenen Browser zu verschluesseln und sie sich selbst wieder zu geben. Fuer mein Notariat ist das genauso brauchbar wie ein Tresor ohne Tuer nach aussen. Ich koennte es nicht einmal intern verwenden: die Drops kleben am Browserprofil eines Rechners. Meine vier Mitarbeiterinnen sehen sie nicht. Wenn ich krank bin, kommt niemand an den Vorgang.

**Was ich trotzdem geprueft habe, weil ich wissen wollte, ob der Rest taugt**

Im selben Browser funktioniert alles. Falsches Passwort: "That password does not open this drop", nach 4,1 Sekunden - die Wartezeit ist gewollt, sie kommt von 600.000 PBKDF2-Runden (index.html Zeile 2652). Richtiges Passwort: nach 1,1 Sekunden offen, "5 cloaked files - 2.9 MB TOTAL - OPENS FOR 7 MORE DAYS". Der Knopf "alle Dateien holen" lieferte ein ZIP, und ich habe nicht geglaubt, sondern nachgerechnet: **alle fuenf PDF byteidentisch mit den Originalen.** Bei 153 MB dasselbe, ZIP in 4,6 Sekunden gebaut.

Netzwerk: ich habe jeden Aufruf mitgeschrieben. Waehrend der Verschluesselung von 153 MB: **null Anfragen.** Waehrend Oeffnen und Herunterladen: eine einzige, das Laden der Seite selbst. Und, das hat mich als Nichttechnikerin am meisten ueberzeugt, weil es nicht auf Vertrauen beruht: die Seite liefert einen Kopfzeileneintrag `connect-src 'none'` mit. Ich habe mir erklaeren lassen, was das heisst - der Browser selbst verbietet der Seite, irgendetwas zu senden. Das ist keine Zusage in einem Dokument, das ist eine verschlossene Tuer.

Nach dem Schliessen des Browsers habe ich das Profil auf der Festplatte durchsucht. 152,9 MB verschluesselte Bruchstuecke lagen da. Nach den Woertern "Kaufvertrag", "Grundbuch", "Vollmacht", "Sparkasse", ".pdf" gesucht: **kein einziger Treffer.** Die Dateinamen sind wirklich mitverschluesselt. Nach dem Loeschen eines Drops schrumpfte das Profil von 156,9 MB auf 4,1 MB - es loescht wirklich, nicht nur in der Anzeige.

**Kaputtmachen - Minute fuenfzig bis neunzig**

Abgeschnittener Link: "That is not a key", mit dem Hinweis, dass Chatprogramme Links kuerzen. Zeilenumbruch mitten im Link: geht trotzdem auf. Fremde Domain cloakdr0p.com: erkannt und benannt. Punkt am Satzende, Klammern, ein zitierendes ">" davor, ein ganzer Satz vor dem Link: alles geht auf. **Ein Satz hinter dem Link geht nicht.** "Anbei der Link: https://... Das Passwort nenne ich telefonisch." liefert "That is not a key". Ich habe im Quelltext nachgesehen: in Zeile 4454 werden zuerst alle Leerzeichen entfernt und erst danach die Felder gelesen - dadurch klebt der Folgetext am Schluessel. Direkt darueber steht ein Kommentar, der genau diesen Fall zitiert ("Ein Link am Satzende ist in Outlook der Normalfall") und behauptet, ihn geloest zu haben. Er ist nicht geloest. Das ist mein Alltag: ich schreibe nie einen Link ohne einen Satz dahinter.

600-MB-Datei: sauber abgewiesen, "That is 600.0 MB - a drop carries up to 500.0 MB." Abbruch mitten im Verschluesseln von 450 MB, bei 20 Prozent: danach null Datensaetze, null Bruchstuecke, Speicherbelegung zurueck auf 48 KB. Neuladen mitten im Verschluesseln: ein Rest von 184 MB bleibt, wird aber in der Uebersicht als "Unfinished" benannt, mit Warnung, und war nach zwoelf Sekunden und dem naechsten Oeffnen restlos weg. Speicher volllaufen lassen: "This browser ran out of room, so nothing was kept". Zwei Tabs gleichzeitig: beide Drops sauber. Zurueck-Knopf: der Link ueberlebt. Und ich habe versucht zu betruegen - die Ablauffrist im Datensatz von einer Stunde auf zehn Jahre gesetzt: der Drop **oeffnet nicht mehr**, die Frist haengt am Chiffrat. Das ist besser, als die eigene FAQ zugibt.

**Was fuer mich fehlt und nicht auf der Liste steht**

Beweiskraft. Ich habe den gespeicherten Datensatz aufgemacht: die Felder heissen manifest, ivPrefix, created, expires, aad, kdf, bytes, id, label. **Kein Feld dafuer, wann jemand geoeffnet hat. Keins dafuer, wer.** Kein Protokoll, kein Export, kein PDF, das ich in die Akte heften koennte. Wenn ein Beteiligter in drei Jahren bestreitet, den Entwurf rechtzeitig erhalten zu haben, habe ich mit diesem Werkzeug exakt nichts in der Hand. Das ist keine Nachlaessigkeit, das folgt aus der Bauart - wer nichts weiss, kann nichts bezeugen. Aber dann ist es fuer meinen Beruf ungeeignet, und zwar auch dann noch, wenn das Relay fertig ist.

Die Uebersicht der gespeicherten Drops zeigt Datum, Groesse, Restlaufzeit und ein Feld fuer einen Kurznamen. Sie zeigt **nicht**, welche Dateien drin sind (verstehe ich, der Schluessel ist ja weg) und **nicht**, welcher Drop ein Passwort hat (verstehe ich nicht). Das Kurznamenfeld ist auf 40 Zeichen begrenzt, ohne einen Ton: aus "Kaufvertrag Mueller ./. Schaefer, UR-Nr. 412/2026, an die Sparkasse" wurde stillschweigend "Kaufvertrag Mueller ./. Schaefer, UR-Nr." - abgeschnitten genau vor der Urkundenrollennummer, also vor dem einzigen Teil, der eine Akte identifiziert. Und aus der Uebersicht bekomme ich den Link nicht zurueck; ich habe nachgezaehlt, es gibt dort null Knoepfe dafuer. Wer den Link verliert, kann den Drop nur noch loeschen. Das steht in der FAQ, aber nicht dort, wo der Link zum ersten Mal auf dem Bildschirm steht.

Sieben Tage sind meine Obergrenze, verlaengern geht nicht. Eine Bankpruefung eines Kaufvertragsentwurfs dauert regelmaessig zwei bis drei Wochen. Ich muesste denselben Vorgang zweimal neu verschicken.

**Was mich ueberrascht hat**

Im Guten: die Ehrlichkeit. Die Seite "Verify a transfer" hat einen Abschnitt "What this does not prove" mit fuenf Punkten, darunter "It does not audit the code you are running" und "It does not hide how much you sent". Die Seite "Read the code" sagt ausdruecklich: "CloakDrop is not open source: there is no repository, no licence". Und in der FAQ zu den Grenzen steht auf die Frage nach Datenschutz und Auftragsverarbeitung woertlich: "treat this as something to try, not something to rely on at work". Ich habe in zwanzig Jahren Berufspraxis kaum einen Anbieter erlebt, der von sich aus schreibt, man solle ihn beruflich noch nicht einsetzen. Das ist rechtlich die sauberste Haltung, die ich hier gesehen habe - sie schliesst genau die Luecke, in der sonst die Haftungsfrage sitzt.

Im Schlechten: dass ein Menue prominent "Read the code" heisst, wenn es kein Repository gibt. Und dass in der Fusszeile jeder Seite "Status page - coming soon" steht, obwohl es eine Statusseite unter status.html gibt, die man aufrufen kann und die dann selbst erklaert, dass eine Statusseite kommt. Kleinigkeiten - aber ich lese solche Sachen berufsbedingt, und sie kosten Vertrauen.

**Fazit**

Was hier gebaut wurde, ist gut gebaut. Ich habe versucht, es kaputtzumachen, und es ist mir nicht gelungen; ich habe seine Zusagen nachgemessen und sie stimmten. Nur ist das Gebaute nicht das, was ich brauche, und es ist nicht einmal die Haelfte davon. Es verschluesselt hervorragend und uebermittelt gar nicht, und selbst wenn es uebermitteln wird, protokolliert es nicht. Ich bleibe beim beN mit seinem traegen Kartenleser, genau deshalb: weil es ein Blatt Papier ausspuckt, das in fuenf Jahren noch etwas beweist. Ich schreibe mir den Namen auf und sehe in einem Jahr wieder nach. Wenn dann ein Relay laeuft, ein Zustellnachweis existiert, den ich exportieren kann, ein Impressum mit einem haftenden Betreiber dahintersteht, ein Auftragsverarbeitungsvertrag angeboten wird und die Oberflaeche Deutsch spricht - dann reden wir noch einmal. Heute: nein.

---

## Dr. Annika Reuther — Postdoc Humangenetik, 34

**Note 3.8 · wuerde nutzen: nein**

### Begruendung der Note

Handwerklich ist das eine der saubersten Web-Krypto-Umsetzungen, die ich je aufgemacht habe: 420 MB in 2,1 s verschluesselt, 500 Dateien byteidentisch zurueck, kein einziger Fremdrequest in acht Testlaeufen, und jede Fehlermeldung trifft die tatsaechliche Ursache. Dafuer allein gaebe ich 8,5. Nur loest das Ding mein Problem zu exakt null Prozent: 500 MB pro Drop sind bei 80 bis 400 GB je Datensatz Faktor 800, und der Link oeffnet sich nur im Browser, der ihn erzeugt hat — Uebertragung, also der ganze Zweck, existiert nicht. Dazu kommt ein reproduzierbarer Defekt, bei dem mir die App zweimal einen Link auf einen Drop mit 4 von 105 Bruchstuecken als Erfolg verkauft hat. Ich bewerte, was ich heute damit tun kann, und das ist nichts; die Note zieht die Qualitaet des Gebauten nach oben, die Nutzlosigkeit fuer meinen Fall nach unten.

### Blocker

1. Kein Relay: ein Link oeffnet ausschliesslich im Browser, der ihn erzeugt hat. Im frischen Kontext gemessen: 'Nothing here to open ... in this build a drop lives only in the browser that made it'. Damit gibt es keine Uebertragung an Kooperationspartner — also gar keinen Anwendungsfall fuer mich.
2. 500 MB Obergrenze pro Drop. Meine Datensaetze sind 80 bis 400 GB, ein Projekt 5 TB. Das waeren 160 bis 800 Drops je Datensatz und rund 10.000 je Projekt, jeder einzeln zu erzeugen, zu benennen und zu verschicken.
3. Das Chiffrat liegt zusaetzlich im Browserprofil auf derselben Platte. Ich braeuchte den doppelten Plattenplatz fuer Daten, die ich ohnehin kaum unterbringe (gemessen: 486,5 MB Chiffrat im Profil nach 451 MB Nutzdaten).
4. Keine Wiederaufnahme nach Abbruch. Bei 400-GB-Uebertragungen ueber europaeische Uni-Leitungen ist Resume Pflicht, nicht Kuer — Globus kann das, hier gibt es nicht einmal das Konzept.
5. Keine Kommandozeile, keine API, kein Skriptzugang. Meine Uebergaben laufen aus Pipelines heraus; ein Browsertab, in dem jemand 800-mal klickt, ist kein Verfahren, das ich in einen Ethikantrag schreibe.
6. Kein AVV, kein Impressum, keine belastbare Datenschutzangabe — die Seite sagt das selbst und rae die Nutzung im beruflichen Kontext bis dahin ausdruecklich ab. Fuer Daten unter Artikel 9 DSGVO ist das ein Ausschlusskriterium.

### Was gut ankam

- Kein einziger Fremdrequest ueber acht Testlaeufe hinweg — nachgemessen, nicht geglaubt. Der CSP-Header lautet default-src 'none'; connect-src 'none' mit SHA-256 je Inline-Block, dazu HSTS, COOP, CORP, referrer-policy: no-referrer, X-Frame-Options: DENY.
- Durchsatz stimmt: 420 MB in 2,1 s verschluesselt (198,8 MB/s), Rueckweg 10,6 s inklusive Plattenschreiben, SHA-256 der zurueckgeholten Datei identisch mit dem Original.
- 500 Dateien in einem Drop (74,3 MB): 2,4 s verschluesselt, ZIP mit 500 Eintraegen, 500 von 500 byteidentisch. Auch 60 Dateien: 60 von 60 identisch.
- Die Ablauffrist haengt in der AAD des Manifests. Ein Verlaengerungsversuch durch Editieren von 'expires' im IndexedDB fuehrt zu 'This drop did not open. The authentication tag does not match' statt zu einem geoeffneten Drop — die Zusage traegt kryptografisch, nicht nur als Behauptung.
- Zwoelf verstuemmelte Links durchprobiert, jeder einzelne bekam eine Meldung, die die tatsaechliche Ursache benennt: abgeschnitten, Zeilenumbruch, Satzzeichen, leeres t, fremde Id, falscher Schluessel, Salz ohne Passwort-Drop. Kein einziger Fall landete kommentarlos auf der Startseite.
- Das Einfuegefeld ist robuster als die Adresszeile: Link am Satzende, Umbruch mitten im Schluessel, Link in Klammern, nur das Fragment — alles oeffnet. Fremde Domain, javascript:, mailto: und Outlook-Safelinks werden mit praeziser Begruendung abgewiesen.
- Aufraeumen funktioniert restlos: Neuladen mitten im Verschluesseln hinterlaesst einen als 'never finished' gekennzeichneten Rest, der beim naechsten Start samt Bruchstuecken verschwindet — nachgezaehlt, die verbleibenden 167 Bruchstuecke entsprachen exakt den drei gueltigen Drops.
- Vollgelaufener Speicher (Kontingent auf 120 MB gedeckelt): nach 31,1 s ehrliche Meldung, 0 Drops, 0 Bruchstuecke, und die Dateiauswahl bleibt stehen, damit man sofort weitermachen kann.
- Nach dem Schliessen des Browsers: 486,5 MB Chiffrat im Profil, aber null Treffer bei der Volltextsuche nach Dateiinhalt, nach Dateinamen und nach einem geloeschten Kurznamen. Nur der aktive Kurzname liegt im Klartext — genau so, wie die Oberflaeche es ansagt.
- Der Warnsatz zum Kurznamen ist vorbildlich formuliert: 'It is the one thing here that is not encrypted — write what helps you tell two drops apart, not what the drop contains.'
- Passwortpruefung mit Augenmass: unter 8 Zeichen abgelehnt, Wortlisten-Klassiker abgelehnt, 600.000 PBKDF2-SHA256-Runden, falsches Passwort nach 3,0 s mit klarer Meldung, kein Teilergebnis.
- Der Abschnitt 'What this does not prove' auf verify.html und die Antwort auf 'Can I use this at work' sind ehrlicher als alles, was ich in dieser Kategorie kenne — inklusive des Satzes, dass man sich im Beruf noch nicht darauf verlassen soll.
- Die App hat eine 0-Byte-Datei erkannt und gemeldet ('That is usually not what you meant'), obwohl die Ursache ein Windows-Pfadlaengenproblem auf meiner Seite war und nicht ihres.
- Laeuft in WebKit und Firefox durch, ZIP jeweils byteidentisch — nicht selbstverstaendlich bei IndexedDB und WebCrypto.

### Heutige Loesung

Sciebo (uni-gehostetes ownCloud in NRW) fuer alles bis in den zweistelligen GB-Bereich, mit passwortgeschuetzten Freigaben und Ablaufdatum; Globus fuer die grossen Transfers zwischen den Rechenzentren in Leuven, Uppsala und Nijmegen, weil es Wiederaufnahme nach Abbruch beherrscht; rsync ueber SSH direkt auf den Cluster des Partners, wenn beide Seiten einen Endpunkt haben; verschluesselte Platten per Kurier beim Erstaufsatz eines Projekts. Fuer Einzeldateien gelegentlich age oder 7-Zip als zusaetzliche Schicht, croc privat. Ich bleibe dabei — nicht weil es angenehm ist, sondern weil es die Groessenordnung traegt, einen AVV hat und aus Skripten heraus laeuft.

### Gemeldete Defekte (5)

- **Loeschen im zweiten Tab kurz vor Abschluss: App meldet Erfolg und gibt einen Link auf einen unvollstaendigen oder gar nicht mehr existierenden Drop aus** (schwer, gemessen)  
  Ort: https://cloakdrop.com, Verschluesselungsschleife im Inline-Skript von index.html (Lebenszeichen-Pruefung 'hoechstens alle drei Sekunden', vor dem abschliessenden saveTransfer/loadTransfer)  
  Beleg: Zweimal reproduziert mit gedrosselter CPU (CDP Emulation.setCPUThrottlingRate rate=8), 420-MB-Datei: bei 80 % (336 MB von 420 MB) den unfertigen Drop im zweiten Tab geloescht. Tab 1 endete beide Male in Zustand st-done und gab einen Link aus. IndexedDB danach: Lauf 1 Drop 'PBOSnULCaDRO' mit bytes=420000000, unfertig=false, aber 4 Bruchstuecke; Lauf 2 Drop 'SQWUYKmPK_Cl', bytes=420000000, unfertig=false, 5 Bruchstuecke — erwartet waeren 105. Beim Oeffnen des Links erscheint die vollstaendige Dateiliste, der Download bricht mit Konsolenfehler 'Error: chunk missing at dateiEntschluesseln' ab und meldet 'A piece is missing'. Variante mit 60 Dateien (Drosselung 12x, Loeschen bei 80 %): Tab 1 meldete st-done mit Link, IndexedDB danach 0 Drops und 0 Bruchstuecke; der ausgegebene Link fuehrt auf 'Nothing here to open'.
- **In der Uebersicht 'Manage' ist die Restlaufzeit auf jeder Bildschirmbreite abgeschnitten, auf dem Telefon vollstaendig** (mittel, gemessen)  
  Ort: https://cloakdrop.com, Ansicht #st-drops, Zeilen '#drops-list .file-row .file-name'  
  Beleg: Gemessen ueber scrollWidth/clientWidth je Zeile. Viewport 1280x900, 1600x1000 und 1920x1080 liefern identische Werte: sichtbar 213-270 px, benoetigt 354-358 px — der Text 'Cloaked 2026-07-31 22:07 · opens for 24 more hours' bricht nach dem Datum ab. Viewport 390x844: sichtbar 3-10 px bei 354-358 px Bedarf, die Zeile ist praktisch unsichtbar. Die Karte waechst nicht mit dem Viewport, breitere Schirme helfen also nicht. Ein title-Attribut wird nicht gesetzt, es gibt also auch keinen Tooltip.
- **Firefox blockiert die eigene favicon.ico per CSP, jede Sitzung erzeugt einen Verstoss in der Konsole** (klein, gemessen)  
  Ort: _headers, Direktive 'img-src 'self' data:' im Zusammenspiel mit 'default-src 'none''; Ressource /favicon.ico  
  Beleg: Playwright/Firefox, Aufruf von cloakdrop.com: Konsolenfehler '[JavaScript Error: "Content-Security-Policy: The page's settings blocked the loading of a resource (img-src) at https://cloakdrop.com/favicon.ico because it violates the following directive: "default-src 'none'"" {file: "resource:///modules/FaviconLoader.sys.mjs" line: 224}]'. In Chromium und WebKit tritt der Fehler nicht auf. Fuer ein Produkt, dessen Verify-Seite ausdruecklich zum Oeffnen der DevTools auffordert, ist ein selbstverschuldeter CSP-Verstoss auf der Startseite unguenstig.
- **Der Einstieg 'Manage' erscheint in einem Tab nicht, das geoeffnet war, bevor der erste Drop existierte** (klein, gemessen)  
  Ort: https://cloakdrop.com, Zeile #storeline mit Knopf #drops-open, aktualisiert nur ueber speicherZeile() im eigenen Tab  
  Beleg: Im Wettlauftest: Tab 2 wurde geoeffnet, als noch kein Drop existierte. Waehrend Tab 1 verschluesselte, blieb #drops-open in Tab 2 unsichtbar ('element is not visible', 30 s Playwright-Timeout). Erst nach einem Neuladen von Tab 2 war #storeline sichtbar (gemessen: storeline hidden=false) und der Drop in der Liste. Es gibt keine tabuebergreifende Aktualisierung.
- **Die Platzvorwarnung vor dem Verschluesseln kann nicht greifen, weil navigator.storage.estimate() ein Kontingent nennt, das die Platte um ein Vielfaches uebersteigt** (klein, gemessen)  
  Ort: https://cloakdrop.com, Vorabpruefung mit navigator.storage.estimate() vor showState('st-progress')  
  Beleg: Gemessen auf einem Rechner mit 109 GB freiem Plattenplatz: estimate() liefert quota=575.533.525.401 Byte (575 GB) bei usage=1.271 Byte. Die Bedingung 'frei < gesamt + 4 Chunks' wird damit fuer jeden zulaessigen Drop bis 500 MB nie wahr, die Warnung kann also nicht ausgeloest werden. Erst der harte Fehlerzweig greift: mit per CDP auf 120 MB gedeckeltem Kontingent kam nach 31,1 s 'This browser ran out of room, so nothing was kept' — sauber aufgeraeumt (0 Drops, 0 Bruchstuecke), aber eben nach 31 Sekunden statt vorher.

### Vollstaendiger Review

## Wer hier testet, und mit welcher Frage

Ich bin Postdoc in der Humangenetik, arbeite mit Sequenzierdaten. Ein einzelner Datensatz sind 80 bis 400 GB, ein Projekt liegt schnell bei 5 TB. Ich tausche mit Gruppen in Leuven, Uppsala und Nijmegen aus, und mein Ethikvotum schreibt vor, dass alles pseudonymisiert und verschluesselt uebertragen wird. Heute laeuft das ueber unseren Sciebo-Server (ownCloud, Uni-gehostet, NRW), fuer die grossen Sachen ueber Globus, und beim Erstaufsatz eines Projekts ueber verschluesselte Platten per Kurier. Umstaendlich, aber es traegt die Groesse.

Meine erste Frage bei jedem neuen Werkzeug ist immer dieselbe: passt meine Groessenordnung ueberhaupt hinein. Ich habe die Antwort nach 90 Sekunden gehabt, und sie lautet nein — aber ich habe trotzdem zweieinhalb Stunden weitergetestet, weil das, was da ist, mich neugierig gemacht hat.

## Die ersten Minuten

Startseite laedt, drei HTTP-Anfragen insgesamt, alle an cloakdrop.com. Ueber der Falz steht fett: „Today it encrypts and stores; it does not yet send. A link opens only in the browser that made it." Das ist ungewoehnlich. Ich bin es gewohnt, dass so etwas auf Seite vier der FAQ steht. Hier steht es im Fliesstext des Hero.

Direkt darunter faengt es dann aber doch an: eine Laufschrift mit WhatsApp, Telegram, Signal, Threema, iMessage, Discord, Matrix, E-Mail, Slack, QR-Code unter der Ueberschrift „A CloakDrop link is plain text, so it survives any channel you already use" — und darunter der Satz „Not yet, though". Man bewirbt also mit Bewegtbild eine Faehigkeit, die nicht existiert, und nimmt sie im naechsten Absatz zurueck. Ebenso „Zero knowledge — we couldn't look if we wanted to": es gibt kein „wir", das irgendetwas haelt. Das ist Marketing fuer ein Produkt, das erst gebaut wird, mit einem Zettel dran.

## Der Groessentest

Ich habe eine 1,40-GB-Datei ausgewaehlt, wie sie bei mir als komprimiertes FASTQ-Fragment jeden Tag entsteht. Nach 1,5 s: „1 file · 1.40 GB — over the 500.0 MB preview limit". Klick auf Cloak: „That is 1.40 GB — a drop carries up to 500.0 MB. Remove a file, or send this in several drops." Ich habe dann das `aria-disabled` am Knopf per DevTools entfernt — die Grenze wird auch danach durchgesetzt, mit derselben Meldung plus „Your selection is still here". Sauber. Ehrlich. Und fuer mich das Ende der Geschichte: 400 GB waeren 800 Drops, 5 TB waeren 10.000. Jeder Drop muss zusaetzlich als Chiffrat in mein Browserprofil, das heisst ich brauche die Datenmenge zweimal auf der Systemplatte.

## Der Relay-Test

Der eigentliche Test. Ich habe 60 Per-Sample-VCFs (31,0 MB) verschluesselt, den Link genommen und ihn in einem voellig frischen Browserkontext geoeffnet — so, wie ich ihn wirklich benutzen wuerde. Nach 2,3 s: „Nothing here to open. No drop with this address is stored in this browser. Either it was created somewhere else — in this build a drop lives only in the browser that made it — or it was deleted, or it expired and was cleared." Die Adresszeile stand danach auf `#geoeffnet`; der Schluessel wird sofort aus dem Verlauf geraeumt, auch im Fehlerfall. Das ist richtig gemacht, aendert aber nichts: aus meinem Kollegen in Uppsala wird so kein Empfaenger.

## Durchsatz, weil ich Durchsatz messe

- 420-MB-Datei: Auswahl 0,8 s, Verschluesselung 2,1 s — **198,8 MB/s**. Das ist AES-NI-Niveau, daran ist nichts auszusetzen.
- Entschluesseln und auf Platte schreiben: 10,6 s, also rund 40 MB/s. SHA-256 der zurueckgeholten Datei identisch mit dem Original.
- 60 Dateien / 31 MB: 0,9 s (35,9 MB/s — hier dominiert der Overhead je Datei).
- 500 Dateien / 74,3 MB: Auswahl 1,8 s, Verschluesselung 2,4 s, 500 Zeilen im DOM, Manifest 49.802 Byte, ZIP mit 500 Eintraegen, **500 von 500 byteidentisch**.

Hochgerechnet: 400 GB waeren bei 199 MB/s rund 33 Minuten reine Rechenzeit. Das waere sogar akzeptabel. Es scheitert nicht an der Krypto, es scheitert an der Architektur.

## Was ich versucht habe kaputtzumachen

Ich habe zwoelf verstuemmelte Links durchprobiert: abgeschnitten, auf 16 Byte gekuerzt, Zeilenumbruch mitten im Schluessel, Leerzeichen, Satzpunkt angehaengt, leeres `t`, fremde Drop-Id, falscher Schluessel bei richtiger Id, Salz ohne Passwort-Drop, `<script>` im Fragment. **Jeder** Fall bekam eine Meldung, die den tatsaechlichen Zustand beschreibt — „That is not a key", „This link is incomplete", „The authentication tag does not match", „That is not a whole link". Kein Fall lief kommentarlos auf die Startseite. Das habe ich so noch nicht gesehen.

Das Einfuegefeld ist noch besser: „Hier ist der Link: …. Viele Gruesse, Jan" oeffnet den Drop. Umbruch mitten drin: oeffnet. In Klammern: oeffnet. Nur das Fragment: oeffnet. Fremde Domain: „That link points at cloakdrop.example.org, not at this site." Ein Outlook-Safelink wird ebenso abgewiesen — bei uns laeuft alles ueber Microsoft 365, das waere in der Praxis der Normalfall und ist damit ein reales Reibungsthema, aber die Meldung ist korrekt.

Passwort: ein Zeichen und sieben Zeichen werden abgelehnt („8 characters at the least"), `12345678` und `Passw0rd` fliegen als Wortlisten-Klassiker raus, ein gutes Passwort erzeugt einen Link mit drei Feldern (`t`, `k`, `s`). Falsches Passwort: nach 3,0 s „That password does not open this drop." Richtiges: nach 4,0 s offen. 600.000 PBKDF2-Runden, das kostet eben.

Frist: 1 h / 24 h / 7 Tage, Vorgabe 24 h. Ich habe im IndexedDB `expires` in die Vergangenheit gesetzt — „This link no longer opens". Dann in die Zukunft, zehn Jahre — **„This drop did not open. The authentication tag does not match"**. Die Frist haengt in der AAD des Manifests, sie laesst sich also nicht durch Editieren des Datensatzes verlaengern. Ein gekipptes Bit im Chiffrat: „This file was changed … Nothing was written to your disk." Genau so soll das sein.

Abbruch mitten im Verschluesseln bei 20 %: raeumt vollstaendig auf, Auswahl bleibt stehen. Neuladen mitten drin: der Rest wird beim naechsten Start als „never finished" markiert und beim uebernaechsten geloescht — ich habe die Bruchstuecke gezaehlt, 167 blieben uebrig und das war exakt die Summe der drei gueltigen Drops. Speicher voll (Kontingent per CDP auf 120 MB gedeckelt): nach 31,1 s „This browser ran out of room, so nothing was kept" — danach 0 Drops, 0 Bruchstuecke, Auswahl noch da. Das ist der Weg, den die meisten Produkte nie testen.

## Der eine echte Defekt

Zweiter Tab. Ich habe Tab 1 gedrosselt 420 MB verschluesseln lassen, bei 80 % (336 MB) in Tab 2 den unfertigen Drop geloescht. Tab 1 lief weiter und meldete **Erfolg**, mit Link. In der Datenbank stand danach ein Datensatz mit `bytes: 420000000`, `unfertig: false` — und **4 von 105 Bruchstuecken**. Beim zweiten Durchlauf 5 von 105. Beim Variantentest mit 60 Dateien war die Datenbank danach sogar komplett leer, waehrend Tab 1 mir einen Link praesentierte. Der Code hat genau dafuer eine Wache (Lebenszeichen alle drei Sekunden, mit einem Kommentar, der den Fall woertlich beschreibt) — sie greift nur nicht im letzten Fenster vor dem Abschluss. Ein Zaehlen der Bruchstuecke vor der Erfolgsmeldung wuerde es kosten, was es kostet: nichts.

## Manage-Ansicht

Die Uebersicht kann Kurznamen, sie ueberleben ein Neuladen, Loeschen ist zweistufig und nimmt Datensatz und Bruchstuecke in einer Transaktion mit. Der Warnsatz zum Kurznamen ist vorbildlich: „It is the one thing here that is not encrypted — write what helps you tell two drops apart, not what the drop contains." Ich habe nachgesehen: der Kurzname liegt tatsaechlich im Klartext in der leveldb, genau wie angesagt.

Nur ist die Zeile abgeschnitten. Gemessen bei 1280, 1600 und 1920 Pixel Breite: sichtbar 213 bis 270 px, noetig 354 bis 358 px. Bei 390 px Breite sind 3 bis 10 Pixel sichtbar. Ein `title` gibt es nicht. Das heisst: die Restlaufzeit — die einzige Information, wegen der ich diese Ansicht ueberhaupt aufmache — kann ich nicht lesen.

## Netz, Konsole, Platte

Ueber acht Testlaeufe: **kein einziger Request an eine fremde Domain**. Der CSP-Header ist `default-src 'none'; connect-src 'none'` mit SHA-256 je Inline-Block; dazu HSTS, COOP, CORP, `referrer-policy: no-referrer`, `X-Frame-Options: DENY`. Nach dem Schliessen des Browsers lagen 486,5 MB Chiffrat im Profil — erwartbar, die Drops standen ja noch. Volltextsuche im gesamten Profil nach „Ethikvotum", nach Dateinamen und nach einem geloeschten Kurznamen: **null Treffer**. Die 4-MB-Bruchstuecke liegen als 4.000.038-Byte-Dateien auf der Platte, wer das Profil oeffnet, kennt also die Groessen genau — steht so auch auf der Verify-Seite.

WebKit und Firefox habe ich gegengeprueft, beide durchgaengig, ZIP jeweils byteidentisch. Firefox meldet bei jedem Aufruf einen CSP-Verstoss fuer die eigene `favicon.ico` — bei einem Produkt, das mich auffordert, die DevTools aufzumachen, ist das ein unnoetiger Schoenheitsfehler.

## Die Seiten

Limits, Verify, Status, Opensource, Changelog habe ich gelesen. Der Abschnitt „What this does not prove" auf verify.html — fuenf Punkte, darunter „It does not audit the code you are running" und „It does not pin down what you are served next time" — ist ehrlicher als alles, was ich in dieser Kategorie sonst kenne. Die Antwort auf „Can I use this at work" endet mit „treat this as something to try, not something to rely on at work". Dem habe ich nichts hinzuzufuegen; sie haben mein Urteil selbst geschrieben. Der Opensource-Text sagt klar: lesbar, aber nicht quelloffen, keine Lizenz, kein Repository. Das ist konsistent, aber es heisst auch, dass ich nichts habe, wogegen ich das Ausgelieferte diffen koennte.

## Markt, und warum ich bleibe

Sciebo bleibt. Es traegt Terabytes, es liegt bei der Uni, es hat einen AVV, und ich kann Freigaben mit Passwort und Ablauf setzen. Globus bleibt fuer alles ueber 100 GB, weil es Wiederaufnahme nach Abbruch kann — das ist bei 400 GB ueber eine europaeische Uni-Leitung keine Kuer, sondern Pflicht. WeTransfer ist bei uns verboten und waere mit 2 GB ohnehin ein Witz; Firefox Send haette technisch am naechsten gelegen und ist 2020 eingestellt worden, unter anderem wegen Missbrauch — dieselbe Frage wird sich hier stellen. Wormhole und croc kenne ich, croc nutze ich privat; croc kann heute schon alles, was CloakDrop verspricht, plus Uebertragung, plus Wiederaufnahme, ohne Groessengrenze. Cryptomator und `age` decken die Verschluesselungsseite ab, wenn ich sie brauche. Bitwarden Send fuer Zugangsdaten. Tresorit und Proton Drive habe ich angesehen, beide teuer, beide fuer meinen Massstab zu langsam.

Fuer die kleinen Dinge — Manifeste, VCFs, Abbildungen — waere CloakDrop charmant. Nur: sobald es die tatsaechlich verschicken koennte, konkurriert es mit einem Sciebo-Link, den ich in vier Sekunden erzeuge, und der Mehrwert waere die clientseitige Verschluesselung, die ich mir mit `age` in einer Zeile dazubaue.

## Was mich ueberrascht hat

Im Guten: dass jede einzelne Fehlermeldung stimmt. Dass ein 500-Dateien-Drop byteidentisch zurueckkommt. Dass die Frist kryptografisch gebunden ist und nicht nur danebensteht. Dass die App eine 0-Byte-Datei erkennt und mir sagt „That is usually not what you meant" — die war ein Windows-Pfadproblem auf meiner Seite, nicht ihres, und sie hat sie trotzdem gemeldet. Dass wirklich nichts das Geraet verlaesst, und zwar nicht als Versprechen, sondern weil `connect-src 'none'` es verbietet.

Im Schlechten: dass ich mit einem Standard-Handgriff — zweiter Tab, aufraeumen — einen Erfolgsbildschirm samt Link fuer einen zu 96 % nicht existierenden Drop bekomme. Und dass eine so sorgfaeltig gebaute Sache in der Kategorie „Dateiuebertragung" antritt, ohne uebertragen zu koennen.

## Urteil

Kaufen wuerde ich das nicht, benutzen auch nicht — nicht, weil es schlecht gemacht ist, sondern weil es fuer meinen Fall um zwei Groessenordnungen daneben liegt und die eine Funktion fehlt, die den Namen traegt. Ich wuerde es mir in einem halben Jahr wieder ansehen, wenn das Relay steht und die Grenze bei mindestens 100 GB pro Drop liegt, mit Wiederaufnahme. Bis dahin: schoen gebaut, fuer mich nutzlos.

---

## Jonas Reinhardt — Dateningenieur bei einem Rennstall, 31

**Note 3.6 · wuerde nutzen: nein**

### Begruendung der Note

Das, was gebaut ist, ist handwerklich besser als die meisten Produkte, die ich taeglich benutze: null Netzverkehr beim Verschluesseln (in zehn Laeufen gemessen), CSP mit connect-src 'none', 440 MB in 2,8 s, ZIP byte-identisch ueber Chromium, Firefox und WebKit, Manipulation am Chiffrat und an der Frist scheitert nachweisbar. Dafuer gibt es Punkte. Aber ein Uebertragungswerkzeug, das nicht uebertraegt, loest null Prozent meines Problems: der Link oeffnet nur im erzeugenden Browser, gemessen im zweiten Kontext "Nothing here to open". Dazu 500 MB pro Drop gegen meine 2 bis 20 GB pro Session, und nur drei 440-MB-Drops passen in ein Browserprofil, ehe der vierte nach 32,3 s abbricht. Zwei gemessene Defekte sitzen ausgerechnet im haeufigsten realen Pfad, dem Einfuegen eines Links aus einer Mail. Unter 4 muss es bleiben, ueber 3 darf es bleiben, weil nichts auf der Seite luegt.

### Blocker

1. Kein Relay: ein Link oeffnet ausschliesslich in dem Browser, der ihn erzeugt hat. Im zweiten Browserkontext gemessen: 'Nothing here to open' nach 2,51 s. Damit loest das Produkt fuer eine Uebergabe ans Werk und an zwei Zulieferer exakt nichts.
2. 500 MB pro Drop gegen 2 bis 20 GB pro Session. 620 MB werden korrekt abgewiesen. 20 GB waeren 40 Drops, 40 Links, 40 Passwoerter.
3. Das Browserprofil ist die harte Obergrenze, nicht die Plattengroesse: bei 1,72 GB Kontingent passten drei 440-MB-Drops, der vierte scheiterte nach 32,3 s. Eine einzige Session passt nicht in einen Browser.
4. Kein Wiederaufsetzen nach Abbruch. Wer bei 380 von 440 MB die Seite neu laedt, faengt bei null an - der Rest wird 13 s spaeter weggeraeumt (gemessen). Bei schlechtem Netz und Zeitdruck ist genau das der Normalfall.
5. Kein Preis, kein Betreiber, keine Verfuegbarkeitszusage, kein Termin fuer das Relay. Ich kann intern nichts vorschlagen, bei dem ich auf 'was kostet es und wer haftet' schweigen muss.
6. Keine Automatisierung: kein CLI, keine API, kein Ordnerabgleich. Alles laeuft ueber einen Menschen, der einen Dateidialog bedient. Unsere Uebergaben laufen als Skript nach dem Lauf.

### Was gut ankam

- Null Netzverkehr beim Verschluesseln, ueber rund zehn Laeufe mitgeschnitten: kein einziger Request an einen anderen Host als cloakdrop.com, und dort nur Seitenaufrufe. Der CSP-Header setzt default-src 'none' und connect-src 'none' - das ist eine Sperre, kein Versprechen.
- Durchsatz: 440 MB in 2,8 bis 3,6 s in Chromium (124 bis 158 MB/s), 91,1 MB aus 26 Dateien in 2,50 s kalt. Firefox 40,7 MB/s, WebKit 21,3 MB/s. Nichts davon ist geschoenzt.
- Byte-Treue: das ZIP aus 'Download all' war in Chromium, Firefox und WebKit fuer jeden einzelnen Eintrag sha256-identisch mit dem Original; eine 440-MB-Einzeldatei ebenfalls.
- Nach dem Schliessen des Browsers habe ich den ganzen Profilordner byteweise durchsucht: 6,5 MB Chiffrat liegen da, aber kein Dateiname, kein Schluessel und kein Linkfragment. Die Blockgroessen verraten die Klartextgroessen auf 37 Byte genau - und genau das sagt die Seite auch.
- Manipulation scheitert laut: ein gekipptes Byte im Chiffrat fuehrt zur vollen Fehlerseite 'This file was changed', nichts wird geschrieben. Eine vorgeschobene Ablauffrist scheitert am Authentifizierungstag.
- Aufraeumen stimmt: Abbruch mitten im Lauf laesst transfers 0 und chunks 0 zurueck. Ein Neuladen mittendrin hinterlaesst einen als 'Unfinished' benannten Rest, der beim naechsten Start nach 13 s wirklich verschwindet.
- Ein zweiter Tab, der den Drop waehrend des Verschluesselns loescht, fuehrt zu einer korrekten Meldung statt zu einem Link auf ein halbes Chiffrat.
- Bremse bei falschen Passwoertern waechst messbar: 0,26 / 0,79 / 1,32 / 2,31 / 4,36 Sekunden.
- Dateinamen: Steuerzeichen fuer die Schreibrichtung werden entfernt (aus 'abrechnung[RLO]gpj.exe' wird 'abrechnunggpj.exe'), Umlaute, chinesische Zeichen und Emoji laufen unveraendert durch bis ins ZIP. Ein 200 Zeichen langer Name kommt vollstaendig zurueck.
- Funktioniert komplett offline, sobald die Seite einmal geladen ist - im Fahrerlager tatsaechlich etwas wert.
- Kopfzeilen sind strenger als bei unserem eigenen Werksportal: HSTS, referrer-policy no-referrer, COOP same-origin, X-Frame-Options DENY, nosniff, enge Permissions-Policy, script-src ausschliesslich ueber SHA-256-Hashes.
- Der Ton der Seite. Auf der Startseite, auf limits.html, auf status.html und ueber dem Cloak-Knopf steht, dass ein Link nur im erzeugenden Browser oeffnet. Ich habe nirgends einen Satz gefunden, der mehr behauptet, als das Ding kann. Das ist selten genug, um es zu erwaehnen.

### Heutige Loesung

Eigenes WireGuard-VPN plus rsync ueber SSH ins Werk und zu den beiden Zulieferern, angestossen als Skript direkt nach der Session. Das setzt nach Abbruch wieder auf, schiebt 20 GB ueber eine wackelige Leitung und braucht keinen Menschen. Preis dafuer: rund zwei Tage Einrichtung pro neuem Zulieferer, Schluesseltausch und Firewallfreigabe inklusive. Fuer einmalige Uebergaben nach draussen nehmen wir Tresorit, gelegentlich SwissTransfer, und fuer Rohdaten, die nicht ueber die Leitung passen, verschluesselte SSDs per Kurier. croc laeuft bei uns auf zwei Maschinen fuer Ad-hoc-Uebergaben zwischen Technikern. Ich behalte das alles - CloakDrop ersetzt heute keinen einzigen dieser Wege, weil es nichts uebertraegt.

### Gemeldete Defekte (8)

- **Link mitten in einem Satz wird abgewiesen: nachfolgendes Wort klebt am Schluessel** (schwer, gemessen)  
  Ort: index.html:4454 (frag = frag.replace(/\s+/g, '')), gelesen in tryOpenLink, index.html:4432-4462  
  Beleg: Gemessen ueber das Einfuegefeld auf https://cloakdrop.com. Ohne Passwort: Link + ' Gruss Tom' -> Fehlerseite 'That is not a key'. Link + Zeilenumbruch + 'Passwort kommt per Telefon' -> 'That is not a key'. Mit Passwort dieselben Faelle -> 'That is not a whole link'. Zum Vergleich im selben Lauf: Link allein -> oeffnet, Link + '.' -> oeffnet, Link in Klammern -> oeffnet, Outlook-Umbruch mitten im Schluessel -> oeffnet. Ursache: die Leerzeichen werden global entfernt, BEVOR feld() die base64url-Felder liest, dadurch wird aus '...&k=<key> Gruss Tom' das Feld k='<key>GrussTom' bzw. s='<salt>PasswortkommtperTelefon'. Der Kommentar direkt darueber (index.html:4450-4453) beschreibt genau diesen Fall als geloest und zitiert einen frueheren Tester.
- **Text VOR dem Link erzeugt eine sinnlose Fehlermeldung ueber ein angebliches Adressschema** (mittel, gemessen)  
  Ort: index.html:4413 (var schema = v.match(/^([a-z][a-z0-9+.-]*):/i))  
  Beleg: Eingabe 'Hier: https://cloakdrop.com/#t=...&k=... danke' -> Meldung 'That is a hier: address, not a CloakDrop link. Paste the link itself, or only the part starting at the #.' Gemessen in zwei Durchgaengen, mit und ohne Passwort auf dem Drop. Der Schema-Test verlangt kein '//' und keine bekannte Schemaliste, also matcht jedes Wort mit Doppelpunkt am Zeilenanfang.
- **Die Warnung vor knappem Speicher wird geschrieben und in der naechsten Zeile unsichtbar geschaltet** (mittel, gemessen)  
  Ort: index.html:3171 (sendeWarnung) gegen index.html:3180 (showState('st-progress')); das Ziel #send-err liegt in index.html:2182 innerhalb von #st-list (index.html:2150-2188)  
  Beleg: Speicher gezielt auf 98,2 MB frei gebracht, dann 91,1 MB verschluesselt. Die Bedingung im Code (frei < gesamt + 4*CHUNK_SIZE = 107,1 MB) ist damit erfuellt, sendeWarnung() laeuft. Waehrend des gesamten Laufs alle 50 ms abgefragt, ob #send-err sichtbar wird: kein einziger Treffer, Ausgabe 'NIE waehrend des Laufs'. Der Drop lief erfolgreich durch (st-done sichtbar). Gegenprobe im Fehlerfall: bei vollem Speicher wird #send-err erst 30 s spaeter mit dem Fehlertext ueberschrieben, die Warnung ist also nie zu sehen.
- **Bei vollem Browserspeicher steht der Fortschrittsbalken 30 bis 32 Sekunden ohne Regung** (mittel, gemessen)  
  Ort: Verhalten der 30-s-Frist um storage.saveChunk (mitFrist(..., 30000, 'storage did not answer'))  
  Beleg: Zwei unabhaengige Messungen: (a) Kontingent 1,92 GB komplett mit Ballast gefuellt, danach 91,1 MB cloaken -> Rueckkehr in die Liste nach 30,6 s mit der Meldung 'This browser ran out of room, so nothing was kept'. (b) Vier 440-MB-Drops nacheinander: Drop 1-3 nach 3,3 / 2,3 / 2,1 s fertig, Drop 4 bricht nach 32,3 s ab. Die IndexedDB war danach nachweislich sauber (transfers 0, chunks 0), die Meldung stimmt also inhaltlich - nur kommt sie eine halbe Minute zu spaet.
- **limits.html behauptet, ein Angreifer koenne die Ablauffrist im Browserprofil editieren und wieder hineinkommen - das stimmt nicht** (klein, gemessen)  
  Ort: limits.html, Abschnitt 'What happens when the time is up?' ('anyone who can open your browser profile can edit it and get back in before the cleanup runs')  
  Beleg: Datensatz in der IndexedDB direkt manipuliert: expires von 1785616042397 auf 2100889659057 (zehn Jahre) gesetzt, dann den Link geoeffnet -> 'This drop did not open / The authentication tag does not match'. Zweiter Versuch zusaetzlich mit geloeschter aad-Marke (aad: 1 -> 0) -> identisches Ergebnis. Die Frist haengt in der additionalData des Manifests, ein Vorschieben ist also unmoeglich. Die Seite stellt ihre eigene Sicherheit schlechter dar, als sie ist - auf einer Seite, deren Verkaufsargument Genauigkeit ist.
- **Ein offensichtlich zu kurzer Schluessel wird als 'nicht in diesem Browser gespeichert' gemeldet** (klein, gemessen)  
  Ort: Reihenfolge in enterReceiveMode: Datensatzpruefung vor der Laengenpruefung des Schluessels  
  Beleg: Eingabe '#t=abc&k=AAAA' -> 'Nothing here to open. No drop with this address is stored in this browser...'. Die passende Meldung 'That is not a key' existiert und wird hier nicht erreicht, weil zuerst der Datensatz gesucht wird. Der Nutzer bekommt eine Ursache genannt, die nicht die seine ist.
- **Passwort 'aaaaaaaa' wird angenommen, und die eigene Meldung fuer ein leeres Passwort ist toter Code** (klein, gemessen)  
  Ort: PW_ZU_HAEUFIG-Liste (17 Eintraege) und PW_MINDEST=8 im Inline-Skript; #pw-open traegt required im Markup (index.html, Block st-pw)  
  Beleg: 'abc' -> abgewiesen, '12345678' -> abgewiesen, 'Passw0rd' -> abgewiesen, 'aaaaaaaa' -> akzeptiert, Drop wurde erzeugt (Link 145 Zeichen). Zweitens: Auf der Empfangsseite mit leerem Feld auf Unlock geklickt -> #pw-err bleibt unsichtbar, stattdessen die Browsermeldung 'Please fill out this field'. Die im Code hinterlegte Meldung 'Type the password first - the sender has it.' kann nie erscheinen, weil required den submit vorher abfaengt.
- **README nennt 310.000 PBKDF2-Runden, der ausgelieferte Code verwendet 600.000** (klein, gemessen)  
  Ort: README.md ('PBKDF2-SHA256 over 310,000 rounds') gegen index.html (KDF_RUNDEN = 600000); changelog.html nennt ebenfalls nur 310.000  
  Beleg: grep ueber die Dateien: '600,000'/'600000' kommt in limits.html einmal und in index.html dreimal vor, in README.md und changelog.html gar nicht; '310,000' steht in README.md und changelog.html je einmal. Auf einem Projekt, dessen Kern die Nachpruefbarkeit jeder Zahl ist, ist eine veraltete Zahl in der Datei, die zum Nachlesen einlaedt, ein Defekt.

### Vollstaendiger Review

Ich habe den Link am Donnerstagabend bekommen, mit dem Satz "schau dir das mal an, das ist wie Firefox Send, nur ohne Server". Ich hatte zwei Stunden. Ich schreibe auf, was ich gemessen habe, nicht was ich gefuehlt habe.

Zu mir, damit klar ist, gegen was ich das halte: nach jedem Lauf gehen bei uns 2 bis 20 GB Telemetrie ans Werk und an zwei Zulieferer. Zeitdruck ist extrem, das Netz im Fahrerlager ist eine Zumutung. Heute laeuft das ueber ein eigenes WireGuard-VPN und rsync ueber SSH, mit Wiederaufsetzen nach Abbruch. Das funktioniert und es ist schnell. Es kostet mich zwei Tage Einrichtung pro neuem Zulieferer, und genau deshalb habe ich ueberhaupt hingeschaut.

Erster Eindruck nach 40 Sekunden: die Seite laedt in 4,1 Sekunden bei 400 kbit/s und 300 ms Latenz, ich habe das mit gedrosseltem Netz gemessen. 420 KB unkomprimiert, brotli auf der Leitung, alles in einer Datei. Kein CDN, keine Schrift von woanders, kein Analytics-Pixel. Ueberprueft, nicht geglaubt: ich habe jeden Request mitgeschnitten, ueber alle Testlaeufe hinweg gingen genau null Anfragen an irgendeinen Host ausser cloakdrop.com, und die waren alle "GET /". Der CSP-Header sagt default-src 'none' und connect-src 'none'. Das ist kein Versprechen, das ist eine Sperre im Browser. Dazu HSTS, referrer-policy no-referrer, X-Frame-Options DENY, script-src nur ueber SHA-256-Hashes, kein unsafe-inline. Das ist strenger als das, was unser eigenes Werksportal ausliefert. Respekt dafuer.

Dann der echte Test. Ich habe eine typische Session gebaut: 24 Kanal-CSVs (Reifentemperaturen, Bremsen, Federwege, GPS, Drehzahl) plus zwei Binaerlogs, zusammen 26 Dateien und 91,1 MB. Auswahl per Dateidialog, Liste steht nach 0,05 s. Verschluesseln: 2,50 s beim ersten Lauf (36,5 MB/s), 0,7 s warm. Dann habe ich es ernst gemacht: eine 440-MB-Datei, 2,8 bis 3,6 Sekunden, also 124 bis 158 MB/s in Chromium. Firefox 40,7 MB/s, WebKit 21,3 MB/s. Das ist AES-NI plus WebCrypto, da ist nichts geschoenzt. Waehrend des Verschluesselns: null Requests. Ich habe das Netz komplett abgeschaltet und einen Drop geoeffnet, die Dateien kamen raus. Das ist fuer das Fahrerlager tatsaechlich bemerkenswert.

Und dann der Punkt, an dem das Produkt fuer mich aufhoert. Ich habe den Link genommen und ihn so benutzt, wie ich ihn wirklich benutzen wuerde: in einem zweiten Browserkontext, also Inkognito. Nach 2,51 Sekunden stand da woertlich: "Nothing here to open. No drop with this address is stored in this browser." Der Drop lebt nur in dem Browser, der ihn gemacht hat. Es gibt kein Relay. Das steht auf der Startseite, es steht auf limits.html, es steht auf status.html und im Empfangshinweis ueber dem Knopf. Niemand hat mich getaeuscht. Aber ich brauche kein Werkzeug, das mir eine Datei von meinem Laptop auf meinen Laptop schickt. Fuer meinen Fall ist das nicht "eingeschraenkt", das ist "existiert nicht". Ein Kollege haette mir dafuer einen USB-Stick geben koennen, der kann dasselbe und braucht keinen Browser.

Der zweite Blocker ist die Groesse. 620 MB werden korrekt abgelehnt, mit einer klaren Meldung, und ich habe die Sperre auch mit einem manipulierten aria-disabled nicht umgehen koennen, sie wird im Code nochmal geprueft. Sauber. Nur: 500 MB gegen meine 2 bis 20 GB heisst 4 bis 40 Drops pro Session, also 40 Links und 40 Passwoerter, und mein Zulieferer soll die dann einzeln aufmachen. Schlimmer noch, ich habe nachgemessen, wie viele davon ueberhaupt in einen Browser passen: Kontingent 1,72 GB, Drop 1 nach 3,3 s okay, Drop 2 nach 2,3 s okay, Drop 3 nach 2,1 s okay, Drop 4 bricht nach 32,3 Sekunden ab. Eine 2-GB-Session passt also nicht mal in einen Browser, ohne zwischendurch aufzuraeumen.

Diese 32 Sekunden sind uebrigens der zweite Fund, der mich stoert. Wenn der Speicher voll ist, steht der Fortschrittsbalken eine halbe Minute lang und tut nichts. Die Meldung danach ist richtig und ehrlich ("This browser ran out of room, so nothing was kept"), und ich habe nachgesehen: die Datenbank war danach wirklich leer, transfers 0, chunks 0. Aber 30 Sekunden Stille sind im Fahrerlager 30 Sekunden, in denen ich denke, das Ding haengt.

Und es gibt eine Warnung, die genau das verhindern sollte, und die kein Mensch je sieht. Ich habe den Speicher gezielt auf 98,2 MB frei gebracht und dann 91,1 MB verschluesselt. Die Schwelle im Code greift bei 107,1 MB, die Warnung wird also geschrieben. Ich habe alle 50 ms nachgesehen, ob das Warnfeld sichtbar wird: kein einziges Mal. Der Grund steht im Quelltext. Die Warnung geht in ein Element, das in der Dateiliste haengt, und die naechste Zeile blendet die Dateiliste aus. Neun Zeilen weiter unten wird die eigene Warnung unsichtbar geschaltet.

Dann habe ich versucht, es kaputtzumachen, und dabei den Fund gemacht, der mich am meisten aergert, weil er den Normalfall trifft. Ich habe den Link so eingefuegt, wie er bei mir in einer Mail steht: "Hier die Daten: <Link> Passwort kommt per Telefon." Ergebnis: "That is not a key." Bei einem Drop mit Passwort: "That is not a whole link." Der Link allein geht, Link mit Punkt am Ende geht, Link mit Zeilenumbruch mitten im Schluessel geht sogar. Aber ein Wort hinter dem Link, und es ist vorbei. Der Grund: die Leerzeichen werden entfernt, bevor die Felder gelesen werden, dadurch klebt "GrussTom" hinten am Schluessel. Im Quelltext steht drei Zeilen darueber ein Kommentar, der genau diesen Fall als geloest beschreibt und einen frueheren Tester zitiert. Er ist nicht geloest. Und wenn ich Text davor setze, "Hier: https://cloakdrop.com/#t=...", dann kommt "That is a hier: address, not a CloakDrop link." Das ist die Sorte Meldung, wegen der mich Zulieferer anrufen.

Was gut war, und davon war viel: Passwort mit drei Zeichen wird abgewiesen, "12345678" und "Passw0rd" auch, mit einer Begruendung statt einem roten Rahmen. Falsche Passworteingaben werden gebremst, gemessen 0,26 / 0,79 / 1,32 / 2,31 / 4,36 Sekunden. Ich habe ein Byte im gespeicherten Chiffrat gekippt: volle Fehlerseite, "This file was changed", nichts auf die Platte geschrieben. Ich habe die Ablauffrist im Datensatz auf zehn Jahre vorgeschoben, um mir laenger Zugriff zu erschleichen: geht nicht, "The authentication tag does not match". Auch nicht, wenn ich zusaetzlich die aad-Marke loesche. Die Frist haengt im Authentifizierungstag, das ist richtig gebaut. Lustigerweise behauptet limits.html das Gegenteil, dort steht, wer das Browserprofil oeffnen kann, koenne die Frist editieren und wieder reinkommen. Kann er nicht. Die Seite macht sich schlechter, als sie ist.

Abbruch mitten im Verschluesseln raeumt sauber auf, ich habe danach in die IndexedDB geschaut: transfers 0, chunks 0. Neuladen mittendrin hinterlaesst einen Rest, der ehrlich als "Unfinished" in der Uebersicht steht und beim naechsten Start nach 13 Sekunden wirklich verschwindet, nachgemessen. Ein zweiter Tab, der den Drop loescht, waehrend der erste schreibt, fuehrt zu einer korrekten Meldung statt zu einem Link auf ein halbes Chiffrat. Kurznamen ueberleben das Neuladen. Loeschen ist zweistufig und loescht wirklich alles, inklusive aller Bruchstuecke.

Der Forensiktest war der, bei dem ich am ehesten damit gerechnet habe, etwas zu finden. Ich habe mit einem echten Profilordner gearbeitet, sechs Dateien verschluesselt, den Browser geschlossen und dann den ganzen Ordner byteweise durchsucht. Ergebnis: 6,5 MB Chiffrat liegen da, aber kein Dateiname, kein Schluessel, kein Linkfragment. Die Blockgroessen verraten die Klartextgroessen auf 37 Byte genau, und genau das sagt die Seite auch. Das deckt sich.

Unterm Strich: das ist die sauberste Verschluesselungsdemo, die ich seit Firefox Send gesehen habe, und sie ist ehrlicher als alles, was ich in dem Bereich kenne. Aber ich kaufe kein Transportmittel ohne Transport. Ich bleibe bei VPN und rsync, weil rsync 20 GB ueber eine wackelige Leitung schiebt, nach einem Abbruch dort weitermacht, wo es war, und keine 40 Links produziert. Fuer einmalige Uebergaben nach draussen nutzen wir Tresorit und gelegentlich SwissTransfer, und beide loesen genau das Problem, das CloakDrop heute nicht anfasst. Wormhole und croc kenne ich, croc laeuft bei uns auf zwei Kisten, und croc kann heute, was hier "in Arbeit" heisst. Bitwarden Send waere das naechste Vergleichsstueck, und auch das uebertraegt.

Was mich positiv ueberrascht hat: dass wirklich nichts rausgeht, und dass ich es in zehn Minuten selbst belegen konnte. Was mich negativ ueberrascht hat: dass ausgerechnet der Einfuegepfad, auf den die Seite mit einem Kommentar im Code stolz ist, an einem angehaengten Wort scheitert. Und dass es nirgends einen Preis, keinen Betreiber, keine Zusage gibt, wann das Relay steht. Ich kann intern keinen Dienst vorschlagen, bei dem ich auf die Frage "was kostet das und wer haftet" nichts sagen kann.

Meldet euch, wenn das Relay steht, wenn ein Drop mindestens 5 GB kann und wenn ein abgebrochener Transfer wieder aufsetzt. Dann rechne ich neu. Heute nicht.

---

## Dr. Almut Rehberg-Sander — Compliance-Officer einer Regionalbank, 47

**Note 3.6 · wuerde nutzen: nein**

### Begruendung der Note

Handwerklich ist das eine der saubersten Sachen, die mir je auf den Tisch gelegt wurden: null Netzverkehr bei 457 MB, gemessen; eine CSP mit connect-src 'none', die das maschinell erzwingt; 457 MB byteidentisch zurueck; Loeschen, das Datensatz und alle Bruchstuecke wirklich entfernt; eine Ablauffrist, die kryptografisch gebunden ist. Dafuer gibt es Punkte. Abgezogen habe ich fuer zwei belegte Defekte im Passwortpfad — eine Mindestlaenge, die vor dem Trimmen prueft und nach dem Trimmen wickelt, und acht Leerzeichen, die kommentarlos einen ungeschuetzten Link erzeugen —, fuer einen Einfuegefehler, der genau den Outlook-Normalfall trifft, den der Code selbst als geloest bezeichnet, und dafuer, dass die Kernfunktion, das Versenden, nicht existiert. Vor allem aber: es gibt keinen Vertragspartner, kein Protokoll und keinen Nachweis. Ein Werkzeug ohne Auftragsverarbeitungsvertrag und ohne Aufzeichnung kann ich nicht freigeben, egal wie gut die Kryptografie ist. 3,6 ist die Note fuer ein ehrliches, gut gebautes Vorprodukt, das mein Problem nicht loest.

### Blocker

1. Kein Vertragspartner: keine Firmierung, keine Rechtsform, keine ladungsfaehige Anschrift, kein Auftragsverarbeitungsvertrag, keine Unterauftragnehmerliste. Ohne Vertrag ist keine Eintragung in das DORA-Informationsregister (Art. 28-30) und keine Auslagerungspruefung nach §25b KWG / MaRisk AT 9 moeglich.
2. Die Kernfunktion fehlt: es gibt kein Relay. Ein Link oeffnet ausschliesslich im Browser, der ihn erzeugt hat — gemessen im fremden Kontext: 'Nothing here to open'. Ein Versandweg, der nicht versendet, loest mein Problem nicht.
3. Keine Revisionssicherheit: kein Protokoll, kein Zeitstempel, kein Empfaengernachweis, kein Export. Ich kann der Innenrevision oder der Aufsicht nicht belegen, welche Unterlage wann an wen ging.
4. Kein Notfallkonzept: das Endgeraet ist der einzige Ort. Festplattendefekt, Geraetetausch, Loeschen der Websitedaten oder eine Speicherbereinigung des Browsers vernichten den Drop ohne zweiten Weg und ohne Wiederherstellung.
5. Aufbewahrungspflichten kollidieren: maximale Frist sieben Tage, keine Verlaengerung moeglich, gegen zehn Jahre nach §257 HGB und §147 AO.
6. Keine zentrale Administration: keine Richtliniendurchsetzung, keine erzwungene Mindestfrist, kein erzwungenes Passwort, keine Mandantentrennung. Jeder Mitarbeiter entscheidet allein — und der Passwortpfad haelt seine eigene Regel nicht ein.
7. Kein Support-SLA, keine Zertifizierung (ISO 27001, C5, SOC 2), kein veroeffentlichter Pentest-Bericht, kein Sicherheits-Whitepaper — laut about.html alles hinter dem Relay eingereiht.
8. Der Client ist lesbar, aber nicht lizenziert und nicht als Repository verfuegbar. Unser IT-Sicherheitsbeauftragter darf ihn nicht in einer eigenen Umgebung nachstellen oder pruefen lassen.

### Was gut ankam

- Null Netzanfragen waehrend der Verschluesselung, selbst bei 457,3 MB in 2,9 Sekunden — gemessen ueber die Netzwerkaufzeichnung, nicht geglaubt. Insgesamt nur Anfragen an cloakdrop.com selbst, kein einziger Fremdhost.
- Die CSP erzwingt das maschinell: default-src 'none', connect-src 'none', script-src nur ueber SHA-256-Hashes, kein unsafe-inline, kein unsafe-eval. Playwright konnte deswegen nicht einmal eine Wartebedingung als String auswerten — der Browser hat es blockiert. Das ist ein Beleg, den ich meiner IT-Sicherheit vorlegen kann.
- 457,3 MB in zwei Dateien gingen byteidentisch wieder heraus (SHA-256 verglichen), das ZIP wurde in 12,3 Sekunden gebaut und war formal fehlerfrei. Auch der 55-MB-Drop mit zwoelf Dateien kam vollstaendig identisch zurueck.
- Das Loeschen haelt, was es verspricht: nach zwei Klicks waren transfers 0 und chunks 0, und der Link zeigte danach 'Nothing here to open'. Der Abbruch waehrend des Verschluesselns bei 61 Prozent hinterliess ebenfalls nichts.
- Ein Neuladen mitten im Verschluesseln hinterlaesst 39 Bruchstuecke und 156 MB — die App nennt sie in der Verwaltung ausdruecklich beim Namen ('One drop below was never finished') und raeumt sie nach 13 Sekunden beim naechsten Start restlos weg. Gemessen.
- Die Ablauffrist ist kryptografisch gebunden: ein im Browserprofil manipuliertes Ablaufdatum macht den Drop unbrauchbar statt ihn zu verlaengern.
- Die Fehlermeldungen sind ungewoehnlich gut. Sie unterscheiden zwischen abgeschnittenem Schluessel, nicht passendem Tag und fehlendem Bruchstueck und schieben dem Nutzer keine Schuld zu, wo sie nicht hingehoert.
- Fremde Domain, javascript: und data: werden im Einfuegefeld sauber und mit Nennung des Grundes abgewiesen. Zeilenumbruch mitten im Schluessel, Klammern und ein zitiertes '> ' davor werden korrekt verkraftet.
- Die Bremse gegen Durchprobieren greift messbar: 0,27 / 0,78 / 1,33 / 2,32 / 4,38 Sekunden bei fuenf Fehlversuchen in Folge.
- Die 500-MB-Grenze wird nicht nur ueber den Knopfzustand durchgesetzt: nach dem Entfernen des aria-disabled kam trotzdem 'That is 520.0 MB — a drop carries up to 500.0 MB'.
- Auf der Platte bleibt nach dem Schliessen nur Chiffrat: 2.400.038 Byte fuer eine 2.400.000-Byte-Datei. Eine Suche nach Dateiname und Inhalt im Browserprofil ergab keinen Treffer — das Manifest ist tatsaechlich verschluesselt.
- Die Ehrlichkeit der Texte. Der Verify-Abschnitt 'What this does not prove' nennt selbst, dass der Client nicht quelloffen ist und dass die Chiffratlaenge die Klartextlaenge verraet. limits.html schreibt in einer FAQ auf einer Marketingseite den Satz 'treat this as something to try, not something to rely on at work'. Das habe ich in fuenfzehn Jahren Anbieterpruefung dreimal gesehen.
- Die App hat mir ungefragt gemeldet, dass zwei meiner Dateien 0 Byte gross sind — einer davon war ein echter Fehler meiner eigenen Testumgebung, den sonst niemand bemerkt haette.

### Heutige Loesung

Dreigleisig, und wir behalten alle drei. Meldungen an die Aufsicht laufen ueber die vorgeschriebenen Portale; fuer den Wirtschaftspruefer nutzen wir dessen Datenraum mit Vertrag, Zugriffsliste und Protokoll; intern liegt ein selbst betriebenes Nextcloud auf eigener Hardware mit AD-Anbindung, Ablaufdatum, Freigabeprotokoll und einem von der Revision abgenommenen Loeschkonzept. Fuer die schnelle Einzelakte an externe Anwaelte: 7-Zip-Archiv mit AES-256, Passwort per Telefon, Versand ueber unser protokollierendes Mailgateway. WeTransfer ist seit der Aufregung um die Nutzungsbedingungen im Juli 2025 gesperrt, Dropbox und Google Drive waren es vorher schon. Tresorit und Sync.com haben wir wegen des Preises pro Platz vertagt, Proton Drive und Filen liegen fuer den naechsten Turnus in der Schublade. CloakDrop ersetzt nichts davon, weil ihm der Vertrag, das Protokoll und der zweite Weg fehlen — nicht, weil die Kryptografie schlechter waere.

### Gemeldete Defekte (8)

- **Passwort-Mindestlaenge wird vor dem Trimmen geprueft, verwendet wird das getrimmte Passwort** (schwer, gemessen)  
  Ort: index.html, Inline-Skript der App (Funktion cloakAndStore): Pruefung ueber 'var pwWert = pwFeld ? pwFeld.value : ""' gegen PW_MINDEST = 8; spaeter 'var passwort = ($("pw-input").value || "").trim()' fuer das Einwickeln des Schluessels  
  Beleg: Gemessen am 31.07.2026 mit Playwright (Skript p5-8c.py, eigenes Browserprofil): Eingabe '   ab   ' (8 Zeichen) wird ohne Fehlermeldung angenommen, der erzeugte Link traegt ein Salz, und der Drop laesst sich anschliessend mit dem Passwort 'ab' (2 Zeichen) oeffnen -> '1 cloaked file'. Eingabe ' abcdefg ' (9 Zeichen) wird angenommen und oeffnet sich mit 'abcdefg' (7 Zeichen). Die App setzt also eine Mindestlaenge durch, die sie anschliessend selbst unterschreitet.
- **Ein Passwort aus lauter Leerzeichen erzeugt kommentarlos einen ungeschuetzten Link** (schwer, gemessen)  
  Ort: index.html, Inline-Skript der App: derselbe trim()-Aufruf; anschliessend 'if (passwort) { ... schluesselEinwickeln ... } else { fragment = "#t=" + id + "&k=" + b64urlEncode(rawKey) }'  
  Beleg: Gemessen am 31.07.2026 (Skript p5-8-test.py, Stufe 2): Eingabe von acht Leerzeichen ins Passwortfeld wird ohne jede Meldung angenommen. Der ausgegebene Link lautet 'https://cloakdrop.com/#t=9CXVSN6jCoN3&k=j3nHQJbKsMr6dcgkYAYt8ZOb-8KN0cSBWHMYnUCC-LE' — kein '&s=' Feld, also 32 Byte blanker AES-Schluessel im Klartext im Link. Die Fertig-Ansicht zeigt done-nopw statt done-pw, sagt aber an keiner Stelle, dass die Eingabe verworfen wurde. Der Nutzer glaubt, ein Passwort gesetzt zu haben.
- **Text hinter dem eingefuegten Link wird an den Schluessel geklebt und macht ihn unbrauchbar** (schwer, gemessen)  
  Ort: index.html, Inline-Skript, Funktion tryOpenLink: 'frag = frag.replace(/\s+/g, "")' laeuft VOR 'frag.match(new RegExp(...name + "=([A-Za-z0-9_-]+)"))'  
  Beleg: Gemessen am 31.07.2026 (Skript p5-8d.py) gegen einen Drop, der im selben Browser liegt. Link + ' Viele Gruesse' -> Fehlerseite 'That is not a key'. Link + Zeilenumbruch + 'Viele Gruesse' -> dieselbe Fehlerseite. Link + ' Az 4711' -> dieselbe Fehlerseite. Dagegen oeffnen sich: Link + '.', Link + ', viele Gruesse', Link in Klammern, Link mit '> ' davor, Link mit Zeilenumbruch mitten im Schluessel. Der Kommentar im Quelltext bezeichnet genau diesen Fall ('Ein Link am Satzende ist in Outlook der Normalfall') als geloest und die Meldung 'That is not a key' als schuldzuweisend — beides trifft weiterhin zu.
- **limits.html behauptet eine Schwaeche der Ablauffrist, die es nicht mehr gibt** (klein, gemessen)  
  Ort: limits.html, FAQ-Abschnitt 'What happens when the time is up?': 'the check compares against a timestamp stored in your own browser, so anyone who can open your browser profile can edit it and get back in before the cleanup runs'  
  Beleg: Gemessen am 31.07.2026 (Skript p5-8e.py): Drop mit 1-Stunden-Frist angelegt, dann das Feld 'expires' im IndexedDB-Datensatz auf einen Zeitpunkt in zehn Jahren gesetzt. Ergebnis beim Oeffnen: 'This drop did not open / The authentication tag does not match' — der Drop laesst sich danach ueberhaupt nicht mehr oeffnen, weil die Frist in die authentifizierten Zusatzdaten des Manifests eingebunden ist. Zur Gegenprobe 'expires' in die Vergangenheit gesetzt: korrekte Meldung 'This link no longer opens', und nach einem Neustart transfers 0 / chunks 0. Die Dokumentation beschreibt das Produkt schlechter, als es ist.
- **Die Verwaltung der gespeicherten Drops ist aus der Fertig-Ansicht nicht erreichbar, ohne den Link zu vernichten** (mittel, gemessen)  
  Ort: index.html: der Knopf 'Manage' (#drops-open) sitzt in der Zeile #storeline, die Teil des Zustands #st-idle ist; enterAppMode() zeigt bei vorhandenem erzeugterLink immer wieder #st-done  
  Beleg: Gemessen am 31.07.2026 (Skript p5-8-test.py, Stufe 1): Nach dem Verschluesseln ist #drops-open unsichtbar; auch ein erneuter Aufruf von '#app' fuehrt zurueck nach st-done, Manage bleibt unsichtbar. Erst zwei Klicks auf 'Start a new drop' (der erste warnt 'Press again — the link is gone then') fuehren nach st-idle; das Linkfeld ist danach leer. Wer den gerade erzeugten Drop in der Liste sehen oder einen aelteren loeschen will, muss also erst den frischen Link aufgeben.
- **Umlaute fallen aus dem Namen des Sammelarchivs** (klein, gemessen)  
  Ort: index.html, Inline-Skript, Aufbau des ZIP-Namens: '.replace(/[^\w .()-]+/g, "")' — \w umfasst in JavaScript nur A-Z a-z 0-9 _  
  Beleg: Gemessen am 31.07.2026: Ein Drop, dessen erste Datei 'Anlage_A_Ümlaute_äöüß_Straße.pdf' heisst, ergibt beim Knopf 'Download all' die Datei 'Anlage_A_mlaute__Strae and 11 more.zip'. Die Dateien im Archiv selbst tragen ihre Umlaute korrekt (mit UTF-8-Flag, Bit 11), nur der Archivname nicht.
- **Das Kanalband beschreibt das eigene Verhalten falsch** (klein, gemessen)  
  Ort: index.html, Abschnitt unter dem Kanalband: 'Sending one to someone else shows them an empty page.'  
  Beleg: Gemessen am 31.07.2026: Der Link, in einem fremden Browserkontext geoeffnet, zeigt nach rund 1,5 Sekunden eine vollstaendige Fehlerseite mit Titel 'Nothing here to open' und einem dreisatzigen Erklaertext, keine leere Seite. Die Aussage untertreibt das eigene Produkt, ist aber sachlich unzutreffend.
- **Kein Protokoll, keine Empfaengerangabe, kein Nachweis — und nach Verlust des Links kennt die App den Inhalt eines Drops selbst nicht mehr** (kritisch, gemessen)  
  Ort: Gesamtes Produkt; index.html, Funktion dropsAnzeigen(): die Zeile lautet 'Cloaked ' + Zeitstempel + ' · opens for ' + Restzeit, dazu Groesse und ein frei tippbares Etikett (maxLength 40)  
  Beleg: Gemessen am 31.07.2026: Die Verwaltung zeigt fuer meinen Drop 'Cloaked 2026-07-31 22:31 · opens for 7 more days | 55.1 MB | Delete'. Dateinamen erscheinen nicht, weil das Manifest mit dem Schluessel aus dem Link verschluesselt ist. Es gibt kein Empfaengerfeld, keine Empfangsbestaetigung, keinen Export und keine Aufzeichnung ausser dem selbst getippten Etikett, das ich mit 'BaFin-Anfrage 2026-07 / Az. 4711' belegt und im IndexedDB-Datensatz im Klartext wiedergefunden habe. Fuer MaRisk AT 4.3.1, die Revisionssicherheit und die Aufbewahrungspflichten nach §257 HGB / §147 AO ist das kein Mangel im Sinne eines Fehlers, aber ein Ausschlussgrund.

### Vollstaendiger Review

Ich bin Compliance-Officer bei einer Regionalbank, seit elf Jahren. Wenn eine Fachabteilung ein neues Werkzeug will, landet es auf meinem Tisch, bevor es auf einem Rechner landet. Den Link zu CloakDrop hat mir unser Leiter Marktfolge Aktiv geschickt, mit dem Satz "das waere doch was fuer die Pruefungsunterlagen". Ich habe mir zweieinhalb Stunden genommen und es nicht angeschaut, sondern benutzt.

Zum Testmaterial: Ich habe zwoelf Dateien angelegt, wie sie bei uns wirklich anfallen — eine Kreditakte mit 8,4 MB, einen MaRisk-Pruefungsbericht mit 22 MB, einen Jahresabschluss-Entwurf, ein Auslagerungsregister als CSV, ein Vorstandsprotokoll, eine Kundenliste, dazu absichtlich eine Datei mit Umlauten, eine mit Sonderzeichen, eine leere und eine mit einem 195 Zeichen langen Namen, weil unsere Aktenzeichen so aussehen. Zusammen 55,3 MB. Spaeter noch einen Datenraum-Export von 457 MB, um an die Grenze zu gehen.

**Der erste Durchgang.** Nach 0,9 Sekunden war ich hinter der Vorabwand, nach zwei Sekunden hatte ich die zwoelf Dateien in der Ablage. Die Liste sagte "12 files, 55.1 MB" und darunter, ungefragt: zwei der Dateien seien leer, das sei vermutlich nicht gemeint. Das war korrekt — eine leere hatte ich absichtlich eingebaut, die zweite war ein Fehler meiner eigenen Testumgebung, den mir das Werkzeug freundlicher gemeldet hat als mancher Kollege. Ich habe die Frist auf sieben Tage gestellt, es gibt eine Stunde, 24 Stunden, sieben Tage, mehr nicht. Dann "Cloak and create link". Nach 0,4 Sekunden stand der Link da. Ich habe die Entwicklerwerkzeuge mitlaufen lassen: null Anfragen waehrend der Verschluesselung. Nicht wenige. Null. Bei dem 457-MB-Drop spaeter dasselbe, 2,9 Sekunden, null Anfragen. Das ist die eine Zusage dieser Seite, und sie haelt.

Ich habe dann getan, was ich wirklich taete: den Link in einen fremden Browser gelegt. Nach eineinhalb Sekunden stand dort "Nothing here to open. No drop with this address is stored in this browser." Damit ist der Fall fuer meine Fachabteilung eigentlich erledigt, und die Seite sagt es auch selbst, auf der Startseite, in limits, in verify, in about, in status. Es gibt kein Relay. Was hier steht, ist ein Verschluesselungswerkzeug mit einem Ablagefach im eigenen Browser, kein Versandweg. Ich rechne der Seite hoch an, dass sie das an sechs Stellen ausspricht statt es zu verstecken — der Satz "Today it encrypts and stores; it does not yet send" steht in der Ueberschrift, nicht im Kleingedruckten. Nur aendert er nichts daran, dass mein Problem der Versand ist. Wir verschluesseln nicht zum Vergnuegen.

**Was ich trotzdem weiter geprueft habe.** Im eigenen Browser oeffnet der Link sauber, alle zwoelf Zeilen, Umlaute richtig dargestellt, der 195-Zeichen-Name vollstaendig. "Download all" baute ein ZIP von 55,1 MB; ich habe es mit Pythons zipfile geoeffnet und Byte fuer Byte gegen die Originale gehalten: identisch. Beim 457-MB-Drop dasselbe, ZIP-Bau 12,3 Sekunden, beide Dateien identisch nach SHA-256. Das ist mehr Sorgfalt, als ich von Werkzeugen dieser Groesse gewohnt bin.

Der Archivname allerdings heisst "Anlage_A_mlaute__Strae and 11 more.zip". Die Umlaute sind herausgefallen. Fuer ein Produkt, dessen Seiten in tadellosem Englisch geschrieben sind, aber dessen Quelltext deutsche Kommentare hat, ist das eine Nachlaessigkeit — bei uns heisst jede zweite Datei "Straßenbau" oder "Rückstellungen".

**Der Passwortpfad, und hier wird es unangenehm.** Ich habe die Reihe durchgespielt. Ein Zeichen: abgewiesen, mit einer gut geschriebenen Begruendung. Sechs Zeichen: abgewiesen. "passwort", "Passwort", "12345678": abgewiesen mit dem Hinweis, das stehe auf jeder Rateliste. Soweit ordentlich. Dann habe ich getippt, was ein Mensch tippt, der aus einem Word-Dokument kopiert: ein Passwort mit Leerzeichen davor und dahinter. " abcdefg " — neun Zeichen, wird angenommen. Der Drop laesst sich anschliessend mit "abcdefg" oeffnen, sieben Zeichen. "   ab   " — acht Zeichen, wird angenommen; der Drop laesst sich mit "ab" oeffnen. Zwei Zeichen. Die Regel, die die App verkuendet und die auf zwei Seiten steht, wird also geprueft, bevor die Eingabe bereinigt wird, und angewendet, nachdem sie bereinigt wurde. Das ist im Quelltext nachzulesen und ich habe es dreimal gemessen.

Schlimmer ist der Sonderfall: acht Leerzeichen. Die App nimmt sie an, meldet nichts, und der Link, den sie ausgibt, traegt gar kein Salz — also den blanken Schluessel im Klartext. Der Nutzer glaubt, er habe ein Passwort gesetzt; er hat einen ungeschuetzten Link in der Hand. Die Fertig-Ansicht zeigt in diesem Fall den Text ohne Passwort, das ist der einzige Hinweis, und den liest niemand, der gerade ein Passwort eingegeben hat. Fuer ein Produkt, das seinen gesamten Wert aus "cryptography keeps the promise, not a privacy policy" zieht, ist eine Zusage, die stillschweigend nicht gilt, der teuerste Fehler von allen.

Positiv: die Bremse bei Fehlversuchen greift wirklich. Ich habe fuenf falsche Passwoerter durchprobiert und 0,27 / 0,78 / 1,33 / 2,32 / 4,38 Sekunden gemessen. Und ein falsches Passwort liefert nichts, nicht etwas Falsches — GCM prueft den Tag zuerst.

**Kaputtmachen.** Ich habe sechzehn Varianten durch das Einfuegefeld geschickt. Fremde Domain: sauber abgewiesen mit Nennung des Hosts. javascript: und data:: abgewiesen. Nur das Fragment, Fragment ohne Raute, Link in Klammern, Link mit Zeilenumbruch mitten im Schluessel, Link mit "> " davor wie in einer zitierten Mail — alles geht auf. Das ist deutlich besser als bei den meisten. Aber: Link, Leerzeichen, "Viele Gruesse" — "That is not a key". Link, Zeilenumbruch, "Viele Gruesse" — dasselbe. Link, dann "Az 4711" — dasselbe. Ein Punkt oder ein Komma direkt hinter dem Link stoert nicht, ein Wort dahinter zerstoert den Schluessel. Der Grund steht im Quelltext: es werden erst alle Leerzeichen entfernt und dann die Felder gelesen, wodurch das folgende Wort an den Schluessel geklebt wird. Ausgerechnet dieser Fall ist im Code mit einem Kommentar versehen, der ihn als geloest bezeichnet und die Meldung "That is not a key" ausdruecklich als schuldzuweisend kritisiert. Genau diese Meldung habe ich bekommen. In Outlook ist ein Link mit "Viele Grüße" dahinter nicht die Ausnahme, das ist jede zweite Mail bei uns.

**Abbruch, Neuladen, zweiter Tab.** Hier war ich am staerksten ueberrascht, im Guten. Abbruch bei 61 Prozent eines 300-MB-Drops: Datensatz und alle Bruchstuecke weg, gemessen ueber IndexedDB, nicht ueber die Oberflaeche. Neuladen mitten im Verschluesseln hinterlaesst 39 Bruchstuecke und 156 MB — die Verwaltung nennt sie beim Namen, "One drop below was never finished", und nach 13 Sekunden Wartezeit und einem Neustart waren sie restlos fort. Loeschen ueber die Verwaltung: transfers 0, chunks 0. Der Link danach: "Nothing here to open". Das ist ein Loeschkonzept, das haelt, was es sagt, und ich habe schon Datenraumanbieter geprueft, bei denen das nicht so war.

Die Ablauffrist habe ich manipuliert, weil limits.html selbst behauptet, wer das Browserprofil oeffnen kann, koenne die Frist editieren und wieder hineinkommen. Das stimmt nicht mehr. Ich habe das Ablaufdatum im Profil auf zehn Jahre gesetzt; der Drop oeffnet danach gar nicht mehr, weil die Frist in die authentifizierten Zusatzdaten des Manifests eingebunden ist. Die Seite redet ihr eigenes Produkt schlechter, als es ist. Das ist mir lieber als andersherum, aber falsch bleibt falsch — ich haette diese Schwaeche in meine Risikobewertung geschrieben.

**Und jetzt die Frage, die ich immer zuerst stelle: wer ist mein Vertragspartner?** Es gibt keinen. Kein Firmierung, keine Rechtsform, keine ladungsfaehige Anschrift, kein Auftragsverarbeitungsvertrag, keine Unterauftragnehmerliste, kein SLA, keine Zertifizierung, kein Pentest-Bericht, kein Ansprechpartner ausser hello@cloakdrop.com. Die Seite argumentiert, ein AVV habe nichts, woran er sich festmachen koenne, weil niemand die Daten haelt. Das ist fuer den heutigen Bauzustand sogar richtig gedacht, und limits.html sagt selbst den Satz, den ich sonst haette schreiben muessen: "treat this as something to try, not something to rely on at work". Nur fuehrt das fuer mich zu einem Widerspruch, den die Seite nicht aufloest. §25b KWG und MaRisk AT 9 verlangen bei einer Auslagerung einen Vertrag; DORA Artikel 28 bis 30 verlangt seit 2025 ein Informationsregister ueber jeden IKT-Drittdienstleister, mit Vertragsklauseln, Ausstiegsstrategie und Meldewegen. Ein Werkzeug ohne Betreiber laesst sich in dieses Register nicht eintragen — und ein Werkzeug, das ich nicht eintragen kann, kann ich nicht freigeben, auch wenn es technisch die sauberste Loesung im Feld waere.

Dazu kommt der Punkt, an dem sich das Versprechen dieser Seite und meine Pflichten frontal widersprechen. CloakDrop fuehrt kein Protokoll. Es gibt kein Empfaengerfeld, keine Empfangsbestaetigung, keinen Zeitstempel, den ich einer Pruefung vorlegen koennte, keinen Export. Wenn die Innenrevision in achtzehn Monaten fragt, welche Unterlagen am 31. Juli an welchen Wirtschaftspruefer gegangen sind, habe ich nichts. Schlimmer: nach Verlust des Links weiss nicht einmal die App noch, was in einem Drop lag — das Manifest ist verschluesselt, die Verwaltung zeigt "Cloaked 2026-07-31 22:31, 55.1 MB" und ein Etikett, das ich selbst getippt habe. Ich habe "BaFin-Anfrage 2026-07 / Az. 4711" eingetragen; das Feld nimmt vierzig Zeichen und speichert im Klartext, was fuer sich genommen ehrlich dokumentiert ist. Aber ein selbstgetipptes Etikett ist kein Nachweis, das ist eine Notiz. Was fuer einen Journalisten oder einen Anwalt das Kaufargument ist — nichts bleibt liegen, niemand kann etwas herausgeben — ist fuer mich das Ausschlusskriterium. Aufbewahrungspflichten nach §257 HGB und §147 AO fordern zehn Jahre; eine Frist von maximal sieben Tagen, die niemand verlaengern kann, arbeitet dagegen.

Auch das Notfallkonzept fehlt vollstaendig, und zwar nicht aus Nachlaessigkeit, sondern konstruktionsbedingt. Das Geraet ist der einzige Ort. Wird der Laptop getauscht, faellt die Festplatte aus, raeumt der Browser den Speicher auf, oder loescht ein Kollege die Websitedaten — dann ist der Drop weg, ohne zweiten Weg. Ich habe nach dem Schliessen des Browsers ins Profil gesehen: dort liegen 2.400.038 Byte fuer eine 2.400.000-Byte-Datei, also das Chiffrat plus Tag, und die Groesse verraet exakt die Klartextlaenge. Nach Klartext habe ich gesucht, Dateiname und Inhalt: keine Treffer, das Manifest ist wirklich verschluesselt. Sauber gemacht. Aber es bleibt liegen, bis jemand die Seite das naechste Mal oeffnet, und das sagt limits.html auch so.

Zwei Kleinigkeiten noch. Die Verwaltung der gespeicherten Drops ist aus der Fertig-Ansicht nicht erreichbar; ich musste zweimal auf "Start a new drop" druecken, was den gerade erzeugten Link vernichtet, um ueberhaupt an die Liste zu kommen. Und das Kanalband behauptet, ein weitergeleiteter Link zeige dem Empfaenger "an empty page" — er zeigt eine ordentliche Fehlerseite. Selbst beim Untertreiben ungenau.

**Meine heutige Loesung.** Fuer die Aufsicht gehen Meldungen ueber das vorgeschriebene Portal, daran aendert kein Werkzeug etwas. Fuer den Wirtschaftspruefer nutzen wir dessen Datenraum, mit Vertrag, Protokoll und Zugriffsliste. Intern liegt ein selbst betriebenes Nextcloud auf unserer eigenen Hardware, mit AD-Anbindung, Ablaufdatum, Freigabeprotokoll und einem Loeschkonzept, das die Revision abgenommen hat. Fuer die schnelle Einzelakte an einen externen Rechtsanwalt: ein 7-Zip-Archiv mit AES-256, Passwort per Telefon, Versand ueber unser Mailgateway, das den Vorgang protokolliert. Das ist umstaendlicher als CloakDrop und kryptografisch nicht besser, aber es hat drei Dinge, die CloakDrop nicht hat: einen Vertrag, ein Protokoll und einen zweiten Weg, wenn etwas schiefgeht. Ich behalte es. WeTransfer ist bei uns seit der Aufregung um die Nutzungsbedingungen im Juli 2025 gesperrt, Dropbox und Google Drive waren es schon vorher; Tresorit und Sync.com haben wir angesehen und wegen des Preises pro Platz vertagt; Proton Drive und Filen liegen in der Schublade fuer den naechsten Turnus; an Firefox Send erinnere ich mich gut, und dass es 2020 wegen Missbrauchs abgeschaltet wurde, ist genau die Frage, die ich CloakDrop stellen werde, sobald das Relay steht.

**Was mich ueberrascht hat.** Im Guten: dass ein Werkzeug seinen eigenen unfertigen Zustand an sechs Stellen ausspricht, statt ihn zu verstecken; dass die Verify-Seite einen Abschnitt "What this does not prove" hat, in dem ausdruecklich steht, dass der Client nicht quelloffen ist und dass die Ciphertext-Laenge die Klartext-Laenge verraet; dass ich in einer FAQ auf einer Marketingseite den Satz finde, ich solle das im Beruf noch nicht einsetzen. Diese Haltung habe ich in fuenfzehn Jahren Anbieterpruefung dreimal gesehen. Im Schlechten: dass ausgerechnet der Passwortpfad, das einzige Stueck, das die Seite als Schutz gegen den weitergeleiteten Link verkauft, zwei belegbare Loecher hat. Und dass "Read the code" bedeutet: lesen ja, pruefen lassen nein, keine Lizenz, kein Repository. Mein IT-Sicherheitsbeauftragter darf den Client nicht einmal in einer eigenen Umgebung nachstellen, um ihn zu testen. Das ist eine nachvollziehbare Entscheidung fuer ein junges Produkt und trotzdem genau die Huerde, an der eine Freigabe bei uns scheitert.

Fazit: technisch respektabel, sprachlich das ehrlichste Produktauftreten seit langem, fuer meinen Bereich nicht einsetzbar. Ich moechte in zwoelf Monaten wieder eingeladen werden — dann mit Relay, mit einer Firmierung, mit einem AVV-Muster und einem Exportformat, das ich der Revision hinlegen kann. Die Kryptografie brauche ich nicht mehr zu pruefen, die stimmt.

---

## Lina, Kurzvideo-Creatorin (180.000 Follower), arbeitet fast nur am iPhone und in Discord — Content Creatorin, 23

**Note 3.6 · wuerde nutzen: nein**

### Begruendung der Note

Die Verschlüsselung ist echt und nachweisbar sauber: 212 MB in 1,4 s, null Netzanfragen, das ZIP kam byte-identisch zurück (sha256 aller sechs Dateien gleich). Dafür allein gäbe es eine gute Note. Aber das Produkt kann die eine Sache nicht, für die ich es brauche: verschicken. Im zweiten Browser stand nach 2,5 Sekunden "Nothing here to open" — mein Kunde sieht eine leere Seite. Dazu 500 MB Deckel gegen meine 620 MB bis 2 GB Master, zwei gemessene Handy-Defekte (Copy-Knopf 97 px über dem Bildrand, Dateinamen im Empfang auf 101 px gekürzt) und zwei Parser-Fehler, die genau meine Kanäle treffen: Link + Leerzeichen + Wort ergibt "That is not a key", "Link: <url>" ergibt "That is a link: address". Als Demo 8, als Werkzeug für meinen Job 1. Daraus wird 3,6.

### Blocker

1. Kein Relay: der Link oeffnet ausschliesslich im Browser, der ihn erzeugt hat. Im frischen Kontext kam nach 2,5 s 'Nothing here to open'. Damit kann das Produkt meine Kernaufgabe - fertige Cuts an eine Agentur schicken - heute nicht erfuellen.
2. 500 MB Deckel pro Drop. Mein Master hat 620 MB, viele haben 1 bis 2 GB. Gemessen: '1 file · 620.0 MB — over the 500.0 MB preview limit'. Discord Nitro gibt mir 500 MB pro Datei, WeTransfer 2 GB gratis, SwissTransfer 50 GB.
3. Der Link ueberlebt kein Neuladen und kein Verwerfen des Tabs - am iPhone passiert genau das staendig, wenn ich zwischen Safari und Discord wechsle. Ohne Warnung, ohne Wiederherstellung.
4. Zwei Parser-Fehler treffen exakt die Art, wie ich Links verschicke: Wort hinter dem Link und 'Link:' vor dem Link. Beides ergibt eine Fehlermeldung beim Empfaenger, und beide Meldungen schieben ihm die Schuld zu.

### Was gut ankam

- Beim Verschluesseln von 212 MB in sechs Dateien: null Netzanfragen mitgeschrieben. Ueber den kompletten zweiten Durchlauf inklusive Download all genau eine Anfrage, und die ging an cloakdrop.com selbst. Kein Analytics, kein Sentry, keine fremde Domain.
- 212,0 MB in 1,4 Sekunden verschluesselt (Fortschritt bei 0,4 s schon 31 %). 40 Clips mit 120 MB in 0,9 s. Das ist schneller als der Upload-Balken von WeTransfer ueberhaupt anlaeuft.
- Download all lieferte ein ZIP mit allen sechs Dateien, testzip() ohne Beanstandung, alle sechs SHA-256-Summen identisch mit den Originalen. Auch der 178 Zeichen lange Dateiname mit Emoji und Umlauten kam unveraendert zurueck.
- Im Browserprofil auf der Platte (61 Dateien in der IndexedDB durchsucht) steht kein einziger Dateiname im Klartext. Die Namen liegen wirklich im verschluesselten Manifest.
- Das RLO-Zeichen wird aus dem Namen entfernt: 'rechnung<RLO>gpj.exe' erscheint als 'rechnunggpj.exe' - in der Liste, im ZIP-Eintrag und im Download-Vorschlag des Browsers. Das macht nicht mal Dropbox.
- Passwort-Bremse waechst messbar: zehn Fehlversuche kosteten 0,26 / 0,77 / 1,27 / 2,30 / 4,30 / dann konstant 8,3 Sekunden. 'passwort' und auch 'Passwort' mit grossem P werden als zu haeufig abgelehnt, unter acht Zeichen geht gar nichts.
- Fremde Domain, javascript: und data: werden im Einfuegefeld sauber abgewiesen; www-Variante und Grossbuchstaben im Host werden korrekt als eigene Seite erkannt.
- Abbruch mitten im Verschluesseln raeumt vollstaendig auf (Datenbank leer, 55 Chunks unveraendert) und laesst meine Dateiauswahl stehen. Neuladen mitten drin hinterlaesst einen als 'Unfinished' markierten Rest, der beim naechsten Start nach 12 Sekunden von selbst verschwindet - nachgemessen.
- Ehrlichkeit ueber der Falz: 'Today it encrypts and stores; it does not yet send.' Die Status-Seite weigert sich, ein gruenes Haekchen fuer etwas zu setzen, das es noch nicht gibt. Die Limits-Seite schreibt selbst 'Only in the browser that created the drop'. Sowas habe ich in dieser Klarheit noch bei keinem Anbieter gesehen.
- Fehlermeldungen erklaeren statt zu beschuldigen: 'The authentication tag does not match, and AES-GCM checks it before it returns a single byte.' Kein 'Ein Fehler ist aufgetreten'.
- Kein Cookie-Banner, kein Newsletter-Popup, kein Konto. Auf 390 px Breite kein einziger horizontaler Ueberlauf, auch nicht mit einem 178 Zeichen langen Dateinamen.

### Heutige Loesung

Dropbox-Freigabe ueber den Laptop meines Freundes (weil zwei Agenturen es verlangen), Discord Nitro fuer alles unter 500 MB, WeTransfer wenn die Agentur nichts vorgibt, Google Drive fuer eingehendes Rohmaterial. Firefox Send war das, was ich eigentlich wollte, und ist seit 2020 tot. Ich bleibe vorerst dabei - nicht weil es besser gebaut ist, sondern weil es beim Empfaenger ankommt.

### Gemeldete Defekte (10)

- **Link mit einem Wort dahinter wird abgelehnt: "That is not a key"** (kritisch, gemessen)  
  Ort: index.html:4454 (frag = frag.replace(/\s+/g, '')), Einfuegefeld #open-input  
  Beleg: Gemessen im Handy-Viewport 390x844. Eingabe 'https://cloakdrop.com/#t=bNU7Vi9RnAuR&k=rEqw...jc danke' -> Fehlerseite 'That is not a key'. Dieselbe Eingabe ohne das Wort danach -> oeffnet. Ebenso 'hey marc hier sind die reels <link> viele gruesse lina' -> 'That is not a key'. Ursache im Quelltext: erst werden ALLE Leerzeichen entfernt, danach liest die Regex (Zeile 4456) das base64url-Feld - das nachfolgende Wort klebt dann am Schluessel. Der Kommentar direkt darueber (Zeile 4450-4453) beschreibt genau diesen Fall und behauptet, er sei geloest.
- **Text mit Doppelpunkt vor dem Link wird als fremdes URL-Schema gelesen** (schwer, gemessen)  
  Ort: index.html:4413 (var schema = v.match(/^([a-z][a-z0-9+.-]*):/i))  
  Beleg: Gemessen: Eingabe 'Link: https://cloakdrop.com/#t=...&k=...' -> Meldung 'That is a link: address, not a CloakDrop link.' Ebenso 'Hier: <link>' -> 'That is a hier: address...' und 'reels: <link>' -> 'That is a reels: address...'. Mit Umlaut oder Emoji davor ('Gruesse <link>', '🎬 <link>') oeffnet der Drop dagegen normal.
- **Nach dem Verschluesseln liegen Linkfeld und Copy-Knopf oberhalb des Bildschirms** (schwer, gemessen)  
  Ort: index.html:3393-3399 (karte.scrollIntoView vor showState('st-done'))  
  Beleg: Handy-Viewport 390x844, fuenf Messungen ueber 3 Sekunden nach Erreichen von #st-done: copy_y = -95 bis -97 px, link_y identisch, window.scrollY = 486, innerHeight = 844. Der Knopf steht also 97 px ueber dem oberen Bildrand; document.elementFromPoint(195,60) liefert 'done-note', also Erklaertext. Ursache: scrollIntoView() (Zeile 3394) laeuft, waehrend #st-done noch hidden ist - showState('st-done') kommt erst in Zeile 3399. Der Kommentar in Zeile 3389-3391 beschreibt genau den Fehler, den dieser Code beheben sollte.
- **Dateinamen in der Empfangsansicht auf 101 px gekuerzt - Versionen nicht unterscheidbar** (schwer, gemessen)  
  Ort: Empfangsansicht #receive-list .file-name, Handy-Viewport 390 px  
  Beleg: Gemessen: zwei Dateien 'Nike_AirMax_Hook_A_9x16_v3_FINAL.mp4' und 'Nike_AirMax_Hook_A_9x16_v4_FINAL_korrigiert.mp4'. clientWidth der Namensspalte 101 px, text-overflow ellipsis, scrollWidth > clientWidth. Per Canvas-Textmessung sichtbarer Teil: 'Nike_AirMax'. Beide Zeilen sehen identisch aus. In der Senderliste sind es 169 px, ebenfalls gekuerzt.
- **Neuladen nach dem Cloaken vernichtet den Link ohne jede Warnung** (schwer, gemessen)  
  Ort: Fertig-Ansicht #st-done; erzeugterLink lebt nur im Arbeitsspeicher (index.html:3372)  
  Beleg: Gemessen: Drop erzeugt, Link im Feld, dann page.reload() -> Linkfeld leer (''), Zustand zurueck auf #st-idle, Drop liegt weiter in der Verwaltung und ist nur noch loeschbar. Volltext der Fertig-Ansicht enthaelt keines der Woerter 'reload', 'refresh', 'copy it', 'lost', 'gone' (geprueft). Der Knopf 'Start a new drop' hat dagegen eine zweite Sicherheitsabfrage. Nach dem Testlauf standen fuenf ununterscheidbare Zeilen ('Cloaked 2026-07-31 22:52' bis '22:55') in der Verwaltung.
- **Die Speicher-Vorwarnung ist unsichtbar, weil sie sofort weggeblendet wird** (mittel, gemessen)  
  Ort: index.html:3171 sendeWarnung(...) schreibt in #send-err (Zeile 2182), das in #st-list (Zeile 2150) liegt; Zeile 3180 showState('st-progress')  
  Beleg: Gemessen mit CDP Storage.overrideQuotaForOrigin auf 60 MiB und einem 212-MB-Drop: navigator.storage.estimate() lieferte quota 62914560 / usage 1271, die Vorbedingung frei < gesamt + 4*CHUNK_SIZE war also erfuellt. 1,5 s nach dem Klick war #send-err trotzdem hidden und der Text leer. Sichtbar wurde erst 30,7 s spaeter die Fehlermeldung 'This browser ran out of room'.
- **Kein Service Worker: ohne Internet kommt man nicht einmal an die eigenen, lokal gespeicherten Dateien** (mittel, gemessen)  
  Ort: index.html - keine serviceWorker-Registrierung im gesamten Dokument (grep -c serviceWorker = 0)  
  Beleg: Gemessen: Kontext auf offline gesetzt, harter Aufruf von https://cloakdrop.com/?x=1 -> net::ERR_INTERNET_DISCONNECTED, Seite leer. Die verschluesselten Chunks liegen weiterhin in der IndexedDB desselben Browsers (203 MB im Profil nachgemessen), sind aber ohne die Seite nicht zu erreichen.
- **Unfertiger Drop wird in der Verwaltung mit 0 Byte gefuehrt, obwohl Chiffrat auf der Platte liegt** (klein, gemessen)  
  Ort: Verwaltungsansicht #drops-sum; Datensatzfeld bytes wird erst nach 3 s Lebenszeichen fortgeschrieben (index.html um Zeile 3288)  
  Beleg: Gemessen: Neuladen mitten im Verschluesseln bei CPU-Drosselung 8x. Danach chunks-Store von 55 auf 59 gestiegen (4 Chunks = 16 MB geschrieben), Datensatz aber bytes:0, geplant:162000000. Die Verwaltung zeigte '2 drops · 212.0 MB' - die 16 MB fehlen in der Summe.
- **Die 7-Tage-Frist ist auf iPhone-Safari vermutlich nicht haltbar, und nirgends steht ein Wort dazu** (mittel, vermutet)  
  Ort: limits.html (Auswahl '7 days'), privacy.html, status.html  
  Beleg: Nicht gemessen - getestet wurde in Chromium, nicht in Safari. Aus eigener Erfahrung raeumt iOS-Safari script-schreibbaren Speicher (IndexedDB) nach sieben Tagen ohne Interaktion mit der Seite. In allen gelesenen Seiten kommt das Wort 'Safari' genau einmal vor (privacy.html, 'Safari under Manage Website Data'), 'evict' oder 'reclaim' im Zusammenhang mit iOS gar nicht. Wer am Handy '7 days' waehlt, bekommt eine Zusage, die die Plattform vermutlich nicht haelt.
- **Verwaltungsliste ohne Kurznamen ist bei mehreren Drops nicht mehr lesbar** (klein, gemessen)  
  Ort: Verwaltungsansicht #drops-list, Zeilenbeschriftung 'Cloaked <Zeitstempel>'  
  Beleg: Gemessen: nach mehreren Durchlaeufen standen fuenf Zeilen 'Cloaked 2026-07-31 22:52' bis 'Cloaked 2026-07-31 22:55 · opens for 24 more hours', jeweils 2.0 MB, ohne Dateinamen. Das Kurznamenfeld ist leer vorbelegt und wird auf 40 Zeichen gekappt (maxLength 40, gemessen: 'Nike Reels FINAL an Marc - bitte bis Fre'). Wer den Kurznamen nicht von Hand pflegt, kann seine eigenen Drops nicht auseinanderhalten.

### Vollstaendiger Review

## Wer ich bin und was ich heute mache

Ich schneide Kurzvideos für Marken. Pro Kampagne kommen 5 bis 40 Videos zurück, zwischen 50 MB und 2 GB, und die dürfen vor dem Launch nirgendwo auftauchen. Wenn ein Cut leakt, bin ich den Kunden los. Heute läuft das so: Rohmaterial kommt per Google Drive oder WeTransfer von der Agentur, ich schneide am Handy und auf dem MacBook meines Freundes, und zurück geht es über eine Dropbox-Freigabe, weil zwei Agenturen darauf bestehen. Kleinkram schiebe ich über Discord (Nitro, 500 MB pro Datei), und wenn die Agentur nichts vorgibt, nehme ich WeTransfer, obwohl mir bewusst ist, dass da alles im Klartext auf einem fremden Server liegt. Firefox Send war 2020 genau das, was ich wollte, und es ist tot. Wormhole und Bitwarden Send kenne ich, croc benutze ich nicht, weil ich kein Terminal auf dem Handy habe. Genau deshalb habe ich den Link zu CloakDrop überhaupt aufgemacht.

## Die ersten dreißig Sekunden

Die Seite sieht gut aus. Wirklich gut. Ich entscheide sowas in zwei Sekunden, und hier stimmt es: fette Headline, "Cloak anything. Reveal nothing.", ein Kanal-Band mit Telegram, Signal, Threema, Discord. Kein Cookie-Banner, kein Newsletter-Popup, kein "Book a demo". Nichts scrollt seitlich weg (gemessen: scrollWidth 390 = clientWidth 390 auf iPhone-Breite). Das ist mehr, als 90 % der Tools schaffen, die ich sonst am Handy aufmache.

Und dann steht direkt unter der Headline, fett: **"Today it encrypts and stores; it does not yet send. A link opens only in the browser that made it."** In der App noch mal: "Preview: a link opens only on the device that made it."

Das ist ehrlich, und ich sage das ohne Ironie. Aber es ist auch der Satz, der für mich alles entscheidet, und ich habe trotzdem weitergetestet, weil ich es sehen wollte.

## Der Test: sechs Reels, 212 MB

Nach 6 Sekunden war ich in der App, nach 7,5 lagen sechs Reels drin (38, 42, 27, 55, 31, 19 MB, zusammen 212,0 MB). Fristauswahl steht da: 1 hour / 24 hours / 7 days, 24 Stunden vorausgewählt. Passwortfeld optional. Cloak gedrückt — Fortschrittsbalken kam nach 0,08 s, bei 0,4 s stand 31 %, **nach 1,4 Sekunden war alles fertig**. 212 MB. Das ist schneller als der Upload-Balken von WeTransfer, bevor er überhaupt anfängt zu laufen.

Ich habe den Netzwerkverkehr mitgeschrieben: **null Anfragen während des Verschlüsselns**. Über den ganzen zweiten Durchlauf inklusive Download aller Dateien: eine einzige Anfrage, und die ging an cloakdrop.com selbst (die Seite). Kein Analytics, kein Sentry, kein Google Font. Ich habe danach das Browserprofil auf der Platte durchsucht, 61 Dateien in der IndexedDB — kein einziger Dateiname im Klartext, kein "Reel_", kein ".mp4". Die Namen stecken wirklich im verschlüsselten Manifest. Das ist der Punkt, an dem ich anfing, das Ding zu mögen.

Download all: 5,2 Sekunden, ein ZIP mit allen sechs Dateien, testzip() sauber, und alle sechs SHA-256-Summen identisch mit meinen Originalen. Kein Byte verloren. Bei WeTransfer habe ich einmal drei Wochen später gemerkt, dass eine Datei abgeschnitten ankam.

## Der Moment, in dem es kippt

Dann habe ich getan, was ich wirklich tun würde: den Link in ein anderes Browserfenster geworfen, so als hätte ich ihn Marc geschickt. Nach 2,5 Sekunden stand da:

> **"Nothing here to open."** — "No drop with this address is stored in this browser."

Ich weiß, dass die Seite mir das vorher gesagt hat. Trotzdem: für meinen Job ist das ein Werkzeug, das die Datei einpackt, den Karton zuklebt und ihn mir dann wieder in die Hand drückt. Ich kann meiner Agentur keinen Link schicken, der bei ihr eine Fehlerseite zeigt. Damit ist heute Ende, egal wie schön der Rest ist.

## Und dann die Sachen, die mich am Handy wirklich geärgert haben

**Der Link liegt nach dem Verschlüsseln oberhalb des Bildschirms.** Ich habe das dreimal gemessen, weil ich es nicht glauben wollte: nach dem Cloaken steht die Seite bei scrollY 486, und das Linkfeld samt Copy-Knopf sitzt bei y = **minus 97 Pixel**. Also 97 px über dem oberen Bildrand. Was ich sehe, ist Erklärtext. Ich muss nach OBEN wischen, um an das zu kommen, wofür ich hier bin. Im Quelltext steht bei Zeile 3391 ein Kommentar, dass genau dieses Problem schon mal gemeldet wurde ("eine Testerin hielt es für einen Absturz"), und dass die Karte deshalb ins Bild geholt wird. Der Aufruf `karte.scrollIntoView()` steht in Zeile 3394 — aber `showState('st-done')`, das die Karte überhaupt erst sichtbar macht, kommt erst in Zeile 3399. Man scrollt zu einem Element, das noch `hidden` ist. Der Fix läuft eine Zeile zu früh. Auf 390×844 gemessen, über drei Sekunden stabil, kein Nachrutschen.

**Die Dateinamen sind im Empfang unbrauchbar.** Ich habe zwei Dateien reingelegt, wie ich sie wirklich benenne: `Nike_AirMax_Hook_A_9x16_v3_FINAL.mp4` und `Nike_AirMax_Hook_A_9x16_v4_FINAL_korrigiert.mp4`. In der Empfangsansicht ist die Namensspalte **101 Pixel breit**. Sichtbar ist: `Nike_AirMax…`. Beide Zeilen sehen identisch aus. Der Empfänger kann v3 und v4 nicht unterscheiden, ohne beide runterzuladen. Bei mir steht die Version IMMER hinten. Gekürzt wird aber hinten. In der Senderliste sind es 169 px, auch zu wenig, aber wenigstens erkenne ich meine eigenen Sachen. Wer 40 Clips schickt, produziert damit garantiert eine Rückfrage.

**Der Link ist weg, wenn der Tab wegfliegt.** Ich habe nach dem Cloaken neu geladen — genau das, was mein iPhone macht, wenn ich kurz nach Discord wechsle und wieder zurückkomme. Ergebnis: Linkfeld leer, Zustand zurück auf Start. Der Drop liegt noch da und ist nur noch löschbar. In der Fertig-Ansicht steht kein einziges Wort, das mich warnt: ich habe den Text nach "reload", "refresh", "copy it", "lost" und "gone" durchsucht — nichts davon kommt vor. Beim Knopf "Start a new drop" gibt es eine Sicherheitsabfrage ("Press again — the link is gone then"). Beim Neuladen, dem viel wahrscheinlicheren Fall, gibt es keine. Nach meinem Testlauf standen fünf Zeilen in der Verwaltung, alle "Cloaked 22:52", "Cloaked 22:53", "Cloaked 22:54" — ein Friedhof, in dem ich nichts mehr auseinanderhalten kann.

**Zwei Parser-Fehler, die genau meine Kanäle treffen.** Ich schicke Links in Discord und WhatsApp, und da tippe ich immer was dazu.
- `<link> danke` → **"That is not a key"**. Gemessen, reproduzierbar. Grund steht in Zeile 4454: `frag = frag.replace(/\s+/g, '')`. Erst werden alle Leerzeichen entfernt, dann wird das base64url-Feld gelesen — und weil das Leerzeichen weg ist, klebt "danke" am Schlüssel. Direkt darüber steht ein langer Kommentar, der genau diesen Fall erklärt und behauptet, er sei gelöst. Ist er nicht.
- `Link: <link>` → **"That is a link: address, not a CloakDrop link."** Das Wort "Link" mit Doppelpunkt wird als URL-Schema gelesen (Zeile 4413). "Hier:" ebenso. Ich schreibe genau so. Immer.

Was funktioniert hat: Link mit Punkt dahinter, Link in Klammern, Link mit Emoji davor, Zeilenumbruch mitten im Schlüssel, nur das Fragment, www-Variante, Großbuchstaben im Host. Fremde Domain wird korrekt abgewiesen, `javascript:` und `data:` auch. Das ist gut gebaut — es fehlt genau der eine häufigste Fall.

## Passwort, Grenzen, Aufräumen

Passwort ist ordentlich gemacht. "kurz" wird abgelehnt, "passwort" und sogar "Passwort" mit großem P werden als zu häufig abgewiesen. Zehn falsche Versuche habe ich durchgemessen: 0,26 s, 0,77, 1,27, 2,30, 4,30, dann 8,3 Sekunden pro Versuch. Das richtige Passwort kostete danach auch 8,5 s — ehrlich, aber am Handy fühlt sich das lang an. "Copy link again" gab den Link inklusive Salt zurück, identisch mit dem Original.

Mein 620-MB-Master: "1 file · 620.0 MB — over the 500.0 MB preview limit", und beim Klick "That is 620.0 MB — a drop carries up to 500.0 MB." Sauber gesagt, aber 500 MB ist für mich einfach zu wenig. Discord Nitro gibt mir 500 MB pro Datei, WeTransfer 2 GB kostenlos, SwissTransfer 50 GB. Ein Drop, in den mein Master nicht passt, ist kein Drop.

Abbruch mitten im Verschlüsseln: sauber. Datenbank leer, Auswahl bleibt stehen, ich konnte sofort weitermachen. Neuladen mitten drin: der Rest taucht als "Unfinished" auf, wird nach 12 Sekunden beim nächsten Start selbst weggeräumt — nachgemessen, hat funktioniert. Kleiner Schönheitsfehler: die Verwaltung zeigte "2 drops · 212.0 MB", obwohl vom unfertigen Drop schon 4 Chunks (16 MB) auf der Platte lagen.

Speicher volllaufen lassen (Quote auf 60 MiB gedreht, 212 MB reingeworfen): nach 30,7 Sekunden kam "This browser ran out of room, so nothing was kept", Datenbank leer, Auswahl noch da. Korrekt. Die Vorwarnung, die laut Code vorher kommen soll, habe ich nie gesehen — sie wird in eine Zeile geschrieben, die im selben Atemzug versteckt wird (`#send-err` liegt in `#st-list`, Zeile 2182 in 2150, und direkt danach kommt `showState('st-progress')` in Zeile 3180).

Offline getestet: die Seite lädt gar nicht (ERR_INTERNET_DISCONNECTED), es gibt keinen Service Worker. Meine eigenen, in meinem eigenen Browser liegenden Dateien komme ich ohne Internet also nicht mehr an. Für ein Tool, das "kein Server" als Kern verkauft, ist das eine komische Lücke.

## Was mich positiv überrascht hat

Das RLO-Zeichen. Ich habe eine Datei `rechnung<RLO>gpj.exe` reingelegt — der Trick, mit dem eine .exe wie ein .jpg aussieht. CloakDrop zeigt sie als `rechnunggpj.exe`, im ZIP heißt sie so, und der Download-Vorschlag des Browsers auch. Das macht nicht mal Dropbox.

Und die Texte. "The authentication tag does not match, and AES-GCM checks it before it returns a single byte." Kein "Ein Fehler ist aufgetreten". Die Limits-Seite sagt selbst: "Where a link opens — Only in the browser that created the drop." Die Status-Seite weigert sich, ein grünes Häkchen für etwas zu setzen, das noch nicht existiert. Sowas habe ich noch nie gesehen.

## Fazit

Ich bleibe bei Dropbox über den Laptop meines Freundes und Discord für alles darunter. Nicht weil es besser gebaut ist — CloakDrop ist in den Details klar besser —, sondern weil es ankommt. Sobald das Relay steht, 2 GB gehen, der Copy-Knopf sichtbar ist und ich in Discord ein Wort neben den Link schreiben darf, ohne dass das Ding "That is not a key" sagt, komme ich wieder. Ehrlich. Schreibt mir.

---

## Ursula Behrend — Rentnerin, 72, frueher Buchhalterin

**Note 3.1 · wuerde nutzen: nein**

### Begruendung der Note

Ich wollte 42 eingescannte Familienfotos an meine Enkelin schicken. Genau das kann dieses Programm nicht: ich habe den Link in einem frischen Browser geoeffnet, so wie Lena ihn bekaeme, und nach vier Sekunden stand da "Nothing here to open". Dazu ist die ganze Seite englisch, ohne einen einzigen Knopf, um das umzustellen — ich lese das nicht, und damit ist fuer mich Schluss, bevor es anfaengt. Warum trotzdem nicht eine 1: was da ist, arbeitet sauber und schnell. 42 Fotos in 0,6 Sekunden verschluesselt, alle 42 kamen aus dem ZIP wieder heraus, Byte fuer Byte identisch, und waehrend des ganzen Vorgangs ist nachweislich nichts ins Netz gegangen. Die Warnungen sind ehrlich statt beschoenigend. Punktabzug obendrauf fuer echte Schlampereien am Tablet und am Handy: das Passwortfeld ist auf dem Handy nur 19 bzw. 21 Pixel hoch, in der Uebersicht wird genau die Angabe abgeschnitten, die ich brauche. Fuer mich heute: unbrauchbar. Fuer meinen Sohn in einem Jahr: vielleicht.

### Blocker

1. Alles auf Englisch, ohne jede Moeglichkeit, auf Deutsch umzustellen — ich lese es schlicht nicht und muss jedes Mal meinen Sohn anrufen
2. Der Link oeffnet nur im eigenen Browser. Meine Enkelin bekommt eine leere Seite. Damit ist der einzige Grund, warum ich hier waere, nicht erfuellt
3. Ohne meinen Sohn haette ich nach zwei Minuten aufgegeben. Es gibt keine Stelle, die mir in meiner Sprache sagt, was gleich passiert und was ich anschliessend tun soll
4. Das Passwortfeld ist auf dem Handy 19 bzw. 21 Pixel hoch. Wenn ich Lena ein Passwort geben soll, muss sie es auf so etwas eintippen koennen

### Was gut ankam

- 42 Fotos, 38,4 MB, in 0,6 Sekunden verschluesselt; ein 251,7-MB-Video in rund 1,2 Sekunden. Schneller als jeder Ladebalken, den ich kenne
- Der Knopf, der alles auf einmal holt, liefert eine einzige ZIP-Datei. Alle 42 Fotos kamen Byte fuer Byte identisch heraus, testzip meldete keinen Fehler
- Nichts verlaesst das Geraet: waehrend des ganzen Verschluesselns wurden nur drei Anfragen gestellt, alle nur zum Laden der Seite selbst. Kein einziges Foto ging ins Netz
- Nach dem Schliessen des Browsers war der Dateiname "Oma und Opa Hochzeit" nirgends im Klartext auf der Platte zu finden, obwohl 38,4 MB dort liegen
- Umlaute, Akzente, russische, japanische und arabische Zeichen, Emoji und ein 197 Zeichen langer Dateiname kamen unveraendert durch — bei Google Drive ist mir das schon zweimal zerschossen worden
- Passwortpruefung mit Verstand: "abc" zu kurz, "password" und "12345678" abgelehnt, weil sie auf jeder Rateliste stehen. Sieben Fehlversuche wurden von 0,26 auf 8,5 Sekunden ausgebremst
- Der Link vertraegt alles, was beim Kopieren aus einer Mail schiefgeht: Zeilenumbruch mittendrin, Leerzeichen, spitze Klammern, http statt https, mitten in einem Satz — alles wurde erkannt und geoeffnet
- Bei einer fremden Adresse warnt sie und nennt die fremde Adresse beim Namen, statt einfach nichts zu tun
- Beim Neuladen mitten im Verschluesseln steht der Rest sauber als "Unfinished" da, ist nicht zu oeffnen, laesst sich loeschen und raeumt sich selbst weg
- Vor dem Verschluesseln wird nachgerechnet, ob der Platz reicht: "This browser reports about 454.9 MB free, and this drop needs 440.4 MB plus room to write it"
- Eine leere Datei wird angemerkt, eine doppelt ausgewaehlte Datei wird nicht zweimal genommen, ueber 500 MB ist der Knopf gesperrt und nennt die Zahl
- Loeschen braucht zwei Antipper ("Press again to delete") — bei mir rutscht der Finger oft
- Die Tippflaeche fuer die Dateiauswahl ist 600 x 320 Pixel gross und reagiert ueberall, nicht nur auf dem kleinen Wort "browse"
- Ehrlichkeit statt Werbung: "Read the code" sagt ausdruecklich, es sei NICHT Open Source, nur lesbar. Die Statusseite sagt, es gebe noch keine Statusseite, statt ein gruenes Haekchen hinzumalen

### Heutige Loesung

E-Mail ueber GMX mit Anhang, in Haeppchen zu fuenf oder sechs Bildern, weil sonst die Meldung kommt, es sei zu gross. Wenn das klemmt, WhatsApp — da werden die Bilder haesslich klein, aber sie kommen an. Zweimal im Jahr macht mein Sohn es mit WeTransfer fuer mich; da sind es inzwischen 3 GB pro Sendung, zehn Sendungen im Monat, und nach drei Tagen ist der Link tot. Google Drive habe ich auf dem iPad, benutze es aber nicht selbst, weil ich mich mit dem Freigeben nicht auskenne und einmal aus Versehen einen ganzen Ordner freigegeben habe. Fuer die wirklich wichtigen Bilder fahre ich mit einem USB-Stick hin. Ich behalte das alles, weil es umstaendlich ist, aber ankommt.

### Gemeldete Defekte (8)

- **Die ganze Seite ist ausschliesslich englisch, es gibt keine Umschaltung** (kritisch, gemessen)  
  Ort: index.html Zeile 1 (lang="en"), sowie limits.html, verify.html, about.html, opensource.html, glossary.html, changelog.html, contact.html, status.html — alle mit lang="en"  
  Beleg: Gemessen mit Playwright: document.documentElement.lang liefert auf index.html und auf allen acht geprueften Unterseiten "en". Eine Suche im Quelltext nach "deutsch|german|i18n|lang-switch|hreflang" liefert 0 Treffer. Auf der gerenderten Startseite ist kein Sprachwaehler vorhanden (alle sichtbaren Knoepfe aufgelistet: nur theme-pill und drei theme-opt).
- **Der Link oeffnet in keinem fremden Browser — der eigentliche Zweck fehlt** (kritisch, gemessen)  
  Ort: gemessenes Verhalten, https://cloakdrop.com/#t=...&k=... in frischem Browserkontext  
  Beleg: 42 Fotos verschluesselt, Link in einen komplett frischen Playwright-Browserkontext (eigene Sitzung, eigener Speicher) eingefuegt. Nach 4,0 Sekunden zeigt die Seite "Nothing here to open — No drop with this address is stored in this browser." Im erzeugenden Kontext oeffnet derselbe Link "42 cloaked files". Die Seite kuendigt das selbst an, deshalb kein versteckter Fehler, aber der Zweck des Produkts ist damit heute nicht erfuellbar.
- **Passwortfeld faellt unter 520 px Breite auf 19-21 px Hoehe zusammen** (schwer, gemessen)  
  Ort: index.html Zeile 1631-1632 (.pw-input { flex: 1; ... height: 40px }) zusammen mit Zeile 1663 (@media max-width:520px { .pw-row { flex-direction: column } }); dasselbe fuer Zeile 1654 (.pw-form .pw-input { height: 46px }) mit Zeile 1665 (.pw-form { flex-direction: column })  
  Beleg: getBoundingClientRect gemessen: Senderfeld #pw-input bei Viewport 412x915 = 340 x 19 px, bei 768x1024 = 457 x 40 px, bei 820x1180 = 445 x 40 px. Empfaengerfeld #pw-open bei 412x915 = 336 x 21 px, waehrend der Knopf #pw-go daneben 336 x 46 px hat. Ursache: in der Spaltenrichtung wird height durch flex-basis:0 aus dem Kurzschreiben flex:1 verdraengt. Auf dem Bildschirmfoto 24_pw_handy.png sichtbar als flachgedruecktes Feld.
- **In der Uebersicht wird die Ablauffrist abgeschnitten — Drops sind nicht unterscheidbar** (mittel, gemessen)  
  Ort: gemessenes Verhalten in #drops-list .file-name (Markup index.html Zeile 2139)  
  Beleg: Gemessen mit scrollWidth/clientWidth: Zeile "Cloaked 2026-07-31 22:25 · opens for 7 more days" braucht 341 px, bekommt bei Viewport 820x1180 nur 227 px, bei 1180x820 ebenfalls 227 px, bei 412x915 nur 39 px. Auf Bildschirmfoto 10_manage.png stehen drei Drops als "Cloaked 2026-07-31 22:11 · op…", "… · ope…", "… · ope…" — die einzige unterscheidende Angabe fehlt. Kurznamen sind auf maxlength=40 begrenzt (index.html Zeile 2139 Bereich, input class=drop-label).
- **Tippflaechen unter dem Mindestmass fuer Beruehrung** (mittel, gemessen)  
  Ort: gemessenes Verhalten, #exp-grp button (index.html Zeile 2161-2163) und die Entfernen-Kreuze in #file-list  
  Beleg: getBoundingClientRect bei allen fuenf geprueften Breiten (412, 768, 820, 1180, 1440 px) identisch: Ablauffrist-Knoepfe 62 x 27 px, Entfernen-Kreuz 28 x 28 px. Apples eigene Vorgabe fuer Beruehrungsziele ist 44 x 44 px. Der Hauptknopf #cloak-btn ist mit 48 px hoch dagegen richtig bemessen.
- **Das Linkfeld zeigt nur einen Bruchteil des Links** (klein, gemessen)  
  Ort: gemessenes Verhalten, #link-input (index.html Zeile 2211)  
  Beleg: scrollWidth/clientWidth gemessen: Inhalt braucht 630 px. Sichtbar bei Viewport 820x1180 nur 172 px (27 %), bei 1180x820 ebenfalls 172 px, bei 412x915 nur 34 px (5 %). Der Kopierknopf arbeitet korrekt — navigator.clipboard.readText() lieferte den Link zeichengleich (83 Zeichen) —, aber eine Sichtpruefung vor dem Versenden ist nicht moeglich.
- **Der Abbrechen-Knopf ist praktisch nicht erreichbar** (klein, gemessen)  
  Ort: gemessenes Verhalten, #cancel-btn (index.html Zeile 2202)  
  Beleg: 251,7 MB (eine Datei) waren nach rund 1,2 Sekunden fertig; 38,4 MB in 42 Dateien nach 0,6 Sekunden. In drei Versuchen mit unterschiedlichen Wartezeiten lief der Klick auf #cancel-btn in einen Timeout, weil #st-progress bereits verborgen war. Fortschrittsanzeige sprang von 10 % ueber 40 % auf 70 % in 0,8 Sekunden.
- **Uebersichtssumme unterschlaegt den Platz eines abgebrochenen Drops** (klein, gemessen)  
  Ort: gemessenes Verhalten, #drops-sum gegen navigator.storage.estimate()  
  Beleg: Nach Neuladen bei 30 % von 251,7 MB (Fortschrittsanzeige zeigte "76.0 MB OF 251.7 MB") meldete #drops-sum "2 drops · 3.8 MB", waehrend navigator.storage.estimate() 136 MB Belegung auswies. Die Zeile "Unfinished · 2026-07-31 22:20" traegt keine Groessenangabe. Der Warnhinweis dazu ist vorhanden und richtig, die Zahl daneben ist es nicht.

### Vollstaendiger Review

Ich bin 72, war 38 Jahre Buchhalterin, und ich habe ein iPad, das mein Sohn Michael mir eingerichtet hat. Mein Problem ist seit Jahren dasselbe: ich scanne alte Familienbilder ein — meine Eltern, die Hochzeit 1952, das Haus in der Lindenstrasse — und will sie meiner Enkelin Lena schicken. 42 Stueck waren es diesmal, zusammen 38 Megabyte. Per Mail geht das nicht, da kommt seit jeher die Meldung, es sei zu gross. Michael hat mir den Link zu CloakDrop geschickt und gesagt, ich soll das mal ehrlich ausprobieren. Also habe ich es ausprobiert, und zwar gruendlich. Er hat danebengesessen und die technischen Sachen nachgesehen, die ich nicht kann. Was ich selbst gesehen habe, schreibe ich als das, was ich gesehen habe.

Die Seite war nach fuenf Sekunden da. Schoen aufgeraeumt, grosse Schrift, viel Weiss — das gefaellt mir, ich sehe schlecht und die meisten Seiten sind mir zu eng und zu bunt. Und dann stand da: "Cloak anything. Reveal nothing." Und darunter "CloakDrop encrypts your files in this tab with AES-256-GCM."

Da hoere ich auf. Ich lese kein Englisch. Ich habe die ganze Seite von oben bis unten durchgescrollt und gesucht, ob irgendwo eine kleine Fahne ist oder ein "DE" zum Anklicken. Es gibt keins. Michael hat nachgesehen: die Seite sagt selbst, sie sei englisch, und es gibt an keiner Stelle etwas Deutsches. Auch nicht auf den Unterseiten — ich habe acht davon aufgemacht, limits, verify, about, changelog, glossary, contact, status, opensource, alle acht englisch. Das ist fuer mich kein Schoenheitsfehler, das ist die Tuer, die zu ist. Ich soll hier meine Familienfotos hineinlegen und mich auf ein Versprechen verlassen, das ich nicht lesen kann. Bei so etwas rufe ich meinen Sohn an, und dabei schaeme ich mich jedes Mal ein bisschen.

Er hat mir uebersetzt. Und dann kam der Satz, bei dem ich das iPad weggelegt habe. Auf der Startseite steht sinngemaess: "In dieser Fassung oeffnet ein Link nur in dem Browser, der ihn gemacht hat. Wenn Sie ihn jemandem schicken, sieht der eine leere Seite." Das Ding, dessen einziger Zweck es waere, mir zu helfen, etwas zu verschicken, verschickt nichts.

Ich habe es trotzdem gemacht, weil ich es genau wissen wollte. Auf die grosse graue Flaeche getippt — das geht, die Flaeche ist 600 mal 320 Pixel gross und der Finger trifft sie ueberall, nicht nur auf dem kleinen unterstrichenen Woertchen "browse". Das ist gut geloest. Alle 42 Fotos ausgesucht, nach drei Sekunden standen sie untereinander in einer Liste, jede mit Namen und Groesse, 42 Zeilen, alle richtig. "42 files · 40.2 MB". Dann "7 days" angeklickt, weil Lena nicht sofort hineinschaut. Dann den grossen schwarzen Knopf.

Nach 0,6 Sekunden war es fertig. Ich habe zweimal hingesehen, weil ich es nicht geglaubt habe. 38 Megabyte in einer halben Sekunde. Michael hat spaeter mit einem 251-Megabyte-Video nachgemessen: 1,2 Sekunden. Das ist schneller, als bei WeTransfer der Balken ueberhaupt anfaengt zu laufen. Es gibt einen "Cancel"-Knopf waehrend des Verschluesselns — den habe ich in drei Anlaeufen nicht getroffen, weil immer schon vorher alles fertig war. Der Knopf ist Zierde.

Dann kam der Link. Und dann der Moment, auf den es ankommt. Michael hat ein zweites, voellig frisches Browserfenster aufgemacht — so, wie Lenas Handy es waere, das noch nie von dieser Seite gehoert hat — und den Link eingefuegt. Nach vier Sekunden: "Nothing here to open." Eine leere Seite. Genau wie angekuendigt. Ich habe also 42 Familienbilder in einen Tresor gelegt, der in meinem eigenen Wohnzimmer steht, und den Schluessel dazu verschickt. Fuer meinen Fall ist das nichts. Null.

Was ich dann trotzdem noch geprueft habe, weil ich es fair finden wollte:

Der Knopf, der alle Dateien auf einmal holt, funktioniert. In meinem eigenen Browser den Link aufgemacht, auf "Download all" getippt, nach 1,3 Sekunden lag eine ZIP-Datei da. Michael hat sie ausgepackt und jede einzelne Datei mit meinem Original verglichen: 42 von 42 exakt gleich, kein einziges Byte anders. Auch die Namen stimmten, mit Umlauten, mit Akzenten. Er hat extra noch Dateien mit russischer Schrift, japanischen Zeichen, arabischen Buchstaben und einem Namen aus 197 Buchstaben durchgeschickt — alles kam heil an. Das ist mehr Sorgfalt, als ich von Google Drive gewohnt bin, das mir schon zweimal aus "Ömas Hochzeit" ein "Omas Hochzeit" gemacht hat.

Das Passwort habe ich durchprobiert. "abc" wird abgelehnt, zu kurz. "password" wird abgelehnt. "12345678" auch — sie haben eine Liste der ueblichen Verdaechtigen. Ein ordentliches Passwort geht durch, und beim Oeffnen fragt die Seite dann danach. Falsches Passwort: klare Absage. Michael hat sieben Fehlversuche hintereinander gemacht, da wird jedes Mal laenger gewartet, zuletzt 8,5 Sekunden. Das ist richtig so.

Kaputtmachen wollte ich es auch. Ich habe den Link mitten in einen Satz gesetzt ("Hallo Lena, hier sind die Bilder: ... Liebe Gruesse Oma") — die Seite hat ihn trotzdem gefunden. Zeilenumbruch mittendrin, Leerzeichen mittendrin, spitze Klammern drumherum, http statt https, nur den hinteren Teil ab dem Rautezeichen: alles hat funktioniert. Bei einer fremden Adresse hat sie gewarnt und die fremde Adresse beim Namen genannt. Bei Unsinn kam eine verstaendliche Absage. Das ist gut gebaut, viel besser als das, was ich von den meisten Seiten kenne, wo ein Umbruch aus der Mail sofort alles zerschiesst.

Michael hat mitten beim Verschluesseln eines 251-Megabyte-Videos die Seite neu geladen, bei 30 Prozent. Danach stand in der Uebersicht "Unfinished" mit dem Hinweis, dass der abgebrochene Rest nicht zu oeffnen ist und von selbst weggeraeumt wird. Das hat mich beruhigt. Und er hat den Speicher volllaufen lassen — bei 1,5 von 1,9 Gigabyte kam eine Warnung, die vorher nachrechnet: "This browser reports about 454.9 MB free, and this drop needs 440.4 MB". Sowas habe ich noch nie gesehen. Als Buchhalterin sage ich: das ist saubere Arbeit.

Und das Wichtigste, was er nachgesehen hat: waehrend die 42 Fotos verschluesselt wurden, ist nichts ins Internet gegangen. Er hat mitgeschrieben, was der Browser verschickt — drei Anfragen, alle nur "die Seite laden". Kein einziges Foto. Danach hat er den Browser zugemacht und im Ordner auf der Platte nach dem Wort "Oma und Opa Hochzeit" gesucht. Nirgends. Die 38 Megabyte liegen da, aber verschlossen. Das nehme ich ihnen ab, weil man es messen kann und nicht glauben muss.

Jetzt das Aergerliche.

Die Uebersicht, wo meine gespeicherten Sendungen stehen, schneidet die eine Angabe ab, die ich brauche. Bei mir standen drei Zeilen, alle drei "Cloaked 2026-07-31 22:11 · op..." — und dahinter waere gestanden, wie lange die Sendung noch gilt. Gemessen: der Text braucht 341 Pixel, bekommt auf meinem iPad 227. Auf dem Handy meiner Nachbarin sind es 39 von 341, da sieht man praktisch gar nichts mehr. Drei Sendungen aus derselben Minute sehen identisch aus. Ich kann ein Kuerzel danebenschreiben, das bleibt auch nach dem Neuladen erhalten, aber es sind nur 40 Zeichen und die Ueberschrift dazu heisst "Label".

Und dann das Passwortfeld. Auf meinem iPad ist es 40 Pixel hoch, das geht gerade so. Auf dem Handy ist es 19 Pixel hoch — halb so hoch wie der Knopf darunter, ein flachgedruecktes Strichlein. Auf der Empfangsseite, also da, wo Lena das Passwort eintippen soll, sind es 21 Pixel. Das sieht kaputt aus, und mit meinen Fingern treffe ich das nicht sicher. Genauso die drei kleinen Knoepfe fuer "1 hour / 24 hours / 7 days": 62 mal 27 Pixel, und das kleine Kreuzchen zum Entfernen einer Datei 28 mal 28. Apple selbst sagt, so ein Feld soll 44 Pixel haben. Das ist keine Kleinigkeit fuer jemanden mit zittrigen Haenden.

Das Feld, in dem der Link steht, zeigt auf dem iPad 172 von 630 Pixeln — ein Viertel. Auf dem Handy fuenf Prozent. Ich sehe nie, was ich da eigentlich verschicke. Der Kopierknopf arbeitet zwar richtig, das hat Michael geprueft, aber sehen will ich es trotzdem.

Was mich positiv ueberrascht hat: die Ehrlichkeit. Auf der Seite "Read the code" steht ausdruecklich, das sei NICHT Open Source, nur lesbar. Die Statusseite sagt, es gebe noch keine Statusseite, statt ein gruenes Haekchen hinzumalen. Das Wort "Preview" steht ueberall. Ich bin es gewohnt, dass mir Firmen erzaehlen, alles sei fertig und sicher — und dann liest man in der Zeitung, dass sie im Juli meine Bilder fuer irgendeine kuenstliche Intelligenz benutzt haben, so wie WeTransfer es letztes Jahr versucht hat. Hier passiert das Gegenteil: sie sagen mir, was nicht geht, bevor ich es merke. Dafuer Respekt.

Negativ ueberrascht hat mich, dass so viel Muehe in die Innereien gesteckt wurde und so wenig in die Frage, wer davorsitzt. Wer 600.000 Runden fuer ein Passwort rechnet und dann das Passwortfeld auf dem Handy 19 Pixel hoch macht, hat lange nicht mit jemandem wie mir am Tisch gesessen.

Meine heutige Loesung: Ich schicke die Bilder per Mail ueber GMX, in Haeppchen zu fuenf oder sechs Stueck, und wenn es klemmt, ruft mich Lena an und wir machen es ueber WhatsApp, wo die Bilder haesslich klein werden. Zweimal im Jahr macht Michael es mit WeTransfer fuer mich. Ich behalte das, denn es ist umstaendlich, aber es kommt an. CloakDrop kommt nicht an. Ein Ding, das schoen verschluesselt und dann nichts verschickt, ist fuer mich ein Briefkasten ohne Schlitz.

Wenn sie den Versand hinbekommen, das Passwortfeld reparieren und mir die Seite auf Deutsch geben, dann rufe ich meinen Sohn an und sage: schau dir das nochmal an. Vorher nicht.

---