DogStark / DogStark/Wordbloc

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

Open
#25 3 comments 0 reactions 1 assignee Claimed by @Kureszn View on GitHub
backend difficulty: hard frontend GrantFox OSS Maybe Rewarded security smart-contracts Third Campaign
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.