IT/AV终端检测认证事业部

打开一个 APP，第一眼看到的往往是登录界面。

输入手机号，获取验证码，勾选已阅读并同意隐私政策，点登录。整个过程不到 30 秒。

但就在这 30 秒里，你的 APP 可能已经踩了好几个 GDPR 的坑：

· 隐私政策链接藏在角落，字小到看不清

· 同意框默认勾选，用户不注意就被同意了

· 用第三方账号登录，却没告诉用户会共享什么数据

· 收集了手机号、设备 ID、位置信息，却没说为什么要收、存多久

· 密码明文传输，或者存在了不安全的地方

这些问题，在欧盟市场都是实打实的违规。轻则被客户要求修正，重则被数据保护机构罚款。

这篇文章不讲宏观体系，只聚焦一个点：APP 登录界面的隐私合规，到底该怎么设计、隐私政策该怎么写。看完你能直接照着改。

01 先搞清楚：登录界面到底在收集什么数据？

很多人以为登录界面只收集了一个手机号和密码。实际上，一个典型的 APP 登录界面，在用户点登录的那一刻，至少在处理以下几类数据：

注意一个关键点：设备信息和行为数据往往是 SDK 自动采集的，不需要用户输入，但 GDPR 认为这些也是个人数据，同样需要告知和合法基础。

很多制造商的 APP 用了第三方统计 SDK、推送 SDK、广告 SDK，这些 SDK 在登录时就开始采集设备 ID、IP 地址、行为数据，但隐私政策里根本没提。这是常见的违规点之一。

02 GDPR对登录界面的 4 条核心要求

搞清楚收集了什么数据之后，再来看看 GDPR 对登录界面有哪些具体要求。不需要翻 99 条法条，记住下面 4 条就够了。

要求一：收集数据前必须告知（第 13、14 条）

GDPR 第 13 条规定，从数据主体那里直接收集个人数据时，必须在收集时告知以下信息：

· 控制者的身份和联系方式（你是谁、怎么联系你）

· 数据保护官的联系方式（如果指定了 DPO）

· 处理的目的和合法基础

· 个人数据的类别

· 数据的接收方或接收方类别

· 数据是否会传输到第三国，以及采取了什么保障措施

· 数据的保存期限

· 数据主体的权利（访问、更正、删除、限制处理、可携、反对）

· 撤回同意的权利（如果基于同意）

· 向监管机构投诉的权利

· 提供数据是否是法律或合同要求，以及不提供的后果

· 是否存在自动化决策（包括画像）

注意关键词：在收集时告知。也就是说，用户在输入手机号、点登录之前，就应该能看到这些信息。不能等用户注册完了、登录进去了，才在设置里藏一个隐私政策链接。

要求二：同意必须是自由、具体、知情、明确的（第 7 条）

如果登录界面的数据处理基于同意（consent），那么这个同意必须满足 4 个条件：

· 自由给出（freely given）：不能把同意跟服务使用捆绑，不能说不同意就不能用 APP（除非数据是提供服务所必需的）

· 具体的（specific）：不能用一个大而全的同意框覆盖所有目的，不同目的要分开同意

· 知情的（informed）：用户必须知道自己同意了什么，不能用晦涩的法律术语糊弄

· 明确的（unambiguous）：必须有明确的肯定动作，不能默认勾选，不能用预勾选框，不能用沉默或不活动作为同意

这一条直接决定了登录界面的设计：同意框必须默认不勾选，用户必须主动点一下才算同意。而且，用户应该可以只同意必要的，不同意非必要的（比如个性化广告、数据统计），不能搞捆绑同意。

要求三：数据最小化（第 5 条）

GDPR 第 5 条规定，个人数据必须是充分的、相关的，并且限于实现处理目的所必要的范围。

翻译成大白话：登录需要什么就收什么，不需要的别收。

比如，用户登录只需要手机号和验证码，你就没必要在登录时就要求用户提供姓名、性别、生日、地址。这些可以等用户登录后，在使用相关功能时再收集。

再比如，设备信息里，IMEI 属于敏感的设备标识符，如果只是为了统计活跃用户，用更温和的标识符（比如 app 内生成的随机 ID）就够了，没必要采集 IMEI。

要求四：安全措施（第 32 条）

登录界面处理的是账号和密码，是安全风险较高的环节。GDPR 第 32 条要求采取适当的技术和组织措施，包括：

· 密码必须加密存储（用 bcrypt、Argon2 等慢哈希算法，不能明文存，不能用 MD5/SHA1）

· 传输必须加密（HTTPS/TLS）

· 验证码要有过期时间和尝试次数限制（防暴力破解）

· 登录失败要有日志和告警

· 多因素认证（MFA）作为可选增强

这些虽然不是隐私政策文本的内容，但属于登录界面合规的一部分，因为如果数据泄露了，隐私政策写得再好也没用。

03 逐元素拆解：登录界面的隐私政策到底怎么写？

前面讲了要求，这一节落到实处。一个合规的登录界面，至少包含以下几个元素，我们一个一个说。

元素一：隐私政策入口——要显眼、要可点、要在收集前

这是基本的要求，但也是容易做错的。

错误做法：

· 隐私政策链接放在登录按钮下面，字号 10px，颜色跟背景差不多

· 链接文字写的是 详情，用户不知道点进去是什么

· 用户点登录之后才弹出隐私政策

· 隐私政策是一张图片，不能复制、不能放大

正确做法：

· 隐私政策链接放在登录按钮附近，字号不小于正文，颜色有对比度

· 链接文字明确写 隐私政策 或 Privacy Policy

· 链接在用户输入任何数据之前就可见、可点击

· 点击后在 APP 内打开网页或原生页面，不要跳外部浏览器（体验差），也不要用图片（不可访问）

· 提供英文版本（如果面向欧盟用户，至少要有英文，建议提供用户所在国语言）

元素二：同意框——默认不勾选、主动勾选、可分开

同意框是 GDPR 执法中常被挑毛病的地方。

错误做法：

· 同意框默认勾选

· 用 登录即表示同意 这种话术，把登录动作等同于同意

· 一个同意框同时覆盖隐私政策、用户协议、第三方数据共享、个性化广告

· 不同意就不能用 APP，即使非必要数据处理

正确做法：

· 同意框默认不勾选，用户必须主动点击

· 同意框旁边的文字写清楚：我已阅读并同意隐私政策，不要用 登录即同意 这种模糊表述

· 必要数据处理（账号登录本身）和非必要数据处理（个性化推荐、广告、统计分析）要分开同意。用户可以只同意必要的，不同意非必要的，仍然能使用基本功能

· 非必要处理的同意框也要默认不勾选

· 提供 仅必要模式 或 拒绝非必要 的快捷选项

这里有一个常见的困惑：登录本身需要手机号和验证码，这个需要用户同意吗？

答案是：不一定需要同意。因为登录是履行合同所必需的（用户要使用 APP 就必须登录），合法基础可以用 合同履行（第 6(1)(b) 条），而不是同意。但你仍然需要告知用户你在收集什么、为什么收集。

但是，如果登录时还收集了非必要的数据（比如设备 ID 用于广告追踪、位置信息用于个性化推荐），这些非必要的处理就需要单独的同意。

元素三：隐私政策摘要——别让用户读 5000 字才知道你在干嘛

GDPR 不要求你把所有信息都塞在登录界面，但要求用户在收集前能获得关键信息。稳妥做法是在登录界面放一个简明摘要，然后链接到完整隐私政策。

摘要应该包含：

· 我们收集什么数据（列 3 到 5 类主要的）

· 我们为什么收集（对应每个目的）

· 数据会传给谁（第三方 SDK、云服务商等）

· 数据存多久（比如 账号注销后 30 天删除）

· 用户有什么权利（查、改、删、导出）

· 怎么联系我们（邮箱或表单）

摘要控制在 200 字以内，用大白话，不要用法律术语。下面是一个示例：

摘要示例：

为了帮你登录和使用本 APP，我们会收集你的手机号或邮箱、设备信息（型号、系统版本）和登录日志。这些数据用于账号验证、安全防护和服务改进。我们会使用推送和统计 SDK，它们会收集设备标识符。你的数据存储在欧盟服务器，保留至账号注销后 30 天。你可以随时访问、更正或删除你的数据，联系邮箱 privacy@yourcompany.com。点击 隐私政策 查看完整信息。

这个摘要放在同意框上方或旁边，用户一眼就能看到关键信息，然后可以选择点进去看完整版。

元素四：完整隐私政策——登录相关部分怎么写

完整隐私政策不需要在登录界面展示，但登录界面链接到的隐私政策，必须包含登录相关的处理活动。具体要写清楚：

（1）控制者信息

公司名称、注册地址、联系邮箱。如果有欧盟代表（GDPR 第 27 条，非欧盟企业通常需要指定），也要写明代表的联系方式。

（2）我们收集什么数据

按数据类别列清楚，不要笼统地说 我们可能收集各种信息。要具体到：手机号、邮箱、密码（加密存储）、设备型号、操作系统版本、IP 地址、登录时间、登录失败记录、第三方登录返回的 OpenID 和昵称。

（3）我们为什么收集（目的和合法基础）

每个目的对应一个合法基础。比如：

· 账号创建和登录：合法基础是合同履行

· 安全防护和反欺诈：合法基础是合法利益

· 个性化推荐：合法基础是同意（可撤回）

· 统计分析：合法基础是同意（可撤回）或合法利益（取决于是否匿名化）

（4）数据共享

列出所有会收到数据的第三方：云服务商（AWS/阿里云欧洲节点）、推送 SDK（Firebase Cloud Messaging）、统计 SDK（Google Analytics 或类似）、第三方登录服务（Google Sign-In、Facebook Login）。写明每个第三方处理什么数据、为什么、第三方的隐私政策链接。

（5）数据存储地点和期限

数据存在哪里（欧盟/中国/美国），如果存在欧盟以外，说明传输机制（SCC、充分性认定等）。每类数据存多久，或者确定保存期限的标准。

（6）用户权利

列出访问权、更正权、删除权、限制处理权、可携权、反对权、撤回同意权。说明怎么行使这些权利（邮箱、表单），以及响应时限（1 个月）。

（7）投诉权利

告诉用户可以向当地数据保护机构投诉，提供欧盟数据保护机构列表的链接。

04 第三方登录的特殊合规问题

很多 APP 在登录界面提供了微信、Google、Facebook、Apple 等第三方登录选项。这个功能很方便，但合规复杂度也更高。

第三方登录时发生了什么

用户点 Google 登录，跳转到 Google 授权页面，用户同意后，Google 把用户的 OpenID、昵称、头像、邮箱等信息返回给你的 APP。这个过程中：

· 你的 APP 从 Google 那里收到了用户的个人数据

· Google 知道用户在使用你的 APP

· 如果你的 APP 还请求了额外权限（比如通讯录、日历），那数据共享范围更大

第三方登录的合规要点

（1）单独告知和同意

用户点第三方登录按钮之前，你需要告诉用户：使用第三方登录会向第三方发送什么信息、会从第三方获取什么信息。不能用户点了 Google 按钮才弹出来说明。

稳妥做法是在第三方登录按钮下方加一行小字：使用 Google 登录，我们将获取你的公开资料（昵称、头像、邮箱），用于创建账号。

（2）数据最小化

只申请你需要的权限。如果只需要 OpenID 来识别用户，就不要申请邮箱、通讯录、位置等额外权限。Google 和 Facebook 都支持只请求基本资料。

（3）第三方 SDK 的数据处理

第三方登录 SDK 本身可能会采集设备信息、行为数据。你需要：

· 在隐私政策中列出使用了哪些第三方 SDK

· 说明每个 SDK 收集什么数据、用于什么目的

· 跟第三方签数据处理协议（DPA），保障第三方也符合 GDPR

· 评估第三方的数据出境情况（比如 Google 的数据可能传到美国）

（4）账号合并和删除

如果用户同时用手机号和第三方登录，你需要能把两个账号关联或合并。用户要求删除账号时，要能同时删除所有关联的第三方登录信息，并通知第三方删除（如果适用）。

05 常见错误写法 vs 正确写法对照

下面是登录界面中常见的错误，以及对应的正确写法。可以直接对照检查你的 APP。

06 一份可直接套用的登录界面合规清单

最后，给你一份可以直接打印出来对照检查的清单。每一项都做到了，登录界面的隐私合规基本就过关了。

界面设计：

· 隐私政策链接在用户输入数据前可见、可点击

· 链接文字明确为 隐私政策 或 Privacy Policy

· 同意框默认不勾选

· 必要处理和非必要处理分开同意

· 提供 仅必要 或 拒绝非必要 的快捷选项

· 第三方登录按钮下方有数据共享说明

· 有简明隐私摘要（200 字以内）

隐私政策内容：

· 控制者名称、地址、联系方式

· 欧盟代表联系方式（如适用）

· 具体列出收集的数据类别

· 每个处理目的对应合法基础

· 列出所有第三方 SDK 和数据接收方

· 数据存储地点和出境机制

· 每类数据的保存期限

· 用户权利及行使方式

· 撤回同意的方式

· 投诉渠道

技术安全：

· 密码用 bcrypt 或 Argon2 加盐哈希存储

· 传输全程 HTTPS/TLS 加密

· 验证码有过期时间（通常 5 到 10 分钟）和尝试次数限制

· 登录失败有日志记录和告警

· 多因素认证作为可选增强

· 会话有超时自动退出机制

流程管理：

· 有数据主体权利响应流程，1 个月内响应

· 有数据泄露响应计划，72 小时内通知监管机构

· 第三方 SDK 有清单和 DPA

· 员工有数据保护培训

· 隐私政策定期复审（至少每年一次）

07 写在最后

登录界面是用户接触你的 APP 的第一个页面，也是隐私合规的第一道关口。

很多团队觉得登录界面就是一个手机号输入框加一个登录按钮，没什么好设计的。但实际上，就在这个小小的界面上，集中了 GDPR 核心的几个要求：告知、同意、数据最小化、安全。

做好登录界面的隐私合规，不需要花很多钱，也不需要复杂的技术。核心就是三件事：

第一，告诉用户你在收集什么、为什么收集。不要藏着掖着，用大白话说清楚。

第二，让用户主动选择，而不是被动同意。默认不勾选，必要和非必要分开，给用户拒绝的权利。

第三，只收集你需要的，保护好你收集的。数据最小化，加密存储，安全传输。

这三件事做到了，你的登录界面就已经超过了市面上 80% 的 APP。

而且，登录界面的合规不是一次性的。APP 每次更新、每次新增 SDK、每次修改登录流程，都要重新检查隐私政策和同意机制是否还匹配。合规是一个持续的过程，不是一劳永逸的项目。

最后一句话：隐私合规不是给监管看的，是给用户看的。一个设计清晰、告知明确、尊重用户选择的登录界面，本身就是有力的品牌信任背书。

广测电磁：全球数字安全合规服务伙伴

别让合规只停留在“拿证”。

面对欧盟 CRA网络弹性法案、AI法案及 GDPR/CCPA/数据法案等严苛监管，凭借CNAS(L18872)+A2LA(6947.01)双资质及前360/深信服核心网络安全专家团队，为您提供“贴合实战”防护。

为什么GTG能为您降本避险？

拒绝模板：不只给报告，我们提供定制化漏洞修复方案，协助提升产品安全性。

高效省心：代写核心文档，免除繁琐填表，让合规更高效。

多领域覆盖：从消费电子到汽车、工控、医疗，一体化解决全球隐私与数据安全难题。

您的全球合规通行证，从这里开始。