​

Privacy

Privacy is a core design goal for Astral — but almost all of it is ahead of us, not behind us. The current hosted service does not run in a TEE and does no input encryption: it receives inputs as plaintext, and signed results can carry those inputs back in plaintext (see below). So Astral does not provide input or output privacy today. (Astral has run the service on real TEE hardware in test deployments — which isolates process memory from the host operator — but does not operate one continuously, and a TEE on its own would not add the privacy affordances below.) Private inputs and private/shielded outputs are on our near-term development roadmap; continuous attested operation and zero-knowledge approaches are the directions we’re pursuing. See the trust model for current deployment status.

​

What the TEE does and doesn’t protect

A TEE provides one specific thing: process isolation. Running the service inside an attested enclave would stop the host operator from inspecting the running process’s memory. That’s real, but narrow — on its own it would not encrypt your inputs end-to-end (there is no client-to-enclave encryption in the design; inputs arrive as plaintext), stop the service from returning your inputs in the response, or hide the reference geometry and evaluation function. Those need the privacy affordances we’re designing, not just a TEE. What an attested deployment is intended to keep from the host operator (a goal, not a guarantee today): raw input coordinates, exact geometries, and location stamp signals would live only in enclave memory during computation. What the service returns today: the signed result (a boolean, numeric value, or credibility vector), the operation type, and input references (inputRefs — hashes or UIDs). The service is stateless and does not persist or log raw inputs — but “not persisted” is not the same as “private.” However, in v0 the signed results do include input data in plaintext. Compute results can carry the full location claim and credibility vector via 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. They’re on our near-term development roadmap — 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/within check 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.

The output-stripping piece is tracked in astral-location-services#57; the broader design is collected in astral-location-services#65. If any of this matters to you, get in touch.

​

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: More specific operations leak more. A 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. The hard part isn’t only the geometry. ZK computational geometry circuits — polygon containment, distance — are expensive but tractable; zkMaps, a project Astral has supported, has done some benchmarking here. But ZK geometry on its own isn’t very useful: a location proof’s value comes from evaluating evidence, not from computing a bare predicate. The frontier we care about is ZK evaluation functions combined with ZK computational geometry — proving privately that a credible body of evidence supports a claim. That’s research, not a current capability.

​

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).

---

See also:

• Trust model — what’s verified vs. what you’re trusting
• Astral Location Services — TEE architecture details