🤖 machine learning

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

Dit artikel toont aan dat het gebruik van de 'add/remove'-adjacentie in differentieel privacy de bescherming van recordattributen overdrijft vergeleken met de 'substitute'-adjacentie, wat leidt tot inconsistente auditresultaten en benadrukt dat de keuze van de adjacentie cruciaal is afhankelijk van het beschermingsdoel.

Oorspronkelijke auteurs: Gauri Pradhan, Joonas Jälkö, Santiago Zanella-Béguelin, Antti Honkela

Gepubliceerd 2026-04-08

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Gauri Pradhan, Joonas Jälkö, Santiago Zanella-Béguelin, Antti Honkela

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een geheim recept voor een heerlijke taart hebt. Je wilt dit recept delen met de wereld, maar je wilt niet dat iemand erachter komt welke specifieke ingrediënten jij persoonlijk hebt gebruikt.

Dit is precies wat Differentiële Privacy (DP) probeert te doen voor machine learning-modellen. Het is een wiskundige "veiligheidsbril" die ervoor zorgt dat een model niet kan onthullen of een specifieke persoon (of een specifieke data-punten) in de trainingsset zat.

Maar in dit nieuwe onderzoek van ICLR 2026 ontdekken de auteurs een groot gat in deze veiligheidsbril. Ze laten zien dat de manier waarop we nu de privacy berekenen, ons een vals gevoel van veiligheid geeft.

Hier is de uitleg in simpele taal, met wat creatieve metaforen:

1. De Twee Manieren om te "Vernietigen" (De Adjacentie)

Om privacy te garanderen, kijken onderzoekers naar twee scenario's:

Scenario A (Toevoegen/Verwijderen): Stel je hebt een lijst met 100 namen. Als je één naam verwijdert, is de lijst bijna hetzelfde. De huidige standaard in de tech-wereld is om te zeggen: "Als je één naam verwijdert, kan niemand zien of die persoon erin zat." Dit noemen ze Add/Remove.
Scenario B (Vervangen): Stel je hebt dezelfde lijst, maar je verwisselt de naam "Jan" met de naam "Piet". De lijst heeft nog steeds 100 namen, maar de inhoud is anders. Dit noemen ze Substitute.

Het probleem: De meeste software die privacy berekent, kijkt alleen naar Scenario A (Verwijderen). Ze denken: "Als we Jan verwijderen, is het geheim veilig." Maar in de echte wereld willen mensen vaak niet alleen beschermen dat Jan in de lijst zat, maar ook wat voor gegevens Jan had (bijvoorbeeld: "Jan heeft een hoge bloeddruk" of "Jan kocht een dure auto").

2. De Metafoor: De Luie Wachter vs. De Slimme Vervanger

Stel je een museum voor dat een schilderij bewaakt (het model).

De huidige wachter (Add/Remove): Hij kijkt alleen of er een schilderij ontbreekt. Als er één schilderij weg is, denkt hij: "Geen probleem, niemand merkt het op." Hij is bang dat iemand ziet dat een schilderij ontbreekt.
De echte bedreiging (Substitute): Een dief komt niet om een schilderij te stelen, maar om één schilderij te vervangen door een nep-schilderij dat er heel anders uitziet. De wachter kijkt niet naar het verschil tussen "er is" en "er is niet", maar naar het verschil tussen "dit schilderij" en "dat schilderij".

De auteurs van dit paper zeggen: "De huidige wachter slaapt!"
Als je alleen kijkt naar het verwijderen van een record, denk je dat je veilig bent. Maar als je een record vervangt door een ander (bijvoorbeeld een andere label of een andere foto), lekt er veel meer informatie uit dan de wachter denkt. De privacy-berekening is te optimistisch.

3. De Experimenten: De "Kanon" (Canary)

Om dit te bewijzen, hebben de onderzoekers een slimme truc bedacht. Ze maken een "Kanon" (in het Engels: Canary).

Dit is een speciaal gemaakt voorbeeld (een "valstrik") dat ze in de trainingsdata stoppen.
Ze trainen het model twee keer: één keer met het echte voorbeeld, en één keer met het nep-voorbeeld (de vervanging).
Vervolgens kijken ze of het model zich anders gedraagt.

Wat ontdekten ze?

Als je de privacy berekent volgens de oude regels (Verwijderen), zegt de computer: "Je bent 99% veilig."
Maar als ze de "Kanon" gebruiken om te testen of het model het verschil ziet tussen het echte en het nep-voorbeeld, blijkt het model veel meer te weten. Het kan het verschil zien met veel meer zekerheid dan de oude regels voorspelden.

Het is alsof je zegt: "Mijn huis is veilig tegen inbrekers die de voordeur openen," terwijl de inbreker eigenlijk door het raam klimt. De beveiliging werkt wel, maar niet tegen de juiste dreiging.

4. Waarom is dit belangrijk?

In veel toepassingen, zoals het trainen van AI voor medische diagnoses of het analyseren van klantgedrag, willen we niet alleen beschermen dat iemand in de dataset zat. We willen beschermen dat we niet kunnen afleiden wat die persoon deed of wat zijn/haar kenmerken waren.

Voorbeeld: Als een AI is getraind met DP om te voorspellen of iemand ziek is, en we gebruiken de oude "Verwijderen"-methode, denken we dat de privacy van de patiënt gewaarborgd is. Maar de onderzoekers tonen aan dat als je de data van die patiënt vervangt door een andere, de AI toch kan onthullen of de oorspronkelijke patiënt een specifieke ziekte had.

5. De Conclusie: Pas de Bril aan!

De boodschap van dit paper is duidelijk:
Als je privacy wilt garanderen voor inhoud (zoals labels, diagnoses, of gedrag), dan is de standaardmethode (Add/Remove) niet sterk genoeg. Je moet de privacy-berekening aanpassen naar de "Vervangen"-methode (Substitute).

Als bedrijven en onderzoekers nu vertrouwen op de standaard software (zoals de populaire bibliotheken die ze nu gebruiken), denken ze dat ze veiliger zijn dan ze eigenlijk zijn. Ze moeten hun "veiligheidsbril" aanpassen, anders lopen ze het risico dat hun geheimen toch lekken.

Kort samengevat:
We dachten dat we een muur hadden gebouwd tegen inbrekers die de deur openen. Maar deze paper laat zien dat inbrekers eigenlijk door het raam klimmen. Als we dat niet zien, denken we dat we veilig zijn, terwijl we dat niet zijn. Het is tijd om het raam ook te vergrendelen!

Probleemstelling

Dit paper adresseert een fundamenteel misverstand in de praktijk van Differentiële Privacy (DP) voor machine learning. De meeste bestaande DP-implementaties (zoals Opacus) gebruiken de add/remove-benadering (adjacency). Hierbij worden twee datasets als "buren" beschouwd als ze slechts één record verschillen door toevoeging of verwijdering. Deze benadering is ontworpen om lidmaatschap te beschermen (d.w.z. of een individu wel of niet in de dataset zit).

Het paper stelt echter dat in veel ML-toepassingen, zoals supervised fine-tuning, het werkelijke doel is om attributen van individuele records te beschermen (bijvoorbeeld labels of gevoelige kenmerken van een bekend lid van de dataset). De auteurs tonen aan dat de privacygaranties die worden berekend onder de add/remove-benadering de bescherming tegen attribuut-inferentie-aanvallen sterk overschatten. De juiste burenrelatie voor het beschermen van attributen is de substitute-adjacency (waarbij één record wordt vervangen door een ander), maar deze wordt zelden gebruikt in standaard accounting-tools.

Methodologie

Om de kloof tussen de theoretische garanties (add/remove) en de werkelijke kwetsbaarheid (substitute) te kwantificeren, ontwikkelen de auteurs een reeks audit-tools en aanvalsscenario's:

Audit Framework voor Substitute Adjacency:
De auteurs definiëren een audit-procedure waarbij een aanvaller een paar naburige datasets ( $D$ en $D'$ ) creëert door een doelrecord $z$ in $D$ te vervangen door een "canary"-record $z'$ . De aanvaller probeert vervolgens te onderscheiden of het model is getraind op $D$ of $D'$ .
Ontwerp van Canarys (Aanvalsstrategieën):
Er worden verschillende scenario's onderzocht, variërend in de kennis van de aanvaller en de ruimte waarin de canary wordt gegenereerd:
- Gradient-Space (S1 & S2): De aanvaller manipuleert direct de gradiënten. In scenario S1 worden "worst-case" datasets gemaakt waarbij de gradiënt van $z$ en $z'$ maximaal tegengesteld zijn (norm $C$ ). In S2 worden gradiënten gegenereerd die constant blijven tijdens training om de parameterupdates te maximaliseren.
- Input-Space (S3, S4 & S5): De aanvaller kan alleen invoerdata manipuleren. Dit omvat het creëren van aangepaste invoermonsters ( $z'$ ), verkeerd gelabelde monsters, of het selecteren van natuurlijke adversarial monsters uit een hulpdataset.
- Threat Models: De audits worden uitgevoerd in zowel "Visible-State" (White-box, toegang tot gradiënten) als "Hidden-State" (Black-box, alleen toegang tot het finale model) scenario's.
Privacy Accounting:
De auteurs vergelijken de empirisch gemeten privacyverlies ( $\epsilon$ ) met drie theoretische bovenkanten:
- $\epsilon_{AR}$ : Berekend met add/remove accounting (standaard in bibliotheken).
- $\epsilon_{S}$ : Bereken met directe substitute accounting (via numerieke accountants gebaseerd op Privacy Loss Random Variables).
- $\epsilon_{S, group}$ : Een schatting van substitute privacy afgeleid van add/remove privacy via de "Group Privacy"-stelling (Theorem 4.1), wat vaak een te losse bovengrens geeft.
Experimentele Opstelling:
Er wordt getraind met DP-SGD en DP-Adam op diverse datasets (CIFAR10, SST-2, Purchase100) en architecturen (ViT-B-16, Sentence-BERT, MLP). De audits worden stapsgewijs uitgevoerd om te zien hoe privacyverlies zich ontwikkelt tijdens training.

Belangrijkste Bijdragen

Nieuwe Audit-algoritmen: De auteurs presenteren methoden om canarys te ontwerpen die specifiek zijn voor substitute-adjacency audits, inclusief algoritmen voor het genereren van gradiënt- en invoer-gebaseerde canarys (Algoritmes 2 t/m 5).
Empirisch Bewijs van Overschatting: Ze tonen aan dat privacyverlies bij substitute-aanvallen systematisch hoger ligt dan de garanties die add/remove-accounting voorspelt.
Validatie van Substitute Accounting: De empirische resultaten van de audits komen nauwkeurig overeen met de theoretische garanties berekend onder de substitute-adjacency, maar niet met die van add/remove.
Kritiek op Groepsprivacy: Ze demonstreren dat het benaderen van substitute privacy via de "Group Privacy"-stelling (compositie van add + remove) suboptimale en te optimistische bovenkanten oplevert vergeleken met directe numerieke accounting voor substitute.

Resultaten

Overschrijding van Add/Remove Garantiën: In experimenten met natuurlijk getrainde modellen (bijv. fine-tuning van ViT op CIFAR10) overschrijdt de empirische privacylek ( $\epsilon$ ) duidelijk de $\epsilon_{AR}$ -grens. Dit betekent dat een aanvaller met meer vertrouwen kan bepalen of een specifiek attribuut in de training zat dan de DP-garantie suggereert.
Effectiviteit van Canarys:
- Gradiënt-gebaseerde canarys leveren de strakste (tightest) audits op en volgen nauwkeurig de $\epsilon_{S}$ -accounting.
- Invoer-gebaseerde canarys zijn minder effectief, vooral bij lage subsampling-rates ( $q$ ) en bij training "vanaf nul" (non-convex optimalisatie), maar tonen toch vaak een lek dat groter is dan de add/remove-garantie.
Fine-tuning vs. Training from Scratch: Fine-tuned modellen zijn gevoeliger voor privacylekken via invoer-canarys dan modellen die vanaf nul worden getraind. Dit is relevant omdat fine-tuning de standaardpraktijk is voor het gebruik van gevoelige data.
Subsampling Impact: De effectiviteit van audits neemt af bij lagere subsampling-rates, wat betekent dat de "privacy-utility trade-off" die vaak wordt nagestreefd, de detectie van privacylekken bemoeilijkt, maar de feitelijke kwetsbaarheid voor attribuut-inferentie blijft bestaan.

Betekenis en Conclusie

Het paper concludeert dat de keuze van de burenrelatie (adjacency) cruciaal is bij het rapporteren van DP-garanties. Als het beschermingsdoel attributen of labels zijn (en niet alleen lidmaatschap), is de add/remove-benadering misleidend en onvoldoende.

Voor Praktici: Het vertrouwen op standaard DP-bibliotheken (die add/remove gebruiken) kan leiden tot een gevaarlijke overschatting van de privacybescherming tegen attribuut-inferentie-aanvallen.
Voor Onderzoek: Er is een dringende behoefte aan het gebruik van substitute-adjacency accounting in plaats van de huidige standaard.
Toekomstige Richting: De auteurs wijzen erop dat hoewel hun huidige input-space canarys gevoelig zijn voor hyperparameters, er behoefte is aan robuustere methoden om audits uit te voeren op realistische, niet-convexe optimalisatieproblemen.

Kortom, dit werk waarschuwt dat "Differentiële Privacy" niet gelijkstaat aan "Privacy voor alles"; de specifieke definitie van wat wordt beschermd (lidmaatschap vs. attributen) bepaalt of de gekozen privacy-maatstaf geldig is.