Threat model

This document tells who Lasbolt defends against, what it protects, and what is out of scope. GOAL.md has the decisions. docs/DESIGN.md has the mechanisms. If a design change weakens a statement here, change this document in the same commit.

1. Assets

2. Adversaries and what Lasbolt promises

2.1 Network attacker

• Promise: cannot read or change traffic.
• How: TLS in front of lasboltd (the operator’s proxy or the server). Cookies are __Host-, Secure, HttpOnly, SameSite=Strict. Tokens are bearer secrets and need TLS.
• Limit: the operator must set up TLS. Dev mode on localhost has no TLS.

2.2 Theft of the server disk or a backup (server not running)

• Promise: server-readable data stays encrypted. E2E data stays encrypted.
• How: the data key is wrapped by the KEK. With the passphrase provider, the KEK comes from Argon2id. With the key-file provider, the KEK is a file that must not be on the same disk.
• Limit: with the passphrase provider, the thief can guess the passphrase offline at Argon2id cost. A sealed backup (--backup-recipient) also needs the offline backup identity. A long random passphrase is the defense.

2.3 Running server compromised, passive (reads memory and DB)

• Promise: E2E data stays secret. The master password and the encryption keys stay secret. The secret of a scoped key stays secret: the server stores only the hash of its token, and the token cannot open the key’s keys_enc. Grant rows are sealed to the principal.
• Lost: all server-readable data, because the data key is in memory. This is by design (GOAL.md: server-readable by default).
• Recovery kit (DESIGN 8.1): the server holds recovery_keys_enc and HashToken of the auth key of the code. The code has 130 random bits, so neither can be guessed offline. The server never sees the code or its enc key.
• Tab unlock (DESIGN 7.4): while a browser tab is unlocked, server memory holds the wrap key W of that tab (at most 8 for each session, gone after 15 minutes without use, at log out and at restart). With W and the sealed blob a reader could open the user keys. The blob is only in the tab (sessionStorage), so memory alone is not enough, and the data key is in memory anyway. A copy of the database or of a backup has no W. The E2E promise of this section is the same as before: a passive server that reads memory and the database, and never sees a tab blob, gets no E2E data.

2.4 Running server compromised, active (changes code or answers)

• Web client: no promise for E2E. The server sends the JavaScript and the WASM, so it can send code that reads E2E data after unlock. This is true for every web-based E2E product.
• CLI and native clients: E2E values stay secret, and the client detects changed or forged E2E ops (signatures, bundle checks, trust rules in DESIGN 4.7). This is the main reason for the CLI (GOAL.md, Phase 3). This promise holds fully for lasbolt login --password (the CLI derives the keys itself, trust rule 1).
• Device-code sessions and scoped keys get their keys from the web app, so they have the web caveat. An active server can serve page code that seals keys of its own choice. In addition, HPKE base mode does not prove who sealed a grant, and the server knows the client’s public key. A session pins the user’s sign key at its first login (DESIGN 10.17), so a later change is detected, but an active server at the first login is not. A scoped key takes the owner’s sign key from its own encrypted bundle, which the server cannot change. Ops of a key count only with a valid cert of the user and only inside the cert scope.
• Recovery: an active server can serve a bad /recover page or kit card that sends the code away (the web caveat). A user who doubts the server must not type the code there.
• Limits for all clients:
  • Rollback and withholding (DESIGN 12.2, 12.8). Clients that can sign write signed checkpoints of each E2E folder, and every client checks the checkpoints of the server and the checkpoint that it remembers. A client finds that the server hides, changes or adds an op below a checkpoint that it knows, shows the problem rollback and refuses writes to that folder (CLI exit 10). Limits:
    • Forks. A server that shows two devices two different histories, and never forwards a checkpoint of one device to the other, is not found. A user can compare “checkpoint of , ”.
    • New device. A device with no memory trusts the checkpoints that the server gives. A server can hide all of them (and the newest ops) from a new device.
    • Ops above the newest checkpoint. Changes made after the last checkpoint that a device knows can be hidden from it. The cadence (one each hour, and one after each own write) makes the window short.
    • Restore. A server can change db_epoch to look like a restore. Clients then say “the server was restored”, but writes stay off until the user accepts (lasbolt e2e accept-rollback, Accept in the web app with the master password). Accept refuses a folder whose state does not agree with the checkpoints of the server either. A user who accepts a false restore loses the hidden changes from that device’s view.
    • Web memory. The web app keeps its memory in localStorage, which the server’s page code can change (the web caveat).
    • Key rotation (DESIGN 12.10). A scoped key or a pinned session made before a rotation finds the new user key by a forward walk of the signed chain from the old key. A bad server with a leaked old key can show it a forked chain at its first walk. Two records from one old key stop the client (key-fork); a client with a local store keeps the newest key that it reached. Making the key again closes this.
    • Purges (DESIGN 12.3, 12.9). A purge of an E2E entity needs a record that the user (or a key with write access) signed. The server checks it in the transaction of the purge and keeps it for ever, and clients accept a missing op below a checkpoint only if a verified record names it. So a bad server cannot “purge” E2E items as an excuse: ops missing without a record are a rollback. What remains: a server can withhold the records from a new device (it then sees a rollback for an honest purge: a denial of service, as with checkpoints); a leaked key with write access can sign purges of the items in its scope until it is revoked; the record proves who signed, not that all devices wanted it.
  • The server can see and change metadata (tree shape, plaintext E2E root names, timing).
  • The server can deny service.

2.5 Online attacker against login

• Promise: guessing is slow, and a valid password alone is not enough when TOTP is on.
• How: rate limits per IP and per user, TOTP, Argon2id on the client and a hash of the auth key on the server. Prelogin gives fake KDF parameters for unknown usernames.
• Limit: behind a proxy, rate limits per IP need --trusted-proxy. Without it, all clients share the proxy’s IP.
• Recovery is a login path (DESIGN 8.1). /api/recover/start and finish take tokens of the same per-user and per-IP buckets as the login, and give the same 401 for a wrong code and an unknown user. /api/recover/id gives a stable fake user ID for an unknown name. The code has 130 random bits, so online guessing is hopeless. A recovery needs no TOTP code (decision of the user): the kit replaces both factors. A new kit needs the auth key of the master password (same limits), so a stolen session cannot plant a kit.
• Reset links (/api/reset/check|finish) take a token of the per-IP limit for each failure. The token has 256 random bits and lives 1 hour.

2.6 Stolen credential

• A principal that has read a value or an E2E key can keep a copy. Revocation stops future access only.
• Signed revocation (DESIGN 10.20). The owner signs a revocation record with a cutoff HLC. Clients drop ops of the key above the cutoff (revoked-signer) and above the expiry of a v2 cert (expired-signer). So a leaked key secret and a bad server together cannot add new ops after the revocation. Limits:
  • A client with a local store (the CLI and its agent) also drops a backdated op that it did not hold when it first verified the record (the sticky rule). A client that sees the key’s ops only after the revocation (a new device, the web app) cannot tell a backdated op from a real old one.
  • A bad server can withhold the record, as it can withhold ops (2.4).
  • A revocation while E2E is locked ends access at once, but the record is signed only at the next unlock on the Keys page (or lasbolt keys revoke again after lasbolt unlock). Until then, clients do not know.
  • The CLI takes the sticky snapshot only while its E2E keys are unlocked (it must verify the record first). Ops that arrive while it is locked count as held.
  • A LASBOLT_KEY run keeps nothing on disk, so it applies the cutoffs only, as the web app does.
  • A write or admin device-code session with a user grant signs as the user. Signed revocation cannot stop it. A rotation of the user keys (DESIGN 12.10) does: it ends the session, and clients drop ops of the old key above the cutoff (rotated-signer; the sticky rule also drops backdated ones on clients with a local store).
  • After a rotation, old items stay readable to a holder of an old folder key, also their later edits: an item key does not change (@key is set once). New items use the new folder key. To lock an old key holder out of one item, move it into a new E2E folder, or make it again and purge the old one (DESIGN 10.17, 12.9).
• A device-code session gets keys_enc and the KDF parameters only through GET /api/v1/account/keys?unlock=1, for the master password unlock on the phone (DESIGN 13.10). A stolen session token can therefore be used to guess the master password offline. Limits: the Argon2id cost, 5 fetches per 10 minutes per user, and an audit row (keys_fetch) with the IP for each fetch. Scoped keys never get them. A device token already had this access.
• A refresh token used a second time revokes its session at once. The CLI refreshes under the store lock (or only in the agent), so a normal client never does this by mistake.

2.7 Malicious or tricked agent

• Promise: an agent gets only its scope. With lasbolt run, lasbolt inject and the MCP tools, secret values do not enter the agent’s context.
• Limits:
  • “Inject only” and output masking are done by the client. An agent that runs commands as the user can work around them. They reduce accidents; they are not a boundary.
  • Prompt injection: notes and metadata are written by other principals. Clients show the author, and the MCP tools mark them as untrusted data. An agent can still be tricked.
  • Metadata is untrusted input (DESIGN 10.18). Values have types and length limits, and the server checks every server-readable value. The server cannot check E2E values: clients check them when they decrypt and drop a bad one. The web UI makes links only for http and https URLs. A client that uses metadata (for example an auth header for a base URL) must treat it as input from another principal: a bad base_url can send a secret to another host. The UI shows the author and the device of each value.
  • meta grants. A principal with only a meta grant gets the meta key of an E2E entity. That key opens the name and the metadata fields only. Clients never use it for another field, also if a writer sealed one with it (core/e2e tests this). A meta principal that can write is limited to metadata fields by the server and by the clients (trust rule 2).
  • Per-use approval (DESIGN 10.21). For server-readable items the server withholds the secret values from sessions and keys and gives one value for each approval. For E2E items it is a boundary only for a principal without the item key (a just-in-time grant). A principal with a folder or user grant can read without asking: the check is in the honest client. A principal can keep a value or a key that it got, and values synced before @approve was set. The prompt reaches only an open web app. A user who approves without reading the prompt gives the value.
  • Fill and copy with approval (DESIGN 11.14). The browser extension and the macOS app ask through the agent, so the prompt names the login of the agent (the session or the key), not the front end. The front end is only in the purpose (“fill on github.com via Lasbolt extension in Chrome”, “copy in the Lasbolt app”), and the purpose comes from the client: any process of the same user can talk to the agent and write any purpose (section 3). Read the item, the field and the host before you approve. Cancel in a client does not take back the request: it stays pending in the web app until its 5 minutes end, and an approve after the Cancel gives the value to the next fill or copy of the same login, item and field. An approval ID is no secret that grants a value: the server gives the value only to the principal that asked.
  • Device-code phishing: an attacker can send the user an approval link. The approval page shows the code, the client, the host, the IP and the scope, and says “Did you not start this? Deny it.” The user can lower the access, never raise it. Lasbolt accepts this risk for ease of use, like AWS. The audit log shows each approval and the IP of the client.

2.7a Browser extensions and the native messaging host

• Promise: a web page cannot get a secret from Lasbolt. Only the extension of an allowed ID can start lasbolt nm-host (the browser enforces allowed_origins and allowed_extensions). The host relays five ops only (fill.match, fill.get, search, status, and lock, which drops the end-to-end keys and gives no data). fill.match and search give names, usernames and URLs, never a secret value. fill.get gives only username, password and TOTP of an item whose URL fits the page, checked again in the agent, with scope and the audit as for lasbolt read (the audit names the extension, set by the host).
• Limits:
  • Any process of the same user can talk to the agent socket and so skip the host (THREAT_MODEL 3). The host adds no boundary there. The extension ID is a check of the browser, not a secret.
  • The URL comes from the extension. A hostile or buggy extension build can send any URL, so the extension ID list in the manifest is the control. The agent still refuses a URL that does not fit the item (look-alike hosts, http, other registrable domains).
  • An extension user action is needed for a fill in the extension (DESIGN 11.4), but the agent cannot see it. The host cannot tell a click from a script of the extension.
  • Matching by registrable domain gives a login to a sibling subdomain of the same site (for example a.example.com and b.example.com). Hosts that share a public suffix entry (github.io) stay apart.
• In the extension (DESIGN 11.11):
  • Only the background talks to the host. The URL that it sends is the URL of the tab from the browser, never a value from a page or a content script. A web page cannot send a message to the extension (no externally_connectable, no web_accessible_resources).
  • The values go to one frame: the top frame, or a frame whose origin and the origin of each frame above it are the origin of the top page. A cross-origin frame, and an opaque frame (about:blank, srcdoc, data:, blob:), never gets a value. The background checks it with the frame data of the browser, and the content script checks it again.
  • A fill needs a user action: Fill in the popup, the shortcut, or a pick in the inline menu. The content script acts only on events with isTrusted, so a page script cannot open the menu or pick an item.
  • The inline icon and menu are in a closed shadow root. The page sees the element, not its content. The menu has names and usernames only. A secret enters the page only at the fill. The icon shows on each login field, so the page does not learn from it if Lasbolt has a login for the site.
  • Approval waits (DESIGN 11.14). The background keeps the approval ID; the popup, the content scripts and the page never see it. A fill after an approval goes only to the tab and the frame of the click that started it, and only if the full tab URL and the document of the frame did not change; a navigation stops the wait. The click is the user action, also when the approval comes minutes later.
  • Limits. After the fill, the page (and each script on it) can read the values in the fields: this is true for each password manager. The page sees the host element of the menu and can hide it, cover it, or stop its key events (a denial of service, or a trick to make the user click). A page can learn that the extension is installed. The clipboard is cleared after 30 seconds without a check, so a copy that the user made in that time is cleared too.

2.7b The macOS app and Touch ID unlock (DESIGN 11.13)

• Promise: the Touch ID item gives enc only to the Lasbolt app (code of the team with the keychain group <team>.se.pengstrom.lasbolt.keys; the Safari appex and the helper do not have it), only on this Mac, and only after a match of a finger that was enrolled when the item was written (.biometryCurrentSet). The Mac login password does not open it. The app sends enc only to an agent whose code signature is the bundled helper of the same team (checked with the audit token of the socket peer), so a process that replaces the socket or the agent-path file does not get it. No agent op gives enc or a private key out: the agent gives enc only in the reply to an unlock that sent the password.
• Limits:
  • After a Touch ID unlock the agent holds the E2E keys, as after a password unlock. Each process of the same user can then read E2E data through the socket (section 3). Touch ID does not make this wider or narrower.
  • A person whose finger was enrolled before the item was written can unlock.
  • The app cannot tell who caused the unlock window to show. The prompt names Lasbolt. A user who touches the sensor on a prompt that they did not expect gives the unlock.
  • The keychain group needs a free-team provisioning profile, which lives 7 days. After that, the app does not start until it is built again (DESIGN 11.13). This is a limit of use, not of security.
  • A Debug build (make apple) has get-task-allow, and its helper has no hardened runtime. A debugger of the same user can read enc in the app and the keys in the agent. The release build (make apple-release, hardened runtime, no get-task-allow) is for daily use.
  • When the item is older than 14 days, the app asks for the master password again.

2.7c The local store key in the app (DESIGN 11.15)

Not built: the user accepted the gap (2026-10-17). The promise and limits below describe the design for when it is built, after a caller check in the agent.

• Promise (Touch ID build, when the user turns on “Keep the local store key in the app”): the local store key is only in a data protection keychain item of the app’s group, on this Mac. A program of the same user without that entitlement cannot read, change or delete it, also when no agent runs. The move encrypts the store again with a new key, so a key that a program read from the security item before the move does not open the store after it. The app sends the key only to an agent with the code signature of the bundled helper, and the agent uses a key from any key store only if it opens the check record of the store. No agent op gives out a key that is only in the app. The promise is for a move that the app ran.
• Limits:
  • While the agent runs, each process of the same user can read the vault through the socket (section 3). The move does not change this.
  • A program of the same user can start the app, or run a lasbolt command, so that the app unlocks the store. The app does not ask the user first (no biometry, so that a launch at login works).
  • A program of the same user can delete state.db or change its keyinfo row: a denial of service, as today.
  • The default build cannot have the item (no keychain group without a profile), and the legacy login keychain gave no protection in the probe. The default build keeps the security limit.
  • When the 7-day profile of the Touch ID build ends, the CLI cannot open its store until the user builds the app again or signs out.
  • A Debug build (make apple) lets a debugger of the same user read the key in the app and in the agent.
  • A peer of the same user can run the move ops itself before the app does. It then knows the key, and the app shows bad_key.

2.7d The Android app (DESIGN 13)

• Promise: the app and its helper run in the app sandbox (one UID). The agent socket (<filesDir>/agent/a.sock, directory mode 0700) is reachable by the app UID only, and the agent checks the peer UID (SO_PEERCRED) as on Linux. Another app cannot connect, read the local store (state.db, keys.json) or the wrapped key. Cloud backup and device transfer are off (allowBackup=false, dataExtractionRules exclude all), so the store and the wrapped blob never leave the phone (a copy without the Keystore key would be useless, but it is not made). A copied value is marked sensitive and is cleared after 30 s if it is still the clip of the app. The sign-in and the item view use FLAG_SECURE when “Block screenshots” is on (the default of a release build; a debug build has it off, so a debug build on a real phone shows values in screenshots and in the recent apps view).
• Limits:
  • Root, or a debugger on a debuggable build, reads the memory of the helper and the app and the files, and can use the Keystore key through the app. The Keystore key of the local store (DESIGN 13.3) has no user authentication, so an unlocked phone in other hands gives the vault (the signed-in app opens it with no check). It is the same trust as the agent on a desktop (section 3). Biometric unlock (below) adds a check for the E2E keys only: it does not protect the local store.
  • The wrapped key and the store belong together. If the Keystore key is definitely lost (entry missing, GCM tag fails, malformed blob), the app cannot open the store: it wipes the local data and asks for a new login. A transient Keystore error wipes nothing: the app shows it with “Try again”. The server data is not affected. An uninstall deletes both.
  • The login helper commands get the store passphrase in the environment (LASBOLT_KEY_PASSPHRASE), because there is no terminal. A process of the same UID can read it from /proc/<pid>/environ for the time of the command. Other apps cannot. The agent gets it with the vault.unlock op and does not keep it.
  • DNS (DESIGN 13.2). The helper sends plain DNS (UDP port 53) to the servers of the active network, from $LASBOLT_HOME/dns. Private DNS (DNS over TLS) is not used, so a network operator or a hostile Wi-Fi sees the server name and can answer with a wrong address. Login and sync use TLS with the certificate check, so a wrong address gives a failed connection, not a leak of data. A server over plain http (the “Allow plain http” switch, meant for a VPN) has no such protection. The app writes the file and the helper reads it, both with the app UID.
  • The agent is a child process of the app. Android can stop it (memory, battery). The app starts it again. The agent holds the E2E keys in memory only, so a stop locks the E2E folders.
  • Biometric unlock (DESIGN 13.16). The app keeps enc of the user (it opens the E2E keys, and it can sign as the user, section 2.6) wrapped with an AES-GCM key of the Android Keystore. The key needs a fresh BIOMETRIC_STRONG match for each use (a CryptoObject prompt, timeout 0), works only on an unlocked phone, goes invalid when a fingerprint or face is added (setInvalidatedByBiometricEnrollment), and sits in StrongBox when the phone has it. The wrapped blob is in the private files of the app and is not in a backup.
    • What it defends. A person who holds the unlocked phone, or who holds the phone and knows its screen lock PIN, cannot open the E2E folders with the PIN alone: the PIN does not open this key (only a strong biometric does; there is no screen lock fall back). A person who adds a fingerprint with the PIN makes the key invalid, so they cannot use it either, and the app asks for the master password.
    • What it does not defend. A match of the owner is needed for each unlock, but while the folders are open (the agent holds the keys, as on a desktop) a same-UID process reads them. Root or a debugger on a debuggable build can call the Keystore through the app after one match. A fingerprint that is enrolled before the user turns the feature on can unlock it (a person who is already enrolled on the phone is trusted, as for the lock screen). The app clears its byte copy of enc after the send, but the JVM keeps the hex text until the garbage collector runs.
    • The 14-day rule. After 14 days without the master password, the item is not used and the app asks for the password, so the user does not forget it. It is a rule of the app only: the clock can be moved back (a creation time in the future counts as old, but a user who moves the clock forward and back can keep the item). It is not a security boundary.
    • Only for a password login. A browser sign-in has no enc (DESIGN 11.13), so it has no biometric unlock.
  • Approvals on the phone (DESIGN 13.17). A password login can list and decide approvals (/api/v1/approvals, device token only; a session or a scoped key gets 403). This gives no new read power: the device token reads every value of the user already. The approve in the app needs the owner check of the phone (a strong biometric or the screen lock), but it has no CryptoObject: it is a gate of the screen. Root, or any process that has the agent socket, can send approvals.decide with no check. A notification has no Approve button, so a tap on the lock screen cannot approve. The notification shows names of items, so the lock screen shows a public text only. A push (FCM) is not built: a request shows while the app process lives (poll every 15 s in front and 60 s in the background, and at each sync). The phone cannot approve an E2E request that needs a sealed key of the browser (DESIGN 10.21); the web app does it.
  • Autofill (DESIGN 13.4, 13.11). Another app, or a web page in another app, can try to get a password by faking the page address.

    • Trust in webDomain. The service reads webDomain only from a package that is a pinned browser (Chrome, Chrome Beta, Firefox, Firefox Beta, Firefox Nightly) with a pinned signing certificate (SHA-256, checked by the system with hasSigningCertificate). A WebView in another app can set webDomain to any text, so for any other package the service offers nothing. The pin list comes from Google’s published list of privileged browsers; a new browser needs a digest from a source like that. We trust that the pinned browser sets webDomain from the real page address (a flaw in the browser breaks this), and that the signing keys of those vendors stay safe. A debug build also trusts its own package (test only; no release build has it).

    • Fields of different sites. A page that has the user name and the password fields under different domains (frames) gets no fill.

    • No secret before the pick. A FillResponse has names and user names only; every dataset has an authentication intent. fill.get runs only after the user picks a dataset, in an activity that is not exported. That activity takes the URL and the field IDs from the structure that the system gives it (not from its intent) and checks the package against the pin list again. An item with a per-use approval waits for the web app (DESIGN 11.14).

    • Names are visible. The drop-down and the keyboard strip show the item names and user names on the screen (a shoulder-surfing and a screen-recording risk, as a list in the app). After the fill, the browser page holds the value, as if the user had typed it. The app keeps the value in memory only while the pick activity lives.

    • Save from the browser (DESIGN 13.12). A page that the user fills in goes to the agent as a new login or as a changed password.

      • Trust. onSaveRequest runs the same browser trust check as fill (pinned package and signing certificate) and reads webDomain from the same place. An untrusted package gets no SaveInfo and no save. A pinned browser that lies about the page address is the same risk as for fill. The saved item has the domain of the page as its URL, so a wrong webDomain makes a login for a wrong site; the value is never sent to another site.
      • Values go to the agent only. The typed user name and password are in the SaveRequest (the system holds them for the save sheet, as for every service), then in the service in memory, then in item.create or item.update on the agent socket. The service keeps no copy after the call. Deviation: when the save needs the screen (an item of this user name exists, or the agent must start first), the values wait in one process-memory slot (LasboltApp.holdSave). The slot is cleared when SaveActivity takes the values, or after 2 minutes. The values are not in the intent, in a file or in a log. The activity is not exported.
      • The system save sheet is the consent for a new login. A page cannot make a save without the user: the sheet is the system’s.
      • No SaveInfo for a read session or a signed-out app. The agent also refuses the write (outside_scope).
      • The agent ops. item.create, item.update and item.delete are not in the allow-list of nm-host or of the Safari relay, so a browser extension cannot write. On the socket they need the app UID like all ops. They log the item ID and the caller, never a value. The old password stays in the history of the item, so a wrong update can be restored in the web app.

    • The rest of the autofill API (DESIGN 13.15).

      • Cards. A card has no URL, so card.match and card.get do not bind a card to a site. Any page of a pinned browser can offer the card items, and a hostile page can show a payment form. The control is the same as for logins: the user must pick a dataset, the pick may need the web approval (11.14), and the page never receives a value before the pick. The difference is that a wrong site is not refused by the agent, so the user must see where the card goes: the dataset subtitle has the host (webDomain), next to the cardholder. A pick with no approval fills at once and shows no further screen. The ops are not in the allow-list of nm-host and not in the Safari relay, so an extension cannot call them. A dataset shows the name and the cardholder, never digits.
      • Strong password. gen.password runs in the agent (pwcrypto). The password goes through the result of AutofillActivity to the page, as a login does. If the user submits the form without a change, the system may show no save sheet (13.13), and the password exists only in the form; this is a loss risk, not a leak.
      • One-time codes. The agent makes the code at the pick. A code is good for seconds. The same pick rules apply.
      • Response authentication. The activity returns a FillResponse that has datasets with their own authentication, so it holds no secret value. A cancelled unlock returns nothing.
      • Never list and pick history. NeverSites (hosts) and PickHistory (host, kind, item ID, time) are in the private preferences of the app (no backup). They show which sites the user visits and which items they used, to a process with the app UID or root, like the local store does. The history is cleared at sign-out. “Don’t offer on ” is a dataset whose intent opens NeverActivity (not exported); it reads the host from the structure, not from the intent, and asks before it adds the host.
      • More browsers. Samsung Internet, Brave, Edge, Vivaldi and DuckDuckGo are pinned from the same published list (digests in 13.15). Compatibility mode is not used: the system puts the page address (the text of the URL bar) on the URL-bar node only (Helper.sanitizeUrlBar in AOSP), not on an ancestor of the form fields, and the text of a URL bar is a weaker source than webDomain. The finder offers nothing there. These browsers work only where they call the autofill API themselves.

2.7e Pairing a phone (DESIGN 13.9, 13.10)

2.7f The iOS app (DESIGN 14)

• Promise: the agent runs in the app process, in the app sandbox. The agent socket (<Library>/agent/a.sock, directory mode 0700) and the local store are in the app container, which other apps cannot open. The store key is a Keychain item that only this app can read, AfterFirstUnlockThisDeviceOnly and not synchronized, so it does not go to iCloud Keychain or to a backup, and LASBOLT_HOME is excluded from backups. A copied value stays on the device (localOnly, no Universal Clipboard) and expires after 30 s. The app covers its window when it is not active, so the app switcher does not show a value.
• Limits:
  • The cgo exception. The Go core is a static library in the app (DESIGN 14.1). The Go code and the crypto are the same as on the other platforms, but the process now also holds the Swift UI and the system frameworks: a flaw in the app process has the agent keys in the same memory. On macOS and Android the agent is a separate process.
  • iOS cannot block screenshots or screen recording. A value on screen can be captured.
  • The Keychain item of the store key has no user authentication, so an unlocked phone in other hands gives the vault (also the server-readable items). The same trust as the agent on a desktop (section 3). Face ID (below) protects only the E2E keys, the extension and the approvals, not the store key.
  • Face ID unlock (DESIGN 14.9). Promise: enc is in a Keychain item of the app only (.biometryCurrentSet, WhenUnlockedThisDeviceOnly, not synchronized, the default group of the app, not the App Group), and it is read only after a Face ID match. A face that was enrolled later does not open it. The phone passcode does not open it. After 14 days, the app and the extension ask for the master password. Limits: a face that was enrolled before the item was written can unlock; enc gives all E2E keys, as the password does (but it cannot log in); after a Face ID unlock the agent holds the E2E keys in the process of the app until the user locks them; iOS has no peer check of the agent (it is in the app process); a session may now get and use enc (DESIGN 14.9), and each unlock fetches keys_enc under the limit of 5 in 10 minutes with an audit row.
  • The gate of the extension (DESIGN 14.9). The extension reads a second item in the App Group (random bytes, .biometryCurrentSet) and takes a Face ID match as the password check. It is a gate, not encryption: code in the extension process can read the snapshot key without a match, as without the master password (DESIGN 14.8). The gate holds no key and not enc, so the extension never holds the key of the E2E data. A good password renews it. The app deletes the gate with its own item.
  • Approvals on the phone (DESIGN 14.9, 10.21). Only a password login (a device token) can decide. A session and a scoped key get 403 device_only: they are the principals that get asked. The API is the one of DESIGN 13.17, shared with Android. A phone that signed in with a QR code cannot approve. “Approve” asks for a Face ID match in the app. The server cannot see that match: a copy of the device token can decide with no match. It is the same trust as the web user, because a device token may also set and clear @approve (DESIGN 10.21). The phone gives no key: it cannot approve an E2E item that the asking program cannot open (409 needs_grants: it needs a key sealed in the web app). A local notification has the name of the program and the item, and no value. It shows on a locked screen, unless the user hides previews. The poll and the wake are best effort: iOS can delay or skip a wake, a request ends after 5 minutes, and there is no push. A missed request is a denied one (it ends), so a late alert is a loss of use, not of safety.
  • The environment of the process holds the store passphrase (LASBOLT_KEY_PASSPHRASE, DESIGN 14.1) for the life of the process. Only the app process can read it.
  • iOS suspends the app and can stop it at any time. The agent holds the E2E keys in memory only, so a stop locks the E2E folders.
  • AutoFill snapshot (DESIGN 14.8). The extension reads a copy of the server-readable logins in the App Group container, sealed with its own random key. That key is a Keychain item in the App Group access group with the same protection as the store key (AfterFirstUnlockThisDeviceOnly, not synchronized), so only the app and its extension can read it, and it does not leave the device. The snapshot never has E2E items, items that ask for approval, a TOTP secret or the trash. The master password in the extension is a gate for a person with the unlocked phone, not a second encryption: code in the extension process can read the key without it. The snapshot also has keys_enc and the KDF parameters, to check the password offline; a person who copies the container and the Keychain item gets the logins anyway, and a copy of the container alone allows offline guessing of the master password at the full Argon2id cost (the same data is on the server). Sign-out deletes the snapshot, its key and the identities. A changed password can show in the extension up to the next refresh of the app (DESIGN 14.8).

2.7g Peer sync (DESIGN 15, draft; the server part is built, 15.15; the transport is built, 15.17; the agent and CLI are built, 15.19)

2.7h Import files (DESIGN 16)

2.8 Other users of the same server

• Promise: a user reads only spaces where they are a member. IDs of other spaces stay hidden (“not found”).
• For E2E: membership is also enforced by keys. A server bug cannot give E2E plaintext to a non-member.
• Shared spaces and teams: 2.12.

2.9 Attacks on the web app

• Promise: no script injection, no cross-site requests.
• How: strict CSP with no inline script, textContent for decrypted text, CSRF tokens, SameSite=Strict, all assets embedded (no CDN).
• Limit: an injected script in an unlocked tab has the keys in effect. The worker never gives a private key to the page, but its page-callable list has e2eGrantUser, e2eGrantFolder and e2eGrantItem: the page names the box key, and the worker seals the user bundle or a folder key to it. So a script that runs in an unlocked tab can seal the keys to its own key and send them out. The controls are the ones above (CSP, no inline script, no remote assets); the worker list is not a boundary against a script in the page.
• Tab unlock changes nothing here. A script in an unlocked page could always ask the worker for data. It can also ask the worker to restore a tab, which gives it nothing more. The page never holds W: the worker sends and reads it. The tab-key calls need the CSRF header and a same-origin fetch, also the GET.

2.10 Supply chain

• How: no remote assets, pinned Go modules, govulncheck in make lint, no cgo, few dependencies.
• Limit: a compromised Go module in the build is not detected by the build itself.

2.11 Organisation: instance admins, invitations, the control socket, disable and delete (DESIGN 17.16)

2.12 Shared spaces and teams (DESIGN 17.17, 17.19, 17.22, 17.23; shared spaces and teams are built, in the server and in the web app)

3. Out of scope

• A compromised client OS, browser or browser extension, and malware running as the same user. (On macOS, the security key storage of the local store key does not stop programs of the same user. The Touch ID item of the app does stop them (2.7b), but the running agent does not. The store key item of 2.7c is not built.)
• Physical access to an unlocked device.
• Side channels (timing on shared hardware, power, cache).
• Denial of service beyond basic rate limits.
• The operator as an adversary for server-readable data. Use E2E folders for data the operator must not read.
• The operator can reset any account (DESIGN 8.1). lasboltd user reset-password gives a link that sets a new master password. This is not a new power: the operator always could read and change server-readable data, and could replace the auth verifier in the database. The reset cannot open E2E data: it makes new keys, and the old E2E folders stay locked for ever. The user sees it in the audit log (“Master password reset by the operator”), and all sessions, devices and scoped keys of the user end.
• Traffic analysis.
• Quantum attackers: partly covered. HPKE uses the ML-KEM-768 + X25519 hybrid. Signatures (Ed25519) and symmetric keys are not post-quantum-specific.

4. Known gaps