ADR 0007: Browser lock coordination

Coordinate logical vault locking across tabs with versioned secret-free BroadcastChannel messages and a secure idle default.

Status: accepted for v0.3.

An unlocked VaultClient removes its in-memory root-key handle after fifteen minutes without user activity by default. Pointer and keyboard activity reset the timer. Returning to a visible document first checks elapsed time, so timer throttling in a background tab cannot silently extend an expired session. Applications may configure the interval or explicitly set it to zero.

Tabs for the same vault coordinate through a vault-scoped BroadcastChannel. Version 1 messages can request a lock, announce device revocation, announce removal of shared local state, or announce rotation start and completion. Messages contain only the vault ID, source instance ID, timestamp, event type, and a device or rotation ID when required. They never contain root keys, private keys, Recovery Kits, passwords, record identifiers, or plaintext. Unknown and malformed messages are ignored.

Lock messages destroy each receiving client’s in-memory root-key handle. Revocation and local-state removal also clear the shared IndexedDB record and transition tabs to unavailable-on-device. Rotation start locks peer tabs and blocks record access until atomic cutover; completion makes them reload the new vault metadata and device envelope before unlocking. dispose() destroys the local root-key handle, closes the channel, removes activity listeners, and cancels timers.

This lock is a same-origin application control. A malicious script can suppress events, create its own client, or use an available non-extractable device key. It is not OS user-presence authentication and must not be described as protection from XSS or a compromised application.