1. What we process
| Category | Current data | Where it lives |
|---|---|---|
| Account and eligibility | Email address, screen name, password hash where email sign-in is selected, date of birth, Canada residence confirmation, and acceptance timestamps for the Terms and Privacy Notice. | Server-side account storage. |
| Session and play security | Session identifier, CSRF token, account-bound fictional-credit balance, idempotent spin references, virtual-credit activity, cookie-choice state, and Player Care setting. | Essential cookies and server-side storage. |
| Google sign-in, if activated | Verified email, provider subject identifier, and basic profile name required to complete registration. Google does not replace the Canada 19+ eligibility confirmation. | Google OAuth callback and server-side account storage. |
| Support request | Name, reply email, selected topic, message, local reference number, timestamp, and local delivery status. | Local support-ticket record. |
| Technical request data | Standard request information needed to serve a page and diagnose errors, such as time, route, and server logs. | Local application/server logs. |
2. Why we use it
- Run accounts and games — to create an eligible account, keep a fictional balance stable, protect forms, and prevent duplicate application of a spin request.
- Provide requested account access — to authenticate email/password sign-in, prepare password recovery, and, only if enabled, complete Google sign-in.
- Provide requested help — to capture and reference a Support submission in this local build.
- Apply Player Care choices — to remember the local reminder or break selection during the current session.
- Keep the product secure — to investigate errors, misuse, or attempted interference.
4. Retention
Account, virtual-credit activity, and support data are retained in the local development storage while this local environment remains available. Password recovery tokens are stored only as hashes and expire after one hour. A public release must set and publish a verified retention, deletion, and privacy-request process before collecting production user data.
5. Security posture
The current build uses CSRF protection and HttpOnly cookies for the local session. Because localhost is not HTTPS, the local cookie configuration cannot demonstrate the Secure-cookie setting required for a public HTTPS release. Never submit passwords, payment details, government identifiers, or sensitive personal narratives through the local Support form.
6. Your choices and questions
You can clear browser data through browser controls, though doing so may end the current local session. For access, correction, or privacy questions about a local Support record, contact help@ryanjbanda.com and include the support reference when available.
7. Updates to this notice
We will update the effective date and this notice when the product's data handling changes. The operator identity and production privacy-contact process remain launch blockers and will not be invented in this local build.