# Das Loch ist tragend **Deck:** Vor sechs Tagen hat Kalifornien begonnen, jedem registrierten Datenhändler eine Liste der Menschen auszuhändigen, die um ihre Löschung gebeten haben. Die Kennungen sind gehasht, ohne Salt, und ein Laptop macht daraus in etwa dreiundvierzig Sekunden wieder eine Telefonnummer. Kryptografen haben der Behörde im Rechtsetzungsverfahren eine Lösung angeboten. Sie hat schriftlich abgelehnt — weil die Lösung Datenhändler daran hindern würde, Sie dauerhaft zu unterdrücken. **By:** URnetwork-Redaktion **Dateline:** San Francisco — 7. August 2026 **Category:** Nachrichten / Analyse --- ## Ein Verzeichnis der Menschen, die verschwinden wollten Die Menschen auf dieser Liste wollten verschwinden: Überlebende von Stalking und häuslicher Gewalt, Richterinnen und Richter, Patientinnen und Patienten der reproduktiven Gesundheitsversorgung, alle, die einen Grund haben, eine Spur zu tilgen. Seit Januar stellen sie Anträge nach Kaliforniens Delete Act, dem Löschgesetz des Bundesstaates: eine einzige Stelle, um jedem Datenhändler (data broker) in Kalifornien die Löschung aufzugeben. Vor sechs Tagen ist die andere Hälfte in Kraft getreten. Seit dem **1. August 2026** verlangt §1798.99.86(c)(1) des Civil Code von jedem registrierten Datenhändler, *"access the accessible deletion mechanism … at least once every 45 days."* — den zugänglichen Löschmechanismus mindestens alle 45 Tage abzurufen. Das Verzeichnis wandert damit nach außen, in die Systeme von Hunderten Datenhändlern, also genau in die Branche, vor der sich diese Menschen versteckt haben. Der erste verpflichtende Zyklus endet um den **15. September**. Die Kennungen sind gehasht, was nach Schutz klingt. Auf einem einzigen Laptop-Kern wird aus einer kalifornischen Telefonnummer auf der Liste in etwa **dreiundvierzig Sekunden** wieder eine Telefonnummer. Die Behörde, die diese Maschine gebaut hat, hat den Datenhändlern durchaus angekündigt, dass dies kommen würde. In einem Blogbeitrag vom 10. Juli heißt es: *"starting on August 1, data brokers must download the hashed deletion requests and compare them against the personal information in their records."* — ab dem 1. August müssen Datenhändler die gehashten Löschanträge herunterladen und mit den personenbezogenen Daten in ihren Datensätzen abgleichen. Was sie nicht getan hat, ist, etwas über die Gefährdung zu sagen. Ihr Newsroom, am 7. August erneut geprüft, reicht immer noch nur bis zu einem Beitrag vom 4. August über Vermont; zum Start am 1. August gab es eine Anleitung für Datenhändler und überhaupt keinen Hinweis an die Menschen auf der Liste. ## Der Hash lässt sich in Sekunden abstreifen Die Liste führt sechs Arten von Kennungen, und nur eine davon ist in der Verordnung benannt: **MAID**, eine mobile Werbe-ID. Die anderen fünf sind Bezeichnungen aus der technischen DROP-Spezifikation — **NDZ** (Vorname, Nachname, Geburtsdatum, Postleitzahl), **Email** (E-Mail-Adresse), **Phone** (Telefonnummer), **NameVIN** und **CTVID**, die Kennung eines internetfähigen Fernsehers. Bevor irgendetwas gehasht wird, glättet die Regel die Eingabe: Kleinschreibung, Satzzeichen entfernt, Akzente aufgelöst — im eigenen Beispiel der Regel wird so aus *"Björn O'Connor-López"* ein *"bjornoconnorlopez."* Datumsangaben werden zu acht Ziffern, eine Telefonnummer zu ihren letzten zehn, und eine Auffangklausel trägt dem Datenhändler auf, *"implement any other standardization that the data broker knows will increase the likelihood of a match."* — jede weitere Standardisierung umzusetzen, von der er weiß, dass sie die Trefferwahrscheinlichkeit erhöht. Jeder dieser Schritte wirft Entropie weg, und Entropie ist das Einzige, was zwischen einem Hash und dem Wert steht, aus dem er berechnet wurde. Wir haben die beiden Rechenbeispiele aus der technischen Spezifikation des Bundesstaates nachgerechnet. Jeder Feld-Digest und beide zusammengesetzten Digests kommen bitgenau identisch heraus, als einfaches SHA-256 über UTF-8, Base64-kodiert: kein Salt, kein Schlüssel, nichts, was nicht ohnehin schon im öffentlichen Verfahrensmaterial steht. Ein schlüsselloser Hash über einen Wert mit geringer Entropie ist keine Verkleidung. Er ist ein Rätsel, das ein Laptop löst, indem er jede Antwort durchprobiert — und SHA-256 beantwortet etwa **7,1 Millionen Rateversuche pro Sekunde auf einem CPU-Kern**, ohne jede Grafikkarte. | Was auf der Liste steht | Wie viele Möglichkeiten | Zeit auf einem Laptop-Kern | |---|---|---| | Eine kalifornische Telefonnummer | 304.000.000 | **~43 Sekunden** | | Eine beliebige US- oder kanadische Nummer | 6.400.000.000 | ~15 Minuten | | Name, Geburtsdatum und Postleitzahl, abgeglichen mit dem kalifornischen Wählerverzeichnis | ~22.000.000 | **~3 Sekunden** | | Eine kurze Connected-TV-ID | 2,8 × 10¹² | ~4,6 Tage | | Eine mobile Werbe-ID | 2¹²⁸ | nicht praktikabel | Die Telefonliste ist nicht pseudonym. Sie ist Klartext mit einem Zwischenschritt. Bei der Liste aus Name, Geburtsdatum und Postleitzahl muss man gar nicht raten: Man hasht die eine Person, die man sucht, und fragt, ob die Antwort darauf steht — ein Ja/Nein-Orakel, und der Hash ist wieder ein Name. Selbst die Werbe-ID, die sich tatsächlich nicht brechen lässt, muss überhaupt nicht gebrochen werden. Sie ist ein Verknüpfungsschlüssel, den eine Adtech-Firma gegen ihre eigenen Geräte laufen lässt, um zu erfahren, welche davon jemandem gehören, der sich selbst löschen will. Der naheliegende erste Gedanke — die Hashes einfach salzen — funktioniert hier nicht. Salting schützt gespeicherte Passwörter, weil die prüfende Seite das Geheimnis schon besitzt, das der Nutzer gerade eingetippt hat. DROP, der Löschmechanismus des Bundesstaates, hat die umgekehrte Form: Der Datenhändler prüft *seine eigenen* Datensätze, die Kalifornien nie gesehen hat, gegen die Liste des Bundesstaates. Beide Seiten müssen also unabhängig voneinander zum selben Digest kommen — und ein Salt, das jeder registrierte Datenhändler im Land kennt, ist kein Geheimnis. ## Kalifornien wurde die Lösung angeboten und lehnte sie schriftlich ab Hier kommt der Teil, über den bisher niemand berichtet hat. Im Rechtsetzungsverfahren haben Kryptografen der Behörde gesagt, dass genau das passieren würde. In Anhang A des Final Statement of Reasons, der abschließenden Begründung der Regel, schlugen Kommentatoren **Private Set Intersection** vor — ein Protokoll, bei dem zwei Parteien nur erfahren, was sie gemeinsam haben, und nichts weiter — oder den Abgleich in einer **Trusted Execution Environment**, einer abgeschirmten Ausführungsumgebung. Sie benannten den Preis offen und räumten ein, es würde *„Datenhändler daran hindern, Kennungen künftig zu unterdrücken“*, hielten den Tausch aber für lohnend. Die Behörde sagte Nein, und ihre Begründung ist die ganze Geschichte: > „Die Behörde nimmt die vom Kommentator vorgeschlagenen Alternativen zum Hashing zur Kenntnis, hat aber > festgestellt, dass Hashing eine weit verbreitete, sichere und zugängliche Methode zum Schutz von Daten ist > und dass **jede Methode, die die fortlaufende Unterdrückung von Kennungen durch Datenhändler verhindert, das > Gesetz nicht angemessen umsetzt**.“ Lesen Sie die zweite Hälfte langsam. Der Delete Act verlangt vom Datenhändler nicht, Sie einmal zu vergessen. Er verlangt, dass der Datenhändler Sie von jetzt an weiter unterdrückt, also dauerhaft gelöscht hält. Um Sie für immer zu unterdrücken, muss ein Datenhändler etwas Beständiges behalten, das *Sie* bedeutet — und genau das ist ein Hash: ein beständiges, jederzeit neu berechenbares Token. Jedes Verfahren, das die Kryptografen anboten, funktioniert dadurch, dass es dem Datenhändler ein solches Token *nicht* hinterlässt. Deshalb hat die Behörde sie ausgeschlossen. Das Datenschutzloch ist kein Mangel, den das Design zu schließen versäumt hat. Es ist der Mechanismus, den das Design liefern soll. Und §7620(c) schließt den Kreis: *"By submitting a deletion request, a consumer consents to disclosure of their personal information to a data broker for purposes of processing their deletion request."* — mit dem Stellen eines Löschantrags stimmt eine Verbraucherin der Offenlegung ihrer personenbezogenen Daten an einen Datenhändler zu, und zwar zum Zweck der Bearbeitung ihres Löschantrags. Diese Zweckbindung ist real, und sie ist die beste Antwort, die dieses Design zu bieten hat — die Einwilligung ist nicht unbegrenzt. Aber sie regelt, was ein Datenhändler mit der Offenlegung *tun* darf, nicht, was die Offenlegung *ist*. Kalifornien zu bitten, vergessen zu werden, bedeutet immer noch, auf einer Liste zu landen, die Datenhändler herunterladen. ## Die Behörde hat bessere Argumente, als ihre Kritiker zugeben Nichts davon macht die Behörde fahrlässig. Sie hat echte Verschlüsselung abgelehnt, weil Datenhändler dann Entschlüsselungsschlüssel halten würden — offensichtlich schlimmer. Sie hat die Abgleichregel auf eine Übereinstimmung von **100 %** verschärft, eine echte Absicherung dagegen, die falschen Menschen zu löschen. Die Listen sind **segmentiert**, sodass ein Datenhändler, der nur E-Mail-Adressen führt, die Liste mit Namen und Geburtsdaten nie erhält; Downloads sind nach dem ersten **inkrementell**; und der Zugang kostet **6.000 US-Dollar** Registrierungsgebühr pro Jahr, unter einem namentlich geführten Konto. Klartextnamen und -nummern an Hunderte Firmen zu schicken wäre schlimmer als alles davon. Und der härteste Punkt ist überhaupt nicht die Schuld der Behörde. §1798.99.86(b)(3) — eine Anweisung, die der Gesetzgeber geschrieben hat, nicht die Behörde — verlangt einen Mechanismus, mit dem ein Datenhändler feststellen kann, ob Sie einen Antrag gestellt haben, und der *"shall not allow the disclosure of any additional personal information … unless otherwise specified in this title."* — der also die Offenlegung jeder weiteren personenbezogenen Information nicht zulassen darf, sofern dieser Titel nichts anderes bestimmt. Lässt man die abschließende Ausnahmeklausel beiseite, bleibt ein Private-Set-Intersection-Problem, übergeben an eine kalifornische Behörde und finanziert als CSV-Download. Die Verteidigungslinien halten allerdings weniger gut, als sie aussehen. Die inkrementelle Zustellung hilft nichts mehr, sobald der erste Download der gesamte Bestand ist und jeder Datenhändler eine Kopie behält. Die Segmentierung setzt darauf, dass Datenhändler ihre Kennungsarten ehrlich angeben. Und die Schutzvorschriften von §7616 sind rechtlich, nicht technisch: Nichts hindert einen Datenhändler daran, aus der Liste zu *berechnen*, was er will — die Regel verbietet nur, das Ergebnis zu *verwenden*. ## Ein einziger Absatz könnte es schließen, bevor der erste Zyklus endet Es gibt einen Hebel, und ihn umzulegen braucht keinen Gesetzgeber. §7601(c) erlaubt es der Löschliste, ihren eigenen Hash-Algorithmus zu benennen; die Behörde hat SHA-256 in einer Kommentarantwort gutgeheißen, es aber nicht in die Regel geschrieben. Sie kann stattdessen Argon2id festlegen, im Rechtsetzungsverfahren, und der Dreiundvierzig-Sekunden-Angriff wird über Nacht undurchführbar — dieselbe Liste, eine andere Funktion, kein Gesetz nötig. Zwei ehrliche Grenzen liegen darunter. Wir berichten über die Verordnung und die Spezifikation, nicht über das laufende System: Die Verordnung erlaubt jeden Algorithmus, und die Live-API für Datenhändler steckt hinter einem Login, weshalb wir nicht bestätigen können, was das eingesetzte DROP heute ausgibt. Und die viel wiederholte Zahl "300,000+" ist die eigene Zählung der Behörde vom 2. Juni — Menschen, nicht Anträge, und seither nicht aktualisiert. Bestätigen können wir das Design, und das Design ist der Punkt. ## Eine Maschine, die sich für immer an Sie erinnern soll Streicht man alles andere weg, bleibt ein Widerspruch. Ein System, das Sie für immer wiedererkennen muss, um Sie weiter schützen zu können, muss etwas behalten, das Sie bedeutet — und alles, was Sie bedeutet, lässt sich wieder in Sie zurückverwandeln. Der einzige Ausweg ist, für die Maschine überhaupt nicht identifizierbar zu sein. Das ist kein technisches Detail, sondern eine Entscheidung darüber, wer die Arbeit macht: die Datenhändler oder die Menschen, die vor ihnen verschwinden wollen. Kalifornien hat sie im Rechtsetzungsverfahren getroffen, mit der funktionierenden Alternative vor sich, und hat sich für die Datenhändler entschieden. --- ## Quellen - **Cal. Civ. Code § 1798.99.86** — `leginfo.legislature.ca.gov` — (b)(3), die Anweisung zum Mitgliedschaftsorakel; (c)(1), *"Beginning August 1, 2026, a data broker shall access the accessible deletion mechanism … at least once every 45 days."* Gesetz: §1798.99.80 ff. (SB 362); Rechtsgrundlage §1798.99.87. Abgerufen am 7. August 2026. - **11 CCR §§7601–7622**, "Data Broker Registration and Accessible Deletion Mechanism", in Kraft seit 1. Januar 2026 — `cppa.ca.gov/regulations/pdf/data_broker_drop_reg.pdf`, 16 S. §7601(c) (der Algorithmus reist mit der Liste); §7612(c) (inkrementelle Downloads); §7613(a)(1)(A) (Standardisierung, einschließlich des Beispiels *Björn O'Connor-López → bjornoconnorlopez*) und (a)(1)(A)(vi); §7613(a)(2)(A) (jedes Feld hashen, die Digests "without adding spaces or other characters" verketten, erneut hashen); §7616 (Nutzungsbeschränkungen); §7620(b)–(c) (MAIDs; Einwilligung in die Offenlegung). **Korrekturen, 10. August**, alle drei von Übersetzern aufgeworfen, die die Zitate gegen die Quelle geprüft haben. (1) Der Text schrieb alle sechs Kennungsarten §7613 zu; nur `MAID` ist in der Verordnung benannt, die anderen fünf sind Bezeichnungen der technischen Spezifikation — wie es der Eintrag zur technischen DROP-Spezifikation weiter unten schon festgehalten hatte. (2) §7620(c) war so zitiert, dass es mit "to a data broker" endete; weggefallen war "for purposes of processing their deletion request." Die Zweckbindung ist die stärkste Erwiderung auf die Lesart, die auf dieser Stelle aufbaut, und wird deshalb jetzt zitiert und beantwortet statt gestrichen. (3) §1798.99.86(b)(3) war mit "no additional personal information" wiedergegeben und als "Wort für Wort" bezeichnet; im Gesetz heißt es "shall not allow the disclosure of any additional personal information … unless otherwise specified in this title", und die Ausnahmeklausel wird nun gezeigt. Korrektur (3) wurde auch in den Hot Takes vorgenommen, im Absatz zum gesetzlichen Punkt und im Vorspann. - **Final Statement of Reasons, Anhang A**, 53 S. — `cppa.ca.gov/regulations/pdf/drop_fsor_45day.pdf`. Kommentare 117–122, die Private Set Intersection und eine Trusted Execution Environment vorschlagen, sowie die oben vollständig zitierte Antwort der Behörde; Kommentar 196 und der SHA-256-Wortwechsel zu §7613(a)(1)(B); Kommentare 73–75 (Verschlüsselung abgelehnt, weil Datenhändler die Schlüssel halten würden); Antwort auf Kommentar 216 (segmentierte Listen); der FTC-Kommentar und die Antwort der Behörde, sie werde "will also monitor the DROP". Auch `cppa.ca.gov/regulations/pdf/drop_fosr.pdf` und `cppa.ca.gov/regulations/drop.html`. - **Technische DROP-Spezifikation** — `privacy.ca.gov/drop-for-data-brokers/technical-specifications/working-with-data/`, v1.2.0, "Last updated July 2026", abgerufen am 7. August 2026. Die Hashing-Regeln ("SHA-256 using UTF-8 input encoding", "Output as Base64"), die sechs Listentypen und die beiden Rechenbeispiele, die diese Redaktion nachgerechnet hat. - **Reproduktion und Benchmarks, diese Redaktion, 7. August 2026.** Die Rechenbeispiele der Spezifikation mit `hashlib.sha256` und Base64 nachgerechnet: 7 von 7 Feld-Digests und 2 von 2 zusammengesetzten Digests stimmen überein. Durchsatz lokal gemessen mit `openssl speed sha256` (113,894.45 kB/s bei 16-Byte-Blöcken ≈ 7.1M Hashes/s auf einem Kern) und mit einer Python-`hashlib`-Schleife (3,413,611 h/s). Suchräume aus den Formaten der Verordnung selbst berechnet: Telefon 6,4 × 10⁹ für den vollständigen NANP (nordamerikanischer Rufnummernplan) und 3,04 × 10⁸ für kalifornische Vorwahlen; CTVID 36⁸ bei der Mindestlänge von 8 Zeichen; MAID 32 Hexadezimalstellen. `grep -ci 'salt\|pepper'` = 0 über Verordnung und FSOR. - **CalPrivacy-Newsroom** — `privacy.ca.gov/about-us/newsroom/`, am 7. August 2026 erneut abgerufen und nochmals am 10. August: neuester Beitrag vom 4. August 2026 (Vermont tritt dem Konsortium der Aufsichtsbehörden bei), davor 21. Juli ("California Privacy Protection Agency Launches First Sectoral Audit, Targets Gig Economy Platforms", am 10. August anhand der serverseitig gerenderten `privacy.ca.gov/sitemap.xml` bestätigt, da der Newsroom-Index selbst per JavaScript gerendert wird); **kein Newsroom-Beitrag zur Datenhändlerpflicht vom 1. August**. **Korrektur, 10. August:** Diese Ausgabe schrieb zunächst, die Behörde habe "zum Start nichts gesagt". Sie hatte es getan — in ihrem *Blog*, nicht im Newsroom: `privacy.ca.gov/2026/07/drop-data-broker-deletions-how-do-they-work/`, 10. Juli 2026, sagt den Datenhändlern "starting on August 1, data brokers must download the hashed deletion requests and compare them against the personal information in their records." Der Text sagt jetzt, was tatsächlich zutrifft, und das ist enger und schlimmer: Die Behörde hat die Datenhändler unterrichtet und die Menschen auf der Liste nie gewarnt. Die Zahl "300,000+" stammt aus der Mitteilung vom 2. Juni 2026, "Privacy Momentum Builds: 300,000+ Californians Sign Up for DROP as Registered Data Brokers Hit a Record High", vollständig abgerufen (HTTP 200); sie verzeichnet außerdem 581 registrierte Datenhändler. - **Nicht belegt, als Lücken berichtet:** welchen Algorithmus die laufende DROP-Installation ausgibt (die Dokumentation der Datenhändler-API unter `databroker.drop.privacy.ca.gov` ist login-geschützt; eine Sandbox existiert, ihre Dokumentation war aber nicht erreichbar); jede von der CPPA veröffentlichte Zählung von Lösch*anträgen*; und jede Zahl, die neuer ist als der 2. Juni.