This document describes our vulnerability-handling process. Statutory and contractual rights (including the security-update obligations in our Terms of Service and under applicable law) are set out in the Terms of Service; this page explains how to report issues and what we commit to operationally.

Scope

This policy covers:

The desktop application — the Electron app, its main/preload/renderer code, the local Whisper transcription pipeline, and the offline licence-token verifier.
The licence-minter service — the backend that mints PII-free Ed25519 licence tokens from Paddle webhooks.

Out of scope: third-party services we integrate with but do not operate (e.g. Paddle as Merchant of Record, the Sentry ingestion endpoint) — report those to their respective vendors. Findings that require a jailbroken/rooted device, physical access, or social engineering of our staff are generally out of scope.

Reporting a vulnerability

Please report security issues privately. Do not open a public issue, pull request, or discussion for a suspected vulnerability.

Email: security@insight42.com
If you do not receive an acknowledgement within a few business days, follow up to support@insight42.com.
If you wish to encrypt your report, request our PGP key at the address above.

What to include

A clear description of the issue and its security impact.
Step-by-step reproduction (proof-of-concept, affected version/commit, OS/arch).
Any relevant logs or screenshots with secrets and personal data removed (see below).

Please do NOT include secrets or third-party data

Do not send us, paste into a report, or attach: API keys, tokens, signing keys, webhook secrets, SMTP credentials, or Redis URLs (yours or anyone else’s); raw licence tokens, audio, or transcript content; personal data of third parties, or data obtained by attacking systems you do not own. Redact credentials before sharing logs — if a credential was exposed, tell us that it was and where, not its value.

Our commitment

When you report in good faith under this policy:

We will acknowledge receipt and begin triage on a best-effort basis (target: a few business days).
We will keep you informed of remediation progress and coordinate a disclosure timeline. We prefer coordinated disclosure and ask for a reasonable window to ship a fix before any public write-up.
We will not pursue or support legal action against researchers for good-faith research that respects this policy and applicable law, avoids privacy violations and service degradation, and does not access or modify data beyond what is needed to demonstrate the issue.

We do not currently operate a paid bug-bounty program.

Supported versions and security-update period

We provide security updates for each supported major version of Secretary42 for at least five (5) years from that major version’s release, free of charge. These security updates remain available to you for a supported version whether or not your subscription is active during that period. (An active subscription is required to use transcription and to receive feature updates and support; it is not required to receive a security patch for a supported version.) The latest stable release on the active update channel is the supported release; users of older versions can upgrade to the latest supported release free of additional security-update charge.

Version	Security updates
Latest stable release (active channel)	✅ supported
Earlier releases within their 5-year window	✅ supported until the version’s end-of-support date
Versions past their end-of-support date / pre-release builds	❌ upgrade to a supported release

Concrete per-major-version release dates and end-of-support dates will be listed here as GA versions are released; each major version is supported for at least five years from its release.

Security & privacy posture (context for reporters)

By design, Secretary42 minimises the attack and data surface:

Local-only transcription — audio and transcripts are not transmitted to insight 42; there is no cloud-transcription fallback.
Offline, account-less authorisation — product use is unlocked by an offline Ed25519 licence token verified locally with no network call; the token payload is PII-free by construction and the raw token is never logged or exposed to the renderer.
No Paddle API key in the app — the desktop app stores no Paddle customer/subscription/transaction identifiers; payment runs through Paddle as Merchant of Record.
Opt-in diagnostics — Sentry is off by default and is not initialised before explicit consent; events are sanitised (no tokens, keys, emails, full paths, audio, transcript, or Paddle identifiers).
Hardened Electron — context isolation on, Node integration off in renderers, a narrow preload bridge, IPC sender-origin validation, and navigation/window-open guards.

If you find a case where one of these properties does not hold, that is precisely the kind of report we want.