COPPA Notes

The Children's Online Privacy Protection Act (COPPA, 15 U.S.C. §§ 6501–6506) and its implementing rule (16 CFR § 312) restrict how operators of online services may collect personal information from children under 13.

This document describes how Curio's design intersects with COPPA. It is engineering notes, not a substitute for legal review.

TL;DR

Curio's UI is built for very young children, but the account holder is the parent. The product collects no personal information directly from a child. The child's name and birth date are entered by the parent, used only locally to age-tune games, and are not used for advertising or for any purpose outside the parent's own account.

The conservative interpretation: counsel may still classify Curio as "directed to children" because the gameplay UI clearly targets young users. In that case, COPPA's verifiable parental consent (VPC) requirements apply to the parent's own act of using the Service, not to a child user.

Key product facts counsel will need

Where the parent provides consent

• At signup. The parent must tick a consent checkbox affirming they are the child's parent/legal guardian, are 18+, and accept the Terms of Service and Privacy Policy before the account can be created. The checkbox gates both the email and Google signup paths (SignupPanel.tsx, AuthModal.tsx).
• Before the parent-only area. A parental gate (two-digit arithmetic — ParentalGate.tsx) stands in front of Settings, where child profiles and account controls live, so a child can't reach them unaided. This is a gate, not verifiable parental consent.
• At first child-profile entry. Settings prompts for the child's first name, birth month, birth year. None are required.
• At first photo upload. The browser's native camera-permission prompt acts as a second affirmative gate. In-app copy directs the parent to photograph the child's belongings, not the child.

If counsel determines that verifiable parental consent under § 312.5 is required (because the Service is treated as directed to children), additional consent steps may be needed. The Service is designed to make the choice of method (credit-card validation, signed-form, government-ID, etc.) straightforward to add at signup without redesign.

Operational controls already in place

1. Server-side admin allowlist. MISTUFF_ADMIN_EMAILS gates the admin endpoints. Empty value fails closed.
2. Row-level security on every user-facing table. A parent's data is never visible to another account.
3. No advertising or analytics SDKs. Product analytics is limited to first-party, aggregated, de-identified game-session metrics (accuracy, usage counts) with no per-child or per-account linkage retained in the aggregate — this falls under COPPA's "internal operations" exception (16 CFR § 312.2) and is disclosed in Privacy Policy §3.
4. CSP, HSTS, X-Frame-Options: DENY prevent third-party framing and most injection vectors.
5. Rate-limited share-invite endpoint (20 / hour) — prevents the email feature from being weaponised as a spam relay.
6. Parent-initiated data export and account deletion are exposed in Settings → Account ("Download my data" / "Delete account"), backed by /api/account/export and /api/account/delete. Deletion wipes child profile fields (name, birth month/year), collections, photos, sessions, share invites, and the auth row.

Open items before public launch (US)

• Counsel confirms COPPA classification (directed-to-children vs mixed-audience vs parent-tool).
• If directed-to-children: choose VPC method and integrate. Note the current signup checkbox is consent acknowledgement, not a §312.5 VPC method (credit-card, signed form, gov-ID). Counsel decides whether the parent-tool posture makes full VPC unnecessary.
• Update Privacy Policy §5 with the chosen approach.
• Apple Kids-category submission (mobile only): parental gate with a math problem before Settings. (Implemented — ParentalGate.tsx.)
• FTC-style direct-notice email at signup (the welcome email is the natural place; see src/app/api/auth/welcome/route.ts).
• Designate a privacy contact. (dscullywebdesign@gmail.com, named in the Privacy Policy.)
• Document an internal data-retention / deletion procedure. (90-day inactivity photo purge — see legal/BREACH_RESPONSE.md sibling doc and src/app/api/cron/purge-inactive-photos.)
• Disclose aggregate/de-identified product-analytics use in the Privacy Policy. (See PRIVACY.md §3 and §5 — no separate VPC needed under the internal-operations exception, provided the aggregate never re-links to an individual child or account.)

Open items for non-US markets

What this file is and is not

• It is a product summary for counsel: what we collect, why, and how the architecture limits exposure.
• It is not a legal opinion. The real Privacy Policy must be written or reviewed by a qualified attorney.

This is an unverified draft.