🤖 machine learning

Beyond Membership: Limitations of Add/Remove Adjacency in Differential Privacy

Die Arbeit zeigt, dass die Wahl der Adjazenzrelation (Hinzufügen/Entfernen versus Ersetzen) entscheidend ist, da die übliche Add/Remove-Definition die Privatsphäre von Attributen einzelner Datensätze im Vergleich zur Substitute-Relation überschätzt und durch neue Angriffe widerlegt wird.

Ursprüngliche Autoren: Gauri Pradhan, Joonas Jälkö, Santiago Zanella-Béguelin, Antti Honkela

Veröffentlicht 2026-04-08

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Gauri Pradhan, Joonas Jälkö, Santiago Zanella-Béguelin, Antti Honkela

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Das große Missverständnis beim Datenschutz

Stellen Sie sich vor, Sie haben eine geheime Liste mit den Lieblingsgerichten Ihrer Freunde. Sie wollen eine KI trainieren, die vorhersagt, was Menschen gerne essen, aber Sie wollen niemandem verraten, wer auf der Liste steht oder was genau Ihr Freund isst.

Um das zu schützen, verwenden Forscher eine Technik namens Differenzieller Datenschutz (DP). Man kann sich das wie einen sehr strengen Sicherheitsbeamten vorstellen, der sicherstellt, dass die KI nicht zu viel über einzelne Personen lernt.

Bisher gab es jedoch ein großes Missverständnis darüber, wie dieser Sicherheitsbeamte eigentlich arbeitet.

1. Der alte Schutzplan: "An- oder Abmelden" (Add/Remove)

Die meisten KI-Systeme nutzen heute einen Schutzplan, den wir "An- oder Abmelden" nennen.

Die Idee: Der Sicherheitsbeamte fragt sich: "Was passiert, wenn ich einen Freund komplett von der Liste streiche oder hinzufüge?"
Der Schutz: Wenn die KI so trainiert ist, dass sie kaum merkt, ob Person X auf der Liste war oder nicht, gilt sie als sicher.
Das Problem: Dieser Schutzplan ist wie ein Schloss, das nur verhindert, dass jemand weiß, ob Sie im Haus waren. Aber er verhindert nicht, dass jemand herausfindet, was Sie im Haus gegessen haben, wenn er weiß, dass Sie dort waren.

In der Praxis bedeutet das: Wenn Sie wissen, dass ein bestimmter Patient in einer medizinischen Datenbank ist, kann die KI unter dem alten Schutzplan trotzdem verraten, welche Krankheit dieser Patient hat. Der Schutzplan sagt: "Du kannst nicht wissen, ob er dabei war", aber er sagt nicht: "Du kannst nicht wissen, was er hat, falls er dabei war."

2. Der neue, strengere Plan: "Austauschen" (Substitute)

Die Autoren dieses Papers sagen: "Moment mal! Wenn wir wirklich schützen wollen, müssen wir einen anderen Plan testen: Austauschen."

Die Idee: Statt jemanden hinzuzufügen oder wegzunehmen, tauschen wir eine Person gegen eine andere aus.
- Szenario A: Die Liste enthält "Max isst Pizza".
- Szenario B: Die Liste enthält "Max isst Sushi".
Der Test: Die KI muss so trainiert sein, dass sie nicht unterscheiden kann, ob Max Pizza oder Sushi gegessen hat.
Die Erkenntnis: Die Autoren haben gezeigt, dass die alten Schutzpläne ("An- oder Abmelden") uns falsch sicher machen. Sie übertreiben die Sicherheit gewaltig, wenn es darum geht, Details über eine Person zu schützen, von der man weiß, dass sie dabei ist.

3. Der Detektiv-Test (Die "Köder"-Methode)

Um das zu beweisen, haben die Forscher wie Detektive gearbeitet. Sie haben eine spezielle Falle (im Papier "Canary" oder "Köder" genannt) gebaut.

Stellen Sie sich vor, Sie mischen einen ganz speziellen, extremen "Köder" in die Trainingsdaten:

Köder A: Ein Bild von einem Hund, das so aussieht, als wäre es ein Hund, aber die KI lernt, es als "Katze" zu bezeichnen.
Köder B: Ein Bild von einer Katze, das die KI als "Hund" lernt.

Sie trainieren die KI nun mit diesen Ködern. Wenn die KI am Ende des Trainings immer noch genau weiß, ob sie mit dem "Hund-als-Katze"-Köder oder dem "Katze-als-Hund"-Köder trainiert wurde, dann ist der Datenschutz gebrochen.

Das Ergebnis war erschreckend klar:

Die alten Schutzpläne sagten: "Die KI kann den Unterschied nicht merken. Alles sicher!"
Der neue Test zeigte: "Nein! Die KI merkt den Unterschied sehr gut. Der Schutzplan hat gelogen."

4. Warum ist das wichtig?

Stellen Sie sich vor, Sie nutzen eine App, die Ihre Gesundheitsdaten analysiert.

Der alte Schutz sagt Ihnen: "Keiner kann herausfinden, ob Sie in der Datenbank sind." (Das ist gut, aber nicht genug).
Die Realität (wie die Autoren zeigen): Wenn ein Hacker weiß, dass Sie in der Datenbank sind, kann er durch geschickte Tricks herausfinden, ob Sie an Diabetes leiden oder nicht. Der Schutzplan hat das nicht verhindert, weil er nur auf das "An- oder Abmelden" achtete, nicht auf das "Austauschen".

Die Moral der Geschichte

Die Autoren sagen: Wenn Sie wirklich sensible Details (wie Diagnosen, politische Meinungen oder private Vorlieben) schützen wollen, reicht der alte Standard ("An- oder Abmelden") nicht aus.

Man muss den strengeren Standard ("Austauschen") verwenden. Wenn man das tut, stellt man fest, dass man viel mehr "Rauschen" (Störgeräusch) in die Daten werfen muss, um wirklich sicher zu sein. Das bedeutet: Entweder man akzeptiert, dass die KI etwas weniger genau ist, oder man muss mehr Datenschutz-Regeln anwenden, als bisher gedacht.

Zusammengefasst:
Der alte Schutzplan war wie ein Vorhang, der nur verdeckt, dass jemand im Raum ist. Die neuen Forscher haben gezeigt, dass dieser Vorhang nicht verhindert, dass man sieht, was die Person tut. Um wirklich sicher zu sein, brauchen wir einen dickeren Vorhang (den "Substitute"-Ansatz), auch wenn das die KI etwas langsamer macht.

1. Problemstellung

Das Paper adressiert eine kritische Lücke in der Praxis des Differential Privacy (DP) beim Training von Machine-Learning-Modellen.

Hintergrund: DP schützt sensible Daten, indem es die Fähigkeit eines Angreifers begrenzt, zwei benachbarte Datensätze ( $D$ und $D'$ ) anhand der Ausgabe eines Algorithmus zu unterscheiden. Die Stärke dieser Garantie hängt von der gewählten Adjazenzrelation ab.
Der aktuelle Standard: Die meisten DP-Implementierungen (z. B. in Bibliotheken wie Opacus) nutzen die Add/Remove-Adjazenz. Hier sind zwei Datensätze benachbrend, wenn einer durch Hinzufügen oder Entfernen eines einzelnen Datensatzes aus dem anderen entsteht. Dies schützt primär die Mitgliedschaft (Membership Inference), also ob eine Person im Datensatz war oder nicht.
Das Problem: In vielen ML-Anwendungen (z. B. Supervised Fine-Tuning) ist das eigentliche Ziel der Schutz von Attributen einzelner Datensätze (z. B. die genaue Klasse/Label eines bekannten Nutzers). Die Add/Remove-Adjazenz bietet für diesen Fall keine ausreichende Sicherheit auf dem Niveau der angegebenen Privacy-Parameter.
Die Diskrepanz: Um Attributschutz zu garantieren, müsste die Substitute-Adjazenz (Austausch eines Datensatzes gegen einen anderen) verwendet werden. Ein Add/Remove-Bound impliziert zwar auch einen Substitute-Bound, aber mit deutlich schwächeren Parametern. Praktiker, die sich auf Add/Remove-Accounting verlassen, überschätzen daher fälschlicherweise den Schutz gegen Angriffe auf Attribute.

2. Methodik

Die Autoren entwickeln neue Auditierungs-Methoden, um die tatsächliche Privatsphäre unter der Substitute-Adjazenz zu messen und die Diskrepanz zu Add/Remove-Garantien aufzuzeigen.

Auditierungs-Framework:
- Es wird ein Hidden-State Threat Model angenommen (der Angreifer sieht nur das finale Modell, nicht die Zwischenschritte).
- Der Angreifer erstellt Paare benachbarter Datensätze ( $D, D'$ ), wobei $D'$ durch Ersetzen eines Ziel-Datensatzes $z \in D$ durch einen „Canary"-Datensatz $z'$ entsteht.
- Ziel ist es, zu testen, ob das Modell trainiert wurde auf $D$ oder $D'$ .
Entwicklung von Canary-Samples (Algorithmus 1–5):
Die Autoren stellen verschiedene Strategien zur Erstellung von Canary-Samples vor, um die Unterscheidbarkeit zu maximieren:
1. Gradient-Space Canaries (S1, S2):
  - S1 (Worst-Case): Konstruktion von Datensätzen, bei denen $z$ einen Gradienten mit maximaler Norm $C$ in einer Richtung und $z'$ einen Gradienten mit Norm $C$ in exakt entgegengesetzter Richtung liefert. Alle anderen Samples tragen 0 bei. Dies liefert die theoretisch engste untere Schranke.
  - S2 (Für natürliche Datensätze): Identifikation des Parameters, der während des Trainings am wenigsten ändert, und Zuweisung eines Gradienten mit Norm $C$ in entgegengesetzter Richtung für $z$ und $z'$ .
2. Input-Space Canaries (S3, S4, S5):
  - Da Angreifer in der Praxis oft keinen direkten Zugriff auf den Gradientenraum haben, werden Canaries im Eingaberaum erstellt.
  - S3: Erstellen eines Eingabe-Canary ( $x'$ ), der den Gradienten von $z$ minimiert (kosinusähnlich).
  - S4: Erstellen eines falsch beschrifteten Samples ( $x, y'$ ), das den Gradienten von $z$ minimiert.
  - S5: Auswahl eines adversarialen natürlichen Samples aus einem Hilfsdatensatz.
Bewertung:
- Die empirische Privatsphäre ( $\epsilon$ ) wird durch wiederholtes Training und Unterscheidung der Modelle berechnet (unter Verwendung von $\mu$ -GDP und Umrechnung in $(\epsilon, \delta)$ -DP).
- Die Ergebnisse werden mit theoretischen Obergrenzen verglichen, die entweder durch Add/Remove-Accounting, Substitute-Accounting oder durch die Gruppieren-Privatsphäre-Approximation (Theorem 4.1) berechnet wurden.

3. Wichtige Beiträge

Algorithmen für Substitute-Auditing: Entwicklung neuer Algorithmen zur Erstellung von Canary-Samples, die speziell für die Substitute-Adjazenz optimiert sind und enge empirische untere Schranken liefern.
Nachweis der Diskrepanz: Empirischer Beweis, dass die Privatsphäre-Leckage bei Substitute-Angriffen die Garantien des Add/Remove-Accounting überschreitet, aber eng mit den Vorhersagen des Substitute-Accounting übereinstimmt.
Kritik an der aktuellen Praxis: Demonstration, dass die Verwendung von Add/Remove-Accounting für Szenarien, in denen der Schutz von Attributen (Labels) erforderlich ist, zu einer gefährlichen Überschätzung des Schutzniveaus führt.
Analyse von Trainingsstrategien: Unterscheidung zwischen dem Verhalten von Modellen, die von Grund auf neu trainiert werden, und solchen, die durch Fine-Tuning vortrainierter Modelle angepasst werden.

4. Ergebnisse

Die experimentellen Ergebnisse (basierend auf CIFAR-10, SST-2 und Purchase100) zeigen folgende Trends:

Verletzung von Add/Remove-Garantien: Bei Modellen, die mit natürlichen Datensätzen feinabgestimmt (Fine-Tuning) wurden, überschreitet die empirisch gemessene Privatsphäre-Leckage ( $\epsilon_{\text{Auditing}}$ ) deutlich die theoretische Obergrenze des Add/Remove-Accounting ( $\epsilon_{AR}$ ).
Konsistenz mit Substitute-Accounting: Die gemessene Leckage folgt jedoch eng der Obergrenze, die durch ein Substitute-Accounting berechnet wird ( $\epsilon_S$ ).
Effektivität der Canaries:
- Gradient-Space Canaries liefern die engsten (stärksten) Audits und verletzen die Add/Remove-Grenzen konsistent.
- Input-Space Canaries sind weniger effektiv, insbesondere bei niedrigen Subsampling-Raten ( $q$ ) und bei Modellen, die von Grund auf neu trainiert werden (nicht-convexe Optimierung). Dennoch zeigen sie bei Fine-Tuning-Szenarien oft eine Leckage, die über den Add/Remove-Garantien liegt.
Einfluss der Subsampling-Rate: Die Wirksamkeit der Audits nimmt mit sinkender Subsampling-Rate ab, was bedeutet, dass bei hohen Subsampling-Raten (oft für bessere Privacy-Utility-Trade-offs genutzt) das Risiko einer Überschätzung des Schutzes durch Add/Remove besonders hoch ist.
Fine-Tuning vs. From-Scratch: Feinabgestimmte Modelle sind anfälliger für Input-Space-Angriffe als Modelle, die von Grund auf neu trainiert werden.

5. Bedeutung und Fazit

Das Paper hat weitreichende Implikationen für die Praxis des Differential Privacy:

Risiko für Praktiker: Entwickler, die Standard-DP-Bibliotheken verwenden, die Add/Remove-Adjazenz als Standard annehmen, könnten glauben, sie schützen die Attribute ihrer Daten (z. B. Patientendiagnosen oder Nutzerpräferenzen), tun dies aber nicht auf dem angegebenen Niveau.
Notwendigkeit korrekter Adjazenz: Wenn das Schutzziel die Privatsphäre von Attributen ist (und nicht nur die Mitgliedschaft), muss die Substitute-Adjazenz verwendet werden. Die Umrechnung über Gruppieren-Privatsphäre (Theorem 4.1) liefert zwar eine Obergrenze, ist aber oft zu locker; direkte Substitute-Accounting-Methoden sind vorzuziehen.
Zukunft der Auditierung: Die Arbeit unterstreicht die Notwendigkeit, Auditierungs-Tools an die spezifische Bedrohungslage (Attribut-Inferenz vs. Mitgliedschaft) anzupassen. Die vorgeschlagenen Gradienten-Canaries bieten einen robusten Weg, um die tatsächliche Sicherheit von DP-Modellen zu validieren.

Zusammenfassend zeigt das Paper, dass „One-Size-Fits-All"-Ansätze in der DP-Praxis gefährlich sein können und die Wahl der Adjazenzrelation entscheidend für die korrekte Einschätzung des Schutzniveaus ist.