After studying this material, you should be able to:

1. Explain what Federated Learning (FL) is and why it was developed
2. Identify the four core privacy principles guiding FL development
3. Describe how Trusted Execution Environments (TEEs) improve FL systems
4. Compare old FL systems vs. the new TEE-based FL system
5. Understand the practical benefits achieved through the new system

---

Step-by-Step Teaching

Step 1: The Problem — Why Does Federated Learning Exist?

The Core Challenge

Traditional machine learning requires collecting all user data in one central location to train models. This creates serious privacy risks.

Example:

Traditional ML:
Your phone data → Google's servers → Model trained on raw data
❌ Google sees everything you type

The Solution: Federated Learning (2017)

Instead of sending raw data to a server, the model travels to your device, trains locally, and only sends back model updates (not your data).

Federated Learning:
Model → Your phone → Trains locally → Sends only updates back
✅ Raw data never leaves your device

Real-world uses:

• Next-word prediction on Gboard
• Smart Compose
• Reply suggestions in Google Messages
• Smart Text Selection on Android

---

Step 2: The Four Privacy Principles

Think of these as the rulebook for building trustworthy FL systems:

🔑 Key Insight: Earlier FL systems satisfied the first three principles reasonably well, but verifiability remained a major gap.

---

Step 3: The Remaining Problem — Trust

What Was Still Missing?

Even with early FL, a critical question remained unanswered:

"How do we PROVE the server is doing what it claims?"

The trust gap looked like this:

Early FL System:
Device sends update → Server processes it → "Trust us, we added noise correctly"
                                              ❌ No external verification possible

Two partial solutions existed but had limitations:

---

Step 4: The New Solution — Trusted Execution Environments (TEEs)

What Is a TEE?

A TEE is a secure, isolated computing environment within a processor. Think of it as a locked room inside a computer where:

TEE Properties:
┌─────────────────────────────────────┐
│  🔒 CONFIDENTIALITY                 │
│     Internal state cannot be seen   │
│                                     │
│  🛡️ INTEGRITY                       │
│     Logic cannot be tampered with   │
│                                     │
│  🔍 REMOTE ATTESTATION              │
│     Third parties can verify what   │
│     code is actually running        │
└─────────────────────────────────────┘

Simple Analogy:

A TEE is like a notarized, glass-walled vault — outsiders can verify what's inside and what rules govern it, but cannot interfere with or secretly observe the contents.

---

Step 5: How the New TEE-Based FL System Works

The Four Core Operational Concepts

FLOW OF DATA THROUGH THE SYSTEM:

1. DEVICE UPLOADS
   📱 Device encrypts training data
   📤 Uploads to server
   ⏱️ Data only accessible for limited time

2. ACCESS POLICIES
   📋 Published to Rekor (public transparency log)
   👁️ External auditors can inspect them
   📌 Describes EXACTLY which programs can access data

3. TEE PROCESSING
   🔐 Encrypted data decrypted ONLY inside TEE
   🐍 Python training programs run inside TEE
   🚫 Server operators cannot see raw data

4. OUTPUT
   📊 Only differentially private model weights released
   📈 Only aggregate metrics visible to operators

Differential Privacy (DP) — A Quick Explanation

Differential privacy adds carefully calibrated mathematical noise to results, so individual contributions cannot be identified.

Without DP:  Model update reveals "User typed X"  ❌
With DP:     Model update + noise = individual unidentifiable ✅

---

Step 6: Verifiability — The Key Breakthrough

How Verification Now Works

OLD SYSTEM:
"We promise we added the right noise"
→ No way to check ❌

NEW SYSTEM:
Access policy published publicly → TEE runs exactly that code
→ Anyone can verify ✅

The Rekor Transparency Log

Rekor is a public, append-only log (like a public bulletin board that cannot be erased).

• Devices check Rekor before uploading data
• They see exactly which server programs could access their data
• External auditors monitor Rekor continuously

🔑 Key Insight: This shifts the system from "trust us" to "verify us"

Handling Proprietary Code

Some model architectures are trade secrets. The system handles this through sideloading:

Python Program (public, in access policy)
    +
Serialized proprietary data (loaded at runtime)
    =
Privacy logic remains verifiable ✅
Proprietary architecture remains protected ✅

---

Step 7: Practical Improvements — Real Results

Improvement 1: Better Privacy AND Better Accuracy

By collecting all device uploads first, then running training:

Old approach:
Train → Wait for devices → Train → Wait → (diurnal variations cause problems)

New approach:
Collect all uploads → Calculate optimal participation schedule → Train once
✅ Better DP parameters possible
✅ Smaller noise multipliers = better accuracy

Improvement 2: Dramatically Faster Training

Improvement 3: Larger Models Possible

Old system:
Gradient computation on device → Limited by phone hardware
                                  ❌ Can't train large models

New system:
Gradient computation on server TEE → Powerful server hardware
                                      ✅ Path to larger models

---

Step 8: Putting It All Together

System Comparison Summary

EVOLUTION OF FEDERATED LEARNING:

2017 — Basic FL
├── ✅ Data stays on device
├── ❌ Server logic unverifiable
└── ❌ Must trust server operator

~2020 — Secure Aggregation
├── ✅ Cryptographic upload protection
├── ❌ Incompatible with best DP guarantees
└── ❌ Still requires trust

2026 — TEE-Based FL (New)
├── ✅ Fully verifiable via remote attestation
├── ✅ Compatible with state-of-the-art DP
├── ✅ Public transparency log (Rekor)
├── ✅ Open source, reproducibly buildable
└── ✅ Faster training, larger models possible

---

Step 9: Future Directions

The article hints at where this is heading:

---

Quick Knowledge Check

Test yourself with these questions:

1. What problem does Federated Learning solve compared to traditional ML?
2. Name the four privacy principles guiding FL development.
3. What three properties do TEEs provide?
4. Why is Rekor important to the new system?
5. How does the new system achieve both proprietary code protection AND verifiability?
6. What caused 1–2 month training times in old FL systems, and how does the new system fix this?

---

💡 Core Takeaway: The new TEE-based FL system represents a fundamental shift from privacy by policy ("trust us") to privacy by architecture ("verify us") — making strong privacy guarantees mathematically provable and externally auditable for the first time.