The server needs the encrypted blob, a derived vault lookup key, browser-limit metadata, rate-limit metadata, and plan state to operate sync.
What Relay can and cannot see
Readable bookmark titles, URLs, folders, and profiles are encrypted in the browser before upload. The recovery key is not sent to Relay.
Sensitive actions require a local ownership token recovered only after a browser decrypts the vault with the Recovery Kit password or, on compatible Chromium builds, a passkey.
Relay intentionally stores the username, stable account and Support IDs, coarse authenticated activity, and sharing relationships for support, abuse controls, and product operation. It still cannot read the encrypted bookmark vault.
Recovery would require Relay to hold a decryption path. Relay intentionally does not.
Each shared collection is encrypted locally with a fresh random key kept in the URL fragment. Relay stores ciphertext and limited expiry, import, and revocation metadata, but the fragment key is not sent to the server.
Recipient keys keep live shares private
Each Relay account creates a P-256 sharing keypair. The public key supports contact sharing; the private key remains inside the encrypted vault. Live profile keys are wrapped for a specific accepted recipient, so the server can deliver and update encrypted shares without holding the key needed to read them.
Extension permissions
Relay's Chromium and Firefox clients request only the permissions needed for native bookmark sync and local bookmark tools. The optional passkey permission applies only to compatible Chromium builds:
- bookmarks: read and update the browser bookmark tree during sync, Preview, Tidy, Undo, restore, and profile switching.
- storage: keep local session state, browser identity, plan cache, and sync metadata.
- alarms: resume debounced Pro auto-sync reliably when browser background execution sleeps.
- Relay-domain host access on Chromium: let the popup use
relayextension.comas its WebAuthn passkey domain. Relay opens no login tab and injects no content scripts. - Firefox boundary: the first Firefox release requests no host access and uses the Recovery Kit password instead of passkeys.
Passkeys can approve a compatible Chromium browser; they do not replace vault encryption
On compatible Chromium builds, Relay stores the passkey public key, attached username, limited credential metadata, and a credential-bound encrypted recovery-key envelope. WebAuthn PRF output opens that envelope only on the client and is never sent to Relay. Compatible passkey providers may synchronize the credential across browsers and devices. Biometric data and device PINs stay with the operating system or passkey provider. Firefox uses the Recovery Kit password in its first release.
Health, Tidy, and Undo stay browser-side
Library health checks, canonical URL-copy detection, local bookmark organization, Undo snapshots, and action result messages are computed from this browser's bookmark tree and local storage. They do not require Relay to read plaintext bookmarks on the server.
Independent verification roadmap
Relay is preparing for an independent browser-extension security review. We will publish only completed review summaries, not future-tense certification claims. The planned review scope is:
- Manifest permissions and Content Security Policy.
- Bookmark sync, profile switching, and restore behavior.
- Client-side encryption and key handling.
- Backend API boundaries, rate limiting, and ownership checks.
- Public website claims against real implementation behavior.
Report a security issue
Please use the support page for a coordinated reporting path. Do not send recovery keys, full bookmark exports, sensitive URLs, or exploit playbooks in an initial report.