Browser integration: implemented delegation and remaining security/acceptance work

[bsutton]

Browser-authorized lockbox delegation is implemented as an experimental, opt-in feature on feature/browser-integration, commit 643e218. It has not been merged. This issue records the delivered work and tracks the remaining acceptance and security work.

The feature lets a user explicitly authorize a paired server to unlock a specific lockbox using their existing local reVault identity. The browser relays an encrypted, recipient-bound envelope; it never receives the vault passphrase, profile private key or plaintext content key. Application login does not substitute for unlock consent.

Implemented

• Versioned, restricted protobuf protocol: GetCapabilities, RequestUnlock and CancelRequest; bounded JSON/base64 Native Messaging transport.
• Chrome/Chromium and Firefox extension sources for Linux, with a separate browser SDK. Browser-derived origin/extension context replaces page-supplied context; iframe requests are rejected. Portable WASM retains its existing boundary.
• Opt-in revault-browser executable, exact-extension native-host installers and local pairing/list/revoke commands. No localhost HTTP service or additional secret cache.
• Dedicated browser API within the existing Session Agent, preserving same-user IPC checks and existing profile/Auto Open mechanisms.
• Explicit pairing of HTTPS origin, application, lockbox, extension and independently verified server signing key. Every unlock requires native approval identifying the recipient, full-lockbox scope and locally configured disclosure.
• RFC 9180 HPKE envelopes bound to signed request metadata, fresh recipient key, server boot, challenge and expiry. Minimum content-key material is handled in protected memory.
• Durable replay rejection, bounded concurrency, cancellation, revocation checks, expiry during approval and suspend invalidation.
• Generic Rust receiver API and synthetic receiver example with session binding, one-time challenges, fresh boot keys and read-only lockbox import without a server Session Agent cache.
• Integration/security guide, including threat model, lifecycle, deployment contract and review checklist.

Verification completed

• Required workspace checks passed (cargo xtask check-required).
• Strict Clippy passed with browser integration enabled. Advisory Clippy completed with warnings.
• 24 targeted tests passed: 7 protocol/crypto, 9 agent-policy, 2 public CLI lifecycle and 6 browser/SDK tests.
• A bounded, seeded Native Messaging fuzz campaign completed 10,000 executions without a crash.
• Synthetic tests cover unlock/read-back, receiver restart, old-envelope rejection and a fresh successful unlock, plus installer lifecycle and malformed transport.

These are automated component and synthetic integration results. Policy tests substitute the approval/key sources privately; browser tests use browser API fixtures. They do not demonstrate the full installed browser → native dialog → agent → server chain on a desktop.

Limitations and security boundaries

• Disabled in ordinary builds; real-secret delegation requires an independent focused security review. The feature flag is an experimental deployment gate, not a runtime prohibition on opening real data.
• Interactive Chrome/Chromium and Firefox acceptance remains unverified; no connected browser runtime was available. Linux approval currently requires /usr/bin/zenity and a working desktop session. OS secure-store interaction may require separate local action.
• Extensions currently use development loading. Store signing, stable production extension identities and production distribution remain outstanding. Safari, Windows and macOS adapters are outside this milestone.
• Delegation grants the entire lockbox content key, not per-secret authority. An approved or compromised recipient can retain the key or plaintext. Envelope expiry and pairing revocation cannot revoke material already delivered.
• Restart/explicit-lock protection depends on the consumer discarding its receiver, lockbox handles and decrypted application data, and never persisting keys or silently reusing an agent cache. This is not enforceable against a malicious recipient.
• The local user account, extension, approved website and approved server are trusted boundaries. Compromise can undermine protection. Same-user IPC is not workload attestation.
• Consumers must implement authenticated challenge issuance, trusted session binding, CSRF protection, request limits and secure signing-key custody. No application HTTP endpoints, Monitor integration, login or passkey work were included.
• This is not a workload identity provider, central secrets-policy service or KMS. Narrower delegation, dynamic credentials and centralized audit are separate work.
• The bounded fuzz run and automated checks are not an independent audit or exhaustive platform validation.

Remaining acceptance work

• Independently review origin/navigation handling, host registration, pairing trust, approval/cancellation races, durable replay, suspend behavior, HPKE binding and transient secret handling.
• Run full synthetic desktop acceptance in Chrome/Chromium and Firefox: approve, read synthetic content, restart receiver, reject old envelope, approve fresh request and read again.
• Exercise real desktop secure-store locked/unavailable/interactive states and actual OS suspend/agent restart behavior.
• Define stable extension identities and signed distribution; validate packaged host installation/removal on supported Linux environments.
• Review a consumer's authentication, CSRF, session, key disposal and restart policy before enabling real-secret delegation.

Keep this issue open for the outstanding validation and review. The implementation branch is ready for code review, not a claim of production security approval.