Privacy-Preserving Computation and Measurement
In Part 1, we covered how organizations protect data internally — minimization, anonymization, query controls, and differential privacy. In Part 2, we explored secure collaboration — clean rooms, identity mapping, purpose limitation, and hardware enclaves.
Part 3 covers the final frontier: how to perform computation across parties without revealing inputs, how to train ML models on sensitive data, and how measurement techniques like sales lift and entropy balancing operate within privacy constraints.
The Computation Problem
Sometimes you need to compute something jointly with another party, but neither side wants to reveal their raw data — not even to a clean room operator or cloud provider.
Consider: Two hospitals want to train a cancer detection model on their combined patient data. Neither can share patient records with the other (HIPAA). Neither trusts a third party to see the combined data.
How do you train a model on data that no single party can see? This is where Multi-Party Computation and privacy-preserving ML techniques come in.
1. Multi-Party Computation (MPC)
Joint Computation Without Sharing Inputs: MPC allows multiple parties to compute a function over their combined inputs without any party seeing the other’s data.
Mental Model: The Millionaire’s Problem Two millionaires want to know who is richer without revealing their actual net worth to each other. They can’t trust a third party, and neither wants to disclose their number.
MPC solves this: through a cryptographic protocol, both parties contribute their encrypted inputs, computation happens on the encrypted data, and only the final answer (“Alice is richer”) is revealed. Neither learns the other’s actual number.
How It Works
The cryptographic details are complex, but the intuition is:
- Each party “secret shares” their input — splits it into pieces that are meaningless alone.
- Computation happens on the shares through carefully designed protocols.
- Only the final result can be reconstructed.
- No intermediate values reveal individual inputs.
Plaintext
Party A has: salary_A = $150,000
Party B has: salary_B = $180,000
Step 1: Each party splits their value into secret shares
Step 2: Parties exchange shares and compute on them
Step 3: Final result reconstructed: "B > A"
Result: Neither party learns the other's actual salary.
Reality Check: MPC as a Concept vs. Implementation
Pure cryptographic MPC (like Yao’s Garbled Circuits) is theoretically beautiful but often extremely slow in practice (think 100X or 1000X slower). In the real world, MPC is frequently implemented using:
- Data Clean Rooms (governance + restricted queries)
- TEEs / CVMs (hardware isolation)
- Hybrid approaches (combining cryptography with trusted hardware)
Think of it this way:
- MPC = the goal (compute without revealing inputs).
- DCR + TEE = common execution fabrics that achieve MPC-like properties.
Where It’s Used Private set intersection (do our customer lists overlap?), joint analytics across competitors, secure auctions, collaborative fraud detection.
Trade-offs
- Slow: Cryptographic protocols have significant overhead.
- Complex: Requires specialized expertise to implement correctly.
- Hard to debug: You can’t inspect intermediate values.
- Overhead: Parties must exchange many messages.
2. PATE: Privacy-Preserving Machine Learning
Training ML on Sensitive Data: Training ML models on sensitive data is risky — models can memorize and leak individual records. PATE (Private Aggregation of Teacher Ensembles) is a technique for training models on sensitive data while providing differential privacy guarantees.
Mental Model: The Panel of Experts Imagine you want to build a medical diagnosis system, but patient data is too sensitive to use directly. Instead:
- You split the sensitive data into separate chunks.
- Train a separate “teacher” model on each chunk (each teacher only sees its own patients).
- When you need a prediction, ask all teachers to vote.
- Add noise to the vote counts (differential privacy).
- A “student” model learns from these noisy aggregated votes — never seeing the original data.
The student model ends up useful for diagnosis but has never directly touched any patient record.
How It Works
Plaintext
Sensitive Data (e.g., patient records)
|
v
+-------+-------+-------+
| | | |
v v v v
Teacher Teacher Teacher Teacher
1 2 3 4
(trained on disjoint data subsets)
|
v
Query: "Is this X-ray cancerous?"
|
v
+---------------------------+
| Teacher 1 votes: Yes |
| Teacher 2 votes: Yes |
| Teacher 3 votes: No |
| Teacher 4 votes: Yes |
+---------------------------+
|
v
Noisy aggregation: 3 Yes + noise → "Yes"
|
v
Student model learns from noisy labels
(never sees original patient data)
Why This Provides Privacy
- Each teacher only sees a subset of data — no single model has full access.
- The aggregation adds noise — individual teacher votes are obscured.
- The student learns from noisy consensus — even if you inspect the student, you can’t extract individual records.
Where It’s Used Healthcare ML (diagnosis models), behavioral prediction on sensitive user data.
Trade-offs
- Complex Pipelines: Managing multiple teachers, aggregation, student training.
- Accuracy Loss: Noise in aggregation reduces model quality.
- Heavy Compute: Training many teachers is expensive.
- Data Requirements: Requires enough data to split meaningfully across teachers.
Related Area: Measurement Techniques
The following two techniques — Sales Lift and Entropy Balancing — are not PETs themselves. But they often operate inside clean rooms to justify the privacy infrastructure.
3. Sales Lift / Incrementality
Measuring Causal Ad Impact: When an advertiser runs a campaign, they want to know: did the ads actually cause more sales, or would those sales have happened anyway?
Mental Model: The Parallel Universe Problem Ideally, you’d want to see two parallel universes:
- Universe A: Customer sees the ad, buys the product.
- Universe B: Same customer doesn’t see the ad — do they still buy?
The difference between universes = the ad’s true causal impact. Since we can’t access parallel universes, we approximate with randomized experiments.
How It Works
Plaintext
All eligible users
|
+------+------+
| |
v v
Test Group Control Group
(sees ads) (no ads)
| |
v v
Measure: Measure:
conversions conversions
revenue revenue
Incrementality = Test - Control
Sales Lift = Revenue(Test) - Revenue(Control)
- Incrementality: Extra conversions caused by the ad.
- Sales Lift: Monetized incrementality (revenue impact).
Privacy Connection Sales lift studies increasingly happen inside clean rooms. The retailer has purchase data, the advertiser has exposure data. They need to measure lift without sharing raw user data — which is why DCRs, DP, and query anonymization matter for measurement.
4. Entropy Balancing
Fixing Imperfect Experiments: What if you couldn’t randomize perfectly? What if your test and control groups ended up with different characteristics (age, geography, etc.)?
Entropy balancing is a statistical technique to make an imperfect control group “look like” the test group. A simple (but inaccurate) intuition here is that Entropy Balancing is effectively trying to find a doppelganger of each user — who has not been exposed to the test experience (like a specific ad).
Mental Model: Reweighting the Jury Imagine you’re conducting a trial and need a jury that represents the population. But your jury pool skews older and more suburban than the defendant’s peers.
You can’t replace jurors, but you can give more weight to the younger, urban jurors’ opinions so the overall jury “acts like” a representative sample.
How It Works Entropy balancing does this mathematically:
- You have a test group with certain feature distributions.
- Your control group has different distributions.
- You reweight control group members so their weighted distributions match the test group.
Plaintext
Test group distribution:
Age 18-34: 40%
Age 55+: 25%
Control group (raw):
Age 18-34: 25% (underrepresented)
Age 55+: 35% (overrepresented)
After entropy balancing (reweighted):
Age 18-34: 40% ← younger users weighted higher
Age 55+: 25% ← older users weighted lower
Privacy Connection Entropy balancing operates on aggregate distributions, not individual records. This makes it naturally compatible with privacy constraints — you can balance on aggregated feature distributions inside a clean room without exposing individual user data.
How These Fit Into the Privacy Lifecycle
Recall the data lifecycle from Parts 1 and 2:
- At collection → Data minimization, purpose limitation
- At rest → Storage anonymization, encryption
- In transit → TLS, Diffie-Hellman, AES
- In use / compute → TEE, CVM, MPC, DCR
- At output → Query anonymization, DP
- In measurement → Sales Lift, Entropy Balancing (Part 3)
- In ML → PATE (Part 3)
- Across partners → Crosswalks, Clean Rooms
MPC and PATE are true PETs — they enable computation and ML training while preserving privacy. Sales Lift and Entropy Balancing are measurement techniques that operate within the privacy infrastructure built by PETs.
Choosing the Right Approach
| Scenario | Techniques |
| Joint computation, no trusted third party | MPC (or DCR + TEE as implementation) |
| ML training on sensitive data | PATE + DP |
| Measuring ad effectiveness with retailer | Sales Lift inside DCR with DP |
| Correcting for imperfect test/control split | Entropy Balancing on aggregates |
| Private set intersection across partners | MPC or cryptographic PSI protocols |
Export to Sheets
Common Misconceptions
- ❌ “MPC is too slow to be practical.”
- Pure cryptographic MPC can be slow, but hybrid approaches (DCR + TEE) achieve MPC-like goals with practical performance.
- ❌ “Sales lift proves ads work.”
- Sales lift measures correlation under controlled conditions. It’s the best we have, but external factors can still confound results.
- ❌ “Entropy balancing fixes bad experiments.”
- It helps, but it can’t fix fundamental problems. If test and control groups differ on unmeasured variables, reweighting won’t eliminate bias.
- ❌ “PATE means we can train on anything.”
- Privacy and utility remain in tension. For small datasets or complex tasks, the noise required for privacy may make the model useless.
Final Thought
Part 3 completes the PETs picture:
- MPC: Compute jointly without revealing inputs (the theoretical ideal).
- PATE: Train ML models on sensitive data with guarantees.
- Sales Lift: Measure causal impact within privacy infrastructure.
- Entropy Balancing: Correct for imperfect experiments by reweighting distributions.
The key insight across all three parts: Privacy isn’t a single technology — it’s a layered system.
The art of privacy engineering is choosing the right combination — understanding what each technique protects, what it doesn’t, and where residual risks remain. No silver bullets, but a well-stocked toolkit for building systems that extract value from data while genuinely protecting the individuals behind it.
