the security model
The mechanisms behind the front page. Short version: your sync key never leaves your device, our servers only ever hold your synced data as ciphertext, and every Google background connection is one switch away from off.
identity
Signing in to UniAuth goes through uniauth.id/api/oauth/*. Each authorization request carries a fresh proof-key challenge, so the code that comes back is useless without the verifier that only your browser holds.
keys
Surferse derives a 32-byte sync key in one of two ways.
desktop, after you unlock your UniAuth Vault (the USK comes from its master password)
HKDF-SHA256(USK, salt="", info="uniauth.browser.sync.v1", 32)
otherwise, and always on iOS
PBKDF2-SHA256(NFC(passphrase), salt=account email, 600000) → HKDF → 32 bytes
The email salt isn't secret; it only defeats precomputed tables. Your passphrase is the secret.
Unlocking your Vault happens entirely on your device: PBKDF2-SHA256 over your NFC-normalized master password, then HKDF, then an AES-GCM unwrap of your stored key. Our server supplies only the salt, the iteration count and that wrapped key — never your master password, and never the USK.
Both paths need you to act: signing in alone never shares data between devices. Until you provide a key, each browser profile encrypts its data under its own random key, which no other device, and not us, can read. Sync payloads, like UniAuth Vault items, are sealed with AES-256-GCM.
our servers
| Your synced data | ciphertext only |
| Your sync key or passphrase | never |
| Your Vault master password or USK | never |
| The pages you visit | never — history syncs only as ciphertext |
| Your account profile | email, display name, avatar URL |
| Each installation | a random device id, not from hardware |
Because we don't hold your key, we can't read your synced data, export it in readable form, or recover it if you forget your passphrase. Like any server, ours see your IP address when your devices connect.
updates
At every startup, signed in or not, Surferse for macOS fetches surferse.app/api/update/surferse/latest.json, verifies its ED25519 signature, and tells you when a new build is out. It never installs an update on its own.
The request carries no cookies. The server sees your IP address and user agent.
Surferse sends no Google telemetry by default: usage metrics have no endpoint compiled in, and field-trial seeds are never requested.
In the default Balanced mode, component updates connect to Google on macOS and iOS. On macOS, so do DRM-protected media, web push, and the Chrome Web Store whenever you install or update an extension. Block all stops every Google background connection on both platforms, and each platform pays for it differently:
Safe Browsing lookups go through surferse.app rather than straight to Google, and send 32-bit hash prefixes, never the addresses you visit.
the download
macOS disk images are signed by UniAuth Inc. Each one's sha256 is published on the download and releases pages, computed from the file as it's served. Check it before you open anything.