Security at Pulse.

What Pulse does not do.

The list below is exhaustive for the shipped product. It is a behaviour contract, not a marketing claim — every item maps to a check that can be reproduced against the binary.

• No telemetry. No anonymous usage counters, no event hooks, no session metrics. The desktop binary and the Android APK contain no analytics SDK.
• No crash reports. No Sentry, no Bugsnag, no Crashlytics, no platform-native crash uploader. A panic is logged to a local file and never sent anywhere.
• No cloud calls for inference. All model inference runs on the local Ollama process. Pulse does not call OpenAI, Anthropic, Google, Mistral, or any other hosted model provider.
• No account creation. No signup form, no email, no password, no OAuth flow. There is no Pulse-issued user identifier.
• No third-party tracking. No Google Analytics, no Mixpanel, no Hotjar, no Facebook pixel, no Segment, no Amplitude, no CDN-hosted analytics. The marketing site and the desktop product are independent codebases with independent dependency trees.
• No AI-training feedback loop. Prompts, completions, and notes are never sent back to the model provider, to Pulse, or to any third party. There is no "thumbs up / thumbs down" telemetry tied to a user.
• No outbound HTTP from the app by default. The two endpoints Pulse can contact are the update manifest and the license endpoint, both described below. Verifiable with netstat -an on Windows, lsof -i on macOS / Linux, or a network capture while the app is idle.

What Pulse does.

The shipped product behaviour, in positive form:

• Runs locally. Tauri process + system WebView on desktop, Capacitor WebView on Android, plus the Ollama process on the same machine for inference.
• Update manifest poll on launch. A single GET against a versioned manifest endpoint. The request carries only the current version string and the platform. The check can be disabled in Settings; disabling it removes the only periodic outbound call.
• License check for PRO. A single POST against the license endpoint, carried over HTTPS. The payload contains the opaque license token and a coarse device identifier for activation-count tracking. No note content, no prompt, no model output, and no user metadata is included. See the privacy page for the exact data flow.
• Local storage only. Notes, chat history, and the license token live in the OS-managed Pulse data directory: localStorage and IndexedDB on desktop, the Capacitor app sandbox on Android. No sync, no replication, no remote backup.
• Pinned dependencies. Both pulse-desktop and pulse-android ship with locked dependency manifests. The web bundle is rebuilt from package-lock.json; the Rust binary is built from Cargo.lock. No floating-version installs.
• Optional OG image fetch. When a link is shared from the side panel, a single GET retrieves an Open Graph preview image. The request only fires on a user-initiated share, not in the background.

Runtime dependencies.

The table below lists the critical runtime components shipped in the Pulse desktop and Android binaries. Build-time tooling, dev-only TypeScript types, and transitive deps are intentionally omitted — the lockfile in each repository is the canonical reference.

Exact pins for the latest release are in the package-lock.json of pulse-desktop and the Cargo.lock of the same repository. Vite, TypeScript, Rollup, and the Tauri CLI appear in the same lockfiles but are build-time only and are not shipped in the binary.

Vulnerability disclosure.

Responsible disclosure is welcome and acknowledged. Reports are triaged by the maintainers of the Pulse repository.

• Where to report — GitHub Security Advisories for the Pulse organisation. A private advisory keeps the report out of the public issue tracker while triage is in progress.
• What to include — affected component (desktop / Android / website), reproduction steps, observed vs. expected behaviour, and impact. A minimal proof-of-concept is preferred over a long prose description.
• Initial triage — within seven calendar days of submission. A follow-up with a timeline lands in the same advisory thread.
• Disclosure timeline — coordinated with the reporter. Default is 90 days from the triage confirmation, in line with industry practice. Shorter windows are honoured on request for severe issues.
• Bounty program — none. Acknowledgement and credit in the release notes are the standing reward.
• Security updates — published via the changelog RSS feed and tagged in GitHub Releases. Critical patches ship as fast as the fix is ready.

Update policy.

• Windows — Pulse ships the Tauri updater. A manifest poll runs on launch; the user is prompted to install when a newer version is published. The check is disable-able in Settings. Manual install is also supported: download the latest NSIS / MSI / portable binary from the download hub and run it over the existing install.
• Android — Pulse is distributed as a signed APK. There is no Play Store listing; updates are sideloaded by installing the new APK over the existing one. The signing key fingerprint is published in the changelog for every release.
• Critical patches — shipped as fast as the fix is ready. There is no fixed patch-day schedule.
• Signing — Windows binaries are Authenticode-signed. Android APKs are signed with a long-lived key; the SHA-256 fingerprint of the certificate is published in the changelog and is reproducible against the downloaded APK.
• Old versions — every previously released version remains available on the downloads archive for at least one major release cycle. Old versions are not patched in place; users on an old version move to the current version to pick up fixes.

Cryptography.

• License tokens. 256-bit random opaque strings. Generated server-side, never reused, and stored hashed at rest. The client only ever sends the raw token to the license endpoint.
• Validation. Server-side, over HTTPS. The response tells the client whether the token is active and when it expires. The token itself is never echoed back in the response body.
• No PII in the license payload. No email, no name, no device fingerprint, no IP-based geolocation. A coarse device identifier may be included for activation-count tracking; the exact contents are documented on the privacy page.
• No key escrow. A lost token cannot be recovered from the Pulse server. The user purchases a new token and re-activates on the device.
• Transport. HTTPS for the license endpoint. The local Ollama endpoint uses plain HTTP because both processes are on the same machine and the user controls the loopback interface.
• Local encryption. The Pulse data directory is protected by the operating system's standard user-account boundary. On Windows this maps to the per-user profile ACLs; on Android the app sandbox is enforced by the Linux UID model. No additional full-disk encryption is layered on top of what the OS already provides.

Build pipeline.

• Source of truth. The source code in the Pulse repositories is canonical. A binary is a build artefact, not the source.
• Release branch. Tagged releases are cut from the main branch of the relevant repository. The tag SHA is recorded in the release notes and matches the source commit that produced the binary.
• Reproducible builds. For a given commit SHA the build is deterministic. The SHA-256 of a downloaded binary can be cross-checked against the manifest in the corresponding GitHub Release.
• Commit signing. Maintainer commits on the main branch are GPG-signed. The signature is verifiable from the GitHub web UI by clicking the "Verified" badge next to any commit.
• Code review. Changes land on main through pull requests. The PR diff, the CI status, and the review history are public.