Access Is Not Egress: Precision-Bounded Location Release

Introduction Consider an assistant asked to find nearby pharmacies, or a weather application asked for a local forecast. The device already has a high-accuracy coordinate. The external service does not need that coordinate. City or region is sufficient. Under ordinary permission models the application that may read exact GPS is also, in practice, the component that may transmit it — including through an SDK, agent tool call, telemetry path, or cloud sync that the user never saw as a separate disclosure. This document treats the outbound release as the consequence that must be authorized. Local access may remain. Exact coordinates remain non-effective for external disclosure until purpose, recipient, destination, jurisdiction, precision ceiling, policy epoch, and sink binding have been verified. If exact precision is unnecessary, the Protected Enforcement Domain issues authority only for a coarser representation. If the application later places exact latitude and longitude on the wire, the egress Finality Sink detects a precision mismatch and the release stays non-effective. The profile uses the two-boundary execution-finality chain defined for AI-native network control in and discussed for general AI interoperability in : Candidate Act, Non-Effective State, Protected Enforcement Domain, protected validation evidence, scoped non-bearer finality authority, and independent Finality Sink verification. This document specifies only the location- and data-egress predicates, the precision ladder, cumulative-disclosure handling, and the JSON objects for that profile.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Failure to establish current finality authority MUST NOT be converted into permission to release protected location or other sensitive data.

Terminology

Location-Release Candidate Act: A Candidate Act whose intended consequence is external disclosure of location or a location-derived signal, including exact coordinates, a mobility trace, proximity, or sensor-derived location.
Available precision: The finest representation the local environment currently holds. Available precision MUST NOT by itself authorize release at that precision.
Authorized precision: The coarsest-or-equal representation permitted to become externally effective for a particular act. The Finality Sink MUST treat authorized precision as a ceiling on the outbound payload.
Precision transformation: A PED-directed reduction of available data to the authorized representation before or at the sink, for example city label, grid cell, shortened geohash, delay, or randomization.
Egress Finality Sink: The first boundary at which the location representation would leave the protected environment. Depending on deployment this MAY be an OS data broker, network egress filter, browser upload control, API gateway, enterprise agent, or equivalent. A component is a sink only if the release is technically non-completable without successful verification.
Cumulative disclosure state: Protected state describing prior releases in a policy window, used to decide whether another individually acceptable release would create an unauthorized movement history or equivalent exposure.

Candidate Act, Non-Effective State, Protected Enforcement Domain (PED), Protected Validation Evidence, scoped non-bearer finality authority, and Finality Sink are used as in .

Problem Scope Mobile operating systems commonly frame location as an application permission: may application A read the user's location. The release question is narrower and later. May application A, or one of its SDKs, agents, analytics components, tools, or external processors, emit this precision to recipient B, for purpose C, in jurisdiction D, at time E, given prior releases F. Those questions are not equivalent. An application can have a legitimate local need for a precise fix — navigation, E911, on-device geofencing — while no external weather, advertising, or model-inference endpoint has a corresponding need. ENISA mobile-privacy guidance already states that an application should not store an exact location point where a generic area is sufficient . European data-protection guidance treats the same idea as data minimisation and protection by default . Aggregation changes the risk further. Individually ordinary coordinates, timestamps, and routes can reveal workplaces, routines, relationships, or activity around sensitive sites once correlated at machine scale. Publicly reported fitness-tracking heatmaps around military installations illustrated that user permission for a benign purpose did not eliminate the downstream intelligence consequence . This document does not treat that class of harm as a reason to ban location. It treats it as a reason not to make the finest available representation the default egress object. AI changes the economics, not the geometry, of that inference. Clustering, mobility analysis, and multisource fusion that once required specialist effort can run continuously over large datasets. The security significance of a disclosure therefore depends on what the value enables a downstream machine to infer, not only on whether a single record looks sensitive in isolation.

Relationship to Existing Mechanisms This profile is intended to consume decisions from existing permission, consent, and policy systems. Those systems remain inputs. They do not replace sink verification of the outbound payload.

Operating-System Location Permissions Current mobile platforms distinguish, to varying degrees, approximate and precise location, one-time and continuous access, and foreground versus background access. Those controls govern whether an application process may read a provider. They typically do not bind a particular outbound payload, recipient, jurisdiction, or precision ceiling at the moment of network egress, and they often do not distinguish the first-party application from an embedded SDK on the same release path.

W3C Geolocation and Permission Policy The W3C Geolocation API and related permission policy give a web origin a location reading after user permission . They do not, by themselves, inspect a later fetch, beacon, or agent tool call that forwards that reading at full precision to a third party.

Coarsening, Fuzzing, and Differential Privacy Geohash prefixes, grid snapping, geo-fuzzing, delay, and differential-privacy mechanisms are compatible with this profile. They are candidate transformation methods. This document does not select one transformation. It requires that whatever representation is actually sent is the representation bound to the authority, and that a finer representation MUST NOT pass the sink under that authority.

Path-Level Privacy Controls Oblivious endpoints, MASQUE-based proxying, and private relay services can hide the client's network location from a destination . They do not bind the precision of application payload fields that already contain coordinates. Path privacy and payload-precision finality are complementary.

What This Profile Adds

precision as an authorization dimension, not only as a provider configuration;
component identity (application versus SDK, agent, analytics, or advertising library) as a predicate;
recipient, destination, and jurisdiction bindings on the release;
optional cumulative-disclosure evaluation;
sink-side comparison of authorized precision with the actual outbound payload; and
fail-closed denial or mandatory downgrade rather than advisory minimisation.

Architecture A Location-Release Candidate Act MUST NOT become externally effective merely because location permission was granted, the coordinate was already computed, an AI component selected a tool, or an upstream policy engine returned ALLOW. The act MUST remain in a Non-Effective State until the PED validates act-specific predicates, protected validation evidence is committed, scoped non-bearer finality authority is released, the egress Finality Sink independently verifies that authority against the outbound payload, and the authority is consumed or otherwise made unsuitable for unauthorized replay.

Precision-bounded egress chain PED approval alone MUST NOT release data. The sink MUST prevent effectuation on verification failure. A warning or audit record is not sufficient.

Precision-Bounded Egress Profile

Precision Ladder Implementations SHOULD be able to distinguish at least the following authorized-precision classes:

EXACT
METER_10
METER_100
GRID
GEOHASH
CITY
REGION
COUNTRY
DELAYED or RANDOMIZED variants of the above
NONE

The applicable class MUST be determined by declared purpose and current authorization state, not by the mere fact that the requester asked for the finest available value. Where a lower-precision representation is sufficient, the higher-precision representation SHOULD remain non-effective for egress.

PED Predicates For a location-release act the PED SHOULD evaluate:

requesting application and component identity and type;
declared purpose and whether exact precision is necessary for that purpose;
recipient, destination, processor type, and jurisdiction;
current user authorization and policy/revocation epochs;
data class and requested fields;
whether the release is one-shot or continuous; and
cumulative disclosure state where the policy requires it;
intended egress sink identity.

Possible PED decisions include ALLOW at the requested precision, ALLOW_WITH_TRANSFORMATION at a coarser precision, DELAY, RANDOMIZE, ESCALATE, or DENY. Exact GPS is not the default success path.

Worked Example Purpose: nearby pharmacy discovery or local weather. Requested precision: exact GPS. Necessary precision: city or local area. Destination: external discovery or forecast service. Decision: exact GPS denied; coarse locality allowed. The external service receives "Balasore, Odisha" rather than a coordinate. The application can still perform the task. Utility did not require unrestricted data authority.

Cumulative Disclosure An implementation MAY incorporate cumulative disclosure state so that repeated individually acceptable releases do not automatically create an unauthorized movement history. This state is policy-dependent and can cause a later request to be downgraded, delayed, randomized, rate-limited, or denied. Cumulative disclosure state is itself sensitive. Implementations SHOULD keep it device-local or inside the PED, SHOULD minimise retained identifiers, SHOULD bound retention to the policy window, and MUST NOT export the state as a movement history under authority issued for a single coarse release. A later revision may define a narrower privacy-preserving accumulator. This version only requires that if the state is used, it is treated as protected input to the PED, not as another egress object.

Jurisdiction-Neutral Policy Input This architecture does not choose among national privacy rules. The PED consumes the policy applicable to the relevant jurisdiction and user or enterprise authorization state. United States, European, Indian, or other deployments MAY produce different authorized-precision decisions from the same Candidate Act. The protocol's role is to keep the selected policy technically binding at the point of release.

Sink Placement and Alternate Paths Possible sink locations include an OS location or data broker, a network-egress filter, a browser upload control, an API gateway, a cloud-sync agent, and enterprise wrapping of SDK traffic. If more than one path can emit the same protected representation — application upload, analytics SDK, advertising SDK, telemetry, clipboard, file export, agent tool call, background sync — each path capable of that consequence MUST be subject to the same precision ceiling or MUST be unable to emit the protected fields. This document does not specify a single on-device enforcement point for every operating system. An implementation that leaves an equivalent path unverified does not satisfy the profile for that data class.

JSON Interoperability Profile This section defines the semantic JSON contract for location-release acts. It does not require one transport. Objects MAY move over protected local IPC, OS broker APIs, HTTPS, or enterprise agents. A transport binding MUST preserve object integrity, sink identity, freshness, and non-bearer authority semantics.

LocationReleaseCandidate Object

Precision Decision Object

EgressFinalityAuthority Object

EgressSinkVerify Request and Response The sink verifies the actual outbound payload immediately before release. Declared precision is not sufficient. The payload fields MUST be within the authorized ceiling.

Precision-Mismatch Denial

Complete Exact-to-Coarse Transaction

Cumulative Disclosure Extension

Protocol Operation

Digest and Substitution A Candidate Act SHOULD have a stable digest over load-bearing attributes including data class, requested and authorized precision, destination, recipient, jurisdiction, purpose, permitted fields, and sink identity. Changing exact GPS to city, recipient A to recipient B, or sink A to sink B MUST invalidate previously issued authority unless the changed operation is separately authorized.

Sink Verification Immediately before release the sink MUST verify authority integrity, act binding, sink identity, expiry and consumption state, nonce freshness, policy and revocation epochs, destination and jurisdiction, authorized field set, and that observed payload precision does not exceed the authorized ceiling. On success, single-use authority SHOULD be consumed atomically with release. Implementations SHOULD define a canonicalization for payload inspection sufficient to detect exact coordinates presented under a city label, hidden in additional JSON fields, or duplicated on a parallel header. This version does not specify a complete media-type inspection algorithm. Absence of such inspection is a residual risk and MUST be documented by the implementation.

Hot Path and Escalation Repeated releases inside a previously validated envelope — same application, purpose, destination, jurisdiction, and precision ceiling — MAY use a hot path with local protected state and short-lived authority. The hot path MUST still perform sink verification. Cache miss, unknown destination, jurisdiction uncertainty, continuous-trace requests, exact precision, or elevated cumulative-disclosure risk SHOULD escalate. Timeout MUST NOT be treated as approval.

Failure Codes The following identifiers are design suggestions and are not IANA assignments. Location-egress implementations SHOULD be able to express at least:

EF-002 NO_FINALITY_AUTHORITY
EF-005 AUTHORITY_ALREADY_USED
EF-006 REPLAY_DETECTED
EF-012 SCOPE_MISMATCH
EF-020 DESTINATION_MISMATCH
EF-021 JURISDICTION_MISMATCH
EF-023 PRECISION_MISMATCH
EF-030 POLICY_EPOCH_MISMATCH
EF-031 REVOCATION_STATE_MISMATCH
EF-040 SINK_MISMATCH
EF-070 ESCALATION_REQUIRED
EF-080 FAIL_CLOSED

A PRECISION_MISMATCH denial MAY include a remediation such as DOWNGRADE_TO_CITY. Other permitted actions include deny, delay, randomize, redact, quarantine, request fresh authority, or escalate.

Security Considerations The objective is that protected location remains technically non-effective for egress unless current, act-specific, precision-bounded authority is verified at the sink. Replay of a previously successful authority MUST be prevented by nonce, consumption, short lifetime, or equivalent state. Authority for city-level weather MUST NOT authorize exact GPS to the same host, a different host, or a different sink. Ordinary application-layer software MAY be compromised or overly permissive. Security MUST NOT depend solely on the application, SDK, browser, or model returning ALLOW. A malicious SDK with valid in-process access SHOULD NOT be able to bypass a correctly placed egress sink. If PED or sink integrity cannot be established, the implementation SHOULD NOT release exact or high-precision location. It MAY fail closed, downgrade, quarantine, or disable the protected consequence class.

Privacy Considerations Finality metadata can itself be sensitive: application identity, purpose, destination, jurisdiction, and precision class can reveal behavior even when coordinates are withheld. Implementations SHOULD minimise metadata exposed outside the PED and MAY use hashes, commitments, or sealed references rather than raw descriptors on untrusted paths. Repeated coarse releases can still build a movement history. Authorized precision of CITY on each of 144 requests is not automatically harmless. Cumulative-disclosure evaluation exists for that reason and must not become a second exportable trace. On-device models that reason over exact coordinates while egress is limited to city labels create an isolation requirement. This document does not specify how an implementation prevents the model or a tool-calling runtime from emitting the exact value through another channel. That channel, if it exists, is an egress path and is subject to .

Data-Sovereignty Considerations Authority to access data inside one environment is not authority to transfer it to another jurisdiction, cloud region, unapproved processor, external analytics provider, unrelated AI provider, or advertising endpoint. A data-export Candidate Act SHOULD bind destination, recipient, jurisdiction, cloud region, purpose, data class, precision, policy and revocation epochs, and sink identity.

IANA Considerations This document requests no IANA actions. The precision-class names and EF-xxx identifiers are illustrative. A later revision MAY propose registries for precision classes, consequence classes, or error codes.

Intellectual Property Note Certain technical concepts described in this document are associated with pending patent applications in the DAS Protocols family, including PCT/IB2026/054453, PCT/IB2026/055615, PCT/IB2026/055760, PCT/IB2026/055870, PCT/IB2026/056058, and PCT/IB2026/053385. IETF IPR disclosure should follow BCP 79 . This section is informational and does not define licensing terms.

Conclusion A device or application may obtain exact location while an SDK, AI agent, analytics service, cloud processor, or external destination is entitled only to a less precise representation or to no location at all. This profile moves that distinction to the actual egress boundary. Precise GPS access is not precise GPS-release authority.