Oak Keyring's security posture is local-first: secrets are protected before they leave the device, sync storage is not trusted with the vault key, and recovery must preserve the same boundary instead of bypassing it.
The core asset is the local encrypted vault. Oak Keyring's security story starts by keeping plaintext secrets and the key material that can reveal them out of the sync provider's trust boundary.
This does not mean the public site should claim perfect device security or audited resistance against every local attack. It means the product is organized so the remote storage path is not the primary place users must place trust.
For sync, the important public claim is narrow: secrets are encrypted before they are synchronized, and Google Drive should not receive the vault key. Remote storage can move encrypted state, but it should not be able to read the vault contents.
That is the useful meaning of zero-knowledge on this site. It applies to the sync storage boundary, not to every possible threat, device compromise, extension, backup, or future integration.
Password managers fail when secret handling becomes scattered. Oak Keyring treats secret entry, unlock, command execution, cancellation, error paths, cleanup, and recovery as one lifecycle that must stay visible to the architecture.
The public page intentionally avoids implementation-sensitive details. The security principle is still public: every path that touches sensitive material needs an exit path, not just a success path.
Recovery is security-sensitive because it is where convenience can quietly defeat the vault model. Oak Keyring treats recovery as part of the same key and vault lifecycle, not as a support shortcut that gets to ignore normal ownership boundaries.
The goal is that losing a device, setting up a new one, or restoring from synchronized data does not change who controls the vault or what the sync provider can learn.
Oak Keyring is still a first-preview project. This site does not claim a stable public release, a public third-party audit, or a complete public implementation review.
The security posture described here is therefore a claim about product boundaries and design priorities, not an invitation to treat the project as a finished replacement for production password-management workflows.
Report suspected vulnerabilities privately through the GitHub Security Advisory form or by emailing alphaqiu@gmail.com.
Do not post passwords, vault files, recovery words, OAuth secrets, tokens, or private logs in public issues or discussions. Use disposable vault data with fake credentials when a reproduction needs sample records.
