Child Safety Policy

This policy sets design, operational, and governance standards to protect children and youths on the Tanqory platform. It covers age gating and consent, data handling, protection against inappropriate content/features, reporting and emergency response, and compliance with global child safety and privacy laws.

1) Scope, Purpose, and Definitions

Applies to all Tanqory services and features that children/youth may access (web, mobile, API, connected third‑party systems). Objectives: (a) prevent harm to children; (b) process data lawfully and minimally; (c) give parents adequate information and choice; (d) meet global standards. “Child” means under 13 where COPPA applies or the stricter local definition; “minor/youth” means under 18 unless local law is stricter. EU/UK: age of consent for personal data is 13–16 depending on country. If conflicts arise, applicable law/contract prevails.

2) Age Gating and Consent

We apply layered age assurance proportional to risk: (1) self‑declaration with responsibility notice; (2) device/behavioral signals and risk‑based checks; (3) documentary/identity checks only when legally required; (4) parental verification where mandated. GDPR‑K/UK AADC: 13–16 by country. US COPPA: <13 requires verifiable parental consent (e.g., payment card/knowledge‑based/ID + facial match where permitted). Provide clear parental dashboards to view/revoke consent, manage settings, and request deletion. Consent/withdrawal is time‑stamped for audit and honored without friction.

We publish concise, age‑appropriate notices explaining why age is requested, what happens if age is misstated, and how parents can supervise. We avoid unnecessary collection (no ID upload unless legally required) and provide a fallback flow if verification fails (e.g., limited experience or deny access). We log and periodically review age‑assurance efficacy to reduce false positives/negatives and adjust signals to minimize intrusion. For shared/family devices, we provide reminders and session time‑outs to prevent silent switching to adult profiles. Where biometric or facial matching is used, it must meet local biometric laws, be optional, and be deleted immediately after verification unless law requires retention.

Parental consent flows include clear disclosures: categories of data collected, purposes, sharing, retention, rights to revoke, and how to contact Tanqory. Withdrawal must be as easy as giving consent. When consent is revoked, we stop processing and delete/erase data unless retention is legally required (e.g., safety logs, billing records). We keep an auditable trail of consent events, revocations, and any parental communications. Appeals relating to age gating (e.g., wrongful denial) are handled via support with defined SLAs.

Age‑based experience: where laws or risk assessments require, we deliver differentiated experiences (e.g., reduced features, no public posting, no messaging with strangers, stricter filters) for children, and stronger spending controls and safer defaults for minors. We do not gatekeep access to safety or educational content behind strict ID unless required; instead we use proportional friction to avoid excluding legitimate child users while meeting legal duties.

3) Data Minimization and Use

Collect only what is necessary for service and safety; avoid sensitive data (biometric/health/belief) without clear legal basis/consent. Use anonymization/pseudonymization where possible; restrict access via RBAC/ABAC and log access. Follow Data Retention Policy: store for the shortest necessary period; delete/anonymize when no longer needed or upon parental/data subject request. Cross‑border transfers require lawful mechanisms (DPA/SCC/Addendum) and encryption in transit/at rest.

We perform DPIA/child‑specific risk assessments for any feature that touches child data. Exact data elements, purpose, and lawful basis are documented and reviewed at least annually. System designs must default to data minimization: no precise geolocation, contact lists, photos, or device IDs unless strictly necessary and consented where required. We prohibit combining child data across contexts for profiling or product bundling without a lawful basis and parental consent where needed. Sensitive categories (health, beliefs, biometric templates) are collected only if mandated or clearly justified and accompanied by enhanced safeguards (encryption, separate storage, strict access). Where feasible, we use edge processing and tokenization to reduce raw data storage.

Access is least‑privilege, time‑bound, and role‑based; elevated access requires approvals and is logged with periodic reviews. We maintain a record of consents, withdrawals, parental communications, and data subject requests with timestamps and outcomes. De‑identification/anonymization methods are validated to reduce re‑identification risk; re‑use of de‑identified data for analytics must pass a re‑identification risk check. We block data brokers and prohibit sale/share of child data for advertising. Data sharing with service providers is purpose‑limited, contractually constrained, and monitored; onward transfers must follow equivalent safeguards. Backup and restore processes must preserve deletion/erasure instructions within feasible technical limits and timelines.

Retention: default to short retention with documented maximums; periodic purge jobs enforce deletion/anonymization. When parents or data subjects request erasure, we process without undue delay, subject to legal holds (e.g., fraud, safety investigations, billing) and inform them of any required retention. Audit trails for access and changes to child data are kept for the legally required period, then minimized. Cross‑border transfers: map data flows; use SCC/IDTA/BCR or applicable addenda; apply TIA and supplementary measures where required (e.g., per EDPB guidance). Encryption keys are segregated and rotated; production data is never copied to non‑prod without minimization/masking and approvals.

4) Safety by Design and Inappropriate Content

Child‑accessible features default to “safe”: limit tracking/behavioral ads; disable public comments/interactions by default where risk is high; enable filters/blocks for CSAM/CSEM, violence, drugs, gambling, adult content, and NSFW classifiers/guardrails for generative AI. Apply age‑appropriate time/use limits where relevant. Disclose third‑party data sharing; avoid dark patterns that nudge youth into oversharing or unintended purchases.

We prohibit nudging toward higher risk settings, excessive spending, or sharing precise location. High‑privacy defaults: precise geolocation, camera, mic are off unless strictly necessary and consented by parent/guardian where required. Loot boxes/gambling‑like mechanics are blocked for children and restricted for minors per local law; spending limits and parental approval are enforced for paid features. For GenAI, we enable safe prompts/outputs, block age‑inappropriate generations, and watermark/label AI content where feasible.

Design follows age‑appropriate principles (e.g., UK AADC, Online Safety regimes): no persuasive design to extend screen time or weaken privacy; prominent safety controls; simplified language for notices and settings; and friction for sharing outside trusted circles. Public posting, messaging with strangers, and group joins are off by default for children; friend requests are limited or require parental oversight. Reporting/flagging is one‑click and visible; unsafe content is hidden pending review. Content recommender systems for youth exclude sensitive categories and high‑risk topics; ranking parameters that could surface harmful content are bounded by policy and filters.

Advertising and commercial features: no behavioral ads for children; contextual ads (where lawful) must exclude sensitive signals and be clearly labeled. Sponsorships/influencer content must be disclosed; no “buy now” dark patterns or pressure tactics. Purchasing and upsells require clear disclosures, spending caps, and, where required, parental approval. No targeted offers based on vulnerability signals. We disallow monetization features that mimic gambling (loot boxes, randomized rewards) for children and constrain them for minors per law and internal policy.

Platform interactions: we rate‑limit and monitor for grooming/bullying signals, with automated detection plus human review where appropriate. Safety classifiers (NSFW, violence, self‑harm) run on uploads and GenAI outputs; high‑risk hits are blocked or quarantined for review. We label AI‑generated media and apply provenance/watermarking (e.g., C2PA) where feasible. Search and recommendation “safe modes” are on by default for child accounts, with easy reversion only by authorized adults where law permits.

Location and device features: precise location sharing is disabled; coarse location only when necessary for core function and with consent where required. Camera/mic access is session‑bound, indicated visually, and defaults off. No background collection of ambient audio or biometrics. User profiles for children hide contact info and limit discoverability.

Third‑party and store content: child‑facing surfaces require apps/themes/plugins/feeds to comply with this policy; non‑compliant items may be blocked/removed. Stores must declare age ratings and supported regions; we may enforce region/age gating for high‑risk categories. AI prompts/examples exposed to youth are curated for safety; user inputs that indicate self‑harm/abuse trigger supportive messaging and optional helpline links in applicable regions.

Testing and validation: child‑accessible features undergo safety QA, threat modeling for harms to minors, and adversarial tests (e.g., prompt injection to bypass safety filters). We review UX for dark patterns and accessibility (WCAG). Any new high‑risk feature requires approval by Child Safety Lead and, where applicable, completion of a children’s DPIA/Online Safety risk assessment.

5) Reporting, Review, and Response

Provide visible reporting channels (in‑app report button/form, safety@tanqory.com), acknowledge within 24 hours, and follow Incident Playbook SLAs. Child/youth cases get priority triage; temporarily block content/accounts if high risk. Coordinate with authorities/child protection orgs as required; notify parents/affected parties where appropriate; preserve evidence lawfully; perform post‑incident review with owners/action items. Maintain clear owners and target times per stage (intake‑triage‑mitigate‑close) in systems for audit. Playbooks cover CSAM/CSEM, bullying, harassment, scams targeting youth, with immediate segregation from harm. Engage law enforcement for potential criminal matters using safe, rights‑respecting procedures. Conduct drills periodically; update playbooks after major incidents.

CSAM/CSEM handling: zero‑tolerance. We use industry‑standard hash‑matching (e.g., PhotoDNA/industry databases where legally permissible), verify matches with trained reviewers, and report to competent hotlines/authorities (e.g., NCMEC in the US or national hotlines) as required by law. We do not deploy invasive device scanning; scanning is limited to content hosted/processed on our services. Evidence is handled under chain‑of‑custody procedures. For grooming, self‑harm, or suicide content, we escalate to specialized reviewers, provide helpline links where applicable, and remove/limit swiftly under Online Safety/child protection rules.

6) Marketing, Ads, and Communications to Youth

No behavioral targeting of children/youth where prohibited/restricted; do not sell/share child data for behavioral ads. Ads must be age‑appropriate; no illegal/harmful/unsuitable products. Marketing must be clear, without coercive/social‑pressure tactics. Email/SMS outreach requires lawful consent and clear opt‑out.

Influencer/paid content must be clearly labeled as advertising/sponsored. We do not allow targeted ads based on precise geolocation, health, or sensitive categories for children, and we avoid profiling for differential pricing or dark‑pattern upsells. Where law permits contextual ads, we ensure they exclude sensitive signals and comply with applicable child codes. Promotions directed at minors include spending controls and transparent disclosures.

7) Partners, Providers, and Third Parties

Processors/suppliers/partners handling child features or data must pass safety, privacy, and contract reviews (use limits, transfer/storage limits). Do not engage providers lacking child safeguards or with CSAM/CSEM violations. Must support deletion/return of data at contract end or upon parental/data subject request. Tanqory may audit/require attestations and may suspend use for non‑compliance.

Third‑party SDKs/APIs used in child‑accessible areas must avoid tracking/ads unless permitted with proper consent; we require written assurances on child safety, logging, and prompt incident reporting. Subprocessors must notify us of any law enforcement data demands involving child data and may not disclose without our review unless legally compelled.

8) Regional Requirements

• US (COPPA/state): <13 requires verifiable parental consent; no behavioral ads; provide notice/parental dashboards when collecting child data; follow stricter state laws where applicable.
• EU/UK: GDPR/UK GDPR Art.8 (age 13–16), ePrivacy/PECR, UK Age Appropriate Design Code, Online Safety Act; high‑default privacy; no inappropriate profiling/ads.
• Singapore: PDPA; use clear local language notices.
• Australia: Privacy Act and Online Safety Act for youth/content.
• Japan/Korea/Brazil/UAE: apply APPI/PIPA/LGPD/local youth/ads rules.
  Update promptly if new child/online safety laws take effect.

If the EU Digital Services Act (DSA) applies, we will perform child‑specific risk assessments/mitigations, and if designated VLOP/VLOSE, publish risk topics and mitigations related to protection of minors, plus transparency on recommender parameters. If UK Online Safety Act applies, we will assess and mitigate priority harms to children and enable user empowerment tools as required. Under Quebec or other language‑mandate regions, we provide notices/consents in required languages.

9) Training, Oversight, and Audit

Staff/partners touching child data/features must complete annual training (child safety, CSAM/CSEM awareness, data protection, AI safety) and pre‑access training for high‑risk systems. A Child Safety Lead works with Legal/DPO/Security/Trust & Safety; reviews incidents/stats quarterly; reports to leadership at least annually. Conduct periodic tests/audits of child‑accessible systems/features. Tanqory may suspend access/contracts for violations.

Training includes spotting grooming/bullying patterns, safe escalation, and lawful evidence handling. Audits check age‑assurance efficacy, ad/commerce compliance, default settings, and log/retention hygiene. Non‑conformities have corrective actions and deadlines; repeated failures may lead to termination of access or contracts.

10) Transparency, Communications, and Changes

Maintain a child safety page explaining usage, restrictions, prohibited content, parent/child contacts, and FAQ. Update version/date on changes; material changes (e.g., new data collection/providers) are announced via email/dashboard (durable medium) with reasonable notice. Provide complaint/appeal channels (legal@tanqory.com, childsafety@tanqory.com, support) with SLAs per Incident Playbook. English controls legally if translations differ. If any part is invalid, the remainder stays effective; specific contract/Order Form terms prevail over general text on conflict.

Appeals/complaints: acknowledge within 24 hours; provide status updates; target resolution per playbook (e.g., severe harm <72h). We maintain logs of notices/consents/appeals and decisions for at least the legally required period, then delete/anonymize. Public transparency: publish a summary of child safety actions/metrics (e.g., CSAM reports, takedowns, appeals outcomes) annually or as required by law, omitting personal data. Notices are WCAG‑compliant and age‑appropriate; language localization provided where legally mandated.

---

Document Details