maneuler / vaultEmergency access and recovery
Proposal, not an available feature. No network permission or new data collection is enabled. These RFCs are locally prepared; remote review/merge awaits the owner repository.
Current architecture
The local-only app has no authenticated delivery service or trusted clock. A recipient who already has a decryptable key cannot be forced by client code to wait.
Design under review
First provide a printable recovery procedure without collecting secrets. For future delayed access, model encrypted grants to recipient identity keys, owner cancellation and an authenticated delivery/notification service. Do not give the contact a usable decryption key before the release condition. Document the trust placed in service availability, clock and approval logic; an untrusted server cannot by itself enforce a cryptographic time delay.
Milestones
- M1: cryptographic protocol and abuse analysis for enrollment/revocation/clock rollback
- M2: isolated recipient grant prototype and owner notification/cancellation simulation
- M3: audited service, identity verification, recovery drill and opt-in policy before launch
Required acceptance tests
- Unapproved recipient identity changes invalidate grants
- Owner cancellation before release prevents future key delivery
- Offline/service-failure state cannot silently release a grant
Limits
No dead-man switch is shipped. Any contact who has received plaintext can retain it; revocation cannot erase that copy.
Any implementation must preserve local unlock/export, add KDBX/KeePassXC regressions for crypto/format changes and update privacy disclosures before new data flows begin.