Design Browser Capture Fallback Route And State Machine

[TheSilkky]

Design Browser Capture Fallback Route And State Machine

Priority

Very high

Type

Design / threat-model follow-up

Labels

backlog, frontend, design, security, documentation, testing

Branch Scope

Created from docs/end-user-product-design at d2c32a3.

Background

The end-user design document describes browser capture as future-facing only: a fallback, desktop capture surface, non-emergency interaction-record tool, testing path, or secondary capture method. It explicitly should not be framed as the primary native mobile capture client or as guaranteed background recording.

Before any implementation, the product needs a state model and threat-model update.

Proposed Scope

• Define the future browser capture route states before adding runtime capture behavior.
• Cover permission prompts, permission denied, capture active, paused, tab closed, upload pending, upload failed, retrying, uploaded, and unavailable states.
• Define warning copy for device lock, tab closure, browser background behavior, storage limits, and emergency non-reliance.
• Define what upload state means in relation to server fields and current API contracts.
• Identify required security-header or Permissions-Policy review without changing headers in this issue.

Acceptance Criteria

• A design and state machine document exists for browser capture fallback behavior.
• The state model is explicit about failure, pause, retry, unavailable, and non-emergency behavior.
• The document states what backend contracts would be required before implementation.
• The document does not authorize runtime capture implementation by itself.
• User-facing copy avoids guaranteed background recording or emergency-service promises.

Out Of Scope

• Implementing browser recording, capture, upload, or permission requests.
• Adding mobile client code.
• Relaxing security headers or Permissions-Policy without a separate implementation issue.
• Browser decryption, raw key handling, playable export, emergency dispatch, or notifications.

Suggested Validation

• Product design review
• Security and threat-model review
• Server API confirmation against open-proofline/server
• Full frontend validation only if a later issue explicitly implements route changes:
  • npm run typecheck
  • npm run lint
  • npm run test
  • npm run build
  • npm run test:e2e
  • git diff --check