Bring your own encrypted storage
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 app currently exports encrypted files and has no provider OAuth or WebDAV/S3 adapter.
Design under review
Build provider adapters outside the web vault’s default network surface. Transfer only encrypted KDBX, use ETag/generation conditional writes and keep encrypted conflict backups. Store provider tokens in OS protected storage with least scopes. Require explicit destination selection, HTTPS, safe redirect/host rules and path validation. Start with native WebDAV; follow with S3 presigned access and provider-approved Drive/Dropbox OAuth.
Milestones
- M1: common ciphertext transport contract and local fake-provider tests
- M2: native WebDAV adapter with TLS, conditional-write and offline recovery tests
- M3: S3/Drive/Dropbox consent, token revocation and provider-review milestones
Required acceptance tests
- Conflicting remote generation never overwrites either copy
- Redirects cannot leak authorization to an unapproved host
- No plaintext vault or master credential reaches a provider
Limits
Provider metadata and OAuth identities are not zero-knowledge. Browser-only OAuth and access scopes require separate review; no provider is connected automatically.
Any implementation must preserve local unlock/export, add KDBX/KeePassXC regressions for crypto/format changes and update privacy disclosures before new data flows begin.