What this notice covers
This notice covers statstoat.com, the account authentication service, the protected dashboard entry point, the current StatStoat desktop application, and the maintained Chrome extension compatibility surface.
Archived scripts, older extension builds, WhatsApp Web, user-configured webhooks, and notify.run are separate surfaces with their own behavior and policies.
The central privacy boundary: detailed activity timelines and diagnostics stay on your device. Contacts you add or import in the protected dashboard synchronize to your encrypted account catalog; live presence processing begins only after you explicitly pair a desktop.
Information StatStoat handles
Email address, an optional display name, account creation and verification status, the accepted legal version, acceptance time and method for newly created accounts, opaque-session metadata, and—when you use Google sign-in—the provider's stable account identifier. Password accounts also store a salted password hash.
Request origin and network address may be processed to enforce origin checks and per-address authentication limits.
Detailed presence timelines, desktop diagnostics, local interface settings, cached contacts, and generated exports stay in browser, Chrome extension, or Electron storage.
The PostgreSQL account catalog stores the contacts you choose to synchronize: display label, favorite and alert preferences, timestamps, revision metadata, and a recoverable E.164 phone number encrypted with AES-GCM.
After you explicitly pair a desktop, the operational alert database receives a deployment-keyed contact identifier, display label, online/offline state, event sequence, and timestamps needed for alerts and daily summaries. That operational database does not store the recoverable phone number.
Email, Telegram, webhook, or notify.run content leaves the device or server only after you explicitly configure and enable that destination.
Passwords and raw session tokens are not stored in the authentication data file. Passwords use per-user salted scrypt hashes; only SHA-256 hashes of random session tokens are persisted.
Consent and email verification
The authentication screen presents the current Terms of use and this privacy notice before an authentication option becomes available. “Continue with Google” signs in an already linked Google identity or creates a new StatStoat account when none exists; it does not silently attach Google to a verified password account. For a newly created account, StatStoat records the accepted legal version, acceptance time, and whether the account was created with password or Google authentication. Authentication does not grant access to detailed local timelines. After entry to the protected dashboard, contacts previously saved for that same account may be imported once into its encrypted contact catalog.
When password-account email verification is enabled, StatStoat stores the SHA-256 hash of a random verification token, not the raw token. It also stores the account's verification state and the times needed to enforce expiry, single use, resend cooldowns, and pending-account retention. The raw token appears in the private link sent to the address and is submitted only when its holder explicitly confirms verification.
A resend replaces the previous verification token. A used, replaced, or expired token cannot verify an account. Google sign-in is accepted only when Google returns a verified email claim, so that flow does not send a separate StatStoat verification link.
Optional transactional mail
Email delivery is optional and operates only when an administrator has configured and enabled it. The configured mail service may process the recipient address, optional display name, message content, sending time, and technical delivery metadata needed to deliver or troubleshoot the verification message. StatStoat does not currently name a mail provider or claim that transactional mail is enabled.
Verification messages are transactional account-security messages. They do not contain advertising or tracking pixels. Delivery infrastructure may retain its own operational records under its applicable configuration and policy.
How information is used
- To create and maintain your account.
- To record verification state, issue or replace time-limited verification links, and send transactional verification mail when that feature is enabled.
- To verify access to protected web routes.
- To prevent excessive authentication attempts and reject requests from an unexpected configured origin.
- To synchronize the contact catalog you choose across authenticated browsers and paired desktops.
- To operate local monitoring, detailed history, export, notification, and diagnostic features that you initiate.
- To derive online intervals and deliver cross-device alerts or daily summaries after you explicitly link a desktop and enable those channels.
The current website does not include advertising pixels or third-party analytics. StatStoat does not sell account or contact information.
Authentication cookies
A completed sign-in sets statstoat_session to authenticate requests. Starting Google sign-in also sets statstoat_google_state and statstoat_google_verifier for up to ten minutes so the callback can validate the request and its PKCE proof. The two temporary cookies are cleared when the callback is handled.
These cookies are HttpOnly and SameSite=Lax, and production uses the Secure attribute. JavaScript cannot read them. The session cookie is cleared when you sign out.
Local history, secure sync, exports, and integrations
The desktop runtime and maintained Chrome extension can observe supported WhatsApp Web presence states through your local signed-in session. The complete detailed timeline remains local. Account contacts synchronize independently through the protected catalog; pairing a desktop is a separate explicit action that sends minimized presence events for cross-device status, notifications, and daily summaries.
- The PostgreSQL contact catalog stores recoverable E.164 numbers only as AES-GCM ciphertext, with the authenticated account and contact metadata needed for cross-device synchronization.
- The notification database stores a deployment-keyed HMAC contact identifier rather than the raw phone number, together with the display label, state, sequence, and timestamps.
- A linked-device bearer token is hashed on the server and protected by the operating system credential store on supported desktops.
- Daily analytics email uses your account address and can contain display labels, online intervals, totals, local date, and time zone. It includes a plain-text version and no tracking pixel.
- Telegram pairing stores the private chat identifier needed for delivery. Online alerts omit phone numbers and are sent only for contacts whose alerts are enabled.
- Exports are created only when you choose CSV, Excel, JSON, copy, print, or PDF output.
- HTTPS webhooks send the payload described in the integration screen to the URL you provide.
- notify.run and device notifications are optional and subject to the destination provider or operating system.
- Deleting browser or application storage may remove local history and preferences permanently.
Before sharing an export: review it for phone numbers, contact names, timestamps, and patterns that may identify another person.
Retention, security, and your choices
Authentication sessions expire according to service configuration; the default is seven days. Expired sessions are pruned. When email verification is enabled, a verification link expires after the configured period—24 hours by default—and a never-verified account is pruned after the configured pending-account period—seven days by default. Server-side presence events and derived intervals are retained for 45 days by default. A verified account record, synchronized contact catalog, and current preferences remain while the account exists. Removing an individual contact deletes its encrypted phone, label, and associated server notification history; only a non-reversible keyed deletion marker remains to stop a delayed desktop event from recreating it. Local monitoring data remains until you clear storage or uninstall the relevant application data.
You can sign out to revoke the current session, revoke a linked desktop, disconnect Telegram, disable daily email or per-contact alerts, clear local history through the application controls, disable optional webhooks, or stop using the service.
Settings > Account & session includes self-service account deletion. After confirmation, it removes the account record, encrypted contact catalog, notification preferences, linked-device records, keyed notification contacts, server-side events and intervals, Telegram pairing, and every server-side session for that account. It also clears that account’s data from the current browser. Detailed local history held by another browser or desktop installation must be cleared on that device.
Questions, requests, and changes
Account deletion is available directly in the dashboard. No public privacy-support channel is currently advertised; authorized repository collaborators can use the project’s private issue tracker for general, non-sensitive questions. Never share passwords, session cookies, phone numbers, contact history, identity documents, or other personal data in an issue.
If this notice changes materially, the revision date above will be updated. Continued use after an update means the revised notice applies from its stated date.