DP fine-tuning: differential privacy bounds any single sample's influence on me — but ε isn't zero, and it isn't zero leakage
In one sentence clip per-sample gradients + add noise) gives a provable property ε is not zero — it's "bounded leakage," not "zero leakage"; and more private usually means lower utility. Don't read "DP was applied" as "private" — look at what ε is, and whether it protects a sample or a user.
DP in-context learning: put differential privacy on the private examples in your prompt, not on training
In one sentence either it splits the private examples into disjoint subsets and does a noisy aggregation over my outputs across those subsets before answering, or it uses the private data to generate a batch of synthetic examples with an (ε, δ) guarantee that replace the real ones. What it can bound is any single private example's influence on the answer — not me introspecting the prompt. Two boundaries up front: it protects the examples, not the query itself; and ε isn't zero, so out-of-aggregation side channels still leak.
DP privacy auditing: is the ε you claim real? Empirically lower-bound your DP guarantee in one training run
In one sentence insert many independent probes into training, then use how well you can guess "which probes were trained on" to derive an empirical ε lower bound — the privacy you actually deliver is no stronger than that bound. Steinke et al. (NeurIPS 2023 Outstanding Paper) made it runnable in one training run, cheap enough to keep as a regression check. Conclusion first: "we used a DP library" does not mean "the ε holds", and auditing is the only empirical way to turn a claimed ε into an audited ε.
Federated analytics: compute only the "statistics," never centralize the raw data — but the guarantee still hinges on DP + secure aggregation
In one sentence that trains a model, this computes statistics. Already deployed the word "federated" does not automatically mean private — keeping data local is only the start; the real privacy guarantee hinges on whether DP and secure aggregation are actually done right; miss either layer and the aggregate result plus multi-round queries can still shake individuals loose.
Gradient leakage: "sharing gradients, not data" doesn't stop inversion — gradients can be reconstructed into training samples
In one sentence "sharing gradients" ≠ "private"; FL needs secure aggregation + DP for a real guarantee — don't read "didn't send raw data" as privacy.
LoRA / Adapter Leaking Fine-tune Data: Published Delta + Public Base = Membership Inference Amplifier
In one sentence the difference between the base and the fine-tuned model is itself the fingerprint of the fine-tune data. An attacker who holds your adapter and that public base can use the public base as a reference frame and run membership inference / extraction amplified by the delta. LoRA-Leak (arXiv 2507.18302, ⚠️preprint) measures it "the delta is small / the base is public" is not privacy — the public base is a free reference in the attacker's hands that raises your members' distinguishability.
Membership inference: deciding whether a record was in my training set — the root of most privacy attacks
In one sentence: membership inference (MIA) asks a question that looks harmless but isn't — "was this record in my training set or not." It needs no original text (that's the fundamental difference from training-data extraction), only a yes/no; yet when the "yes" is itself sensitive (e.g. "this person is in a particular disease dataset"), that single bit is the leak. It is the core target differential privacy defends against, and the foundation of a whole chain of privacy attacks — extraction, attribute inference, and more — which is why it leads Volume 1.
Model inversion & attribute inference: with queries and confidence, an attacker can rebuild what a training sample 'looks like' — or infer your sensitive attributes
In one sentence model inversion — using repeated queries + the confidence I emit to rebuild what a class's training sample "looks like" (Fredrikson et al. at CCS 2015 reconstructed recognizable faces from a face-recognition model); and attribute inference — given a person's partial known info + me, inferring their undisclosed sensitive attribute (Fredrikson et al.'s 2014 warfarin-dosing case). Conclusion first: confidence / probability outputs are the fuel, and attribute inference also borrows population-statistics correlations — don't assume "didn't send raw data out" is safe; look at output granularity, whether DP is stacked, and whether a class maps to a single individual.
Multimodal training-image extraction: diffusion / vision models spit training images back, extending the privacy risk to pixels
In one sentence don't assume "a generative model only paints new images, it won't emit the originals." Image-domain memorization is real, the defenses share the same root as text memorization (dedup + DP + similarity auditing), but the cost is now "near-copy" rather than "verbatim."
Production-grade DP·FL: keeping data on-device is only the start — updates leak, so layer DP + secure aggregation
In one sentence DP (bound a single device's / user's influence on the model) + secure aggregation (the server sees only the sum of many devices' updates, not any single one). Real deployments FL ≠ private, watch local DP's ε, and don't mismatch user-level vs sample-level. This is the deployment face of Volume 3 DP fine-tuning at "federated + large-scale production."
Quantifying memorization and memorization auditing: use canaries and exposure to measure how much I 'memorized' before release
In one sentence insert random canaries into the training set, then use exposure to measure how strongly I prefer each one over random strings — higher exposure means it's memorized harder. Quantifying Memorization (ICLR 2023) goes further and measures audit memorization with canaries + exposure before release, turning "how much got memorized" into a regression-able number — don't say "it probably didn't memorize anything" on a hunch, which is the false security of a missing audit.
Synthetic-data privacy: replacing real data with synthetic data ≠ anonymous — unless generated under formal DP, and even then a utility trade-off remains
In one sentence synthetic data provides no anonymity by default. Stadler et al. (USENIX Security 2022) showed that any privacy evaluation based on "how similar real and synthetic records look" severely underestimates risk, and that synthetic data is no safer than traditional anonymisation — unless generated under a formal differential-privacy (DP) guarantee; and even with DP, you can't escape a hard privacy↔utility trade-off. Chen et al. (GAN-Leaks, CCS 2020) go further: even when the attacker can only sample from the generator (full black-box — exactly the "publish a synthetic dataset" case), membership inference (MIA) still distinguishes whether a given real record was in the training set above chance, and gets more accurate as overfitting rises. The only thing that gives a bound is formal DP, and ε is not zero.
Training-data deduplication: deleting duplicate samples cuts memorization and extraction risk a lot — but it isn't a formal guarantee
In one sentence dedup is a high-return move that cuts memorization / extraction / membership-inference risk a lot; but it lowers frequency and probability, not a formal guarantee — a rare sample appearing once can still be memorized; for a formal guarantee, stack DP.
Training-data extraction: private data you train on, an attacker may get me to spit back verbatim
In one sentence the larger the model, the more often it was duplicated, and the more context you give, the more discoverable memorization there is.