🧒 Privacy-by-design: stop exposing child data on-chain, to third parties, and across profiles
- Dominant language
- JavaScript
- Stars
- 1
- Forks
- 12
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 4
Description
## Problem
The current architecture conflicts with the project’s COPPA/privacy claims. Identifiable child data can be placed permanently on a public blockchain, while the browser sends child gameplay context to third parties and stores all profiles/progress unencrypted under shared, browser-global keys.
## Evidence
- `SpellBlocLeaderboard.registerPlayer(username, ageGroup)` stores a child display name and exact age group in public contract state and emits it in an event; blockchain data cannot honor deletion requests.
- the frontend requests word images from Unsplash at play time, exposing the child’s IP/device metadata and the exact word/category being practiced to a third party.
- names, age, analytics, rewards, AI personality, email preferences, and progress are stored in `localStorage` without per-child namespace, expiry, or deletion workflow.
- Google OAuth creation sets `privacyConsent: true` by assumption.
- no verifiable parental-consent, retention, export, deletion, or third-party inventory implementation is connected to the active browser flow.
## Proposed implementation
1. Complete a data-flow inventory and threat/privacy assessment before collecting more child data.
2. Never put a child name, exact age, email, or stable cross-context identifier on-chain. Use random/pseudonymous identifiers and coarse cohorts only where demonstrably necessary.
3. Proxy, self-host, or bundle child-facing media; apply a strict allowlist/CSP and document subprocessors.
4. Implement verifiable parental consent and make consent purpose-specific, recorded, revocable, and not inferred from OAuth.
5. Namespace data by account/child, minimize it, define retention, and implement export/deletion across local, server, cache, email, analytics, IPFS, and on-chain references.
6. Replace compliance badges/claims until the implementation has been reviewed.
## Acceptance criteria
- No direct child identifier or exact age is written to public chain state/events or third-party URLs.
- A documented data map names every field, purpose, legal/consent basis, processor, retention period, and deletion behavior.
- parents can consent, inspect, export, revoke, and delete a child profile; automated tests verify downstream deletion/tombstoning.
- OAuth and email signup follow the same consent state machine.
- browser storage is account/child scoped and cleared on deletion/logout according to policy.
- a CSP and automated network test prevent undeclared third-party requests from child-facing pages.
## Notes
This needs product/legal review; engineering should avoid representing the result as certified compliance without that review.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.