Research Preview — APIs may change. GitHub
Privacy
Privacy is a core design goal for Astral — but much of it is ahead of us, not behind us. Today, a TEE running under attestation keeps input data from the operator during computation. It does not yet make inputs or outputs private from whoever receives a result — signed results can still carry their inputs in plaintext (see below). Private inputs and private/shielded outputs are affordances we’re actively designing; zero-knowledge approaches are a research direction. This page describes what holds today and where we’re headed. (The properties that depend on the TEE assume the enclave runs under continuous remote attestation — see the trust model for current deployment status.)TEE Privacy Guarantees
When running under attestation, the Trusted Execution Environment processes location data inside hardware-isolated memory that the operator is not able to inspect: What stays private:- Raw input coordinates — the exact lat/lng values submitted
- Exact geometries — polygon boundaries, line paths, and other spatial data used in computation
- Location stamp signals — the raw evidence data from proof-of-location systems
- The signed result — a boolean, numeric value, or credibility vector
- The operation type — which computation was performed
- Input references — hashes of the inputs, not the raw data itself
proofInputs, and verified location proofs include the original proof with all stamps and claim data. This means anyone who receives a signed result can see the raw location inputs.
Privacy modes we’re designing
To be clear: Astral does not offer private inputs or private outputs as features today. These are the affordances we’re scoping — the design feels feasible on this architecture, and we’d welcome input from anyone who needs them:- Private input coordinates — encrypted lat/lng, decrypted only inside the enclave and never echoed in the result.
- Private reference geometries — keep the comparison geometry (a geofence or boundary) hidden, so a
contains/withincheck doesn’t reveal it. - Private evaluation functions — keep a verifier’s evaluation/weighting logic confidential.
- Shielded outputs — return a policy decision (trigger / don’t trigger) carrying no identifying detail about who or where.
- Encrypted outputs — results encrypted so only a specified counterparty can read them.
Information Leakage From Results
The result itself may reveal information about the inputs. This is inherent to the computation, not a limitation of the privacy model:| Operation | What the result reveals |
|---|---|
contains (true) | The point is somewhere inside the polygon |
within (true, 500m) | The point is within 500m of the target |
distance (exact value) | The precise distance between two geometries |
contains check against a country-sized polygon reveals less than a within check with a 10-meter radius.
Spatial and Temporal Uncertainty as Privacy Tools
The uncertainty tradeoff in location claims has a privacy dimension. Broader spatial bounds (larger radius) and wider temporal bounds reveal less about exact location and timing. Applications that want to preserve user privacy can intentionally use coarser claims — “was this user in San Francisco sometime today?” rather than “was this user within 5m 37.7749°N 122.4194°W at 14:32:07?” This isn’t a hack — it’s a principled privacy-preserving approach. If the application only needs to know “roughly where, roughly when,” there’s no reason to collect or process exact coordinates.ZK Location Proofs (Research)
Zero-knowledge proofs would allow verification of location claims without revealing the underlying location data to anyone — including the verifier. A ZK location proof could prove “I was inside this boundary” without revealing where inside the boundary, or even what the boundary was.| Property | TEE (today) | ZK (future) |
|---|---|---|
| Raw inputs hidden from operator | Yes (under attestation) | Yes |
| Raw inputs hidden from verifier | No | Yes |
| No trusted hardware required | No | Yes |
| Verification without re-execution | No | Yes |
| Maturity | Research Preview (test TEE deployments) | Not yet — active research |
TEE Limitations
The TEE provides strong but not absolute privacy:- Hardware trust — You are trusting that the TEE hardware (Intel SGX / AMD SEV) correctly isolates the enclave. Side-channel attacks on TEEs are an active area of security research.
- Result leakage — As described above, the result itself carries information about the inputs.
- Input reference hashes — Hashed input references are visible. If an observer knows the possible input space, they could attempt to match hashes (though this is computationally expensive for arbitrary geometries).
Next: Guides
Walk through common workflows step by step
See also:
- Trust model — what’s verified vs. what you’re trusting
- Astral Location Services — TEE architecture details