Living Document Notice
Published 2026-09-15. The evolving architecture, revisions, and connected notes for this dispatch live in the Stax Digital Garden.
Ephemeral Origins: Zero-Retention Location Models
Summary
Geospatial tools commonly treat user coordinates as durable profile metadata. Mapping applications, weather portals, and aviation tracking dashboards routinely capture observer latitude and longitude, storing these coordinates in relational user databases, session tables, and server access logs alongside device fingerprints and IP addresses. For a tool designed to monitor the sky directly above a user’s home, workshop, or private office, persisting origin coordinates represents an unacceptable privacy vulnerability.
Hushwire implements an ephemeral origin model rooted in zero server-side retention. The system holds no user accounts, maintains no database tables, and executes no session tracking. Geographic centerpoints exist exclusively in client-side runtime memory or encoded within the client’s URL fragment (#lat,lon), which browsers never transmit in HTTP request headers. At the edge network boundary, proxy workers process query parameters purely in-flight, stripping IP addresses and query strings before log ingestion. This dispatch details the privacy architecture, log scrubbing policies, and client-side storage mechanics that guarantee sovereign local observation under Local-First Systems and Synchronization.
The Threat Vector of Coordinate Persistence
A location coordinate with four decimal places resolves a physical location down to approximately eleven meters:
When a user configures a local radar observatory, that coordinate frequently corresponds to the roof of their private residence or business. In conventional web architectures, this coordinate is exposed across multiple data retention tiers:
[ User Browser ] ──( HTTP GET /radar?lat=37.7833&lon=-122.4167 )──► [ Nginx / Cloud Proxy ]
│
Writes to access.log
(IP + Lat + Lon + UA)
│
▼
[ Third-Party Analytics / DB ] ◄── Synchronous Write ─────────────── [ App Backend ]
(Permanent Lat/Lon Profile) (Creates Account Record)
If an attacker breaches the backend database or gains access to un-redacted edge proxy logs, they obtain a complete registry of user physical addresses coupled with their active monitoring schedules.
The Zero-Retention Architecture
Hushwire eliminates coordinate persistence entirely by establishing a strict data boundary: the server infrastructure is completely stateless and blind to user identity.
┌──────────────────────────────────────────────────────────┐
│ Browser Client (Local Sovereign State) │
│ │
│ • Origin held in window.location.hash or localStorage │
│ • Never transmits location in cookies or auth headers │
│ • No tracking pixels, Google Analytics, or telemetry SDKs│
└────────────┬─────────────────────────────────────────────┘
│ Dynamic telemetry fetch:
│ GET /api/telemetry?lat=37.78&lon=-122.41&rad=50
▼
┌──────────────────────────────────────────────────────────┐
│ Cloudflare Edge Worker (Stateless In-Flight Router) │
│ │
│ • Validates bounding box in V8 memory │
│ • Calls upstream telemetry provider │
│ • Strips query string from Cloudflare Logpush │
│ • Discards coordinates immediately after HTTP response │
│ • Zero database writes (No D1, No KV persistence) │
└──────────────────────────────────────────────────────────┘
1. The Fragment Identifier Pattern
When an observer saves a custom radar centerpoint, Hushwire stores the coordinate in the URL fragment rather than a query parameter:
https://hushwire.app/#origin=37.7833,-122.4167,z10
Under RFC 3986, the fragment identifier (everything following #) is processed exclusively by the browser user agent. Browsers never transmit the fragment over the network in HTTP GET requests or TLS handshakes. As a result:
- Edge proxies and CDNs never receive the saved bookmark in network request logs.
- Intermediate ISP proxies cannot inspect the user’s primary observation coordinate.
- The coordinate is restored instantly on page load via
window.location.hashand parsed entirely within client JavaScript.
// Client-side origin extraction
export function resolveLocalOrigin() {
const hash = window.location.hash.slice(1);
const params = new URLSearchParams(hash);
const originStr = params.get("origin");
if (originStr) {
const [lat, lon] = originStr.split(",").map(Number);
if (!isNaN(lat) && !isNaN(lon)) {
return { lat, lon, source: "hash" };
}
}
// Fallback to local storage on the user's physical machine
const localStored = localStorage.getItem("hushwire_origin");
if (localStored) {
try {
return JSON.parse(localStored);
} catch {
// Ignore corrupted local entry
}
}
// Default neutral geographic center if unconfigured
return { lat: 37.6213, lon: -122.3790, source: "default" };
}2. Ephemeral In-Flight Requests
When the client polls for active radar targets, it must transmit a coordinate to receive filtered airspace data. However, the edge worker treats this parameter as an ephemeral routing token:
- The worker parses
latandlonfromrequest.url. - It constructs the upstream aggregator call and awaits the normalized payload.
- Once the response streams back to the browser, the worker execution context terminates.
- No relational write is executed. No KV cache stores the user’s IP-to-coordinate pairing.
3. Log Redaction and Sanitization
To ensure that server access logs do not inadvertently capture coordinates, Hushwire configures Cloudflare Logpush and worker logging pipelines to sanitize query strings:
export default {
async fetch(request, env, ctx) {
// Clone request URL for sanitized internal logging
const sanitizedUrl = new URL(request.url);
sanitizedUrl.search = "?redacted";
// Set custom log metadata for Cloudflare Workers Analytics
// Deliberately omitting client IP and precise coordinates
if (ctx.setLogMetadata) {
ctx.setLogMetadata({
path: sanitizedUrl.pathname,
status: 200,
timestamp: Date.now()
});
}
// Normal processing continues...
}
};Upstream headers sent to data providers omit client identification. The data vendor observes requests originating exclusively from Cloudflare edge IP ranges, effectively masking the end-user’s internet provider and physical location behind thousands of shared edge nodes.
Privacy and Data Governance Comparison
| Governance Dimension | Standard Flight Trackers | Hushwire Ephemeral Model |
|---|---|---|
| User Account Requirement | Mandatory email/password for saved views | None; zero auth infrastructure |
| Coordinate Storage | Relational DB linked to user identity | Client browser (#hash or localStorage) |
| Server Access Logs | Full URL with parameters and client IP retained | Query parameters sanitized; zero retention |
| Third-Party Telemetry SDKs | Google Analytics, Mixpanel, Datadog | None; zero third-party client trackers |
| GDPR / CCPA Exposure | High (stores Personally Identifiable Location Data) | Zero (no personal data processed or retained) |
Data Sovereignty as a Foundation
Software designed for personal knowledge management and ambient observation should observe the environment without observing the user. By decoupling spatial utility from data harvesting, Hushwire proves that complex telemetry visualization does not require sacrificing personal privacy. The sky remains public, but the observer’s location remains their own.
- Directus Target: hushwire
- Garden Source Reference: Data Sovereignty Standards, Zero-Persistence Architecture, MOC - Fleet Operations, MOC - Bosun PKM Tools, MOC - Local-First Systems and Synchronization