03 — Anonymität
k-Anonymität ist kein Versprechen. Sie ist ein Schema-Constraint.
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 heute: Das lokale Gate ist in allen sechs SDKs implementiert und wird gegen die K3-Vektoren geprüft. Das zweite Gate am Mirror ist spezifiziert, aber noch nicht in Betrieb — der Mirror entsteht in Phase 1. Diese Seite beschreibt beide, weil sie zusammen die Zusage tragen; wo etwas noch nicht läuft, steht es dabei.
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
Vierzehn Stufen, zwei 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.
Der Mirror wird dem SDK nicht vertrauen
Auch eine korrekt signierte Submission wird am Ingress erneut vollständig geprüft — ein manipuliertes SDK kommt damit nicht durch. Noch nicht in Betrieb: Der Mirror entsteht in Phase 1; bis dahin greift von den beiden Gates nur das lokale.
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
Was das Schema aktiv 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 sie am Ingress erneut, sobald er in Betrieb ist. Die kanonische Verbotsliste ist breiter 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
Verifizierbarkeit statt 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.