If the operator stops
Pollis is run by one person. This is what breaks, and in what order, if that person stops, and what an outside observer can conclude while it happens.
None of this puts message confidentiality at risk: no asset below can read a message, because the servers never hold plaintext or private message keys. The risks are availability, distribution, and guarantees that depend on someone publishing.
What is singly held
| Asset | What it does | If it is lost |
|---|---|---|
| GitHub repository | Source, CI, releases | No releases or CI gates. Source already published stays available |
| Updater signing key | Signs auto-update manifests | The worst single loss. Its public half is built into every installed app, so no future build could be accepted as an update and every user would have to reinstall by hand |
| Transparency log signing key | Signs all three transparency trees | The log cannot be republished, and moving to a new key is not yet cleanly recoverable (below) |
| Apple and Azure signing | macOS notarization, Windows signing | No new signed builds. Installed apps keep working |
| Cloudflare | DNS, website, Delivery Service, CDN | Everything user-facing stops. The largest single dependency |
| Turso | Metadata and commit-log databases | The Delivery Service cannot serve. Message content was never stored there |
| AWS | Optional relay overlay | The overlay stops. Pollis still works, without IP-address protection |
| LiveKit server | Voice, video, screenshare | Calls stop. Text messaging is unaffected |
| Resend | Sign-in email codes | Nobody can sign in or add a device. Existing sessions keep working |
What breaks, in what order
| When | What happens |
|---|---|
| Immediately | Nothing. Messages deliver, the site stays up |
| ~2 days | The daily transparency publish stops, so new keys and builds are no longer anchored. status.pollis.com still reports the service as up, because it is |
| ~60 days | GitHub disables scheduled workflows on an inactive repository; every cron stops |
| Months | Apple and Azure signing credentials lapse; no new signed builds are possible |
| Any time | A vulnerability or outage goes unfixed |
Between day two and month two the system is at its most misleading: everything a user touches still works, but every guarantee that depends on someone publishing has stopped.
A stalled log looks exactly like a withheld one
The transparency trees are republished daily, and the signed tree head for a given size stays byte-identical forever. From outside, three situations look the same: the log is healthy and idle, the publisher has been abandoned, or entries are being withheld. Polling the served log cannot tell them apart.
The publisher's run history separates them, and anyone can read it without credentials:
gh run list --repo actuallydan/pollis --workflow=transparency-publish.yml --limit 5 --json conclusion,createdAt,url
How to read a stall:
- A stalled publisher says nothing about honesty. The supported claim is "the log is not currently being published", not "Pollis is withholding entries".
- A stale head with a dead publisher is not "healthy" either: a coerced operator would produce the same thing.
- What resolves it is to keep the heads you were served and compare them later and with other people. Two signed heads that disagree are permanent proof. That is what pollis-verify is for.
The operator treats a publisher stall longer than 48 hours as a correctness incident, and acknowledges publicly any stall not fixed within seven days on status.pollis.com.
What is not solved yet
- No second key holder. The two pinned signing keys have one custodian. A second holder is the most valuable continuity step, and needs a second person.
- Log-key loss is not cleanly recoverable. The same key signs the binaries tree, and a new log key can only reach users in a client update verified by that tree. Splitting the two anchors is designed and tracked in #754.
- Nobody independent watches the log. Witness and gossip monitoring is designed but unbuilt (#763). Until it exists, "no alarm" means "nobody looked".
- No legal succession. Ownership, inheritance and escrow need a legal entity to hold them. A timer that publishes a key automatically would be worse than nothing, since it is an unattended path to the signing key.
The engineering plan, with the full asset register and handover order, is in
docs/operational-continuity.md.