On-device
Capture and AI
OCR, transcription, embeddings, and chat all run locally.
Local SQLite storage
Captured content lives in a local SQLite database with FTS5, not in a shared SaaS database.
Encryption at rest
SQLCipher encrypts the local database file at rest. The root secret lives in the platform keychain.
Window and app exclusions
Exclude password managers, HR tools, and private browsing by name, pattern, monitor, or focus state.
Single active device
One laptop per user. Signing in elsewhere revokes the old device automatically.
Security and privacy
Overshow is designed so a security reviewer can answer the normal questions by looking at one laptop and one account. The captured content lives on the device. The account sits in the cloud. These two boundaries are deliberate.
Data protection and encryption
Local storage
- OCR text, audio transcripts, and metadata are stored on the local disk. No screen images or video files are persisted: image payloads are dropped after OCR, retaining only text and derived signals. Nothing is pushed to a shared SaaS database unless the user explicitly exports or integrates it.
- A local SQLite database with FTS5 powers full-text search. Semantic search uses locally-indexed semantic embeddings.
Encryption at rest
- The local SQLite database is encrypted at rest with SQLCipher. OCR output, audio transcriptions, UI snapshots, FTS tables, embeddings, and metadata live inside that encrypted file.
- Any data written briefly outside the database is encrypted at rest as well.
Key hygiene
- The encryption key is derived and stored in the OS keychain; data is encrypted at rest.
- A full local reset clears the active key so retained encrypted artefacts cannot be reopened with the old device key.
Identity, access, and session security
Authentication
- Magic-link: HMAC-signed tokens with a 15-minute expiry.
- OIDC: Google and Microsoft Entra ID with PKCE. Multi-tenant Entra is supported.
- Device registration: the laptop registers against the user account with a label and timestamps.
- Single active device: signing in on a second device revokes the first automatically.
Sessions and hand-off
- Web sessions use SHA-256 hashed tokens with configurable expiry.
- One-time exchange codes with a five-minute expiry handle the desktop-to-web sign-in hand-off.
Privacy controls
Local AI, explicit consent for cloud
- A local language model runs chat on-device. Transcription, speaker labelling, and voice activity detection all run on-device too.
- A developer-only AI assistant integration with external clients requires explicit approval and is not part of shipping builds. Default mode is local-first.
Capture scope
- Per-window and per-monitor rules, with pattern-based exclusion.
- Built-in exclusion categories for HR tools, password managers, and private browsing.
- Pause at any time, including via the tray menu or a keyboard shortcut.
- Sensitive source text is encrypted at rest; search indexes keep tokenised plaintext copies so local recall still works.
Operational hardening
- Desktop binaries are code-signed and notarised (Apple code signing and notarisation on macOS).
- Updates ship as DMG/PKG through a hardened CDN.
- The embedded server is loopback-only. No external network traffic is required for core capture, search, or chat.
- The desktop app runs continuous health checks on capture, audio, and database components and restarts them on failure.
Cloud boundary
- A separate PostgreSQL schema (Neon) holds authentication, billing, and device metadata only. It does not receive captured screens, audio, or transcripts.
- Stripe handles subscriptions with idempotent webhook processing.
- No telemetry is collected from the desktop app. The licence server receives only sign-in, billing, device registration, and aggregate licence-usage counts.
API surface
- A local REST API with an OpenAPI spec sits behind configurable CORS rules.
- WebSocket endpoints provide real-time capture, event, and health streams for internal integration.
- A developer-only AI assistant integration can expose a small approved tool surface to local AI clients. It is not part of shipping builds.
Reporting a security issue
If you believe you have found a vulnerability in Overshow, please email simon@over.show with reproduction steps and any proof-of-concept details. We aim to acknowledge reports within two working days.
- For PGP-encrypted reports, mention it in your first email and we will share a key.
- Please do not file public issues for security problems.
- Coordinated disclosure is appreciated. We will keep you informed of the fix timeline and credit the reporter on request.
- Machine-readable contact is published at /.well-known/security.txt.