Skip to content

I ❤️ PETs

A practical field guide to Privacy-Enhancing Technologies.

Find Your Path

  • I need to choose a PET

    You have a real system and a privacy constraint. Start with the guided chooser.

    Choose a PET

  • I need to design an architecture

    You know your PET candidate and need actors, data flows, and trust boundaries.

    PET Architectures

  • I need to evaluate a claim

    A vendor or paper makes a privacy claim. Check it against the evidence policy and the claim register.

    Evidence Policy  ·  Claim Register

  • I need a research problem

    You want a concrete open problem with success criteria and a first contribution.

    Fix My Itch

  • I need evidence from deployments

    You want deployment maturity, source quality, and lessons from real production use.

    Deployments

  • I need a worked decision

    You want to see a PET choice made under realistic constraints before you copy the pattern.

    Worked Decisions

  • I need to evaluate a PET tool

    You want to know whether a library or platform fits a threat model, architecture, and first benchmark.

    Tool Reviews

Not sure where to start? Read the guided reader paths.

This Is Not Another Awesome List

Existing repositories catalog papers and tools. This site is for the moment after someone asks, "What should we actually build, buy, evaluate, or research?"

I ❤️ PETs focuses on:

  • choosing the right PET for a constraint, not a buzzword;
  • drawing architectures with explicit trust boundaries;
  • spotting privacy claims that are missing a threat model;
  • turning vague "future work" into concrete research problems;
  • learning from deployments without pretending every pilot is production.

How To Use This Site

Use the site as a field guide, not a textbook.

If you need to... Start with... You should leave with...
Pick a PET for a real system PET Compass A primary candidate, likely supporting PETs, and reasons to reject the wrong options
Explain how a PET design works PET Architectures Actors, data flows, trust boundaries, assumptions, and failure modes
Compare recurring designs PET Patterns When to use a pattern, when not to use it, and what to measure
See a decision worked through end to end Worked Decisions A recommended PET stack, what can go wrong, what to measure, and when the choice changes
Check whether a privacy claim is credible Threat Models The adversary, the protected asset, and what the PET does not protect
Evaluate a tool or platform Tool Reviews Fit, evidence level, operational risks, first benchmark, and when not to use it
Exercise a benchmark scorecard Benchmark Example Runs A hypothetical workload, scorecard fields, failure modes, and measurement plan
Find a useful research problem Fix My Itch A concrete problem, current workaround, success criteria, and a first contribution
Judge whether a deployment claim is meaningful Deployments Deployment maturity, source quality, lessons, and unresolved caveats

Opinionated Defaults

  • Federated learning does not provide privacy by itself.
  • Synthetic data is not automatically safe to release.
  • TEEs reduce exposure but add hardware, attestation, and side-channel assumptions.
  • Homomorphic encryption protects data during computation but is constrained by latency, operators, and model design.
  • MPC can be powerful, but many teams underestimate protocol, identity, and operations work.
  • Differential privacy is the clearest formal privacy tool, but the utility cost and budget accounting must be measured.

Main Sections

  • Start Here: shared vocabulary and taxonomy.
  • PET Compass: decision support by data movement, threat model, and ML task.
  • Worked Decisions: end-to-end PET choices for common scenarios.
  • PET Patterns: reusable designs such as federated analytics, private inference, and private RAG.
  • Use Cases: domain constraints in healthcare, finance, advertising, public sector, and AI.
  • Benchmarks: how to measure privacy, utility, cost, latency, scalability, and developer effort.
  • Tool Reviews: tool evaluations tied to concrete architectures, threat models, and first benchmarks.
  • Contributing: quality bar for improving the guide.