🧒 Privacy-by-design: stop exposing child data on-chain, to third parties, and across profiles

[llinsss]

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.

[Kureszn]

I've reviewed the issue and believe I can contribute effectively. My experience spans software development, blockchain technologies, cybersecurity and open source collaboration. I take a structured approach to contributions carefully understanding the existing codebase, identifying the root cause and delivering a thoroughly tested implementation.

[amankoli09]

Can i work on this issue PR merge within 1hr

[grantfox-oss]

🦊 GrantFox — @Kureszn has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #25)
2. Your PR will be reviewed by the DogStark maintainers

Good luck! Track your progress on GrantFox.