Start Here

Privacy-enhancing technologies are not interchangeable. They protect different parts of a system, assume different adversaries, and create different tradeoffs.

Use this section to build a working vocabulary before choosing a PET. The goal is not to memorize families; it is to avoid the common mistake of choosing a tool before naming the output, adversary, and failure mode.

The Short Version

PET	Best fit	Watch out for	Go deeper
Federated learning	Training across data silos without centralizing raw data	Gradients and model updates can still leak information	Cross-silo FL
Differential privacy	Limiting what can be learned about one person or record from an output	Utility loss and accounting complexity	DP taxonomy
Secure multiparty computation	Joint computation across parties that do not reveal inputs	Cost, coordination, and protocol complexity	MPC analytics
Homomorphic encryption	Computing on encrypted data	High cost and narrow workload fit	Private inference
Trusted execution environments	Isolating computation in hardware-protected runtimes	Hardware trust, side channels, and attestation usability	Confidential RAG
Private set intersection	Finding overlap between datasets without exposing nonmatches	Output leakage and repeated-query risk	PSI pattern
Synthetic data	Sharing generated data instead of raw data	Memorization, weak privacy claims, and utility drift	Synthetic release pipeline
Data clean rooms	Controlled collaboration over governed datasets	Governance does not automatically equal cryptographic privacy	Deployments
Zero-knowledge proofs	Proving a statement without revealing the witness	Circuit cost and proving-system expertise	Glossary

How To Read This Guide

Start with the problem, not the PET. Ask:

• Who owns the data?
• What output is needed?
• Who must not learn what?
• What adversary is in scope?
• What latency, cost, and accuracy constraints are acceptable?

Then use PET Compass to choose candidates and PET Patterns to design a system.

Before You Pick A PET

Write these four lines before opening a vendor page or benchmark paper:

Line	Example
Protected asset	Raw patient records, nonmatching customer IDs, private prompts, site-level model updates
Adversary	Curious coordinator, malicious participant, cloud operator, downstream analyst, public data recipient
Allowed output	Aggregate count, trained model, match list, encrypted prediction, synthetic table
Reversal condition	Latency above the product budget, subgroup utility below baseline, cohort size under threshold, unverifiable attestation

If one line is vague, the PET shortlist will be vague too. Tighten the claim first.

Common Wrong Assumptions

Assumption	Better framing
"Data stayed local, so it is private."	Updates, metrics, models, logs, and outputs can still leak.
"Synthetic data is anonymous."	Synthetic data can memorize or reproduce rare records unless tested and governed.
"A TEE means the whole system is confidential."	Attestation, side channels, logs, code, and outputs still matter.
"HE is the strongest choice, so use it."	HE is useful only when the workload fits its operator, latency, and cost constraints.
"DP is just adding noise."	DP requires a privacy unit, sensitivity, mechanism, accounting, and release policy.
"A clean room is a PET guarantee."	Clean rooms are governed workflows; privacy depends on controls and outputs.
"The strongest PET is the safest choice."	A PET that protects the wrong artifact can add cost while leaving the actual leakage path open.

First Decision Path

If your problem is...	Start with...
Choosing a PET	Choose a PET
Explaining terms	Glossary
Comparing PET families	PET taxonomy
Designing a system	PET architectures
Finding failure modes	Threat models
Measuring a candidate	Benchmarks