Enclave-to-application callback across the secure hardware boundary. Manufacturer attestation chain. Per-data-category retention.
Filed · Patent pending
ABT methodology family · variant ABT-D · device-layer privacy
An app that requested your location and got a city
How a hardware enclave enforces the projection boundary at the device layer — before any data reaches the network — so that precise coordinates never leave the device.
US Provisional Patent 64/056,353 · Filed May 4, 2026 · sidratnam.com/abt/
Precise coordinates never cross the device boundary · Enclave enforces projection before network call · App receives city-level — by hardware constraint, not policy
WeatherField requests Soo-Jin Hwang's location
Soo-Jin opens WeatherField. The app requests precise location from the OS API. The request is intercepted by the ABT-D enclave before the OS location service is queried in a form accessible to the app.
Application
WeatherField
Requests: precise lat/lon
Sends to: OS location API
Receives: city-level only
location request →
ABT-D enclave
Device Enclave
Intercepts before OS resolves
Reads: precise coordinates
Produces: city projection
Raw (device internal)
37.7749° N, 122.4194° W
Enclave projection
San Francisco, CA
App receives
San Francisco, CA
The enclave is a hardware boundary, not a software policy. The projection computation occurs inside the device's secure enclave — a processor region inaccessible to the OS, the app, and any process running above the hardware layer. The app does not receive precise coordinates and then round them. It receives the city-level projection as the response to its location request. The precise coordinates never existed in a region the app can read.
Enclave intercepts the request — before any network call
The OS location API is called by the enclave, not the app. The enclave reads the precise GPS coordinates inside its hardware boundary. The app's process space is not the caller — the enclave is. The app waits for the enclave's response.
GPS hardware
Device GPS
Returns: 37.7749° N, 122.4194° W
Caller: Enclave (not App)
precise coords →
Enclave (secure)
Hardware Enclave
Reads full coordinates
Projection computed here
Process space: inaccessible
city projection →
Application
WeatherField
Receives: San Francisco, CA
Never sees raw coordinates
The data flow is: GPS → Enclave → City projection → App. Precise coordinates travel from GPS hardware to the enclave only. They are never placed in a memory region accessible to the app process. The app's perspective: it sent a location request; it received a city name. There were never any coordinates for it to log, transmit, or leak.
Projection computed inside the enclave
The enclave applies the projection function: map(lat, lon, scope=city) → city_name. The scope parameter is set by the user's privacy preference — city, neighborhood, or precise. The projection is computed in hardware and the output (city name) is passed to the app.
enclave_projection:
input: 37.7749° N, 122.4194° W (GPS hardware, enclave-only memory)
scope: city (user preference: maximum)
projection_fn: map(lat, lon, city) → "San Francisco, CA"
output: "San Francisco, CA"
raw_coords_in_app_memory: NEVER
session_nonce: enc_nonce_d7f3 (no cross-session persistence)
Location projection · session enc_nonce_d7f3
precise_lat[ enclave-only · never leaves hardware boundary ]
precise_lon[ enclave-only · never leaves hardware boundary ]
city_projectionSan Francisco, CA
scope_appliedcity · per user preference
session_nonceenc_nonce_d7f3 · per-request · no cross-session link
The session nonce prevents cross-request linkability. Each location request generates a fresh session nonce inside the enclave. WeatherField's location log shows: San Francisco, CA · enc_nonce_d7f3 for one session, San Francisco, CA · enc_nonce_8b1a for the next. The nonces are opaque to the app and cannot be linked across sessions to trace movement patterns more precisely than the city-level projection allows.
WeatherField receives the city projection — works as designed
WeatherField receives "San Francisco, CA" and renders the local weather. The app functions correctly — it needed city-level granularity for weather data, not precise coordinates. The privacy boundary cost the app nothing it needed.
Application
WeatherField
Received: "San Francisco, CA"
Weather API query: /weather?city=SF
Result: 58°F · Partly cloudy
← weather data
Weather API
weather.api.ext
Receives: city name only
Never receives: lat/lon
Cannot log precise location
The external weather API also never sees Hwang's precise location. The app queries the weather API with the city projection — not the raw coordinates. Even if the weather API is malicious, its logs contain only "San Francisco, CA." No third-party data broker who purchases weather API logs can reconstruct Hwang's precise movements.
Cross-session unlinkability — Hwang moves across the city
Hwang opens WeatherField three times during the day at different precise locations — morning in the Mission, noon in SoMa, evening in the Richmond. Each request produces a city-level projection. The app log shows three "San Francisco, CA" entries — no movement pattern.
session_log · WeatherField:
08:14 AM: San Francisco, CA · enc_nonce_d7f3 (actual: Mission District · 37.7599°N, 122.4148°W)
12:33 PM: San Francisco, CA · enc_nonce_8b1a (actual: SoMa · 37.7785°N, 122.3893°W)
06:48 PM: San Francisco, CA · enc_nonce_2c9e (actual: Richmond · 37.7793°N, 122.4637°W)
movement_inferable_from_log: NO
precise_coordinates_in_log: NONE
cross_session_link: enc_nonces are opaque and per-request · not derivable to common root without enclave
Three sessions, one city, no movement trace. A data broker, law enforcement subpoena, or API log compelled in civil discovery shows three location requests returning "San Francisco, CA." The precise movements — Mission to SoMa to Richmond — are not in any external record. They exist only in the enclave's transient compute context, which is cleared at the end of each session.
Privacy by design — enforced at the hardware layer
ABT-D is not a privacy policy commitment. It is a hardware-enforced projection that operates before data leaves the secure enclave. The architectural properties are enumerated.
enforcement_layerhardware enclave · not OS policy · not app policy
registry_witnessprojection events logged without coordinates · hash-chained
The user can choose their own scope. If Hwang grants a food delivery app neighborhood-level access, the enclave produces a neighborhood projection. If she grants a navigation app precise access for turn-by-turn directions, the enclave passes the precise coordinates within the app's session scope. Scope is a user preference enforced at the hardware level — not a permission granted at install time and ignored thereafter.