Compliance & risk
Which questions need a lawyer, which are settled enough to design around, and which are neither.
Where the answer is "ask counsel", that is stated rather than papered over. The researching agent downgraded its own confidence on several claims during this work — those are marked, and some must not be quoted at all until verified.
The five things that matter
1 · Roblox is prohibited
Not grey. Three documents, the most recent eight weeks old, drafted to foreclose the safety-purpose argument. Best-evidenced finding in the research.
2 · Twitch is grey but achievable
Under a narrow design — OAuth only, 13–17 only, derived signals not retained content, and one written question resolved first.
3 · A live App Store exposure exists today
Sway's existing integrations breach Apple 5.1.1(v) on both limbs. Not a gaming problem — it gets worse if platforms four and five join the same pattern.
4 · The DPIA is mandatory and absent
Art 35(3)(b) triggers it alone. Reportedly a named ground in both 2026 ICO children's-data fines. Cheapest risk reduction available.
5 · The child must be told
ICO Standard 11 requires "a clear and obvious sign… when monitoring or tracking is active", at every age band. One decision satisfies three regimes.
What must not be quoted yet
| Claim | Status | Action |
|---|---|---|
| Meta v. BrandTotal holding and settlement | Unverified | Do not publish. The researching agent explicitly retracted its earlier
Confirmed label. Check the docket |
| ICO fines — Imgur £247,590; Reddit £14,472,500 | Likely | Verify at ico.org.uk. The Reddit figure is large enough to be quoted back at you |
| UK under-16 ban, Spring 2027 | Likely | Verify before board discussion |
| UK GDPR Art 6(1)(ea) safeguarding basis | Likely | Not retrieved. Highest-value open question |
| CJEU C-184/20, C-21/23 | Likely | Retrieve judgments before relying on them |
COPPA
The amended Rule has been fully enforceable since 22 April 2026. Confirmed
COPPA reaches operators through two doors. Sway has a decent argument on the first (not child-directed). It walks straight through the second: the product requires the parent to create a sub-account for a named child and supply an age. Sway is not inferring the age or discovering it accidentally — it is told, deliberately, as a precondition of the service functioning. That is actual knowledge in its most unambiguous form.
- Verifiable parental consent: use §312.5(b)(2)(ii), the card-transaction method. Sway is a paid subscription, so the parent already transacts. No new vendor, no biometrics. Bind consent capture to the subscription event and log it.
- §312.10 retention: requires a stated deletion timeframe, a written policy, and publication of that policy. Sway deletes on account closure only, with no time-based expiry on posts, interactions or classifications. That satisfies none of the three.
- §312.8: a written security programme, annual risk assessments, and written assurances from every subprocessor touching child data.
UK Children's Code
Correction to the original brief: parental controls is Standard 11, not Standard 14. Standard 14 is Online tools.
The Code applies — settled by Sway's own code, not by argument. Sub-accounts are User
records and there is a child login flow. Children are literally users of the service.
"If your online service allows a parent or carer to monitor their child's online activity… provide an obvious sign to the child when they are being monitored."
"You should provide a clear and obvious sign for the child (such as a lit up icon) which lets them know when monitoring or tracking is active."
Two non-negotiable design inputs: covert monitoring is non-compliant by construction, and a real-time indicator is required — not a one-off disclosure.
Standard 8 is also a problem: it limits collection to what the child is "actively and knowingly engaged" in. That is hard to satisfy for data ingested without the child's moment-to-moment awareness, and impossible for the child's chat partners.
The Online Safety Act bind
Original reasoning: Sway ingests content through its own pipeline, so it is not user-generated content — out of scope.
Why it broke: that rested on an unstated premise — that the only user of Sway is the parent. False. Once the child is a user, s.3(2)(a) becomes live: "it does not matter if content is actually shared… as long as a service has a functionality that allows such sharing."
The better view is still out of scope — the data is retrieved by Sway's pipeline, making it provider content. But this now needs counsel sign-off, not a comfortable conclusion.
ICO Standard 11 requires a child-facing surface with a real-time monitoring indicator. Every increment of child-facing functionality strengthens the argument that the child is a user of a user-to-user service. The Children's Code pushes toward exactly what the OSA penalises.
Candidate resolution: a strictly read-only, provider-generated transparency view with no child input path. Whether that survives s.3(2)(a) is precisely the counsel question.
GDPR with children
| Data subject | Relationship | Difficulty |
|---|---|---|
| The parent | Customer, contracting party | Easy — Art 6(1)(b) |
| The child | Data subject; a user, not the customer | Hard |
| Third parties | None whatsoever | Hardest |
Consent is structurally weak. Outside Art 8 there is no age, only a capacity test — so for a competent child, the parent's consent is not valid consent. And a teenager pressed to click "allow" to keep their phone is a textbook failure of "freely given".
Children's chat routinely contains health, sexuality, religious and political data. Even on the ICO's narrower intent-based test Sway fails, because the product infers self-harm risk and sexual-content exposure and then treats the child differently by alerting the parent. And much is not inference at all — "I've been cutting again" reveals health data on its face.
There is no version of this product where ingesting chat content avoids Article 9.
DPA 2018 Sch 1 para 18 requires that processing be carried out without the data subject's consent. So you cannot run a belt-and-braces argument of "the teenager consented and we rely on para 18" — they are mutually exclusive. It fits best where the child is too young to consent, and worst for the 15–17 cohort.
Data minimisation — the ranked list
| Mitigation | Real legal effect |
|---|---|
| Don't ingest message bodies | Dispositive — changes the legal character of the product |
| On-device classification | High — but only if genuinely leak-free |
| Store classifier output not content | Partly counterproductive — "@user123: grooming risk HIGH" is an adverse assessment of a third party, arguably worse than the raw message |
| Short retention | Moderate — a short-lived unlawful copy is still unlawful |
| Hashing third-party identifiers | Cosmetic — re-identification is the product; the parent sees the handle |
| Parent warranties of authority | Actively harmful — reads as evidence you knew and papered over it |
Technically possible, legally unwise
| Practice | Exposure |
|---|---|
| Storing session cookies server-side — current Sway practice | Apple 5.1.1(v) both limbs; one column dump is full account takeover for every connected child; GDPR Art 32; COPPA §312.8 |
Asking for the .ROBLOSECURITY cookie or password |
Account termination for the child; Apple 5.1.1(vi) → removal from the Apple Developer Program; possible Computer Misuse Act exposure |
| Scraping undocumented Roblox endpoints | ToU termination; an unfair-processing finding under Art 5(1)(a) |
| Storing full chat transcripts including other children's messages | ICO enforcement; the headline is "child-safety startup leaks children's private messages" |
| Covert monitoring with no indicator | Children's Code non-conformity; Google Play removal as stalkerware |
| Silently continuing after a competent teenager objects | The scenario most likely to trigger a complaint-driven ICO investigation |
| Marketing copy using "spy", "secret", "stealth" | Play rejection on metadata alone, independent of app behaviour |
App stores
"An app may not store credentials or tokens to social networks off of the device and may only use such credentials or tokens… while the app is in use."
Both limbs: UserSocialAccount.cookie lives in Postgres, and a cron job uses it with the
app closed.
Calibrated honestly: the same sentence covers server-side OAuth refresh tokens, which is widespread and unevenly enforced. The cookie case is far more clear-cut. Migrating cookies → OAuth is a large improvement even if it does not achieve perfect purity — and should not be blocked on achieving it.
Google Play stalkerware (in the Malware policy, not Device and Network Abuse)
permits parental monitoring only with: no spying presentation, no cloaking, a persistent
notification at all times when running, a unique icon, store-listing disclosure, the
IsMonitoringTool flag, and compliance with applicable law — which Google has
contractually made its policy problem too.
A persistent, real-time child-facing monitoring indicator satisfies ICO Standard 11, Google Play's persistent-notification requirement, and Apple 5.1.2(iii) on not "surreptitiously" building a profile. It is the highest-leverage single change in the whole programme.
Questions for counsel
- Does the existing child sub-account login make Sway a regulated U2U service under OSA s.3(1)? Highest stakes.
- Can Sway rely on UK GDPR Art 6(1)(ea) "safeguarding a vulnerable individual"? Best available UK basis if it works; untested.
- Does DPA 2018 Sch 1 para 18 survive alongside consent-based onboarding?
- How does Sway handle a Gillick-competent teenager who objects — and what is the parent told?
- Is the EU launchable at all, given no equivalent of para 18 and that explicit consent fails for third parties?