Privacy Policy
Version 2026-07-25-r6 (draft) · Slate Oak LLC dba Price vs Worth · support@pricevsworth.com
What we store (beta)
- Account identifiers: your sign-in provider's stable account id, plus the email address and email-verification state the provider supplies, if any. Price vs Worth does not receive or store your provider password.
- Eligibility record: that you attested 18+ and US residency, the exact document versions you accepted, and the UTC time of each acceptance. We do not store your date of birth.
- Invite/allowlist: the email or account id you were invited/redeemed under.
- Waiting list/access request: if you are eligible but not invited, we record your provider account id, provider-supplied email (if any), email-verification state, first and latest request timestamps, request count, and owner-alert delivery/claim timestamps. We use this record only to manage beta access and tell the owner someone is waiting. It is removed when you are approved or use in-app account deletion.
- Feedback: stored anonymously — never linked to your identity.
If beta email is configured, Price vs Worth uses the operator's Gmail account and Google's Gmail SMTP service to send invite codes and an owner alert when someone joins the waiting list. An owner alert contains your provider-supplied email or, when no email is available, your provider account id, plus the first-request timestamp. An invite email contains the destination address and invite code. Google receives and processes the message, recipient, sender, and delivery metadata under its own terms and privacy practices. If email is not configured, no message leaves the app.
What we do NOT use (beta)
No analytics, no advertising cookies, no third-party trackers, no email marketing.
Processors
- Clerk: when live sign-in is configured, Clerk processes authentication, account, and session information for the enabled Google/Apple sign-in methods.
- Google/Gmail: processes outbound beta email only when Gmail is configured, as described above.
- Finnhub: when live market data is explicitly enabled, the server sends the requested stock symbol to Finnhub. The app does not intentionally send your account id or email with that market-data request.
Payments are disabled during the free beta. Before outside beta access, this draft and the processor list must be checked against the exact hosted configuration.
Deletion & retention
You can request deletion in the app. The workflow first removes app-owned eligibility, allowlist, and waiting-list records from the active store. When live Clerk authentication is configured, it then requests deletion of the same signed-in user's Clerk account/session through Clerk's Backend API only if the earlier required removals succeeded and any provider-owned subscription cancellation was verified. If subscription cancellation is not implemented or cannot be verified, the response lists both subscription cancellation and account/session deletion as pending and keeps the login available, preventing continued billing from being stranded behind a deleted login. If an earlier app-data removal fails, provider deletion is not attempted, preventing retained app data from being stranded behind a deleted login. If the provider request fails, the response does not claim full deletion, and the user can retry after a definite provider rejection while the Clerk account remains available. A network or timeout failure can leave the provider result unconfirmed; the response identifies that outcome separately because the account may already be gone and operator verification may be required. In offline/stub mode, no provider request is made and the response identifies the account/session step as delegated.
For the local file store, the deletion workflow removes the identity from the active file and replaces its rolling recovery backup with the same sanitized state before reporting success. If either write fails, the response reports that app-owned identity deletion failed. It also deletes known content-addressed corrupt-file recovery copies that still contain the identity. Because corrupt bytes cannot be safely edited field by field, each matching copy is deleted whole after a non-identifying hash-and-size disposition receipt is written; unrelated corrupt recovery copies remain as incident evidence. A failure to inspect, record, or delete a matching copy is reported as failed app-owned identity deletion. Manually named or separately retained copies, hosted backups, and provider backup aging are not yet verified. A successful Clerk API response proves the account request was accepted; it does not independently prove aging from every provider backup. Do not treat the current deletion control as proof of deletion from every possible copy.
The intended beta rule is deletion or irreversible de-identification of identifiable beta information by the earlier of 90 days after the beta ends or 30 days after public launch, subject to any legally required hold. The app does not yet automate that schedule or backup aging; those controls must be implemented and verified before outside beta access.