Device data collection: what to review
| Field | Value |
|---|---|
| Branch | feat/admin-and-merchant-portals, draft PR #976: feat(admin): portal navigation, financials and monitoring, plus the agent-process work behind them, not merged |
| Project | README.md |
| Issue | #1003: design(privacy): does Lantern collect device data at all, and at what resolution, before Platform and Device is built |
| Servers you need | None. Nothing was built, and nothing should be until you pick a tier. |
| Local origins | Not applicable |
Is there anything to look at?
No code, and one document. The document IS the review.
README.mdis a decision brief, written because you asked for it on 2026-08-30: "Device data collection > I need waaay more info in relation to this."- It deliberately does not build toward a default. Collecting nothing and deleting the route is presented as a first-class answer rather than a fallback.
- There is a recommendation, and it is a lean rather than a decision. Tier 0, delete the tab, and answer the one real question by asking the ten Alpha participants directly.
The one surface this decision governs, if you want to see what is at stake
http://localhost:3001/admin/analytics/dashboards/platform, the Platform and Device placeholder. It states 123 days as of 2026-08-28, and 125 as of 2026-08-30.- It is not an unbuilt page, it is an uninstrumented one. Building it first would produce a dashboard of empty states.
What changed here?
One commit, and it is the brief. Nothing else in the repo moved.
- No schema change, no ingest change, no client change, no policy change.
It corrected a count that another project asserted.
#999: feat(admin/analytics): the three Dashboards routes have been placeholders for 123 days, and one of them has no data source claimed 1,597 events in the 60-day window. The re-measured figure is 1,643.- Nobody was wrong. Users, sessions and
session_idcoverage all match exactly; 46 events landed after the original query ran. - The stronger correction runs the other way: the device fields are not empty, they do not exist.
analytics.eventshas twelve columns and none is device related.
What are you actually being asked to decide?
Four tiers, and the fork is real.
- Tier 0: nothing new. Tier 1: one five-valued
platformenum. Tier 2: five parsed enums. Tier 3: the raw user-agent plus client-measured signals. - Every field in the brief is tied to a question a person actually asked, and only one such question exists: the iOS share, from
#722: Pre-alpha: iOS real-device coverage for PWA push (no iPhone on the team). - Tier 3 answers no question Tier 2 does not, which rules it out on its own merits before any privacy argument.
- Tiers 2 and 3 are self-defeating at Alpha scale: roughly 50,000 field combinations over ten users means essentially every cell is n=1, so our own k=3 display gate renders the dashboard almost entirely blank during exactly the period it would be used.
What is deliberately NOT done?
Nothing is built, and nothing should be until you pick a tier.
Two of the four tiers cannot be decided in isolation.
- Tiers 2 and 3 are downstream of
#874: design(privacy): one data-classification and egress policy, before search, the assistant, and the apps platform each invent their own. Deciding them now would prejudge it, and would be the fifth ad hoc answer that issue was filed to stop. - Tiers 0 and 1 are independent of it.
What open findings touch this project?
Three, all found while writing the brief, all out of scope for it, and all true at Tier 0.
"We collect no device data" is not accurate today.
PINO_REDACT_CONFIGdoes not redactuser-agent, so raw strings land in Cloud Logging on every analytics request, and Cloud Run's ownhttpRequestlogs carry them independently.- The retention on those logs has never been examined. Not filed yet.
Nothing rejects device data arriving in metadata.
- The ingest schema accepts arbitrary client-supplied keys. The absence of device data today is the absence of client code that sends it, not a guardrail. That is policy, not architecture.
The privacy policy is already wrong, before any tier is chosen.
PrivacyPage.jsxcontains zero occurrences of "analytic", "telemetry", "tracking" or "event", while analytics events, session identifiers and ad telemetry are all collected today.- There is no consent banner and no analytics opt-out anywhere. The
#/profile/privacytoggle is location history, not analytics. - Closing that gap is a precondition for any tier, including Tier 0.
Nothing from ../merchant-and-venue-dashboards/branch-review-0828.md lands here. The brief postdates that review.
What issue does each piece close?
| Piece | Issue | State |
|---|---|---|
| The decision itself | #1003: design(privacy): does Lantern collect device data at all, and at what resolution, before Platform and Device is built | Open, needs your pick |
| The trigger, and the route this governs | #999: feat(admin/analytics): the three Dashboards routes have been placeholders for 123 days, and one of them has no data source | Open |
| The question Tier 1 would answer | #722: Pre-alpha: iOS real-device coverage for PWA push (no iPhone on the team) | Open, answerable by asking the cohort |
| The classification policy Tiers 2 and 3 depend on | #874: design(privacy): one data-classification and egress policy, before search, the assistant, and the apps platform each invent their own | Open, scoping only |