Your input stays local
SnapKeyNext never sends captured key identities, raw input events, physical timing samples, configuration contents, application statistics, file paths, or hardware identifiers.
Startup telemetry
When enabled, one startup request includes only:
- Application version and effective interface language
- Operating system, CPU architecture and vendor, and installed or portable edition
- The successful startup duration in milliseconds
- A SHA-256 signature of simplified typed startup error codes, when the previous initialization failed
On the first update or telemetry API request, the response assigns a signed installation token containing only a random identifier and the server issue time plus a client audience. The client keeps it locally, uses it to authorize package downloads, and does not derive an identity from your hardware. The Worker verifies the token and stores only a separately keyed digest in D1. A pending failure signature contains no message, path, stack trace, dump, or failure timestamp and is removed after a successful API response.
Disable telemetry
Telemetry is enabled by default. It is disabled only when explicitly set to false in config.toml:
telemetry = { enabled = false }Update checking can continue without telemetry. Set bothupdates.enabled = false andtelemetry.enabled = false to prevent the startup API request completely. When updates remain enabled, the installation token is still sent for update authorization but no telemetry object is included.
Local data and retention
Optional statistics contain daily aggregates for at most 90 days, never raw recent samples or captured key identities. Diagnostic logs contain operational lifecycle and error information only and are limited to 30 files of at most 4 MiB each.
The installation token is stored at%LOCALAPPDATA%\SnapKeyNext\installation.jwt for installed builds or data\installation.jwt for portable builds. D1 startup and download-deduplication records are retained for at most 90 days; the public statistics endpoint exposes only aggregate counts.
A website JWT cookie is created only when you request a download. It is secure, HttpOnly, host-only, and marked SameSite=Strict. Its signed website audience and random subject distinguish it from client tokens, authorize the package request, and deduplicate browser downloads without using your IP address. The cookie is issued only after the request passes the same-origin browser and automated-client checks. Desktop downloads use the client token subject in the same way. Raw tokens and subjects are never written to D1.