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

1、研讨背景

App广泛接入第三方服务(如SDK、服务页面/接口等)是移动互联网发展至今形成的一种常态运营模式,其中原因众多,包括开发效率、服务所需、应用交互、用户体验、产品创新、业务风控等等。然而,这对于个人信息处理来说,无疑在厘清责任边界、实施安全措施等方面增加了复杂度、安全隐患以及合规工作的不确定性。对此,企业如何理解和规范App接入的各类第三方服务成为了数据合规实务工作的难点之一。针对上述难点,CCIA数据安全工作委员会于近日组织各方专家进行了研讨。与会专家从厘清基础概念、探索实践路径、提出安全建议等角度各抒己见。现就研讨中形成的主要观点以会议纪要方式公开,供各界参考、指正。参与此次研讨的专家来自:中国电子技术标准化研究院、中国网络安全审查技术与认证中心、北京信息安全测评中心等研究机构,以及部分CCIA数据安全工作委员会委员单位。

以下观点仅代表专家个人观点。

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数据安全工作委员会

相关新闻

返回顶部