Privacy Policy
Placeholder — not legal advice. Must be reviewed and replaced by a qualified professional before this application accepts real users.
The sections below outline what a real Privacy Policy for this specific application needs to cover, referencing what TypeSarthi actually collects and stores today so it's a useful starting point for that review — not filler text to be deleted, and not a substitute for one.
1. What this application collects
Account details (name; email and a bcrypt-hashed password for full accounts — guest accounts have neither until claimed); practice session metrics (WPM, accuracy, per-key mistake data, duration, timestamps); custom practice text a user saves; review submissions; a colour-theme and interface-preference cookie/setting; and, for review submissions specifically, a SHA-256 hash of the submitter's IP address — not the raw address — used only to rate-limit and detect abuse.
2. How this data is used
To operate core features: tracking level progress and streaks, computing badges, generating certificates, powering the opt-in leaderboard, generating adaptive practice text from per-key proficiency, and moderating review submissions.
3. Storage and security
Data is stored in a Postgres database. Passwords are hashed with bcrypt and never stored in plain text. Certificate numbers and password-reset tokens are generated with a cryptographically secure random source, not a predictable one. Needs confirmation of the actual hosting provider and database location before publishing.
4. Third parties
Needs an accurate, current list before publishing: the authentication library in use (NextAuth/Auth.js), the hosting platform, the database provider, and — once integrated — any advertising network. No email-sending provider is connected yet (see the password-reset flow); once one is, it must be listed here too.
5. Cookies
A single cookie stores the visitor's colour-theme choice so it can be applied before the page renders, avoiding a flash of the wrong theme — including for signed-out visitors, who have no account to store a preference against otherwise. Needs a statement of exactly what else is cookied once an ads network is integrated.
6. Guest accounts specifically
A guest account is created immediately on “Continue as guest” with no email collected. Needs a clause on how long unclaimed guest data is retained and whether it is deleted automatically after a period of inactivity.
7. Data retention
Needs a defined retention period for practice history, reviews, and inactive accounts.
8. Your rights and account deletion
Deleting an account is already a real, working feature (available from the Account page) and removes the account and its associated practice history. Needs a clause confirming what “removes” means precisely (hard delete vs. anonymisation) and how a user can request a copy of their data before deleting it.
9. Children's privacy
Needs an age-appropriateness statement suited to the target audience (competitive exam aspirants, generally adults) and, if minors can plausibly use the service, appropriate additional protections.
10. International users
Needs a statement on cross-border data transfer if users outside the hosting region are expected.
11. Changes to this policy
How and when updates take effect, and how users are notified.
12. Contact
Replace with a real contact address before launch.