03 — Anonymität
k-Anonymität als Schema-Constraint
k-Anonymität ist hier kein Versprechen, sondern eine Bedingung des Schemas. Eine Zusicherung, die nur in der Dokumentation steht, ist keine. Bei Prometheus lehnt das Schema ab — lokal im SDK und nochmals am Mirror. Beide Gates sind unabhängig, und keines darf entfernt werden.
Stand 2026-08-13: Das lokale Gate ist in allen sechs SDKs implementiert und wird gegen die K3-Vektoren geprüft. Das zweite Gate am Mirror ist seit August gebaut und getestet — die Mirror-Software lehnt PII-Felder am Ingress ab und benennt dabei das verletzende Feld. Damit tragen erstmals beide Gates. Was noch fehlt, ist ein öffentlich erreichbarer Mirror: Die Software läuft bislang nur auf der Entwicklungsumgebung.
Interaktiv
Was passiert, wenn eine Kohorte zu klein wird
k_effective ist die Anzahl unterscheidbarer Melder hinter einem
Aggregat. Zieh den Regler unter fünf und sieh selbst.
Kohortengröße
Fällt k_effective unter k_min, wird das Aggregat
weder verworfen noch gesendet — es wird lokal in die Sammelkohorte
__small_cohorts umgeschrieben, bevor es je die Maschine verlässt.
Kollidierende kleine Zeilen werden gemergt, k_effective summiert.
Default ist k_min = 5. Für die Modi B und C, die näher am Endnutzer messen, gilt k_min ≥ 25.
Defense in Depth
Die vierzehn Stufen des Datenflusses
Zwei der vierzehn Stufen sind unabhängige PII-Gates. Die Stufen 1 bis 8 laufen im Prozess des Endnutzers, die Stufen 9 bis 14 am Mirror. Die beiden Gates duplizieren sich scheinbar — genau das ist der Punkt.
Beide Gates müssen koexistieren
Ein Diff, der eines der beiden als vermeintliche Dopplung „aufräumt“, ist im Review ein Auto-FAIL. Entfernen geht nur über eine explizite, dokumentierte Architektur-Entscheidung.
Warum der Mirror erneut prüft
Auch eine korrekt signierte Submission wird am Ingress erneut vollständig geprüft — ein manipuliertes SDK kommt damit nicht durch. Die Prüfkette ist gebaut und läuft: Signatur, PII-Schema, k-Anonymität, Zeitfenster, Duplikate. Noch nicht öffentlich: Der Mirror läuft bislang nur auf der Entwicklungsumgebung.
PII niemals auf Disk
Roh-Events liegen ausschließlich in RAM bzw. tmpfs des lokalen Aggregators. Auf die Platte kommen nur bereits signierte Aggregate.
Banding statt Klartext
Numerische Werte aus den Modi A, B und C werden nie als Zahl publiziert,
sondern auf vordefinierte Bänder gemappt — etwa 30-60 statt 47.
Verbotsliste
Felder, die das Schema ablehnt
Kein Filter, der Felder still entfernt — ein Reject. Enthält eine Submission eines dieser Felder, wird sie nicht bereinigt, sondern zurückgewiesen.
Gezeigt sind die dreizehn K3-Negativvektoren, gegen die heute jedes der sechs SDKs geprüft wird; der Mirror prüft am Ingress unabhängig davon gegen die vollständige Verbotsliste. Die kanonische Liste ist breiter als die dreizehn Vektoren und nennt zusätzlich etwa Zeitstempel, die feiner auflösen als das Messfenster. K3 und der k-Anon-Audit sind harte Stopp-Kriterien: Kein Release passiert das Gate ohne sie — auch kein Hotfix.
Prüfbarkeit
Nachprüfbarkeit von außen
Verifizierbarkeit tritt an die Stelle von Vertrauen: Niemand muss dem Betreiber eines Mirrors glauben. Jede akzeptierte Submission hinterlässt einen Hash in einem öffentlichen Log.
Public Audit Log
Jede akzeptierte Submission soll als Hash im Sigstore-Rekor-Log landen — ab Tag 1 des Mirror-Betriebs, nicht als spätere Ausbaustufe.
Cross-Mirror-Konsistenz
Sobald mehrere Mirrors dieselben Aggregate führen, lässt sich von außen prüfen, ob einer davon abweicht. In Phase 1 läuft genau ein Mirror — die Prüfung greift ab dem zweiten.
Snapshots werden archiviert, nicht gelöscht
Ein einmal publizierter Open-Data-Snapshot bleibt. Eine Korrektur bekommt einen neuen Datums-Suffix und einen Log-Eintrag mit hinterlegtem Grund.
ZK-Attestation ab Phase 2
Geplant: ein ZK-SNARK belegt die Einhaltung der k-Anonymität, ohne die zugrunde liegenden Zahlen offenzulegen.