ABT-D — Device Privacy & Location Tokenization

An app requested your location and got a city. Hardware enclave enforces the projection boundary before any data reaches the network. Precise coordinates never leave the device.

Protocol overview  ·  Whitepaper  ·  Counsel version  ·  Patent Pending · US Prov. 64/056,353  ·  Filed May 4 2026
ABT-D
Device
Enclave-to-application callback across the secure hardware boundary. Manufacturer attestation chain. Per-data-category retention.
Filed · Patent pending
The scenario

What ABT-D does

A weather app requests location. Before the coordinate ever reaches the network stack, the device's hardware security enclave intercepts it and applies a precision projection: 37.7749° N, 122.4194° W becomes "San Francisco."

The app receives the city. The enclave boundary is enforced in hardware — the application layer cannot override it, cannot inspect what happened behind it, and cannot receive a higher-precision coordinate by requesting again. The precise coordinate exists only inside the enclave and is never passed to the application.

Restaurant finders, transit apps, local news feeds, emergency services — all receive city-level precision. Stalking requires precise coordinates. A city name does not enable it.

How it works

Three structural properties

01
Hardware enclave projection
The precision reduction from GPS coordinates to city-level occurs inside the device's hardware security enclave before the data reaches any software layer. Software cannot bypass or inspect this boundary.
02
Pre-network precision reduction
The projected coordinate — not the original — is what enters the network stack. Precise coordinates are never transmitted, never logged by network infrastructure, never available to backend systems.
03
Application-layer isolation
The application receives only the projected result. It has no visibility into the original coordinate, the projection algorithm, or the hardware boundary. Multiple requests return the same projection, not additional precision.
Applications

Where ABT-D applies

Weather apps, restaurant finders, transit routing, local news, social check-ins, emergency services dispatch — any application that uses approximate location without requiring surveillance-grade coordinate precision.

Weather appsTransit routingRestaurant discoveryEmergency services

Technical primitives

ABT-D uses Ed25519 digital signatures for authentication of every event at every party. Per-event symmetric keys are derived via HKDF with the event identifier as salt and held in hardware-backed secure storage (Apple iOS Keychain, Android Keystore, or equivalent platform secure-storage). Envelope encryption is performed at the first-party endpoint before any ciphertext leaves the device or origin. Each tier authority’s ciphertext contains only that tier’s authored projection — information not relevant to a tier authority is authored out before encryption, not redacted after. The registry maintains a hash-chained log where each entry’s hash includes the prior entry’s hash, providing tamper-evident integrity across the chain. Forward-only tier activation: registration of a new tier authority causes inclusion of an active tier layer in subsequent envelopes only. Existing envelopes are not retroactively modified. Cryptographic boundary at the first party. Plaintext never moves. Per-tier projection authored at envelope construction. Registry-routed restoration requires structural participation by all three parties.

Who this is for

Cryptography researchers studying envelope encryption, tier-bounded ciphertext, deterministic key derivation, and signed receipt chains in device-layer privacy and app permissions.

Privacy researchers studying architectural privacy enforcement, unlinkability, purpose limitation, retention through cessation, and consumer-controlled key custody.

Consumer protection advocates seeking architectural alternatives to policy-based privacy enforcement. Cryptographic structural enforcement, not vendor trust.

Policy researchers examining cryptographic enforcement of storage limitation (GDPR Article 5(1)(e)), data minimization (GDPR Article 5(1)(c)), and consumer protection requirements.

Mobile security researchers studying secure enclave architectures, hardware-backed key storage (iOS Secure Enclave, Android StrongBox, TPM, ARM TrustZone), app permission models, manufacturer attestation chains, enclave-to-application callback boundaries, and per-data-category retention enforced at the hardware layer.

Read the full walkthrough → Counsel version Protocol overview