Differential privacy (DP)
To safely export aggregate telemetry without leaking user data, the system must structurally prevent opaque isolates from using high-cardinality metrics as a covert exfiltration channel. The current approach relies on a strict allowlisting mechanism for metric names and attributes, which inherently limits the flexibility and depth of observability available to developers.
Differential privacy (DP) integration is a future enhancement designed to allow the safe egress of high-utility, diverse aggregate data without relying on rigid allowlists. The proposed process follows a specific sequence:
- Ingestion: The opaque isolate generates raw telemetry metrics during request processing.
- Interception: The EZ enforcer (or a designated ratified isolate) intercepts the outbound metrics stream before it crosses the TEE boundary.
- Noise perturbation: The system mathematically injects controlled, calibrated noise into the aggregate dataset.
- Egress: The perturbed metrics are safely declassified to
PUBLICand exported to the host's logging infrastructure.
This mechanism ensures that the presence or absence of any single user's data cannot be inferred from the exported metrics, providing a mathematical guarantee of privacy. This advancement will allow EZ to support complex, dynamic observability for proprietary workloads while fully mitigating the risk of covert data exfiltration.
Ecosystem alignment: Project Oak
Encrypted Zone shares foundational goals with Project Oak, Google's open-source framework for verifiable confidential computing. We currently use Oak's verification libraries and are actively collaborating to align our attestation primitives...
Fast state resets
To fully isolate request data between different users within the malicious
operator threat model, the system must either rely on audited open-source code
paths or structurally prevent opaque isolates from entering a
MULTI_USER_PRIVATE data scope. The latter approach traditionally requires
restarting the opaque isolate after each request to ensure a clean memory
state, which introduces significant latency and overhead.
"Fast state reset" is a high-performance alternative designed to mitigate cross-user data egress risks without the overhead of full container restarts. The process follows a specific sequence:
- Initialization: The opaque isolate boots to a "ready" state before receiving traffic.
- Check-pointing: The enforcer snapshots the clean in-memory state and marks the memory as copy-on-write.
- Execution: The isolate processes a single user request.
- Restoration: The enforcer flushes all modified memory pages, restoring the isolate to the exact state captured in Step 2.
- Recycle: The isolate is immediately ready for the next request.
This mechanism allows EZ to efficiently serialize user requests through a single process with minimal delay. High performance scaling is achieved by maintaining a small pool of these reset-capable isolates to handle parallel traffic.