隐私设计规范

一、概述

隐私设计（PbD）的概念由加拿大渥太华省信息与隐私委员会前主席安·卡沃基安博士（Dr. Ann Cavoukian）在20世纪70年代提出，并在90年代纳入第95/46/EC号欧盟数据保护指令（RL 95/46/EC Data Protection Directive）。PbD提倡将隐私保护主动、全面、前置地嵌入企业技术与商业实践中，即在产品或服务设计之初就纳入隐私保护的需求，使得隐私保护的设计贯穿收集、传输、存储、处理、共享、销毁，整个个人数据处理活动的全生命周期，而不是在产品或服务成型后再寻求事后的补偿措施和手段。

二、PbD七大原则

PbD 的概念提出后，受到国际上的广泛关注，各国也将 PbD 的理念融入立法和审判之中。自1995 年由加拿大隐私专员提出后，2008 年英国做了专门的研究和发布，2009 年欧盟采用了它，2012 年 FTC(Federal Trade Commission，美国联邦公平贸易 员会)就发布报告，将 PbD 作为保护用户隐私的主要理念进行推荐；虽然《个保法》未明确引入“隐私设计”的概念，但该法的若干规定直接或间接体现了上述隐私设计原则的要求，相关条款及合规要点总结如下。我们建议企业积极审视自身的个人信息保护合规情况，并将隐私设计理念充分纳入到自身产品和服务的开发以及企业活动的全过程。

三、实施细则

1、产品生命周期隐私保护设计

阶段	安全设计要求
收集	从数据收集开始，就应明确所收集数据的用途、使用的业务和产品范围、保护措施等，避免收集不必要的用户数据。为了保障数据主体的知情权，以及符合法律法规的透明性要求，需要告知数据主体隐私政策。
传输	仅允许使用HTTPS协议，不能使用HTTP协议，无特殊情况，业务仅允许支持TLS1.2以上协议；若涉及到FTP协议，则需使用SFTP协议，不能使用FTP协议；重要业务操作请求需使用post方式提交。
存储	敏感信息需要加密存储，例如：口令、密钥，包括数据库、配置文件中的口令和密钥、敏感的个人隐私数据、敏感的UGC数据（用户生成内容）；使用公司统一的密钥管理系统；个人数据存储设置有效期，到期后删除或匿名化处理；做好备份管理。
使用	访问数据需要基于身份执行授权（页面权限、数据权限）、访问控制、审计留痕；对于敏感数据的展示需要脱敏展示、添加水印。
共享	遵循数据处理最小化、必要原则；数据对外披露前，应当采取严格的脱敏、去标识化等措施、披露给数据处理者之前应当先进行尽职调查及签署DPA；传输过程使用HTTPS或其他加密通道；接口在被调用时需有身份认证及权限验证功能，遵守API安全标准；对外开放的接口被调用时，需具有IP白名单功能（具体根据业务实际情况）；指定的一段时间内，同一请求域名或IP多次调用接口失败后，需锁定该商户或IP登录并以邮件或短信的形式通知商户异常；解析请求包前需校验数据的有效性；交易/对接密钥需掩码，需二次验证后才能显示。
销毁	当存储到期或用户提出删除诉求时，对用户数据进行删除或匿名化处理。

2、APP隐私保护设计

2.1 隐私保护设计原则

数据收集及使用公开透明
应用采集个人数据时，应清晰、明确地告知用户，并确保告知用户的个人信息将被如何使用。

数据收集和使用最小化
应用个人数据收集应与数据处理目的相关，且是适当、必要的。开发者应尽可能对个人数据进行匿名或化名，降低对数据主体的风险。仅可收集和处理与特定目的相关且必需的个人数据，不能进行与特定目的不相关的进一步处理。

数据处理选择和控制
对个人数据处理必须要征得用户的同意，用户对其个人数据要有充分的控制权。

数据安全
从技术上保证数据处理活动的安全性，包括个人数据的加密存储、安全传输等安全机制，系统应默认开启或采取安全保护措施。

本地化处理
应用开发的数据优先在本地进行处理，对于本地无法处理的数据上传云服务时要满足最小化的原则，不能默认选择上传云服务。

未成年人数据保护要求
如果应用是针对未成年人设计的，或者应用通过收集的用户年龄数据识别出用户是未成年人，开发者应该结合目标市场国家的相关法律，专门分析未成年人个人数据保护的问题。收集未成年人数据前需要征得监护人的同意。

2.2 隐私政策

2.2.1 什么是隐私政策

隐私政策通常是指网站、应用程序等依据隐私权政策制定的对用户信息处理的政策，是产品与用户之间关于如何处理和保护用户个人信息的基本的权利义务的文件，用以告知用户个人信息如何被搜集、使用、与第三方共享的情况。它不是仅对产品的束缚，也是提示用户自主、自愿、合理提供和处分个人信息，并区分与用户责任的依据。用户开始使用产品与/或服务前需仔细阅读，并确认已经充分理解相关隐私政策所写明的内容并且同意后才能使用产品/服务。《信息安全技术个人信息安全规范》明确了对个
人信息控制者在信息收集、保存、使用、共享、转让和披露等方面行为的规范，同时也提供了隐私政策书写模板，为APP 完善隐私保护政策提供依据。

2.2.2 隐私政策需要单独成文

《隐私政策》应单独成文，而不是作为《用户协议》或其他文件的一部分存在，保证其独立性及易读性。

2.2.3 APP首次启动需弹窗同意

APP首次进入需要以显著方式提醒用户阅读《隐私政策》，且当用户明确同意后，APP才能开始进行用户信息处理；当隐私政策更新时及时提醒各类声明的更新情况，用户同意后才可继续运行。

2.2.4 隐私政策入口及位置

进入 App 主功能界面后，通过 4 次以内的点击，能够访问到隐私政策，且隐私政策链接位置突出、无遮挡。隐私政策、APP收集个人信息列表、共享信息列表、APP使用权限列表需要放在二级菜单。

2.2.5 隐私政策文本内容规范

隐私政策内必须有声明主体信息，且声明主体应该和APP的运营者或开发者保持一致。

账户注销
APP使用账号注册登录提供产品功能或服务的，隐私政策中必须说明APP注销账号的形式和方式。注销形式可以是APP内部注销、客服电话、电子邮件、在线操作等方式。（如APP本身没有注册和注销的体系，使用其他APP账号注册的，应提供清除、解除相关关联账号的功能或注销服务）

定向推送
隐私政策中如果存在“收集用户搜索记录、浏览记录、设备信息或其他用户个人信息等用于向用户推送、展示其感兴趣的、个性化的消息内容”等提供个性化推荐的，必须在APP中有对应的关闭按钮或关闭方式。

敏感信息声明
1）隐私政策中对每个业务功能都应说明其所收集的个人信息类型，不应出现多个业务功能对应一类个人信息的情况；应当将收集个人信息的业务功能逐项列举，不应使 用“等、例如”字样

2）隐私政策易于阅读，文本文字显示方式(字号、颜色、行间距等)不会造成 阅读困难，隐私政策应对个人敏感信息类型进行显著标识(如字体加粗、 标星号、下划线、斜体、颜色等)。

3）个人信息名称请一定使用规范化的信息名称填写，不要使用简称或者其他广义范围的名称，例如设备标识符包含范围广，IMEI、IMSI、Android_ID等是属于设备标识符的范围，但是在隐私政策中必须明确写IMEI、IMSI、Android_ID，不能只写设备标识符。

第三方SDK引入
APP集成了第三方SDK的，必须在隐私政策中详细列明第三方SDK收集使用个人信息的目的、方式、范围。

用户权益保障
隐私政策中应对用户个人信息查询、更正、删除、注销、撤回已同意的授权等操作方法提供明确说明，并提供联系和申诉渠道。

2.3 个人信息收集

个人信息采集的四大原则：最小、必要、明示、同意。App内应该提供该款产品的隐私政策，隐私政策中需对个人信息收集的目的，方式，范围做准确与详尽的阐述，App需在用户主动同意后才进行权限申请与用户信息收集。

2.3.1 隐私政策弹窗

1）APP首次进入时，必须设置明显的提示方式（隐私政策弹窗）提醒用户阅读隐私政策协议内容，并在用户同意后，APP/SDK才能进行个人信息收集行为；

2）将隐私政策弹窗同意按钮可以使用：同意、愿意、允许、接受、可以，拒绝按钮可以使用：拒绝、不同意、暂不同意、暂不使用、退出、取消、仅浏览。（注：强烈建议用户点击拒绝按钮后，APP仍可以提供仅浏览功能，不要直接退出APP）。

3）注册/登录界面，默认不勾选“我已阅读隐私政策”勾选框，必须要求用户阅读隐私政策后自行勾选。

2.3.2 超范围/频率采集

隐私政策中声明采集的个人信息需和APP实际采集的完全保持一致，并且所采集的信息不超过业务功能所需的必要信息、不超出业务实际需要的收集频率。

2.3.3 禁止一揽子授权

不应以捆绑方式要求用户一次性同意打开多个系统权限，App的目标设备SDK版本（即targetSdkVersion值）应≥23，不要求用户一次性同意打开多个权限。

注4：安卓App 的目标API等级低于23（targetSdkVersion<23）属于捆绑授权的常见情形。

2.3.4 儿童信息采集

采集儿童（未满十四周岁）信息时，需要制定针对儿童的个人信息保护规则，对儿童信息的采集使用处理等 需要征得监护人的同意。 具体的要求可以参考《儿童个人信息网络保护规定》

2.3.5 生物信息采集

生物信息例如 基因信息、指纹、声纹、掌纹、耳廓、虹膜、面部识别特征等，由于生物信息具有 永久性、不可更改性，因此在采集前需先明确必要性（未成年人人脸信息不能采集），在采集时需明示告知、单独同意（需要单独的协议，如下图），且人脸信息仅用作身份识别，不可另做他用；生物信息原则上是禁止存储的，最好能在端上处理、如果要使用 可通过图片的hash来代替直接使用图片，同时在使用过程中需要做好认证鉴权和传输加密。

2.4 系统功能授权

APP可以通过获取的权限来采集用户个人信息，例如APP申请位置权限来获取用户位置信息、申请读取相册权限可以读取手机中的照片信息，对于可收集个人信息的权限 应遵循目的明确、选择同意、最小必要的基本原则，《信息安全技术 移动互联网应用程序（App）收集个人信息基本要求》（GB/T 41391—2022）的6.5.1章节分别对系统权限申请的范围、时机、申请时的行为及拒绝申请后的行为做出了具体要求：

申请的范围——不应声明或申请无关权限；
申请的时机——不应提前申请与当前业务功能无关的权限；
申请时的行为——不应一次性捆绑授权；申请时应同步告知目的，目的描述应真实、准确、易于理解；若系统支持提供单次授权；
拒绝后的行为——若申请的权限为非必要权限，用户拒绝非必要权限后不应影响用户使用该业务功能，且除用户主动触发外，48小时内不能再次申请该权限，否则为频繁索权；建议向用户提供拒绝权限后仍可实现业务目的的替代解决方案。

“可收集个人信息”的敏感权限 因手机系统不同，Android的可收集个人信息的权限范围与iOS的范围也不相同：
Android：日历、通话记录、相机、通讯录、位置、麦克风、电话、传感器、短信、存储、身体活动等；
iOS：日历、提醒事项、相机、麦克风、通讯录、健康、位置、媒体库、运动与健身、照片等。（详细可收集个人信息的权限见《信息安全技术 移动互联网应用程序（App）收集个人信息基本要求》（GB/T 41391—2022）附录D）。

2.4.1 APP启动前授权

APP启动前弹窗申请的流程概括为：APP启动->隐私政策弹窗->系统功能授权提示（APP弹窗）->系统功能弹窗（系统弹窗）

• 系统功能开启的弹窗要在隐私政策弹窗后
• APP弹窗说明使用目的，需要在系统的弹窗之前

针对安卓系统，从用户体验角度避免用户多次点击，可同时展示APP弹窗声明和系统授权弹窗，如下图1（地图类APP在用户同意隐私政策后正常使用需获取用户位置权限）；而iOS由于可自定义系统弹窗文案，因此只一次弹窗即可满足“声明”和“授权申请”，如下图2。

为避免用户开启弹出太多弹窗，可以将系统功能授权说明在一个页面统一说明（如下图1，申请设备信息、存储权限、位置信息），但是必须逐个权限授权，如下图2（设备信息和位置信息用户可分别进行授权）：

2.4.2 APP使用中授权

使用的授权是指在使用APP功能中触发某个功能引起的权限授权申请，流程通常是：启动APP某功能 -> 系统功能授权提示（APP弹窗）→系统功能弹窗（系统弹窗）；

需要注意申请的时机，应在使用到该功能时实时申请、不能提前申请未到使用时的功能；若系统支持，向用户提供单次授权，如下图“本次运行允许”（安卓系统）、“允许一次”（iOS系统）；

2.4.3 关闭/取消授权

支持已授权系统功能的关闭，需要给用户提供关闭的渠道和方法。现在安卓和IOS系统都有各自的权限管理功能，有的APP功能模块里也支持对系统权限的管理（如下图）用户可以自由选择启动和关闭；需要注意的是APP更新后，不可以自动关闭某些系统功能权限，这样违反了“私自操作用户手机，修改配置”的规定。

2.5 个人信息共享和使用

2.5.1 需要关注的个人信息

APP隐私合规中常见未：IMEI、IMSI、设备MAC地址、软件安装列表、剪切板信息、位置、联系人、通话记录、日历、短信、本机电话号码、图片、音视频等，更多可参考 《信息安全技术 个人信息安全规范》（GB/T 35273-2020）；

2.5.2 明示告知、获得同意

APP需要在隐私政策中对用户个人信息的使用和共享进行说明，包括使用的具体信息、使用目的、共享对象、使用期限（建议使用完毕后匿名化或做删除处理），并且在获得用户明示同意后才能进行使用和共享；当已收集的个人信息用于和之前申明的不同用途时，需更新隐私政策并获得用户同意，下图是和第三方SDK共享的示例图：

2.5.3 第三方供应商共享

在和第三方供应商共享个人信息时，建议对供应商做尽职调查，确保对方有一定的安全防护能力，签署数据保密协议，传输过程中使用安全协议并进行加密传输；

2.5.4 跨境传输

若是数据跨境传输，需要遵循《数据出境安全评估办法》