Privacy Product Changes — What We Need to Build

Date: 2026-07-29 · Status: Draft for review

This is the plain-language list of product/engineering work that came out of the privacy-notice review (DPO's draft + outside counsel's comments). The point of all of it: the notice makes promises about how we handle data — we need the product to actually do those things before we publish the promises.

Plain-language on purpose. Where a law is named, it's just so the right people can find it — the "what to do" is the part that matters. The marketing-email consent piece has its own detailed spec: [marketing-consent-product-spec.md].

0. Data Privacy Framework — confirmed active ✅

The notice relies on the EU/UK/Swiss "Data Privacy Framework" (what lets us move European data to the US). Counsel's earlier comment flagged it as lapsed, but it is now confirmed active — so the notice's claim is accurate and there's nothing to fix here.

One ongoing thing: DPF requires annual re-certification. Put the renewal on a calendar with an owner so it can't quietly lapse again (that lapse is what triggered the comment).

1. The work, in plain terms

Each item has a status: ✅ done · 🟡 partly done / confirm · ⬜ to build · 🔎 to check. "Covered in consent spec" points to [marketing-consent-product-spec.md]; "Data Retention PRD" is its own doc.

A. Cookie / tracking consent — 🟡 In place (EU), confirm & extend

Status: 🟡 Usercentrics live in EU — confirm it's actually blocking tags, reconcile the cookie policy, extend config to UK/US.
What it is: the banner that asks permission before tracking cookies run. We use Usercentrics in the EU. Counsel's concern is that the old "you agree just by using the site" approach isn't allowed anymore.
What to do:

• Confirm Usercentrics actually blocks non-essential tags until the user says yes (not just shows a banner).
• Make the on-site cookie list match what Usercentrics blocks — right now the cookie policy and the notice disagree (mention old Flash cookies, list trackers that don't match).
• Decide coverage beyond the EU (UK, and the US signal below) — Usercentrics can handle these too, so this is mostly configuration, not a new tool.

B. "Do not sell or share my info" + honor the browser signal — ⬜ To build/configure

Status: ⬜ To do (likely a Usercentrics config, not new tooling).
What it is: we send a scrambled version of the email to ad partners so ads can be targeted. California treats that as "sharing," and people have the right to turn it off — including automatically via a browser setting (GPC).
What to do: add a "Do Not Sell or Share My Personal Information" link, and make the site automatically respect the GPC browser signal. Usercentrics can drive this too.

C. "Limit use of my sensitive info" — 🔎 Check first, probably NOT required

Status: 🔎 Investigate, don't assume a build (see double-check below).
What it is: California has a special "sensitive info" bucket (e.g. SSN, precise location, log-in credentials, genuine health data). People can ask us to use it only for the basics — but only in specific conditions.
Double-checked against the California law — two corrections to the earlier draft:

• Brain-training/cognitive scores are almost certainly NOT "health" data. After the 2016 FTC settlement, Lumosity is positioned as games, not health; game scores aren't medical info. Drop that claim.
• The "Limit" link is required only if we use sensitive info to profile people (to "infer characteristics") beyond providing the service. If we don't, no link is required — just collecting some sensitive data doesn't trigger it.
  What to do: confirm (a) what sensitive info we actually hold — realistically account login/password, maybe health details people type into surveys/research — and (b) whether we use any of it to profile people. If not (likely), we don't build the link; we just state that accurately. If we do, add the link + honor GPC. So: a check, not a definite build.

D. Kids and Family Plan child accounts — 🟡 US COPPA done, confirm the rest

Status: ✅ US COPPA (under-13) handled (see COPPA compliance work). 🟡 Two things left to confirm, since they're separate from COPPA:
What it is: we're not supposed to knowingly sign up young children without a parent's permission, and child accounts on the Family Plan are supposed to have real parental controls.

• Non-US age rules — parts of the EU set the line at 16, Spain/Korea at 14, and the UK has its own kids' code. Confirm the age check + parental step cover those, not just US-13.
• Family Plan controls — confirm child accounts actually give parents/guardians real controls (counsel flagged these "can't be optional").

E. Recordings (Figment audio/video) — ⬜ To build/confirm

Status: ⬜ Open — currently undisclosed; higher-risk than it looks.
What it is: we record audio/video in Figment. Some US states require everyone on a recording to agree, and some laws treat voice/face as "biometric" with extra rules.
What to do: show a clear permission step before recording, capture that permission, and handle the stricter states/biometric rules. This is currently undisclosed and higher-risk than it looks.

F. Data requests — access, delete, correct, export, object — 🟡 Manual is fine

Status: 🟡 No tooling required — a reliable manual process works. The law cares that we fulfill requests on time, not that it's automated.
What it is: people can ask to see, fix, delete, download, or object to how we use their data.
What to do:

• Keep a tracked intake (help-center queue / ticket) so nothing slips, with a deadline reminder (~1 month EU, ~45 days California).
• Make sure whoever handles it can actually pull a complete, accurate copy and delete across systems.
• Net-new bits worth wiring in: "correct my info", and a clear "stop using my data for marketing" (that one is just the Customer.io unsubscribe from the consent spec).
• Only revisit automation if volume grows — e.g. bulk law-firm requests. Until then, manual is fine.

G. How long we keep data (retention) — ✅ Done

Status: ✅ Done — covered by the Data Retention PRD. Kept here for completeness; no new work. Just make sure the privacy notice's retention wording matches what that PRD actually sets.
What it is: "we keep it as long as needed" isn't specific enough anymore — we need set timeframes per type of data.

H. Vendor / recipient list — 🟡 Covered in consent spec

Status: 🟡 In the consent spec (vendor list). Publish it as an annex to the notice.
What it is: we have to be able to say who we share data with. Today the notice says "and others," which isn't enough.
What to do: keep a current list of the companies we share data with and publish it as an annex. (In the consent spec.)

I. More US states — 🟡 Covered in consent spec

Status: 🟡 In the consent spec (country/state logic). Extend notice wording to match.
What it is: the notice only calls out Nevada and California, but several other states now have their own privacy laws.
What to do: cover the other big state laws (Colorado, Connecticut, Texas, Virginia…). Ties into the country/state logic in the consent spec.

J. India — ⬜ To build

Status: ⬜ Open.
What it is: India's privacy law expects a complaints ("grievance") path, a way to nominate someone to act for you, and a named local contact.
What to do: add a grievance/complaint flow, a "nominate someone" option, and fill in the India representative details (blank today).

K. Confirm, don't necessarily build

• Automated decisions: confirm our cognitive scores aren't used to make big automated decisions about people without a human involved. If they could be, add a human check / opt-out.
• Card data (PCI): confirm payment card handling meets PCI standards and clarify what "payment processor tokens" are.
• Privacy risk assessment (DPIA): document a risk assessment for health / recordings / cognitive data. (Paperwork, not code.)

2. The most important habit

Counsel's comments are mostly questions: "what age check do you use?", "how do you get parental permission?", "what controls exist?" For several of these, the honest answer today is "we don't yet."

So the rule going forward: build it first, then say it in the notice. Publishing a promise we don't yet keep is the same mistake that caused the marketing-email complaint — claiming we're compliant when the facts don't back it up.

3. Suggested shape of the work

Rather than one giant "privacy" project, split into tracks with clear owners:

1. Consent — marketing email + cookies (Usercentrics config) + US do-not-sell/share (+ check whether limit-sensitive is even needed).
2. Kids — US COPPA done; confirm non-US age thresholds + Family Plan controls.
3. Recordings — Figment permission + biometric/state handling.
4. Data rights & records — request handling (manual is fine), retention, vendor list, multi-state, India. (Largely the consent spec.)

4. Next steps

1. Put the DPF annual re-certification on a calendar with an owner (§0).
2. Have product answer counsel's factual questions (age check, parental-consent method, recording permission wording, what "sharing" happens, retention periods) — that closes out about half her comments.
3. Slot the tracks above into the roadmap.
4. Don't publish notice language for anything we haven't built yet.