重拳之下，如何落实SDK个人信息保护？

SDK是「 Software Development Kit 」的缩写，即「软件开发工具包」，它是协助软件开发的相关二进制文件、文档、范例和工具的集合，简称 SDK 。
APP 开发者将 SDK 嵌入 APP 自身代码中，通过调用 SDK 提供的接口来实现相应的功能。如果 SDK 是由第三方服务商提供的，则简称为「第三方 SDK 」。
现如今 APP 接入第三方 SDK 非常普遍，主要是因为第三方 SDK 的易用性和灵活性较强，能够大幅度提升 APP 的开发效率、降低开发成本，并且提高 APP 的兼容性，扩大用户使用范围。
有数据统计，各类 APP 平均使用第三方 SDK 数量在 10 个以上，第三方 SDK 功能也逐渐多样化，应用于不同领域的大量 APP 中。
SDK 通过 APP 这一载体渗透到了用户日常生产和生活的方方面面，但在为 APP 运营开发者和用户提升效率和功能体验的同时，也成为侵犯用户隐私安全的新型重灾区。

SDK 作为独立的软件开发工具包，和 APP 一样具备收集使用个人信息的能力，但至于收集使用了哪些个人信息， APP 和用户都往往难以感知，无异于一个隐藏且缺乏透明度的「黑盒」。
因此，如果 APP 出现侵权违规情形，不一定完全是因为 APP 自身的原因，还可能是由于 APP 嵌入的第三方 SDK 所导致。
也正因如此，治理 APP 侵权的同时也要求规范 SDK 。
今年的2月18日，工信部首次将 SDK 作为与 APP 并列的项目进行通报。
第三方检测机构检查结果显示，其中 13 款第三方 SDK 存在违规收集用户设备信息的行为。
紧接着在3月17日，国家计算机病毒应急处理中心又通过互联网监测到 1 款SDK存在隐私不合规行为，表现为「隐私政策中未对个人信息处理者的基本情况进行描述」以及「未建立并公布个人信息安全投诉、举报渠道，或超过承诺处理回复时限」（ DSR 机制）两个方面。


关于第三方 SDK 违规收集用户个人信息的问题，其实早在2020年7月16日的央视 3.15 晚会就曝光过类似事件。
当时中国互联网金融协会就该现象发布了一则提示，特别分析指出 SDK 主要存在未明示告知个人信息处理规则、过度索取权限和违规收集个人信息三方面的风险隐患需引起重视。

2020年7月，中央网信办、工信部、公安部、国家市场监管总局四部门启动2020年 APP 违法违规收集使用个人信息治理工作，将对 SDK 的治理被列为年度治理重点。
2020年10月，国家标准 GB/T 35273-2020 《信息安全技术个人信息安全规范》（简称 35273 国标）明确了第三方接入者的责任。
2021年4月，《移动互联网应用程序个人信息保护管理暂行规定》对第三方服务提供者履行信息保护义务提出了要求。
2021年11月，工信部更进一步开展信息通信服务感知提升行动（简称524行动），要求被列入名单的 39 家企业建立个人信息保护双清单（已收集个人信息清单和与第三方共享个人信息清单），简洁清晰列出 APP （包括内嵌第三方软件工具开发包 SDK ）个人信息收集和共享的基本情况。

就第三方 SDK 引发的侵犯用户个人信息的问题，虽然现行法律法规并未专门针对第三方 SDK 提供者和 APP 开发运营者之间的法律责任承担进行规定，但根据《个人信息保护法》第二十条的规定，责任界定的关键在于由谁决定个人信息在处理活动中的目的和方式，当两者为共同的个人信息处理者时，第三方 SDK 提供者则需要依法承担连带责任。
但总的来说，无论是从法律规范层面，还是从目前的执法案例来看， APP 开发运营者一般难以置身事外，根本原因在于 SDK 的服务对象是 APP 而非个人用户，所以 APP 最终仍应向个人用户负责。

目前 SDK 合规监管思路已逐渐清晰，但在合规标准化制定、具体监管要求以及 SDK 收集行为规范方面，还是缺乏明文规定和统一标准，在一定程度上给 SDK 的合规治理工作带来困难和挑战，难点主要集中在以下几个方面：
1. SDK 合规标准不完善
现行立法对 SDK 的合规标准还处于不断完善的阶段，主要原因还是在于，相较于国外，我国对个人信息保护的研究起步较晚，而且用户的隐私保护意识普遍比较薄弱。
目前我国尚未出台专门针对 SDK 安全合规的强制性文件,涉及 SDK 合规的相关规定，除网络数据安全领域的「三驾马车」——《网络安全法》《数据安全法》《个人信息保护法》这些规定笼统但 SDK 必须遵守的强制性规定外，比较有代表性的还有技术文件、规范性文件、国家标准和团体标准，但均为参考性文件。
2. SDK 监管要求不统一
不同监管部门在针对 SDK 的检测上，侧重点也会有所不同。对比今年 SDK 的通报结果，可以发现，工信部对采集侧的检测关注度高，而国家计算机病毒应急处理中心更关注 SDK 收集使用个人信息规则的明示告知和用户权益保障问题。
因此，在监管要求尚未进一步细化和统一的情形下，可能会出现同一款 APP 在不同监管部门的检测下存在合规与不合规两种截然不同的结果。
3. SDK 收集行为不规范
同类型中各款 SDK 收集个人信息范围差异较大，缺乏统一标准，比如很常见的移动一键登录 SDK ，实现功能相同，但不同 APP 收集的个人信息类型可能会存在明显差异。
另一方面， SDK 的权限调用和声明行为不规范，手机操作系统并未提供单独的 SDK 权限管理机制，而是由 SDK 直接调用 APP 的已有权限，通过使用 APP 申请到的所有系统权限来收集用户个人信息。这也就增加了 APP 过度收集个人信息的风险。
可见， SDK 合规治理亟需上位法的及时补位和监管要求的细化，同时也依赖技术标准对SDK实际收集行为的统一。
SDK合规不仅仅是法律和监管层面的要求，最终还需要借助技术手段来实现。
而面对不断加大的个人信息保护监管力度，各企业（尤其是互联网企业）如何建立符合现状及发展需求的 SDK 合规治理体系，已成为一项重大议题。

那么在 SDK 合规治理过程中，企业需要重点关注哪些问题呢？这个问题可能需要辩证看待。
一方面，企业需要从法律规范层面，对照审查 APP 所接入或者对外提供的第三方 SDK 收集使用个人信息是否具有正当性依据.
另一方面，还要结合监管部门的规范性文件的制定及工作方案的部署情况，分析监管会重点检测的问题，以制定或完善 SDK 合规治理制度，并推动合规方案落地，严格落实个人信息保护工作的全链条、全覆盖。
《个人信息保护法》设立了 APP 处理个人信息的「告知+同意」原则，除第十三条第二款至第七款规定的特殊情形外， APP 处理个人信息，首先应当依据第十七条之规定，「以显著方式、清晰易懂的语言真实、准确、完整地向个人告知个人信息处理者的名称或者姓名和联系方式、个人信息的处理目的、处理方式，处理的个人信息种类、保存期限、个人行使本法规定权利的方式和程序」，且同时均应当「取得个人的同意」（第十三条）且「该同意应当由个人在充分知情的前提下自愿、明确作出」（第十四条）。
而 APP 委托处理个人信息，除应当遵循合法、正当、必要和诚信原则外（第五条），还应当与受托人约定委托处理的目的、期限、处理方式，处理的个人信息种类、保护措施以及双方的权利义务等，并对受托人的个人信息处理活动进行监督（第二十一条）。
接受委托处理个人信息的受托人，应当采取必要措施保障所处理的个人信息的安全，并协助个人信息处理者履行法定义务（第五十九条）。
因此，从 APP 开发者和第三方 SDK 提供者之间形成了授权委托关系这一角度来看，第三方 SDK 提供者收集使用个人信息的正当性依据，其实不外乎来源于两个方面：一是第三方 SDK 需依赖 APP 本身取得收集、使用个人信息的法律正当性事由；二是第三方 SDK 提供者与 APP 开发者就个人信息处理事宜所作出的有效授权。
再来看下监管部门的相关举措。2020年，工信部发布《关于开展纵深推进 APP 侵害用户权益专项整治行动的通知（工信部信管函[ 2020]164 号）》（简称 164 号文件）指出，将重点整治 APP 、 SDK 违规处理用户个人信息的问题，具体违规情形则包括：
1.违规收集个人信息；
2.超范围收集个人信息；
3.违规使用个人信息；
4.强制用户使用定向推送功能（比如广告类的 SDK ，会对收集到的用户个人信息进行分析用于精准营销，保障用户的知情权和拒绝权）。
2021年12月，工信部开展 524 行动并发布了《关于开展信息通信服务感知提升专项行动的通知（工信部信管函[ 2021]292 号）》（简称 292 号文件），要求在 APP 二级菜单中展示双清单，清晰列出 APP （包含内嵌第三方 SDK ）用户个人信息收集和共享基本情况，对 SDK 明示告知个人信息处理规则的呈现形式和放置路径提出了进一步的要求。
综上所述，企业在SDK合规治理工作中有五个重点问题需要关注：
1. 明示告知的问题
即 APP 是否明示告知第三方SDK收集个人信息的目的、方式、范围。
2. 采集时机的问题
即第三方 SDK 是否是在获得用户授权同意后才开始收集个人信息的。前两点结合起来，可以概括为「明示同意」。
3. 合理必要性的问题
即第三方 SDK 收集个人信息和申请权限是否合理必需，且范围和频次符合最小必要。简单地讲，「最小必要」是指：非必要不收集，如收集必告知，用多少收多少。
4. 安全可控的问题
即第三方 SDK 是否采取必要措施（如加密、去标识化或匿名化等）保障所处理的个人信息的安全。
5. 用户权益保障的问题
即第三方 SDK 是否建立并公布了投诉举报渠道（即设立 DSR 机制），提供了个性化关闭选项等退出机制（即自动化决策机制）。

虽然目前尚未出台专门针对 SDK 安全合规的强制性文件,但是 SDK 提供者和 APP 开发运营者可以根据参考性文件,围绕 SDK 个人信息处理规则明示告知、个人信息的采集时机和范围、存储保护、权限索取、自动化决策、 DSR 机制等重点问题开展 SDK 合规治理工作，自律自查发现合规的差距或漏洞，从而针对性提高 APP 、 SDK 个人信息保护水平。
比如， 35273 国标虽为推荐性标准，但该标准所明确的 APP 使用 SDK 的七大安全原则（公开透明、确保安全、主体参与、权责一致、目的明确、选择同意、最小必要），完全可以成为 SDK 提供者和 APP 开发者开展 SDK 合规治理工作时援引的有效依据。

根据上述七大安全原则，针对 SDK 合规治理问题，分别对 SDK 提供者的合规义务和 APP 开发者的合规义务和可以采取的措施进行了梳理，发现 APP 开发者的合规义务和 SDK 提供者有很多共性之处，比如完善协议和安全性评估。具体如下：
1. SDK 提供者的合规义务
① 完善协议： SDK 提供者宜完善与 APP 开发者的合作协议，明确收集使用的个人信息类型、使用目的、保存期限、超期处理方式等。
② 告知义务：向 APP 开发者明示 SDK 热更新机制及 SDK 的相关信息，如 SDK 提供者基本信息、沟通反映渠道等。
③ 遵循最小必要原则：收集使用个人信息应遵循合理、最小、必要原则。收集个人信息的范围和频率应是实现自身业务功能所必需的最小范围和最低频率。
④ 保障用户权益：作为个人信息共同控制者或独立控制者收集使用用户个人信息的 SDK ，单独向用户告知收集使用个人信息的行为并征得用户同意。
对功能独立的模块，应进行拆分，或提供单独的开启关闭选项，不应强制捆绑无关功能并以此为由申请无关权限或收集无关的个人信息。
⑤ 安全存储和处理：优先在本地的 APP 私有存储空间内存储和处理个人信息。在本地存储和处理个人敏感信息，对个人敏感信息内容进行加密。不留存不可变更的设备唯一标识符。
APP 停止接入 SDK 后，及时删除从该 APP 共享或收集的个人信息或做匿名化处理。
⑥ 安全性评估： SDK 提供者可以通过多种方式进行安全评估，如完整性校验、恶意代码检测等，上线后进行持续和定期的检测与评估。
2. APP 开发者的 SDK 合规义务
① 完善协议：APP 开发者需与 SDK 提供者签订协议，明确 SDK 收集的个人信息类型、申请的敏感权限、个人信息的收集目的、保存期限、超期处理方式等，明确双方在个人信息保护方面分别应采取的措施、承担的责任和义务等。当前述内容发生重大变更时，应重新达成协议。
② 明示同意： APP 开发者应向用户告知所接入的涉及个人信息收集的 SDK 的名称， SDK 收集的个人信息类型、目的和方式，申请的敏感权限、申请目的等，并征得用户同意。
③ 安全性评估：
a 来源安全性评估：如评估 SDK 提供者的基本信息、沟通反馈渠道、安全能力，评估 SDK 隐私政策链接地址，评估 SDK 的基本功能、版本号等；
b 代码安全性评估：如评估是否存在已知的恶意代码、已知的安全漏洞，是否申请敏感权限（如短信、通信录、摄像头、麦克风等），是否嵌入其他的 SDK 等；
c 行为安全性评估：如评估调用的敏感权限、目的和频率，评估收集的个人信息类型、目的和频率，评估传输数据是否加密，评估是否存在单独收集用户个人信息的界面以及收集行为是否与隐私政策中描述的一致等。

目前时代是一个强监管时代， SDK 合规既需要上位法的及时补位和监管要求的细化，也需要企业严格依法守法，承担起应有的社会责任，对用户负责。
于企业而言，要想实现 SDK 隐私合规落地,既需要技术方面的支持,也需要合规层面的支持，而非仅仅停留在过往的隐私政策、合规制度等形式审核。
从宏观角度来看， SDK 合规始终只是企业数据合规治理进程的一小步，必需通过自上而下的组织治理架构，处理和平衡好数据保护和利用之间的关系，才能确保企业隐私保护各项活动能够被有效执行和监督。
总而言之，针对 SDK 个人信息保护问题，尤其是互联网企业，都要增强对个人信息领域合规的重视，做到自律自觉、积极响应政策变化、拥抱监管，避免因个人信息侵权问题而严重影响企业形象或造成巨大经济损失。