Data sovereignty and zero-state telemetry

@@ -1,55 +1,161 @@
---
schema: foundry-doc-v1
title: "Data sovereignty and zero-state telemetry"
slug: data-sovereignty-telemetry
category: security
type: topic
content_type: topic
slug: data-sovereignty-telemetry
short_description: "The platform's telemetry architecture today: what is actually collected, how it is used, and a known gap against the zero-state design it is intended to reach."
title: "Data sovereignty and zero-state telemetry"
quality: complete
status: active
audience: vendor-public
bcsc_class: forward-looking
language: en
language_protocol: PROSE-TOPIC
last_edited: 2026-08-03
editor: pointsav-engineering
short_description: "Zero-state telemetry is the intended posture of measuring site usage without retaining identifying data. The pipeline running today writes full unmasked IP addresses to a plaintext file for up to a year; masking is not implemented."
paired_with: data-sovereignty-telemetry.es.md
last_edited: 2026-07-30
category: security
---

**Major correction (2026-07-30):** this article previously described a live, in-force
IP-masking mechanism ("the final octet is dropped before the record is written") and
framed the platform's telemetry posture as a present-tense GDPR/PIPEDA-compliant
zero-state architecture. Verified directly against the real ingestion code
(`app-mediakit-telemetry/src/bin/telemetry-daemon.rs`, `omni-matrix-engine.rs`): no
masking exists anywhere in the pipeline today. The body below has been rewritten to
describe current behavior accurately, rather than the originally intended design.
Escalated to Command/project-totebox by mailbox (`command-20260730-active-privacy-
compliance-discrepancy-se`) given the compliance stakes — not resolved unilaterally.
This rewrite reflects only what was verified about IP handling; the no-cookie and
no-session-state claims below were not independently re-checked in this pass and are
carried forward from the original article as previously stated, not re-verified.
**Zero-state telemetry** is the design goal governing how the PointSav platform intends to measure
usage of its public surfaces: no personally identifiable information retained, no tracking
cookies, no session state — aggregate signal without individual records. Paired with it is the
broader principle of **data sovereignty**: that operational records generated by a deployment
belong to the customer, run on infrastructure they control, and are not exported to a vendor or a
third-party measurement provider. Zero-state is a security posture as much as a privacy one — a
telemetry store that never contained reader identity is a store whose breach discloses nothing
about readers, which is the cheapest possible incident response available.

That goal is not met today, and this article's first job is to say so plainly. The platform's real
ingestion pipeline currently records the requester's full, unmasked IP address alongside the
timestamp, requested URI, and user-agent string for every request it logs, and retains the raw
record for up to a year. The gap between the stated design and the running code was found by
direct inspection of the ingestion source and has been escalated internally as a
compliance-relevant discrepancy; it remains open as of this writing. What follows describes the
intended architecture, the pipeline's actual behaviour — verified directly against canonical
source — and the specific work required to close the distance between them.

## What the pipeline does today

The measurement pipeline consists of two programs in `app-mediakit-telemetry`, both read directly
from canonical source for this article.

The collector (`telemetry-daemon`) accepts a JSON body containing a requested URI, a timestamp,
and a full user-agent string. It obtains the client address from the `x-forwarded-for` request
header, taking the first comma-separated value, and falling back to a placeholder address when the
header is absent. It then writes a single quoted comma-separated line containing the address, the
timestamp, the URI, and the user-agent to an append-mode plaintext file,
`assets/ledger_telemetry.csv`. The address is written verbatim: **no masking, truncation, hashing,
or generalisation of the client address occurs at any point in the collector.**

The second program, `omni-matrix-engine`, reads that file, skips rows carrying the placeholder
address, and performs a geographic lookup for every remaining address against a locally held
MaxMind GeoLite2 City database, extracting country, first subdivision, city, and time zone. It
buckets events into rolling windows and writes a summary report. It too operates on the raw address
string, and it must: a masked address does not resolve to a useful city-level result, so the
current design actively depends on holding the complete value at that step.

### The collector's exposure

Two further properties of the collector are relevant to a security reading. Its own source comment
attributes its choice to bind to `0.0.0.0` — all interfaces, rather than loopback — to accepting
mesh traffic over the platform's WireGuard network, on a port taken from the environment with a
default of 8081. Its CORS configuration permits any origin (`allow_any_origin`).

Taken together, the endpoint accepts a record from any caller that can reach it, and the values it
stores are supplied by the caller: the URI, timestamp, and user-agent are read from a submitted
JSON body rather than observed by the server, and only the address is derived from a header. A
record in the file therefore attests that something posted it, not that a page was actually
viewed. Anyone building analysis on this data, or assessing its sensitivity, should treat it as
caller-asserted rather than server-observed.

Public-facing descriptions of this platform's telemetry as a zero-state, masked, or
privacy-preserving architecture describe the intended posture, not current behaviour. This gap has
been escalated to platform governance rather than resolved in documentation, and remediation —
masking before persistence, or restructuring the geographic step to work from an already-
generalised value — has not been implemented as of this writing. It is a system change the team
owning the telemetry component needs to make, not a wording change.

## Retention and rotation

A deployment script rotates the live file into a date-stamped archive, restarts the collector,
regenerates reports, then deletes archived raw files older than **365 days** and generated reports
older than **30 days**.

Two things follow. First, raw rows containing complete client addresses persist for up to a year;
this is a bounded retention policy, not a zero-retention one. Second, the rotation performs no
anonymisation — it is time-based deletion only, so an address is either fully present or fully
gone, with no intermediate generalised form retained for long-term analysis.

No timer or scheduled unit that invokes this rotation script was found in canonical source, so its
actual execution cadence in a given deployment could not be established here. The file itself is
not committed to the repository, and neither is the geographic database; both are runtime or
operator-provisioned artefacts, so no size or row count can be reported.

## What the sovereignty claim does hold

Several structural properties of the design are accurate as stated and are worth separating from
the masking gap, because they are the substance of the data-sovereignty claim.

**The measurement runs on the operator's own infrastructure.** The collector, the analysis
program, and the output file are components of the deployment itself. There is no call to an
external analytics provider, no third-party script embedded in a served page for measurement, and
no export of the record to a vendor-operated service.

[[pointsav-overview|PointSav]]'s stated design goal is a zero-state telemetry architecture — no personally identifiable information retained, no tracking cookies, no session state. **That goal is not fully met today.** The real ingestion pipeline currently records the requester's full, unmasked IP address, timestamp, requested URI, and user-agent string for every request — the opposite of the masked, anonymized signal this article previously claimed. This is a known gap against the intended design, not a currently-accurate compliance posture. See also [[sovereign-telemetry|sovereign telemetry]] and [[telemetry-architecture|the telemetry architecture]].
**Geographic resolution is offline.** The lookup runs against a database file held locally on the
same machine. No address is sent to a remote geolocation service for resolution. The operator
provisions the database themselves under their own licence, and it is deliberately not
redistributed inside the repository.

## Key Takeaways
**No cookies are set.** A whole-tree search of canonical source found zero occurrences of a
`Set-Cookie` header anywhere in the platform, and no consent-banner component of any kind. A
published privacy page for one of the marketing surfaces states that the site sets no cookies,
runs no third-party analytics, advertising, or tracking scripts, and shows no consent banner
because there is nothing to consent to. The cookie-free claim is consistent with what the source
shows — resolving what an earlier pass had left as an open flag.

- The intended design is zero-state: no PII, no cookies, no session retention. **The IP-handling piece of that design is not implemented today** — see below.
- No IP masking currently occurs. The full IP address is written to a plaintext record as received; it is not dropped, truncated, or anonymized at any point in the pipeline.
- No cookie-consent banner is currently displayed; the platform's public-facing interfaces do not appear to deploy tracking cookies (carried forward from the original article, not independently re-verified this pass).
- Any disclosure text describing this system's privacy posture in present tense should be treated as describing the *intended* design until the IP-masking gap closes, not the system as it runs today.
That said, two qualifications belong alongside it. A separate marketplace surface does use a
functional session token for signed-in licence status, which is a session mechanism rather than a
tracking one but is not "no state at all." And a set of proposed public-site mockups held in the
tree contain a far more detailed client-side beacon — referrer, viewport, time zone, device
memory, processor count, scroll depth, dwell time, click targets, network type — posted to a
telemetry endpoint with no consent prompt, alongside marketing copy on the same page claiming a
"Zero-Cookie and Zero-State Telemetry architecture." Whether those mockups are deployed on any
live surface could not be determined from source, and they are flagged here rather than assumed
inactive.

## What the pipeline actually does today
## What this is not

The real ingestion path is `app-mediakit-telemetry/src/bin/telemetry-daemon.rs`: it reads the `x-forwarded-for` header verbatim off each incoming request and appends the full IP address — together with the raw timestamp, requested URI, and full user-agent string — to a plaintext CSV file (`assets/ledger_telemetry.csv`). No octet-dropping, truncation, or hashing occurs anywhere in this function. A downstream process, `omni-matrix-engine.rs`, then performs a MaxMind GeoIP lookup directly against that same full IP address to derive coarse geographic signal for usage reporting — a masked address (e.g. final octet zeroed) would not resolve to a useful lookup, so the pipeline's current design actively depends on holding the complete address rather than incidentally retaining it.
**This is not a masked or anonymised telemetry pipeline.** Complete client addresses are written
to a plaintext file and retained for up to a year. Any statement that a final octet is dropped, or
that addresses are hashed before persistence, is inaccurate as a description of running code.

## Known gap and remediation
**This is not a description of a compliance position.** The design intent is aligned with
data-minimisation principles, but a pipeline that stores unmasked addresses alongside timestamps,
requested paths, and full user-agent strings handles personal data, and this article should not be
read as asserting that any particular regulatory obligation — GDPR, PIPEDA, or otherwise — is
satisfied. That assessment is a matter for the operator and their advisers.

Closing this gap — so the system actually matches the zero-state design intent — requires either masking the IP before persistence (accepting coarser geolocation) or restructuring the GeoIP step to work from an already-masked value. Neither has been implemented as of this writing. This is flagged to the team that owns `app-mediakit-telemetry` as a real remediation item, not merely a documentation correction — the underlying system, not just this article, needs to change before the zero-state claim can be made accurately again.
**The absence of cookies is not the absence of identifiers.** An address paired with a user-agent
string and a request path is a re-identifiable record in many contexts. Cookie-free measurement
reduces cross-site linkage; it does not make a record anonymous.

## Regulatory disclosure — treat as intent, not current state
**Time-based deletion is not anonymisation.** Retention limits exposure duration. Within the
retention window the record is fully identifying.

Some public-facing interfaces may carry disclosure language describing this system in zero-state, masked terms. Until the gap above closes, any such disclosure should be understood as describing the platform's intended posture, not a currently accurate technical claim — this wiki does not reproduce that disclosure text here in order to avoid restating a claim known to be inaccurate today.
**Zero-state is not the current state.** It is the target the design is written toward. Whether the
pipeline's present behaviour is consistent with any specific data-protection regime is a legal
determination outside this article's scope; what this article asserts from direct source
inspection is narrower and verifiable: full IP addresses are being written to persistent storage
today, and the zero-state architecture is a target, not a description. Nor is this an incident
report — there is no finding here of unauthorized access or misuse of the logged data, only of a
divergence between design and implementation — and no timeline is attached to the remediation
above, because none has been committed.

## See also

- [[sovereign-telemetry]]
- [[sovereign-telemetry]] — the wider architectural position on operator-held measurement
- [[telemetry-architecture]] — the structure of the collection and analysis pipeline
- [[app-mediakit-marketing]] — the served surface whose published privacy page is quoted above
- [[bcsc-disclosure-posture]] — the disclosure discipline governing forward-looking statements about this platform
- [[cryptographic-ledgers]] — the append-only record used for auditable events, distinct from this pipeline
- [[customer-owned-graph-ip]] — the ownership principle applied to derived data
- [[machine-based-auth]]
- [[zero-execution-routing]]
- [[cryptographic-ledgers]]