Security and hardening review before wider testing #16

New Issue

2026-09-01T23:00:11Z

paulhitt commented

2026-09-01 23:00:11 +00:00

(Migrated from gitlab.com)

Ask: a security and hardening review, for reassurance before the app is put in
front of testers and strangers.

There is already a published audit scope at /audit (Resources/Views/audit.leaf) —
system description, trust boundaries, assets, where to start reading, test surface. This
ticket is not a replacement for that or for a paid external audit. It is the internal pass
that should happen first, so an external reviewer is not paid to find things we already
know.

Why now, specifically

2026-09-01 shipped a lot in one day and changed two security-relevant postures. Both were
argued for in commit messages by one person with no second opinion:

A plain sign-out now KEEPS the device. Identity keys, ratchet state and the
encrypted history stay on a signed-out phone. The argument was that a relay token is
minted with the app password, so leftover keys cannot fetch anything without the
passphrase — that argument should be checked rather than inherited. The erasing door
exists beside it, but the default changed.
A new metadata field, silent. The sender now tells the relay an envelope needs no
human attention, so it can send a background push instead of an alert. That is a real
disclosure — the relay learns which envelopes are protocol traffic. Bounded, and traded
against a phone that announced call signalling as new mail, but it is a concession and
should be recorded as one.

Areas worth a pass

Claims vs enforcement. Every security claim on the public pages should map to something
enforced in code. /comparison and the landing page make specific claims; FTC §5 makes
over-claiming a legal exposure, not just an embarrassment. Today already found the site
under-claiming in three places, which suggests nobody has walked the mapping recently in
either direction.

Key transparency, end to end. Clients pin a head and demand inclusion proofs — but:
is the pin persisted correctly, is a fork actually surfaced to the user rather than only
logged, and what does the app do when the relay simply stops serving a log it used to
serve? A downgrade that looks like an outage is the interesting case.

Sealed sender and delivery tokens. What can the relay correlate across a delivery key,
a token batch, and timing? §21.4 revocation exists; the question is what is learnable
before it is used.

At-rest on the device. History is AES-GCM under a ThisDeviceOnly Keychain key. With
sign-out now keeping it, the exposure of a lost-but-signed-out phone deserves a fresh look,
including what app lock does and does not gate.

Blast radius from a relay flaw. Tracked separately as #15 (the relay runs as a Postgres
superuser, which turns a SQL flaw into RCE via COPY … FROM PROGRAM). Worth doing a
broader pass in the same spirit: what else on that box is reachable from the relay process,
and what secrets are readable by it.

Media privacy regressions. EXIF/GPS stripping is now an explicit guarantee with tests,
but it was an accident of resizing for a long time before that. Check the other paths
that touch user files — attachments, avatars, backups — for the same shape of accident.

Rate limits and abuse. Limits were raised sharply during debugging on 2026-09-01
(FN_BUNDLE_RATE=2000, FN_BUNDLE_RATE_TARGET=600, FN_SEND_RATE=6000) and have not
been reviewed since. They should be set from what a real client needs, not from what an
afternoon of debugging needed.

Suggested shape

Read-only investigation producing findings, each with evidence and a severity, filed as its
own issue. No fixes in this ticket. Owner has suggested running some of this as a
multi-model review; a second opinion is much of the value.

⚠️ The 2026-09-01 code freeze is in effect: investigate and report, do not change.

⚠️ Known and deliberately excluded: unrotated credentials in .env backups, already
assessed and parked.

**Ask:** a security and hardening review, for reassurance before the app is put in front of testers and strangers. There is already a **published audit scope** at `/audit` (`Resources/Views/audit.leaf`) — system description, trust boundaries, assets, where to start reading, test surface. This ticket is not a replacement for that or for a paid external audit. It is the internal pass that should happen first, so an external reviewer is not paid to find things we already know. ## Why now, specifically 2026-09-01 shipped a lot in one day and changed two security-relevant postures. Both were argued for in commit messages by one person with no second opinion: 1. **A plain sign-out now KEEPS the device.** Identity keys, ratchet state and the encrypted history stay on a signed-out phone. The argument was that a relay token is minted with the app password, so leftover keys cannot fetch anything without the passphrase — **that argument should be checked rather than inherited.** The erasing door exists beside it, but the default changed. 2. **A new metadata field, `silent`.** The sender now tells the relay an envelope needs no human attention, so it can send a background push instead of an alert. That is a real disclosure — the relay learns which envelopes are protocol traffic. Bounded, and traded against a phone that announced call signalling as new mail, but it is a concession and should be recorded as one. ## Areas worth a pass **Claims vs enforcement.** Every security claim on the public pages should map to something enforced in code. `/comparison` and the landing page make specific claims; FTC §5 makes over-claiming a legal exposure, not just an embarrassment. Today already found the site *under*-claiming in three places, which suggests nobody has walked the mapping recently in either direction. **Key transparency, end to end.** Clients pin a head and demand inclusion proofs — but: is the pin persisted correctly, is a fork actually surfaced to the *user* rather than only logged, and what does the app do when the relay simply stops serving a log it used to serve? A downgrade that looks like an outage is the interesting case. **Sealed sender and delivery tokens.** What can the relay correlate across a delivery key, a token batch, and timing? §21.4 revocation exists; the question is what is learnable before it is used. **At-rest on the device.** History is AES-GCM under a ThisDeviceOnly Keychain key. With sign-out now keeping it, the exposure of a lost-but-signed-out phone deserves a fresh look, including what app lock does and does not gate. **Blast radius from a relay flaw.** Tracked separately as #15 (the relay runs as a Postgres superuser, which turns a SQL flaw into RCE via `COPY … FROM PROGRAM`). Worth doing a broader pass in the same spirit: what else on that box is reachable from the relay process, and what secrets are readable by it. **Media privacy regressions.** EXIF/GPS stripping is now an explicit guarantee with tests, but it was an *accident* of resizing for a long time before that. Check the other paths that touch user files — attachments, avatars, backups — for the same shape of accident. **Rate limits and abuse.** Limits were raised sharply during debugging on 2026-09-01 (`FN_BUNDLE_RATE=2000`, `FN_BUNDLE_RATE_TARGET=600`, `FN_SEND_RATE=6000`) and **have not been reviewed since**. They should be set from what a real client needs, not from what an afternoon of debugging needed. ## Suggested shape Read-only investigation producing findings, each with evidence and a severity, filed as its own issue. No fixes in this ticket. Owner has suggested running some of this as a multi-model review; a second opinion is much of the value. ⚠️ The 2026-09-01 code freeze is in effect: investigate and report, do not change. ⚠️ Known and deliberately excluded: unrotated credentials in `.env` backups, already assessed and parked.

paulhitt commented

2026-09-01 23:01:53 +00:00

(Migrated from gitlab.com)

mentioned in issue #17