Security by design
Your key. Your permission.
Ostrilo keeps private keys in an encrypted vault on your device. Websites ask for signatures through the extension, and you decide what they can do.
Private keys stay local.
New vaults use Argon2id to derive a key from your master password and AES-256-GCM to encrypt private keys in local extension storage. Keys are not copied into browser sync.
Signing happens in the extension’s background context. A website receives your public key or a signed event. It never receives your private key or master password.
Trust is specific to each site.
A site must have your consent to read your public key, even if you’ve given it a high trust level. You can grant or refuse access, and manage that choice later in Permissions.
Choose which event kinds a trusted site can sign without a prompt. Text notes, deletion requests, zap requests, and relay or HTTP authentication always require explicit approval.
For each approval, Ostrilo shows the requesting origin, signing identity, event kind, and content. That gives you the context to decide before a signature is created.
Lock when you step away.
Lock your vault manually or set an automatic timeout. Password checks protect sensitive actions such as deleting a key, granting high trust, and changing security timeouts.
You can change your master password from Security settings. The extension re-wraps your keys under the new password, with recovery handling for an interrupted change.
Keep a copy you can recover.
When creating your first identity during onboarding, save an encrypted backup with a separate passphrase. Restore it through the import step in a fresh installation, then check that the public key matches.
Keep the backup and its passphrase separately. Your private key is your identity, so a recoverable copy matters. The backup guide covers the available flows and what each file contains.
Follow the code, all the way to signing.
Ostrilo is MIT licensed. The source documents how requests move from websites to the extension, how permissions are checked, and where signing happens.
Unit, integration, security, and Chromium browser tests exercise the signing journeys. CI checks coverage, builds both browser targets, inspects bundles, audits dependencies, and scans for committed secrets.
Explore the test strategy · See the verification workflow
For a deeper assessment, the source README documents the trust boundaries, browser coverage, and review status.
Help keep signing safe.
Report vulnerabilities through GitHub’s private reporting form. Use a disposable identity for reproduction, and keep keys, passphrases, vault files, and unredacted backups out of reports.
The security policy explains how reports and disclosure are handled. If the private form is unavailable, hold the details and check again rather than posting them publicly.