Skip to content
Overshow
Enterprise enquiryStart free

Security

Concrete controls, on-device processing, and no desktop telemetry

Concrete security controls: on-device processing, SQLCipher at rest, window and monitor exclusions, single-device sign-in, and no telemetry.

  • On-device processing
  • ChaCha20-Poly1305 at rest
  • Window and monitor exclusions
  • Single active device

Boundary

Where your data lives

Captured data stays on your laptop. Only sign-in and billing leave the device by default. Optional integrations are off until you turn them on and authorise them yourself.

Integrations are off by default.

  1. 1

    Local capture

    OCR text, audio transcripts, and metadata stored on your device, encrypted at rest.

  2. 2

    Curated memory

    Daily recaps you run and snippets you write yourself. Searchable on-device.

  3. 3

    Optional integrations

    Explicitly turned on, per integration. Nothing flows out until you approve it.

The controls you can verify on one laptop

On-device
Capture and AI

OCR, transcription, embeddings, and chat all run locally.

SQLCipher
Encryption at rest

Whole database file. Keychain-derived key.

1 active device
Per user

Signing in elsewhere signs the other laptop out.

What a reviewer typically asks

Answers to the first six questions

Where is the data stored?

Local SQLite database on disk. No screen images or video files are persisted: only OCR text, audio transcripts, and metadata. No captured content is sent to a shared cloud database.

How is it encrypted?

SQLCipher whole-database encryption. The database key is derived from a high-entropy secret in the platform keychain.

What leaves the machine?

Nothing captured. Account, billing, and device metadata sit in a separate PostgreSQL schema. Captures stay local.

How do people sign in?

Magic-link with 15-minute token expiry, Google OIDC, or Microsoft Entra ID with PKCE. One active device per user.

Can people exclude sensitive apps?

Yes. Window and app exclusions, per-monitor rules, pause / resume, and built-in exclusion categories (HR, password managers, private browsing).

What about telemetry?

There is none. The desktop app does not send usage analytics. The server binds to 127.0.0.1.

Try the controls on a real machine

The fastest way to validate this list is to install the beta on one laptop and inspect the database and settings yourself.

Start freeTrust Centre

More reading

Related pages

Deeper reading

Pillar guides

Security controls

Core controls your IT and security teams will assess first

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 EmbeddingGemma 300M vectors.

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.
  • Durable backpressure queue spillover files outside SQLite are encrypted separately with ChaCha20-Poly1305 using keychain-derived subkeys.

Key hygiene

  • The database key is derived from a high-entropy keychain secret mixed with machine, OS user, and app user identifiers.
  • A full local reset clears the active derivation secret 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

  • Gemma 4 E2B via MLX Swift runs chat on-device. FluidAudio Parakeet TDT v3 runs transcription on-device. FluidAudio Sortformer fastV2_1 runs speaker diarisation on-device. Silero VAD v6 runs voice activity detection on-device.
  • MCP integrations with external clients (Claude Desktop, Cursor, Jan, LM Studio, Ollama) require explicit approval. 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 binds to 127.0.0.1. 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.

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.
  • The MCP server exposes a small approved tool surface to AI clients the user has configured. Most tools are retrieval-only; commitment and meeting-classification tools can update local metadata.

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.