age-gating-services

在线服务的年龄门控实施

概述

年龄门控是指根据用户年龄限制或调整其对在线服务的访问。这是将年龄验证结果转化为访问控制决策的执行机制。年龄门控可以采用硬性门控（完全拒绝未达到指定年龄的用户访问）、软性门控（为年轻用户提供功能减少或保护增强的修改版体验），或自适应门控（根据不同年龄段逐步调整服务体验）。有效的年龄门控必须兼顾儿童保护、用户体验、无障碍性，以及对 GDPR Art. 8、COPPA、UK Online Safety Act 2023、EU Digital Services Act Art. 28 和 UK AADC Standard 3 的合规要求。

年龄门控类型

硬性门控 — 完全拒绝访问

说明：完全禁止未达到指定年龄的用户访问服务。

适用场景：

• 受法律监管的年龄限制商品和服务（赌博：18 岁以上；酒类销售：18/21 岁以上；成人内容：18 岁以上）
• 无法通过设计措施充分降低儿童风险的服务
• 商业模式从根本上与儿童安全不相容的服务（例如，真实货币交易、加密货币交易所）

实施要求：

• 显示清晰说明拒绝访问原因的消息：“本服务仅面向年满 18 周岁的人士”
• 不得收集或保留被拒绝访问的用户的个人数据（门控所需数据除外）
• 尽可能提供适合该年龄段的替代服务信息
• 不得将被拒绝用户的数据用于任何目的，包括分析

法规依据：

• UK Gambling Act 2005：远程赌博运营商必须进行年龄验证
• UK Online Safety Act 2023 Section 11：服务提供商必须防止儿童接触首要优先级有害内容
• EU DSA Art. 28(1)：未成年人可访问的在线平台必须实施适龄措施

软性门控 — 修改版体验

说明：经识别年龄低于特定标准的用户可以访问服务，但会使用功能经过调整、隐私保护增强或内容受限的版本。

适用场景：

• 受众群体多元（包括成人和儿童）的服务
• 儿童可以从中受益，但需要额外保护的服务
• 教育平台、社交媒体平台和内容分享服务

实施方式：

• 定义不同年龄段，并为每个年龄段设置具体功能
• 对儿童用户应用 UK AADC 的“默认启用高隐私保护”标准
• 禁用对儿童风险较高的功能（与陌生人私信、公开个人资料、行为广告）
• 启用适合相应年龄段的功能（经审核的论坛、教育内容、适龄推荐）

示例（BrightPath Learning）：

功能	8 岁以下	8-12 岁	13-15 岁	16-17 岁	18 岁以上
创建账号	仅由家长管理	经家长批准	独立创建并通知家长	独立创建	独立创建
个人资料可见性	不适用	仅限私密	默认私密，可设为仅好友可见	默认私密，可设为公开	用户自行选择
私信	禁用	仅限预设消息	仅可与联系人发送经审核的文本消息	可与联系人发送未经审核的消息	不受限制
内容推荐	由编辑精选	基于内容的算法	基于内容的算法	内容 + 行为（选择加入）	完全个性化
数据共享	无	无	无（默认）	经同意后可选	依照隐私政策
广告	无	无	仅限情境广告	仅限情境广告	行为广告（经同意）

自适应门槛 — 渐进式访问

描述：服务会根据估算或经验证的用户年龄，动态调整用户体验；随着用户年龄增长，限制会逐步减少。

适用场景：

• 为长期用户关系设计，用户会随着年龄增长跨越多个等级的服务
• 希望提供无缝体验、避免访问权限突然变化的平台

实施方式：

• 制定与年龄挂钩的功能解锁时间表
• 新功能因用户年龄增长而开放时，通知用户（如适用，也通知家长）
• 在关键年龄门槛转换时（例如用户达到 13、16 或 18 岁），要求重新验证年龄
• 从符合儿童最佳利益的角度，记录每项功能解锁的理由

中性年龄提示设计

中性年龄提示会收集用户年龄，但不会暗示“正确”答案或所采用的年龄门槛。这对于防止轻易绕过验证至关重要。

设计原则

1. 不要透露年龄门槛：提示不得表明所需年龄。避免使用：“您必须年满 13 岁才能使用本服务。请输入出生日期。”应改为：“请输入出生日期。”

2. 使用出生日期字段，而非年龄字段：与简单的“您多大了？”字段相比，出生日期更难造假；儿童可以在年龄字段中填写任何高于门槛的数字。

3. 使用带有中性默认值的可滚动日期选择器：日期选择器不应默认显示暗示“正确”答案的日期。默认不选择日期，或默认显示当前日期（这会对应 0 岁，促使用户如实填写）。

4. 不要立即提供反馈：如果用户输入的日期表明其未达到年龄门槛，不要立即显示“您的年龄太小”。这会教会儿童重新输入虚假日期。应先完成注册流程，然后再通知家长。

5. 设置冷却期：如果用户因年龄原因被拒绝访问，应设置 Cookie 或设备指纹，防止其立即使用不同日期再次尝试。常见的最低冷却期为 24 小时。

6. 不要提出诱导性问题：避免使用“您是否年满 13 岁？”这会明确告诉儿童该怎么回答。应使用“您出生于哪一年？”或“请输入出生日期。”

ICO 关于中性提示的指导

ICO 的年龄保障指南（与 AADC 同时发布）指出：“如果使用年龄自我申报，不应以鼓励儿童输入虚假年龄或让儿童容易输入虚假年龄的方式进行设计。年龄门槛不得显示所需年龄，也不得让儿童轻易看出应输入什么内容才能绕过门槛。”

COPPA FTC 指导

FTC 在执法行动中（例如 2019 年 Musical.ly/TikTok 案）指出，年龄门槛的设计必须确保“年龄页面不会鼓励儿童输入虚假年龄”。FTC 认为，非中性的年龄门槛表明服务实际知晓其正在收集儿童数据。

防止绕过

技术措施

措施	说明	有效性
基于 Cookie 的锁定	用户未通过年龄门槛检查时，设置一个持久 Cookie，阻止其在 24-72 小时内再次尝试	中等 — Cookie 可以被清除
设备指纹识别	利用浏览器／设备特征识别同一设备上的再次尝试	中等偏高 — 比 Cookie 更难绕过
基于 IP 的速率限制	限制同一 IP 地址在一定时间内尝试通过年龄门槛检查的次数	低 — IP 地址会变化；共享 IP（如学校）会造成误报
电子邮件验证循环	创建账户前要求验证电子邮件；未通过年龄门槛检查的未成年人无法重复使用同一电子邮件	中等 — 儿童可以创建新的电子邮件地址
逐步升级验证	用户未通过自我声明检查后，要求其在后续尝试中采用更高保障级别的验证方式	高 — 提高了绕过检查的难度
以家长同意作为兜底措施	即使儿童绕过了年龄门槛，在开始收集有意义的数据前仍需获得家长同意	高 — 将验证责任转移给家长

组织措施

1. 员工培训：必须培训客户支持人员，使其能够处理与年龄相关的咨询，同时不透露年龄门槛
2. 监控：定期分析注册数据，查找可能表明有人绕过检查的模式（例如，声明年龄恰好达到最低年龄的用户比例异常高）
3. 投诉处理：建立流程，让家长举报孩子绕过年龄门槛的情况
4. 定期重新验证：在关键节点（年度账户审核、解锁功能）重新验证用户年龄

重新验证触发条件

年龄门槛检查不应只进行一次。发生以下事件时应触发重新验证：

触发条件	操作	理由
用户达到新的年龄级别（例如，年满 13、16、18 岁）	确认年龄并解锁／调整功能	确保用户成长过程中获得适合其年龄的体验
账户恢复	恢复访问权限前验证年龄	防止账户共享或转移给年龄更小的用户
请求更改出生日期	更改年龄数据时要求家长验证	防止儿童将自己的年龄改大
可疑的活动模式	升级至更高保障级别的验证	行为信号与声明年龄不符
年度账户审核	确认年龄声明持续准确	定期检查账户信息
请求升级功能	如果该功能仅限年龄较大的用户使用，则验证年龄	防止用户过早访问有年龄限制的功能

BrightPath Learning Inc. — 年龄门槛架构

注册流程

User visits brightpathlearning.eu
│
├─ "Enter your date of birth" [scrollable date picker, no default selection]
│
├─ Age calculated from DOB and current date
│
├─ Age >= applicable threshold (country-dependent, 13-16)?
│  ├─ YES → Standard registration flow for independent user
│  │         ├─ Verification: email confirmation
│  │         └─ Experience: Standard features with AADC-compliant defaults
│  │
│  └─ NO → Child registration flow
│           ├─ "Please ask a parent or guardian to help you sign up"
│           ├─ Child enters parent's email address
│           ├─ Parent receives direct notice with consent request
│           ├─ Parent completes verification (credit card micro-transaction)
│           ├─ Parent reviews and approves processing purposes
│           └─ Child account created with age-appropriate restrictions
│
├─ Age < 8?
│  ├─ YES → Parent-managed-only account
│  │         ├─ Parent sets up account entirely
│  │         ├─ Child cannot modify settings
│  │         └─ Simplified interface (illustrated, limited text)
│  │
│  └─ NO → Child-managed account with parental oversight
│           ├─ Child can navigate the app independently
│           ├─ Parent dashboard shows activity and can modify settings
│           └─ Age-appropriate interface (text with icons)
│
└─ User enters DOB indicating age < 5?
   └─ "This app is designed for children aged 5 and older.
       Please come back when you're a bit older!"
       [No data retained from this interaction]

防止绕过检查的实现

1. Cookie 锁定：如果用户输入的 DOB 表明其年龄未满 5 岁，则设置一个安全 Cookie，阻止其在 48 小时内再次尝试
2. 不暴露年龄门槛：应用绝不说明最低年龄。注册流程会根据年龄无缝调整
3. 家长兜底措施：即使儿童输入虚假的 DOB 以跳过同意流程，在完成电子邮件验证前，服务也只会收集最少量的数据。未验证电子邮件的账户仅限使用演示模式，不会保存任何数据
4. 异常检测：每周自动分析注册数据，标记声明的 DOB 恰好达到年龄门槛的账户（例如，恰好 13 岁），以便进行人工审核

监管合规矩阵

要求	GDPR Art. 8	COPPA	UK AADC Std 3	UK OSA	EU DSA Art. 28
必须进行年龄筛查	是	是	是	是	是
必须使用中立提示词	暗含要求	FTC 指引	ICO 指引	Ofcom 守则	暗含要求
低于年龄门槛时须取得家长同意	是	是	建议	不适用	不适用
对受限内容设置硬性门槛	否	否	否	是（有害内容）	暗含要求
对混合服务设置软性门槛	暗含要求	暗含要求	是	是	是
必须重新验证	暗含要求	暗含要求	建议	暗含要求	暗含要求
门槛环节的数据最小化	Art. 5(1)(c)	312.7	Standard 8	暗含要求	暗含要求

常见合规失误

1. 年龄门槛不够中立：显示最低年龄要求，或使用“您是否已满 13 岁？”这类提示词，教会儿童撒谎
2. 未防止绕过：允许用户使用不同的出生日期无限次重试
3. 通过门槛前收集数据：在完成年龄门槛验证前运行分析跟踪器、设置广告 Cookie，或收集设备标识符
4. 应设置软性门槛时却设置硬性门槛：拒绝所有儿童访问本可通过调整功能安全地为儿童提供服务的服务
5. 未重新验证：将初次年龄声明视为永久有效，却未设置任何持续验证机制
6. 将年龄门槛当作合规表演：设置一个很容易绕过的年龄门槛，却将其视为已完全符合 COPPA 或 GDPR Art. 8

集成点

• 年龄验证方法：年龄门槛是执行层，根据年龄验证或估算结果采取相应措施
• GDPR 家长同意：年龄门槛决定是否需要家长同意，并据此引导用户
• UK AADC 实施：AADC Standard 3 要求应用适合相应年龄，该要求通过年龄门槛来落实
• 儿童隐私声明：年龄门槛的结果决定显示哪个版本的隐私声明
• 儿童数据最小化：在年龄门槛处及之前收集的数据必须符合数据最小化原则