freno-dev/marketing/drafts/privacy-page.md

/privacy — replacement copy, prepared and not applied

Status: patch ready for the CTO's read. The page file is unchanged; nothing here is published. Patch: marketing/drafts/privacy-page.patch — applies cleanly to c1c498e (git apply --check, verified 2026-10-29; parse-checked with esbuild, not the site suite). Evidence base: FRE-333 egress-inventory rev 1, eleven destinations, file:line per row, read at The-Nook 3c3ba7ee; and the same document's §G, which proposed a page text. This patch is the §G text corrected against the inventory — the differences are listed below, each with the row that forces it. Why this exists: FRE-326 + FRE-334 recorded option A — the privacy claim is withdrawn everywhere, and no privacy claim returns until the inventory exists, /privacy matches it, the CTO verifies both, and the sponsor approves the replacement copy. The inventory landed on 2026-10-29. This is the page half.

Field	Value
Claim this page carries	None. It is a disclosure page, not a claim: it states what the app sends and what it does not. The one favourable sentence is (j), which is the CTO's FRE-322 §2 code fact and which he may still decline.
Audience	Someone deciding whether to pay $10 for a tool that reads their prompts. They read this page before the FAQ.
Channel	nook.freno.me/privacy, one page
Owner	CMO (copy + commit), CTO (verification), sponsor (approval of the replacement copy), Chief of Staff (publish switch)
Date	Prepared 2026-10-29. Target apply 2026-11-03, in the same push as c1c498e (FRE-323) and the FRE-326 FAQ patch. Not a public date.
What has to be true before it ships	1) CTO signs the page against The-Nook HEAD, paragraph by paragraph — FRE-354, due 2026-11-02. 2) Sponsor accepts the replacement copy. 3) The Sentry paragraph matches the build being deployed — see Contingency. 4) It deploys in the same push as the FAQ withdrawal; a page that discloses Sentry next to a FAQ that still says "anonymous usage telemetry" is worse than either alone.

What changed against the live page

The live page (fetched 2026-10-29T09:2xZ and again 09:4xZ, HTTP 200, Last Updated: August 26, 2026, unchanged) says the app "runs locally on your device and sends only the minimal data required for trial and licensing" and lists four things. Against the inventory that is wrong in two directions: it omits Sentry (crash reports with IP address and macOS username, every launch, no off switch), the relay and its install ID, the licence key crossing to the relay, sealed phone payloads, weather coordinates going to the relay and to Apple, the GeoIP third parties, the speed test, the changelog fetch, bug-report contents and update checks. It also calls the hardware UUID "masked", which the code contradicts — it sends the raw IOPlatformUUID.

The replacement is organised by connection, not by data type, because that is how a reader checks it: eleven rows in the inventory, ten of them reachable from the page, one (Sentry) prominent because it is the only one with no off switch.

Differences from FRE-333 §G, and what forces each

§G is the Security Engineer's proposed text; this patch is that text corrected against §G's own inventory. Six deliberate differences, none of them stylistic:

#	§G says	This patch says	Why
1	Opening: "processed on your device and are never sent to us"	Opening drops "never sent to us"; (c) and (j) state the two paths agent data does take	Sealed frames still transit our relay (§A.5, §B), and a remote machine carries them by design (§C). §G's own §B says the relay routes them. "Never sent to us" is the class of sentence that got the FAQ answer withdrawn.
2	(d) Weather: relay registration implied only with Phone	(d) adds that Weather registers even with Phone off, and on a licensed Mac that registration presents the license key	§A.3 + §D.2. SidecarController.weather() routes through the same keystore.relayCredential(licenseKey:) as the phone path (SidecarController.swift:269-279, SidecarRelayAPI.swift:298-312). §G under-disclosed it.
3	(a) trial/activate/status only	(a) adds /deactivate (key + UUID) and the trial email (email + UUID, sent once)	§A.2, /D.4. §G omitted both endpoints.
4	(i) "The email you give at trial start or checkout delivers your license key"	(i) checkout delivers the key; a trial email is one reminder before the trial ends	LicenseService.submitTrialEmail + OnboardingExtrasStep say the trial email is an expiry reminder; the key is issued at purchase. §G's sentence promised a key that the trial email does not deliver.
5	(b) Sentry: opt-in, "off unless you turn it on"	(b) describes today's build: on every launch, no off switch, IP + macOS username; the opt-in form is the Contingency swap	The patch must be true on the build it deploys with. See Contingency for the sequence call.
6	No (j)	(j) carries the CTO's FRE-322 §2 code fact, with the remote-machine exception	Not required for truth; it is the one favourable sentence, and the CTO may decline it. Delete the block if he does.

Two facts the inventory corrected and the page does not repeat wrongly: Sparkle's automatic checks are off by default here (UpdateManager owns the schedule; FRE-322 §2.4 said "on by default" and is stale on this row), and the UUID is raw, not masked.

Paragraph-level evidence

Paragraph	What it now says	Evidence at 3c3ba7ee
(a) Licensing/trial	raw UUID + device name; every launch while trialing; key-only once licensed; deactivate sends key + UUID; trial email sends email + UUID once; fails open	LicenseService.swift:316-325 (/trial), :277-290 (/status), :247-262 (/activate), :286-302 (/deactivate), :219-231 (/trial-email)
(b) Crash reporting	on for every launch, no off switch; carries IP + macOS username; never prompts or code	Sources/NookApp/main.swift:272-279 — sendDefaultPii = true, tracesSampleRate = 1.0, no preference gates it
(c) Phone relay	off by default; install ID + license key at registration; sealed payloads; relay sees devices/timing/volume, not content	SidecarRelayAPI.swift:150-160, docs/sidecar-frames.md (sealing), inventory §B
(d) Weather	0.1° grid snapped on the Mac; registers with the relay even with the phone off, licence key included on a licensed Mac; Apple sees place lookups and position	WeatherForecast.swift:25-30, SidecarController.swift:269-279, SidecarRelayAPI.swift:298-312, WeatherLocation.swift:14-77, :89-143
(e) Network panel	third-party IP lookup sees your IP; speed test uploads zeros only	NetworkInfoService.swift:82,276, SpeedTest.swift:10-11,36
(f) Update checks	ship off; turning them on fetches freno.me, app version + IP	UpdateManager.swift:48-55 (automaticallyChecksForUpdates = false, default key false)
(g) Changelog	fetches release notes from freno.me	ChangelogRelease.swift:75-78
(h) Bug reports	user-sent only; machine snapshot listed in full	BugReportClient.swift:44-94, BugReportSnapshot.swift:17-36
(i) Email/payment	checkout email delivers the key; trial email is a reminder; Stripe	LicenseService.swift:219-231, OnboardingExtrasStep.swift:86-110
(j) What does not leave your Mac	hook dials the local socket, bridge only listens, helper has no networking; two paths carry agent data across the network, both user-switched: remote machines over SSH and the sealed phone relay	hook/transport.go:143 (resolveBridge), BridgeBindPlan.swift:9-23, inventory §B + §C

Contingency — the Sentry paragraph is the only one that moves

(b) as committed describes today's build. The inventory's recommendation (§E.1) is an opt-in setting, default off, dropping sendDefaultPii and cutting tracesSampleRate, on Mac and iOS. If that ships, (b) is replaced in the same commit that changes the behaviour:

(b) Crash and error reporting — off unless you turn it on. If you enable crash reporting in Settings, The Nook sends crash and error reports to Sentry, our crash-reporting processor. Reports include the app version, macOS version, Mac model and what the app was doing when it failed, and Sentry also receives your IP address. They never include your prompts or code.

Sequence call, and who owns it. Shipping (b)-with-no-off-switch is honest, but it puts "no off switch" in front of a buyer during launch week. The better order is the build change first, then this page — that is a build/priority call, not mine: it is proposed on the board as FRE-355 (Senior Engineer, date proposed 2026-11-06, CTO to confirm), and if the CTO says the build change cannot land before the page, the page ships with today's text. Publishing the truthful-today version is never blocked by that choice; the preferred order is the other way.

This is why (b) must not be softened on the way out. If the opt-in setting ships but sendDefaultPii stays true, (b)'s opt-in form is false again (it says nothing about the username). The paragraph and the build change move together or neither does.

If the CTO declines paragraph (j)

(j) is the only favourable sentence on the page and the only one carrying a CTO verdict rather than an inventory row. It is FRE-322 §2 — "verified as a code fact, not publishable yet… publishing it before the disclosure work lands would put a true sentence next to false ones." The disclosure work is this page. If the CTO still declines it, delete the whole (j) block; nothing else on the page depends on it, and the page stays complete and true.

Open questions for the CTO's read

1. The iOS app. §D.10: the iOS target starts the same Sentry DSN with the same sendDefaultPii (ios/AgentNookMobile/App.swift:12-20). This page says "runs on your Mac". Is any iOS build in users' hands? If yes, the page needs one sentence (or the build needs the same opt-in); if no, say so and the page stays Mac-only.
2. Weather registration without a licence key. §E.3 suggests decoupling weather registration from the licence key. If that ships before the page, (d) loses its licence-key clause; if after, the page is true today.
3. (j) — publish, or cut.

Apply checklist — what the apply commit must do, in order

1. Re-read the live page and the inventory's HEAD; if either moved, re-derive (a)–(j) before applying. The inventory is pinned to 3c3ba7ee.
2. Bump Last Updated to the deploy date — the patch carries 2026-10-29 as prepared, and that line is the one place the date must change at apply.
3. If the Sentry opt-in build change is in the same release, swap (b) for the Contingency paragraph — one hunk.
4. Apply privacy-page.patch and the FRE-326 faq-page.patch + positioning-privacy-withdrawal.patch in the same commit, so no page states the old claim while another corrects it.
5. Run the site's suite — bun test — which this host cannot do (no bun; node_modules present, package.json test script is bun test). A parse/transpile check with esbuild is not that suite and must not be recorded as one.

Rules this page obeys

• No competitor named (category nouns only, and none needed here).
• No claim without a row in the inventory. Where the inventory has no row, the page says nothing.
• No roadmap promise: the page never says a feature or fix is "coming", so the Sentry paragraph does not promise an off switch.
• No price, no discount, no date, no launch language.
• It is a correction of an existing page, not new marketing; nothing was added to sell anything.
• It does not add a /faq privacy answer. That answer's return is gated separately (FRE-326 privacy-return-path).