Failure model
From docs/failure-model.md in the repository, rendered 2026-10-12.
Design-stage model, written before the code. Much of it is now implemented as 0.0.1-alpha.11; the per-row notes and docs/spec/alpha-0-format.md record what is built. This document states what the design is meant to tolerate, what it limits, and what it does not cover. Statements such as "designed to" become claims about the product only after the tests named in TESTING.md show them.
Public statements about reliability must match this document. In particular, any marketing message about "no single point of failure" (requirement M-005) has to link here and must not claim more than this document lists.
Requirement IDs (F-, S-, P-, N-, M-) refer to the project requirements list. The wider design is described in docs/architecture.
Failure table
| Failure | Effect on data | Effect on sync | What prevents or limits it | What does not | Requirement IDs |
|---|---|---|---|---|---|
| Loss of all keys and of the recovery key | Data in storage stays encrypted and cannot be read by anyone, including the project. There is no key escrow. | No device can unlock or add new devices. | A 24-word recovery key with checksum, shown once; optional threshold split kept in two or three physical places; a recovery test right after creation and then yearly; at least two security keys for daily unlock. Users are told about the consequence before adding data. | If every key and every recovery share are lost, nothing in the design can restore access. The recovery key is a single point of failure that the software cannot remove. | S-002, S-014, F-042, S-005 |
| Loss of one security key | No data loss while another registered key or the recovery key is available. | Unlocking continues with the remaining key. Strongroom folders stay locked until a registered key is present. | Registering at least two keys; a recovery kit for emergencies. | Losing every key that wraps a Strongroom folder, together with the recovery key, leaves that folder unreadable. Whether a passphrase alone may unlock a normal vault is an open decision (TBD). | S-004, S-005, S-012, S-014, F-042 |
| A storage provider deletes data, rolls back to an older state, or locks the account | Data survives if the configured policy keeps copies on another provider or on own devices. With one provider and no other copy, data can be lost. | Sync continues through other storages and between devices. A rolled-back or missing object is meant to be detected through the ledger and flagged. | Several providers (mirroring or erasure coding); own devices counted as copies; periodic scrub and repair from other copies; retention policies with alerts; the index and manifest are mirrored to every provider and to devices. | A single provider with no second copy. A provider can still see object sizes and access times and can refuse service. Rollback detection is a design goal, not a tested property. | F-017, F-018, F-020, F-021, F-031, F-032, S-006 |
| Two devices stolen or destroyed together before changes reach cloud storage (use case UC-1) | Changes that exist only on those two devices are lost. Earlier synced data is unaffected. | Other devices do not receive the lost changes. | The ledger knows which blocks exist only on certain devices; the app is meant to show "only on these devices, not yet in cloud" and policies can raise an alert as soon as a network is available. Devices in the same site count as one failure domain. | Changes that did not leave the two devices cannot be recovered. A stolen, unlocked device can expose what that device could read. | F-011, F-031, F-032, F-033, S-012 |
| One device is stolen or lost | Data on the device is encrypted at rest; other copies are unaffected. | The device can be revoked from another device. | Device revocation with rotation of storage credentials and folder keys; a signed remote wipe command that is applied when the device next sees a network; optional automatic wipe after failed unlock attempts; Strongroom folders stay locked without the security key. Since 0.0.1-alpha.8: revocation cuts the device off from the ledger and from peers and gives the vault new keys for everything written afterwards, and the signed wipe order is applied when the device next reaches a storage (alpha-0-format.md section 21). | Storage credentials are not rotated yet, so the revoked device can delete ciphertext until they are changed at the provider; automatic wipe after failed unlocks does not exist. A thief who keeps the device offline does not receive the wipe command. Revocation and encryption are the protection in that case, and wipe is an additional layer only. Wipe does not reach offline removable disks. | F-035, S-001, S-009, S-011, S-012, F-033 |
| Relay or DHT bootstrap nodes are down or blocked | None. | Peer discovery falls back in layers: known addresses, local network, the rendezvous record in the user's own storage, then manual invitation. Without a relay, some network types cannot connect directly and the app shows "not connected". Sync through shared storage is unaffected. | No central tracker or account server; layered discovery; relays are optional and self-hostable; DHT is a fallback and is off by default. | Two devices behind restrictive NATs, with no shared storage and no relay, cannot find or reach each other outside the local network. Relay and DHT operators can observe IP addresses and traffic volume. | F-012, F-013, F-005, N-001 |
| Corruption or silent loss in one copy (bit rot, a peer that claims data it does not hold, a lost object) | One copy is bad; other verified copies can repair it. | Affected blocks are marked and fetched from other sources. | Authenticated encryption and keyed hashes on every object; periodic scrub with challenge-response checks; self-describing packs so the index can be rebuilt; peers that fail proofs are marked unreliable. | Corruption in every copy at the same time. Blocks that exist in only one place and have no verification yet. | S-001, S-006, F-020, F-031, N-007 |
| A disk of a disk pool is lost, stolen or dies | The objects on it are lost unless another storage or disk holds them; the ledger and the pool index say which objects were only there (varsto disk retire prints the count). Stolen disks expose only ciphertext and a marker that names the pool and disk, not the vault. |
Sync is unaffected. Files whose only copy was on the disk stay pending and name the disk ("attach disk data-01 (shelf)"); policies count the disk's copies as verified at its last check and raise an alert when that ages out. | Encryption of every object; the pool index and the disk's own index make the loss enumerable; durability policies that require a second copy elsewhere (another storage or, in the future, another disk group); retiring a disk prints what exists only on it. | Without a disk group rule (varsto disk group <pool> --copies N) or another storage, a lost disk is lost data. No SMART or health reading; no repair onto a replacement disk by itself. |
F-040, F-031, F-032, S-001 |
| Removable disk not verified for a long time | The disk may have degraded while offline. Its content is known only as of the last check. | Sync is unaffected. The disk counts as a copy only while its claim has not expired. | Claims in the ledger expire and become "assumed", not "present"; retention policies can require a check every few months and alert when it is overdue; on re-attach the disk is verified and damaged blocks are repaired from other copies; disk identity checks detect clones and restored disks. | A disk that fails while it sits on a shelf. A disk with no second copy anywhere. Offline disks are protected only by encryption, not by wipe. | F-040, F-031, F-032, F-033, S-001 |
| Device clock is badly wrong | No data loss is expected: event ordering uses logical clocks and sequence numbers, not wall-clock time. | Ordering of changes is unaffected. Time-based items (claim expiry, freshness checks, alerts, request signing towards some providers) may be wrong or rejected on that device. | Logical clocks and version vectors in the ledger; simulation tests with clock skew are planned. | A wrong clock can still cause false alerts or failed requests until it is corrected. Behaviour against real providers is not tested yet. | F-031, F-003, N-007 |
| Malicious member of a shared folder | The member can read what the folder shares and can change or delete files within the permissions given. Anything already downloaded stays with them. | Their changes sync to other members like any other change. | Version history and trash allow restoring earlier states; the change history view shows who did what; removing a member moves the folder to a new key (a share epoch) that only the remaining members receive, so new data is not readable by them (alpha-0-format.md section 24). | Content the member already read or copied. Fine-grained permission rules are not specified yet (TBD). | F-004, F-003, F-025, F-026, F-034, S-001 |
| Software bug during the alpha stage | Bugs can cause data loss or corruption. File formats and protocols may change without a migration path. The cryptography has not been independently audited. | Devices may diverge or refuse to sync after a bug or an incompatible update. | Prominent alpha warnings; version history; ledger invariants checked in deterministic simulation with fault injection; fuzzing and property tests; an index that can be rebuilt from the stored objects; the advice to keep independent backups. | Bugs that tests do not find. Users who treat alpha software as their only copy. | N-006, N-007, N-010, S-013, F-020 |
| The maintainer disappears | Existing data remains readable by anyone holding the keys: the storage format is documented and the recovery kit comes with an offline reader. | Sync keeps working between installed clients, because there is no project-run server to switch off. | Open, documented storage format and protocols; source-available code; no account server; restic-compatible backup option; recovery kit independent of the application. | Bug fixes, security updates, store releases and OS compatibility stop. Continued development by others is limited by the licence terms. Clients may stop working after operating system changes. | F-005, F-019, F-020, N-004, F-042 |
Remaining single points of failure
The design reduces single points of failure but does not remove these:
- The user's keys and recovery kit. There is no escrow and no account recovery. This is deliberate (S-014).
- The user's own site and provider configuration. The software cannot verify geography. A provider region name does not prove where a data centre is, and two "different" providers can share infrastructure (F-033).
- The software itself. One code base implements the ledger, the cryptography and the sync. A bug there can affect every copy. Independent implementations of the readers and an independent audit are goals, not facts (N-004, S-007).
- The release pipeline and the maintainer. Updates and signed releases depend on a small team (S-007, N-005).
- Platform dependencies. Operating system keystores, hardware security keys and mobile background limits are outside the project's control (S-005, F-036).
- Optional infrastructure. Relays and DHT bootstrap nodes are not required for sync through shared storage, but without them some networks cannot connect directly (F-012, F-013).
Maintaining this document
Update this document in the same change as any design change that adds, removes or alters a failure mode, a mitigation or a requirement ID it cites. Each table row must cite at least one existing requirement ID and must avoid absolute promises.