Privacy Policy

Who is responsible

The person or organisation operating Worthy Watch will be responsible for deciding how information is used in this service. The operator's final legal identity and dedicated privacy contact must be added before public launch.

Information the service handles

• Accounts: an email address, Supabase Auth user ID, authentication/session metadata and the artists the user follows. Worthy Watch does not ask for a public profile, name, date of birth, phone number or postal address.
• Following: a private follow-row ID, Auth user ID, rumour/artist record ID and creation timestamp.
• Push notifications and alert preferences: when push is enabled, the browser/device endpoint and public subscription keys are associated with the Auth user ID. Signed-in users may also save private, structured Advanced Alert rules for followed artists, such as forecast thresholds or evidence categories. These settings are used solely to deliver requested forecast or direct-community-reply updates. Browser and platform push services participate in delivery.
• Community voting: a randomly generated browser voter ID, rumour ID, up/down choice and timestamps. This voter ID is not connected to a Worthy Watch account.
• Submitted signals: artist name, evidence URL, explanation, optional source name and publication date, submission/moderation timestamps and moderation status. The current public form does not attach an account ID or email, and the application does not store an IP address in the submission table. Avoid including unnecessary personal information in free text.
• Community foundation: if community participation is introduced, it may use a public handle, public contributions, private reports and private moderation or sanction records. Those content features are not live yet, and their retention rules require review before launch.
• Optional first-party product analytics: when explicitly enabled by the operator, the service records a strict event name, a short-lived random tab session ID, server timestamp and limited context such as a rumour record ID, feature name or screen. Signed-in activity may be associated with the Auth user ID. Search terms, comment text, signal text, source URLs, email addresses and raw IP addresses are not analytics-event properties.
• Forecast sharing: shared forecast links may contain a short, controlled referral and sharing-method label (native share, X or copied link). These labels contain no account, email, device or session identifier and are removed from the visible address after attribution. The forecast card itself contains only public editorial forecast information.
• Product state: for signed-in users, the service may store when the one-time Plus Preview introduction was dismissed and the server timestamp of the last deliberate personalised catch-up view. This avoids repeatedly presenting the same followed-artist updates.
• Operational information: the application logs limited error codes and failure stages for security and reliability. Hosting and authentication infrastructure may also process technical request and security-log information under their own service configuration.

Why information is used

Account data is used for account creation, login, email confirmation, password recovery, session management, account deletion, a private followed-artists list, private alert preferences and an on-demand catch-up derived from existing forecast history. If a user explicitly enables push, subscription data is used only for requested, meaningful forecast or direct-community-reply updates - not marketing. Voting information prevents the same browser from creating repeated votes for one rumour. Submitted signals are held for manual moderation and never automatically become forecast evidence. If first-party analytics is enabled, aggregate usage is used to understand launch retention, feature usefulness and product reliability - not advertising or user profiling.

Following an artist does not affect probability, evidence, evidence tiers or Community Hype.

Sharing a forecast does not affect probability, evidence, Trending, Community Hype or notification eligibility. If first-party analytics is enabled, a completed or invoked share action may be recorded with only the rumour record ID, page surface and bounded sharing method.

Lawful basis

The operator must confirm and document the applicable UK GDPR lawful basis for each purpose before launch. No final lawful-basis decision is asserted in this draft.

Suppliers, sharing and international processing

Supabase provides authentication and database infrastructure. Vercel hosts and serves the application. Information is shared with these suppliers only as needed to operate the service. Worthy Watch does not sell account data. The operator must complete the processor, hosting-region and international-transfer review before launch.

Passwords and security

Passwords, password hashes and password-reset tokens are handled by Supabase Auth and are not stored in Worthy Watch application tables. Follow records use ownership-based row-level security. Administrative access is separate from ordinary public accounts. No online service can promise absolute security.

Browser storage, cookies and analytics

The app has no advertising, marketing analytics or third-party behavioural tracking. It uses browser storage for the Supabase login session, theme choice, anonymous voter ID and local vote state, return navigation, service-worker reload guard and - only when first-party analytics is explicitly enabled - a random tab-scoped product session. That analytics session rotates after 30 minutes of inactivity or 24 hours and is not a device fingerprint.

The operator must obtain legal review of the UK GDPR/PECR basis and decide whether consent tooling is required before enabling product analytics in production. The implementation is off by default and no consent exemption is asserted in this draft.

Retention and deletion

A follow remains until it is removed or its account is deleted. Advanced Alert rules remain until deleted, and specific-artist rules are disabled when that artist is unfollowed. A push subscription is removed when notifications are disabled on that device or the account is deleted; invalid endpoints may also be removed after a permanent delivery failure. Self-service account deletion removes the Supabase Auth account and cascades deletion of saved follows, alert rules and push subscriptions. Anonymous vote records and signal submissions are not linked to the Auth account and therefore are not removed by account deletion.

The proposed community foundation makes a profile and private user-state row cascade on account deletion. A future discussion launch may need to retain anonymised thread structure and a limited moderation audit trail; that retention and legal basis are still subject to owner/legal review.

The proposed analytics migration cascades deletion of the one-time product-state row and sets the user reference on historical product events to null when an Auth account is deleted. A 13-month raw-event retention period is proposed for review; no automated deletion job has been installed.

Final retention periods for Auth records, moderated submissions, anonymous votes, analytics, provider backups and operational logs have not yet been set and must be documented before launch.

Your rights

Depending on the circumstances, data-protection rights may include access, correction, deletion, restriction, objection and portability, plus the right to complain to the relevant supervisory authority. A privacy contact and request process must be published before launch.

Changes and contact

Material changes will be reflected on this page with an updated date. The final operator identity, privacy email and any required postal contact are still awaiting owner input.