Zoom事件：APP如何做好SDK合规？

关于Zoom被禁事件引发的

APP如何做好SDK合规的思考

文/王捷 曾晨

01

事件快速回顾：Zoom为何被禁？

全球疫情的爆发使更多会议转移到线上，远程会议服务软件Zoom的用户数量也随之大幅增加，但却因为被连续曝出存在隐私和安全问题而引起了广泛关注，根据外媒报道，马斯克的SpaceX公司，以及美国NASA，都要求禁止他们的员工使用视频会议应用Zoom，理由是存在“严重的隐私和安全问题”。伴随Zoom的股价暴跌，Zoom也紧急宣布未来90天将冻结功能更新，并承诺在此期间解决隐私安全问题，同时还发起“漏洞赏金”计划，为发现安全漏洞的人提供报酬，并与第三方一起解决问题。

那么，Zoom究竟为何被禁呢？扼要分析一下：

Zoom被禁的导火索主要有两个：

第一：Zoom客户端本身存在的安全漏洞（Zoom可能并没有做到真正的端对端加密）。

据外媒披露，不同版本的Zoom可能存在对应的安全问题。例如，对于Windows版的Zoom客户端：因容易受到NUC路径注入攻击而存在安全漏洞，从而导致用户面临隐私泄露的风险（用户的Windows 登录凭据将可能被窃取）。而对于iOS版：则因内嵌的脸书的SDK问题，无论使用Zoom的用户有没有注册Facebook账户，Zoom内嵌的这个脸书SDK都会向Facebook传递用户的手机型号、时区、所在城市、运营商以及广告唯一标识符等信息。

第二：Zoom隐私政策内容不甚明确，特别是对于第三方SDK的描述部分。

虽然Zoom的隐私政策有提及“当用户使用脸书帐号登录时，将会收集用户脸书帐号的个人资料”，但是，对于如何使用第三方SDK的内容，可能并没有比较清楚地向用户进行描述，一些没有脸书帐号的用户，也会因为这个内嵌的SDK而接受到相关的推送信息等。据媒体报道，随后，Zoom虽然发表了相关声明，但同时也在IOS客户端移除了脸书的SDK。

关于第一点，与整体的安全保护方案（开发设计、测试、发布和运维全生命周期的安全保护）相关，我们暂不讨论，而引起我们思考的是第二点，关于App中如何做好SDK合规的问题。

02

究竟SDK是个什么玩意？ 

谈所谓的合规之前，我们还是先来扒一扒啥是SDK。其实关于SDK的介绍市面上挺多的。我们也扼要概括一下。

SDK即软件开发工具包（Software Development Kit），是软件工程师用于为特定软件包、软件框架、硬件平台、作业系统等创建应用软件的开发工具集合，开发者无需了解SDK内部实现细节，只需要调用程序接口，便可以帮助App实现登陆分享、支付、广告、数据统计、地图、风控插件等一系列功能。

一般而言，SDK供应商开发出各种类型SDK后，会上传到开发者社区或者其他发布渠道，企业或个人开发者将这些SDK集成到App中后会把这些App再发布到应用商店，供最终用户从应用商店下载这些App使用。在这个链条中，SDK供应商将自身的数据和能力提供给企业和个人开发者，企业和个人开发者利用这些数据和能力使自己的产品变得更加丰富，更加多元化，同时又降低了自己的开发成本。

虽然说SDK是现在各类APP不可或缺的小伙伴，但是这里要注意啦，因为SDK自身就具备获取相当一部分设备信息和用户个人信息的能力，所以存在对应的违规收集和使用个人信息的风险。例如，在上述场景下的SDK就需要引用方采取适当的安全防护措施，保障所引用SDK的安全性。

图1 SDK的供应商路径

1. SDK都有哪些类型？

为了审视SDK相关的安全问题，根据使用形态对SDK进行分类

引入SDK: 自身应用中集成引入的第三方SDK（ZOOM）

外发SDK：将自身业务服务封装，发布出去给第三方厂商调用使用的SDK

2. SDK有哪些神通广大的功能？

SDK根据功能的不同可以分为推送、通信、存储、安全、地图及位置服务、统计及增长、社交、广告、语音识别、图像识别等种类。

例如金融行业的开放银行领域，银行业者通过将自己的业务服务和数据服务封装到一个SDK中，实现向第三方合作伙伴提供开放金融能力。

3. SDK都收集哪些信息？（通过Android提供的标准系统加入平台获取）

• 应用信息类：到用户手机上已经安装的APP信息列表和正在运行的应用列表

• 账号信息类：用户账号信息

• 网络相关信息类：用户移动设备的联网信息、用户通信的设备信息、GPS、NFC信息等

• 设备信息类：用户移动设备标识信息、SIM标识信息等

• 传感器信息类：不同型号的移动设备，集成传感器的数量与种类也有所区别，比如用户的行踪可以通过位置传感器精确追踪

03

第三方SDK的应用现状是怎么样的？ 

近日，南都个人信息保护研究中心、中国金融认证中心（CFCA）对60款常用App以及主流SDK进行了测评。发现了目前SDK使用过程中的部分问题。

问题包括：

1. APP使用SDK数量较多。每款APP携带的SDK平均不少于10款。其中消息推送类SDK最多，综合类和辅助开发类其次。

2. SDK获取的客户的部分个人信息并未在《隐私权政策》中明确告知并说明使用目的。影响了用户的知情权。

3. 收集了超出必要范围的客户信息。

图2  App中使用第三方SDK的数量分布图

（数据来源：南都智库《2019个人信息安全年度报告》）

04

第三方SDK主要存在哪些安全隐患？ 

1. 隐瞒收集个人信息的情况

前面提到过，第三方SDK和APP一样，也是具有收集用户个人信息的能力的，但究竟这个小玩意（SDK）究竟收集了哪些个人信息，从用户的层面来看其实是很难有感觉的，甚至APP的运营者或开发者也未必全都知道（细思极恐~）。一旦这个第三方SDK在没有经过用户同意的情况下，就收集了各类与用户密切相关的敏感信息，例如银行账号，生物特征信息等，并传输到其他服务器甚至境外，将会引发极大的个人数据隐私风险。

2. 程序自身存在安全漏洞

目前，已经发现的SDK安全漏洞包括HTTP误用，SSL/TLS不正确配置、敏感权限滥用、通过日志造成信息泄露等。如果一个APP嵌入的第三方SDK越多，它的安全漏洞可能就越明显，影响范围也就越大了。

3. 恶意SDK导致软件供应链污染

比如说，“引入SDK”的主要安全风险来自SDK自身的恶意行为。由于Android操作系统带有热更新机制，这使得一部分恶意SDK在客户集成阶段会表现为一个非常正常的应用，而一旦应用发布后到了运行阶段，攻击者就会通过热更新机制，更新恶意代码，执行盗取用户数据、采集敏感信息等恶意行为。这种发布后作恶的行为在很大程度上绕过了发布前的静态检测，具有非常大的迷惑性，也使得其作恶行为更加难以被发现。

而“外发SDK”的风险则主要存在于在发布后的运行阶段，极容易遭遇剥离、破解、注入、调试和渗透测试等运行时攻击行为。

05

对于APP开发者使用SDK的合规思路扼要分析 

合规总思路：

• 首先分析嵌入的是哪种类型的SDK

• 根据不同SDK的具体特性，区分第三方SDK的角色

• 根据SDK角色的不同，进一步分析第三方SDK需要承担的责任

合规分析流程图：

1. 第三方SDK是否有收集个人信息行为？

• 如有，则需进一步分析该第三方SDK是自动收集的，还是通过其所依附的宿主APP收集的。

• 如否，属于功能性SDK。

2. 第三方SDK收集个人信息的行为是通过其所依附的App主动获取的，还是该第三方SDK自行收集的？

• 如果是通过APP主动获取的，并将收集到的个人信息共享给第三方SDK，属于间接收集类SDK。

        此时，该APP需要在隐私政策向用户告知第三方SDK的名称、收集个人信息的目的、方式和范围等；

• 如果是该第三方SDK自行收集的，则需要进一步分析该第三方SDK是否与宿主APP为共同控制者。

3. 第三方SDK自行收集个人信息时，如果宿主APP关闭相应收集权限，该第三方SDK是否还能继续收集个人信息？

• 如是，属于直接收集类SDK。

• 如否，则具体要看第三方SDK与宿主APP的具体协议约定，判断是否为共同控制者。

图3  第三方SDK合规分析流程图

06

对于APP开发者使用SDK的合规有哪些合规建议？ 

1. 对于间接收集类SDK

一些常见的情况是，第三方SDK只是作为受宿主APP委托处理数据的数据处理者时，由于用户难以感知这些SDK对个人信息的收集情况，且第三方SDK也不会用自己的名义收集个人信息，这时，APP运营者/开发者就特别需要注意，把如何向第三方SDK分享个人信息的情况告知用户，并获得用户的有效同意了，例如通过弹窗告知、增加链接等不同方式。同时，根据最新出的网络安全标准实践指南 —移动互联网应用程序（App）个人信息安 全防范指引（征求意见稿）的规定，也要求了需要对嵌入的收集用户个人信息的第三方 SDK 进行披露，告知第三方 SDK 类型，及收集使用的个人信息的目的、方式和范围。特别在涉及敏感信息时，还需要告知接收方的身份和数据安全能力，并征得明示同意，当用户撤回同意后，还需要帮助用户删除在第三方SDK的相关数据。

2. 对于直接收集类SDK

当这些嵌入到APP中的第三方SDK直接收集个人信息，并用自己的名义向用户提供服务时，由于第三方SDK露出对应品牌，用户其实对于这类的SDK是有明显的感知的，此时的第三方SDK较大程度成为个人信息控制者，在收集用户个人信息时候，需要向用户告知并获得用户的同意。

这里也要特别注意的是，当第三方SDK也可能与APP开发者进行信息共享的时候，建议采取三重授权原则，即用户授权+平台授权+用户授权，以便解决合法授权的问题。

3. 对风险等级进行评估

建议APP运营者/开发者对第三方SDK进行安全评估和风险等级评估，包括对代码进行审计和对漏洞进行检测，进而评估该SDK来源的可靠性、代码的安全质量以及对应的潜在安全风险。比如说，可以对SDK所收集的个人信息的字段等具体应用场景进行安全评估，遵循最小化权限使用原则等。举一些例子如下：

（1）采集用户移动设备上已经安装的应用信息、安装列表。

通过采集手机APP安装的应用程序列表，从而了解用户的生活习惯、爱好等，实际上侵犯了用户的隐私。

风险级别：极高

（2）采集移动设备正在运行或最近运行的程序任务信息。

通过采集用户手机设备的应用情况，包括启动次数、时长等信息进行记录分析，同样数据侵犯用户隐私。

风险级别：高

（3）采集用户移动设备账户信息。

账户信息也同样具备敏感性，尤其是当账户信息与设备信息进行关联，必然导致客户的账户安全受到不同程度的影响，甚至导致用户的利益损失。

风险等级：极高

但现实中，确实也存在比较难地通过技术检测逐一去核实SDK的合规性和安全性，此时，仍然建议可以通过与SDK供应商签订合同或承诺保证函等方式，约定SDK供应商的权利和义务。

总体来说，从数据合规及安全的角度，客户的个人信息并非不能收集，而是要遵循合法、正当、必要的原则，在获取用户信息前征得用户同意。另外在获取用户个人信息后，应当按照相应的标准进行存储和管理，避免用户因此遭到信息的泄露。一旦APP接入的SDK存在问题，则第一责任主体为APP运营主体。例如，通过制作、发布、吸引 App 嵌入含有恶意代码的第三方 SDK，那么用户首先可追究APP运营者的责任，APP运营者和SDK提供者对用户损失承担连带赔偿责任。当然，也有连带责任的例外，当第三方SDK与用户单独授权获取用户信息，在用户与SDK提供者之前因客户信息授权、使用的责任由用户与SDK使用者之前自行处理。

07

在监管上有哪些对策建议吗？ 

对于SDK的监管，比较可能成为接下来的监管热点，从目前公开的一些资料来看，在监管上的对策建议概括总结如下：

1. 制定SDK安全评估标准

目前尚无明确的SDK安全评估标准规范可以评估和识别SDK厂商是否符合安全标准，这就势必导致部分不合规的SDK厂商由此钻漏洞，“私携”客户信息、或留“后门”等。监管部门应尽快制定安全评估标准，引导APP运用者识别不良SDK厂商，避免用户信息泄露或造成用户风险损失。

2. 引入第三方SDK独立监管体制

目前监管部门把重点放在App上，想通过App对SDK进行管理和监督。但实际头部SDK比App更强势，很多APP运营者无技术能力和监控手段对SDK进行监督和管理。因此由监管部门直接管理或许更有利于行业的健康发展。特别需要注意的是，SDK独立监管并不意味着APP运营者无责任，同样应当对接入的SDK进行评估和管理，当因APP运营者疏忽或者故意引入不当SDK造成客户损失的情况下，仍应按照《民法》等相关法律承担相应的赔偿责任。

参考资料：

1. 安全内参：关注App嵌入第三方SDK收集使用个人信息的安全隐患

2. 《SDK安全与合规白皮书》

【声明】本文内容可能会因法律法规修改而变更，司法实践中依个案实际情况来处理。本文仅代表作者目前所持的理论观点，不代表作者供职机构或其他相关机构的意见。本文仅为交流之用，所有内容不构成对任何个案的意见、建议或观点。作者和发布平台明示不对任何根据本文任何内容的作为或不作为所导致的后果承担责任。

作者简介

王捷，浙江垦丁律师事务所，海外业务负责人，资深出海法律顾问（广州），曾任职阿里巴巴大文娱集团，深耕海内外多条业务线，八年多的科技型公司实务经验与中外律所从业背景，能更准确理解客户核心需求，快速响应并提供基础到战略的有效支持，并为各类出海互联网企业拓展印度、东南亚、中东、非洲、欧美等新兴及重要市场提供有效的合规解决方案与落地支持。
联系方式：13650790754添加微信，请备注来意，如“业务合作”，“学术交流”等等，感谢！
曾   晨，西安交通大学 信息安全法律研究中心 网络安全与个人信息安全方向

更多出海互联网实务交流信息，欢迎扫码入群

---

#更多往期出海业务精彩文章#

转发，是对作者最大的鼓励

在看，是对作者最大的认可

创作不易，请点击一下“在看”↓