专题研讨 | 如何理解和规范App接入的第三方服务处理个人信息的情形？

2、研讨问题

研讨问题1：App与不同类型的 SDK 之间在《个人信息保护法》中的角色如何界定？是 “委托处理”、“各自独立的处理者”or“共同处理者”？

精彩观点如下：

☆  关于SDK受托处理的模式：SDK收集个人信息时无法独立决定对App用户数据处理的目的、方式，需遵照与App运营者的约定处理个人信息，属于App运营者委托SDK提供者处理的情形。此时，App运营者是个人信息处理者、SDK服务商是受托处理者，告知同意的职责由App运营者承担。

☆  App运营者委托SDK提供者定制（包括基于免费版本定制）开发SDK的，同样需要满足以上情形，才构成“委托处理”关系。

☆  关于“各自独立的处理者”模式。由于App运营者无法与对SDK处理个人信息的行为进行充分的定制、限制，SDK对其从App所获取的个人信息自行决定了处理目的、方式，因此App运营者与SDK提供者通常属于“各自独立的处理者”。但即使如此，在对App用户履行告知同意的义务时，App运营者仍需要从接入方角度披露SDK处理个人信息的规则。

☆  例如，App在完成支付业务功能时，需要向嵌入App中的支付SDK发送相关的支付订单信息，支付SDK服务商独立以自己的名义露出、向用户提供支付服务，该过程可视为App向“向其他个人信息处理者提供其处理的个人信息”。

☆  关于“共同处理者”模式。如果App与SDK共同决定个人信息的处理目的、方式（也就是说同一个处理目的，必须两个角色共同参与），那么可能构成“共同处理者”，且都应该对用户以“处理者”的名义来明示告知。

☆  以广告SDK为例，如果广告SDK无法独立完成投放广告的过程，需要App运营者参与对个人信息的处理并与广告SDK共同决定处理的目的和方式，且双方约定了各自的权利和义务，并对用户在广告服务的相关界面同时披露两个责任主体，则有可能构成“共同处理者”。

☆  App与SDK的角色关系比较复杂，即使无法准确判断SDK的法律角色定位，则从用户视角出发，App拥有与用户进行交互的界面和便利条件，还是宜承担更多的告知同意方面的职责；同时，就SDK提供者而言，如其涉及处理App用户个人信息的，也建议主动进行告知（无论是何种法律角色）、公开披露详细的SDK个人信息处理规则。

研讨问题2：如何理解开源SDK、免费SDK、自用SDK等不同形态和性质的SDK？合规的注意点有哪些？精彩观点如下：

☆  关于开源SDK。如SDK与App不存在数据传输、交互等处理活动的，则无需判断SDK服务商的法律角色定位，但如处理了加密数据的，仍需判断其法律角色定位。

☆  因此，从开源代码库中获取的软件包，如果没有数据传输和交互，可以不视为SDK、不用履行告知同意的义务。如果软件包存在数据传输和交互，尤其是包括了个人信息（如常用设备唯一标识符），即使不将其视为SDK，也需要履行告知同意的义务。

☆  开源SDK、免费SDK可以被任意下载使用，App如需接入的，除了审查其安全性，还要关注其数据处理（如有）的合规性。

☆  关于自研SDK。通常说的SDK是指第三方SDK，但一些集团或大公司可能为提升开发者效率、促进业务交互，会在公司内部推广“基建类”组件（常称为“自研/自用SDK”），SDK代码甚至可完全开放共享。此类自研SDK即可视为App自身的一部分，由App在面向用户告知内容里涵盖自研SDK处理个人信息的规则，即App来履行告知同意等义务。

研讨问题3：检测App接入的SDK时，如何根据SDK的行为界定其法律角色，从而判定其是否履行必要的个人信息保护义务？披露SDK的个人信息处理规则的粗粒度有何建议？精彩观点如下：

☆  检测过程中，不宜仅根据SDK处理数据的行为来判断SDK在法律中的角色定位，但可以作为推导和生成技术检测报告的参考。对SDK法律角色的认定，还需要综合判断对方因素判断，例如具体的业务场景、各方隐私政策的告知内容、双方之间协议以及用户视角的感知。

☆  检测过程中，不宜仅根据SDK包名来认定其是第三方SDK，并进而认为App在向第三方提供数据。建议公司自研SDK取名时尽量使用与公司名称（简称）、主要产品名称相类似的名称、避免被误读为第三方SDK。

☆  检测过程中，如从包名推测可能接入了某款SDK，还需要确认App隐私政策中是否披露了该SDK（名称应一致）。如果发现隐私政策并未披露该款SDK时，则需要进一步判断该SDK是否在App中被激活使用、实际获取数据，从而识别出一款未主动披露的SDK。如果数据加密、无法确认SDK是否上传个人信息的，也可对App运营者提出质疑。

☆  对SDK检测时，可对其实际收集信息与隐私政策进行一致性判断：一是SDK实际收集的字段是否与其隐私政策中披露的字段一致；二是App隐私政策中披露该SDK收集的数据字段是否与SDK隐私政策中披露的字段一致。

☆  如检测出SDK实际收集的字段≤其隐私政策中披露的字段，则可以认为符合一致性，反之则不符合一致性。在进行“最小必要”方面评估时，建议依据SDK隐私政策披露的字段进行判断（因可能存在检测时段、检测方法等导致的漏检）。

☆  大部分情况下，App披露SDK收集数据字段只能依赖于SDK隐私政策中的披露，但可能SDK提供者实际收集的数据发生变化而App未及时更新其隐私政策，进而导致App披露信息与实际不符。建议App列举出SDK收集的字段或种类时，还可同时列出SDK隐私政策链接，以便检测人员在验证一致性时获取最新的处理规则。

☆  建议SDK提供者区分SDK的服务类型，明确SDK的主要服务目的，不宜对不同服务目的的SDK进行捆绑、嵌套，以免在App接入SDK后可能出现的超范围收集的现象，检测时也可关注此类问题。

研讨问题4：如何理解平台接入第三方服务时在法律中的角色定位？例如，开放平台引入小程序开发者，但数据主要由小程序处理，开放平台与小程序是否属于“共同决定”处理个人信息活动？精彩观点如下：

☆  独立处理者模式。如果小程序服务中的个人信息主要由小程序开发者处理，开放平台仅提供入驻以及搭建小程序底层技术能力的服务（包括通过开放平台的通道、接口获取部分个人信息），则该场景下小程序开发者通常为独立的处理者，无法与开放平台构成“共同处理者”。

☆  受托处理者模式。如开放平台处理了小程序用户的个人信息（例如为小程序开发者提供存储个人信息的服务器空间及技术服务），但不能自行决定处理目的，宜将开放平台界定为小程序开发者的受托处理方。

☆  平台方责任。如平台主动以链接、窗口等方式接入第三方服务，虽然第三方系独立的处理者，但平台还是应尽最大努力使用户了解该服务由第三方提供。

研讨问题5：SDK是否可以根据法律中规定的角色不同、处理数据法律基础不同，判断是否需要由用户决定是否停止使用？精彩观点如下：

☆  判断是否由App用户可以决定停止在App中使用SDK，需要结合SDK的法律角色定位、处理个人信息的合法性基础以及特定的使用场景等因素，不宜一概而论。

☆  如果SDK运营者系独立的处理者，用户是基于“同意”而使用SDK服务，则用户决定停止使用SDK的，可理解为用户行使撤回同意的权利，可参照有关法律法规、标准要求执行。

☆  如果SDK运营者系独立的处理者，用户是基于“同意”以外的其他合法性基础使用SDK服务，例如SDK系为履行法定职责或者法定义务所必需而获取用户身份证号码、为应对突发公共卫生事件所必需而进行刷脸认证等，则不宜向用户提供停止/拒绝SDK服务的功能。

☆  如果SDK与App构成委托处理中的受托方，那么接入该SDK的App运营者才是处理者，应由App运营者响应其用户限制/拒绝处理个人信息，SDK本身无需向用户提供停止/拒绝SDK服务的模式。

研讨问题6：App接入了第三方互联网广告平台（或生态），对于保障用户的撤回同意权，欧洲IAB的“同意管理平台”模式（CMP）在中国语境下是否可行？精彩观点如下：

☆  为符合欧盟GDPR和ePrivacy Directive的要求，在欧洲地区进行广告投放的网站需要设置Cookie Banner，但Cookie Banner的部署及维护是涉及技术、法律、运维等多层面的复杂工程。

☆  为了更系统、便利解决上述问题而产生了CMP模式这种一站式解决方案。该模式本身有助于个人信息处理合规体系的构建，但该模式主要针对网站的Cookie设置，不太适用国内App的场景，而且在欧盟法语境下认定CMP管理者个人信息处理过程中的不同法律角色和关系，可能与国内法律也不完全一致。因此，可持续研究和观察，寻求适合于中国现有法律框架和产业生态的解决方案。

（文章来源：CCIA数据安全工作委员会）