maneuler / vaultEncrypted sharing with honest limits
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
Current exports share a complete encrypted file; no public sharing endpoint exists.
Design under review
For a single item, generate a fresh random content key locally, authenticate version/expiry metadata with the encrypted payload, and put the decryption secret in the URL fragment, never in a request URL. A minimal opt-in relay stores ciphertext and opaque fetch tokens only. Enforce expiry and atomic view limits server-side, disable caching/referrers, and separate the recipient origin from the vault app. Publish that server limits govern future retrieval only.
Milestones
- M1: protocol and recipient-origin threat model plus schema/fuzz tests
- M2: local relay prototype, concurrent consumption and authenticated metadata tests
- M3: privacy/abuse review, operational expiry deletion, redacted logs and opt-in rollout
Required acceptance tests
- No fragment/key or plaintext appears in network requests or logs
- Tampered metadata and truncated ciphertext cannot decrypt
- Concurrent last-view requests cannot both consume a one-view token
Limits
A recipient can save or screenshot plaintext. View limits and expiry cannot revoke a downloaded/decrypted copy; no guarantee to the contrary.
Any implementation must preserve local unlock/export, add KDBX/KeePassXC regressions for crypto/format changes and update privacy disclosures before new data flows begin.