felhom.eu/documentation/audits/day-2026-10-08/design-R-435.md

R-435 — the snapshot-drop detector does not see one app's off-site history vanish: a one-page design (2026-10-08)

Baselines read: felhom.eu b2dce901, felhom-controller a0370b4. Architecture: 07-backup-architecture.md §11 row 10 (ransomware / malicious deletion; the 2026-10-03..05 [FACT] entries on the append-only key and the clean-up window); 09 §3 decisions 68, 69 (the box prunes only in a hub-opened window; the hub-provisioned key is append-only). Status: design only, nothing built.

1. The problem, and what changed under it since the row was filed (2026-09-01)

• Still true in code. hub/internal/monitor/offsite.go:254-257: an alarm needs a fall of more than half the last count AND at least 5 (snapshotDropped, :285-295). One app's tag (~9 of 69 on demo-hp when measured) is invisible. The limit is written in the comment above the constants (:242-253), as the row says.
• The row's second complaint is gone. STATUS.md no longer says „noticed within a day" (grep -n -i "within a day\|noticed" STATUS.md returned nothing today). 07 row 10 says „only a fall of MORE than half (R-435)".
• The threat the row describes is now mostly PREVENTED, not only undetected. Since decisions 68–69 (2026-10-03) the box's off-site key cannot delete (provider refusal measured, 07 row 10). The box deletes only inside a hub-opened window (controller/internal/backup/offbox_window.go:203-225, t.Pinned()), and inside it the fake-snapshot guard refuses any plan that removes a snapshot younger than keepDaily days that is not superseded the same day (offbox_window.go:24-36). A one-app wipe must remove that app's newest snapshots, so the guard refuses it.
• What is left uncovered: a deletion by something that is NOT the box's key — anyone with a deleting credential for the sub-account or the provider account — or a box that lies about its plan. The count detector sees those only above one half.

2. The new fact that makes a precise detector cheap

On a pinned tier the only legitimate way the count can fall is a clean-up window, and the hub records every window with count_before / count_after (hub/internal/store/store.go:835-845, offsite_keys.go:84-101). So the hub can say „this fall is explained" exactly, with no threshold: between two trustworthy reports, the count may fall by at most what the windows closed in that interval removed. Any fall beyond that is unexplained — even one snapshot.

3. Options

	What	Costs	Risk
A	Keep as is: documented blind spot.	Nothing.	A single-app deletion from outside the box stays silent.
B	The row's own suggestion: the controller reports a count per app tag; the hub keeps a per-tag baseline and threshold.	Two repos, a new report field (wire-contract gate), a per-tag threshold nobody has measured; retention also moves per-tag counts, so it needs its own calibration. ~1.5 sessions.	Noise from retention on boundary days — the reason the global threshold is high.
C	Hub only: on a pinned tier (hub holds a confirmed append-only key for the customer), compare prev − cur with the snapshots removed by windows closed since the previous trustworthy report. Any unexplained fall ≥ 1 raises offsite_snapshots_dropped. Non-pinned tiers (the household's NAS) keep today's half-rule.	One repo. One store query (windows closed in an interval), one branch in snapshotDropped, tests. ~½ session.	A window that closes by timeout without a box result has no count_after; treat it as „explains anything" (no alarm, log one INFO line) — the safe side for noise, recorded as a limit.

4. The pick — C

C covers the shape B was meant to cover — and any size — without a new threshold, a new field or the second repo. It uses the only fact that is exact (the windows the hub itself opened). It keeps the half-rule for NAS tiers, where the box still prunes by itself. B stays a note: it would add per-app naming in the message, which C does not have (C says „N snapshots went, outside any clean-up window"; the operator reads which ones on the box).

5. First slice and its red test

• Hub: store.RemovedByWindowsBetween(customerID, from, to) (removed int, unknown bool); OffsiteChecker keeps the time of the last trustworthy baseline beside lastCounts; on a pinned customer, alarm when prev − cur > removed and not unknown. The message adds „outside any clean-up window".
• Red test (seen failing on today's code): pinned customer, baseline 69, next trustworthy report 60, no window → exactly one offsite_snapshots_dropped event. Today: none (9 < 34.5).
• Controls: same fall with a closed window that removed 9 → no event; NAS (not pinned) customer 69 → 60 → no event (half-rule kept); untrustworthy report → no event and baseline unchanged (existing rule).
• Live proof, when releases resume: on scratch 9202 only — a window granted by hand removes N and no alarm; then the hub's own row for that window as the control from another channel.

6. One question for the operator

Should the hub raise an error mail when even ONE off-site snapshot disappears outside a clean-up window it opened? My pick: yes (option C). If you do nothing: deletions by the box stay blocked as today, but a deletion through any other credential stays silent unless it removes more than half of a household's off-site history.