Security

Design goal

TresorLink is built around a simple rule: bookmark content should be readable only on the user's trusted Apple devices. The app stores and syncs encrypted bookmark records, while the keys needed to read those records stay protected by Keychain and device authentication.

TresorLink does not operate a bookmark-sync server and does not receive plaintext bookmark URLs, titles, notes, or vault keys.

What gets encrypted

TresorLink encrypts bookmark URLs, titles, notes, and tag names on device using AES-256-GCM through Apple's CryptoKit. AES-GCM provides confidentiality and integrity in one operation: encrypted data cannot be read without the key, and tampering is detected during decryption.

Each encrypted field is stored as a combined AES-GCM sealed box containing the nonce, ciphertext, and authentication tag. CryptoKit generates a fresh nonce for each encryption operation, so saving the same URL twice does not produce the same ciphertext.

Some app metadata remains outside the encrypted fields so the app can function and sync correctly. This includes record identifiers, creation dates, deletion state, key version identifiers, and relationships such as which encrypted bookmarks belong to which encrypted tags.

Vault keys

TresorLink uses 256-bit symmetric vault keys. Keys are stored in Keychain and loaded into TresorLink only after device-owner authentication, so unlocking requires Face ID, Touch ID, or the device passcode.

Each device has an active vault key used for new encryptions. That key has a short key version derived from a SHA-256 fingerprint of the key material. Bookmark and tag records store this key version next to their ciphertext, allowing TresorLink to choose the right key when decrypting.

Vault keys are marked synchronizable, so they can sync through iCloud Keychain when the user has iCloud Keychain enabled. This allows a new trusted device to decrypt existing bookmarks after both the encrypted records and the matching keys have synced.

TresorLink does not have a server-side recovery key, master password, or backdoor. If encrypted bookmark data exists but the matching Keychain keys are unavailable, TresorLink cannot decrypt it.

CloudKit sync

TresorLink stores bookmark data in SwiftData with CloudKit-backed sync. CloudKit receives TresorLink records whose sensitive fields are already encrypted by the app. It does not receive plaintext bookmark URLs, titles, notes, or tag names from TresorLink.

Vault keys sync separately through iCloud Keychain, not through the TresorLink website or a TresorLink server. Apple documents iCloud Keychain as end-to-end encrypted.

Both the main app and the Safari native handler use the same App Group SwiftData store and configure SwiftData with CloudKit sync. The main app has the steadier process lifecycle, while the Safari handler can also export extension-originated changes when it is invoked.

Unlocking

When the app unlocks, TresorLink asks the system to authenticate the user with device-owner authentication. After authentication succeeds, the app loads all available vault keys from Keychain into memory and records the active key version for new writes.

When the vault locks, TresorLink clears the in-memory keys. The encrypted database remains on disk, but the app no longer has the key material needed to read bookmark content until the user authenticates again. This keeps private URLs behind a separate vault unlock, even when the device itself is already unlocked.

Safari extension architecture

The Safari WebExtension user interface is JavaScript and HTML running inside Safari. It does not read the SwiftData store directly. Instead, it sends native messages to SafariWebExtensionHandler, the extension's native Swift handler.

The handler uses the shared App Group container to read and write the same encrypted local SwiftData store as the main app. The handler encrypts new bookmark content before saving it, decrypts existing content only after the user unlocks TresorLink, and participates in CloudKit-backed sync through SwiftData.

Extension sessions

When the user unlocks the Safari extension, the native handler performs device authentication, loads vault keys from Keychain, and creates a temporary extension session.

The handler creates an ephemeral 256-bit AES session key using Apple's secure random generator. This key wraps the vault keys into an encrypted envelope that is stored in the App Group container. The session key itself is returned to the Safari background script and kept only in that extension process memory.

For later extension actions, the browser side sends the session ID and session key back to the native handler. The handler verifies the session, checks expiration, unwraps the vault keys, performs the requested operation, and returns only the data needed for that action. If the background process loses the session key, the persisted envelope cannot be opened. If validation fails, the wrapped envelope is deleted and the extension returns to the locked state.

Saving from Safari

When the user saves the current page from Safari, the extension reads the current tab title and URL only as part of that explicit action. It sends those values to the native handler, where they are encrypted before storage.

The extension does not collect browsing history, run analytics, or send bookmark content to a third-party server.

Opening bookmarks

When the native app opens saved bookmarks in Safari, it does not place decrypted URLs into a website URL. Instead, the app writes the selected bookmark IDs into App Group storage and opens a fixed intent page at https://tresorlink.com/intent/open.

The Safari extension detects that intent page, asks the native handler to resolve the pending bookmark IDs, decrypts the matching URLs locally, and then navigates Safari. The TresorLink website sees only the intent page request, not the actual bookmark URLs.

Security boundaries

TresorLink does not reveal bookmark URLs just because the device is unlocked. If the TresorLink vault is locked, the app and extension do not have vault keys in memory and bookmark content remains encrypted.

Once the user authenticates and unlocks TresorLink, the app must decrypt URLs locally to display, copy, export, or open them. At that point, someone with access to the active unlocked vault could see the same information the user can see.

TresorLink protects bookmark content at rest and during sync by encrypting sensitive fields before they leave the device. Apple services may still process account, device, transaction, sync, and operational metadata according to Apple's systems, but they do not receive plaintext TresorLink bookmark content from the app.