背景

App超范围收集个人信息、未经同意收集个人信息、用户不知情情况下向第三方提供个人信息等情况，除了App自身的问题，其嵌入的第三方SDK也是引发问题的原因之一。

SDK收集个人信息，其最大的优势在于其具有使用各类“标识符”关联不同设备的能力，以及因广泛安装所具备的“保活”的能力，而之所以用户逃不出“大数据的追踪”，其中跟SDK无时无刻不在拼凑着我们的“信息碎片”有着一定的关系。

数据不断地被企业累积，在帮助用户获取服务、提升体验的同时，数据“商业变现”过程中的滥用行为、数据安全措施不足的泄露现象也开始显现。在往年3.15晚会上，就曝光了App嵌入的第三方开发的SDK包存在违规收集用户个人信息的情况，包括过度收集用户手机通讯录、短信信息、传感器信息等涉及隐私的个人信息，并发送到了第三方服务器，甚至还有收集上传短信验证码等的行为，无异于App引入了一个可能窃取用户账户的“木马”软件。

现象分析

通过近年来的App收集使用个人信息违法违规专项治理、相关SDK安全标准的制定推广等工作，第三方SDK收集使用个人信息的情况已经逐步透明化，很多SDK都撰写了隐私政策，App也对嵌入第三方SDK的名称、目的、收集个人信息类型进行了说明，“透明化”这第一步已经迈出，意味着整个SDK生态的最大特性“隐蔽化”开始转变。

但是，由于对第三方SDK安全的研究起步较晚，争议点较多，当下仍有不少问题需要解决。笔者通过对100款App嵌入第三方SDK的情况进行了研究，就目前第三方SDK的现状归纳为以下三种现象，供探讨：

现象一：实现同类功能的第三方SDK为什么要嵌入多个？

笔者统计了100款App中实际嵌入的第三方SDK数量（见上图），平均每款App嵌入的SDK个数是13.36，嵌入第三方SDK的有97款App，向第三方传输个人信息的有33款App，平均每款App嵌入的个数是19个。其中在100款App中有8款App嵌入了30以上的第三方SDK，嵌入第三方SDK最多是86个。从收集个人信息最小化的原则来考量，嵌入第三方SDK的最少化也是一种遵守原则的体现，但是事实上发现，一款App嵌入多个具有同样或类似功能的第三方SDK，那么，到底是业务所需，还是有其他目的呢？

以某银行类App为例，为实现音视频通话功能嵌入了菊风音视频SDK和声网音视频SDK（见下图）。‍‍那么，到底第三方SDK的功能对应的是App‍的哪个功能，其实并未说清楚，如果是两个第三方SDK，那么对应的功能也是两个吗？‍‍用户未必同时使用了这两个第三方SDK所对应的功能，那么用户未使用时，SDK是否会收集个人信息也无法得知。

现象二：实现同一功能的SDK在同一个App为什么所需的个人信息类型不同？

笔者发现，常用的第三方SDK中，即便是实现同一功能，收集的个人信息类型也不一样，甚至差别不小。以推送类SDK来看，在某银行类APP中，嵌入了华为推送SDK、小米推送SDK、魅族推送SDK、vivo推送SDK、OPPO推送SDK，其中，根据隐私政策所述，华为推送SDK、小米推送SDK、魅族推送SDK在实现推送功能时不同程度的收集了设备标识信息、App列表信息、MAC地址等信息，但种类也有所不同，而vivo推送SDK和OPPO推送SDK则不收集个人信息（如下图）。

都是推送类SDK，实现的功能基本一样，只是运营者不同，为什么收集个人信息的范围差距如此之多？第三方SDK收集个人信息是否满足了必要性的要求自然成为一个疑问。

‍‍‍‍‍‍‍‍‍现象三：为什么同一第三方SDK在不同App中收集的个人信息类型不同？‍‍‍‍‍‍‍‍‍

发现，某运营商SDK主要功能是识别用户的手机快速登录，某网上购物类App和某地图导航类APP都嵌了该SDK，某地图导航类App隐私政策中声明运营商SDK会收集当前手机号的掩码、设备标识符、运营商信息、网络信息等个人信息，而某网上购物类App隐私政策中声明运营商SDK只收集当前手机号的掩码（如下图）。

如上图所示，通过某网上购物类App的隐私政策和某地图导航类App的隐私政策中提供的第三方SDK的隐私权政策链接，打开后都是一样的《认证服务协议》，该协议中声明在使用一键登录业务时，需要使用网络类型、网络地址、运营商类型、本机号码等个人信息。对于同一个SDK，两家App运营者、SDK提供方所声明收集的个人信息类型存在差异，是因为App运营者单独定制了SDK？还仅是文本层面存在不一致？或者是确实收集的信息类型有所不同？最终结论还需要通过技术手段来进一步验证。不管如何，同一第三方SDK如果存在收集信息类型不一样的情况，对于是否满足最小必要的要求来说是一个需要关注的问题。

思考与建议

上述三种现象，其实暴露了第三方SDK在个人信息保护的实践方面还存在一些需要深入探索的问题。近年来，App收集使用个人信息的规则日益清晰，《个人信息保护法》中提出了履行个人信息保护职责的部门需对App进行测评，App中嵌入第三方SDK的测评也应当包含在内，才能构建更加有效、长效的监督机制。就此，笔者有以下思考和建议供参考：

一是，以现有标准规范、技术文件为参考，为SDK定制一份“体检单”，方便第三方SDK运营者加强对SDK功能开发、收集个人信息范围、隐私政策制定方面的自查和改进，以及检测机构对SDK开展的深度测评工作。可参考的有GB/T 35273—2020《信息安全技术 个人信息安全规范》、TC260-PG-20205A 《移动互联网应用程序（App）使用软件开发工具包（SDK）安全指引》等，查阅下载渠道见文章标准应用|支撑“个保法”“数安法”落地，相关国标梳理（附查阅通道）。

二是，抓紧推进《移动互联网应用程序（App）SDK安全指南》国家标准的制定、试点等工作，进一步提出对SDK安全方面的统一要求，推动提升第三方SDK运营者整体合规“水位线”。

三是基于《个人信息保护法》最新要求，针对SDK隐私政策的内容、发布方式，基本功能和必要信息范围，SDK角色的认定、责任的划分，向用户提供权利实现的方式等难点问题的研究要提上“日程表”，否则将可能让SDK的产业发展和合规工作开展陷入“被动”状态。

（本文作者：中国电子技术标准化研究院网络安全研究中心 刘昊鑫 何延哲）

声明：本文来自CCIA数据安全工作委员会，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。