对《常见类型移动互联网应用程序必要个人信息范围规定》的再理解

编者按:

今天,国家互联网信息办公室秘书局、工业和信息化部办公厅、公安部办公厅、国家市场监督管理总局办公厅联合发布了《常见类型移动互联网应用程序必要个人信息范围规定》【全文见:关于印发《常见类型移动互联网应用程序必要个人信息范围规定》的通知】。

如何理解该规定,在第一篇文章中,公号君从两个方面(必要个人信息基本功能服务)入手,分别结合《个人信息保护法(草案)》和《个人信息安全规范》的相关条款进行分析,供大家参考批判。详见:对《常见类型移动互联网应用程序必要个人信息范围规定》的两点理解

在第二篇文章中,公号君将对为什么要提出基本功能服务这个概念,做深度的分析。主要内容来自于公号君2019年出发表的文章【过度收集个人信息如何破解


《常见类型移动互联网应用程序必要个人信息范围规定》发布之后,公号君遇到最多的一个问题是:为什么要界定基本功能服务?GDPR都只是规定了数据最小化的要求,中国的监管机构直接要求APP做这样的划分,理由和正当性何在?


以下为2019年年初发表文章的内容

------------------------------------------------------------------------------



在移动互联时代,如果单从收集环节来看个人信息保护来看,最突出的问题应是大众应用程序(app)过度收集用户的个人信息。开发、经营app的网络运营者如违反了《网络安全法》关于“不得收集与其提供的服务无关的个人信息”的规定,掌握了本不该获得的个人信息,一旦发生信息的滥用、误用,或发生了信息的泄露、毁损、丢失,对用户合法权益造成的损害将成倍地放大。


另一方面,数据即石油、数据是黄金,已经成为数字经济的常识。在经济利益的驱使下,网络运营者有着天然的冲动最大程度地收集个人信息,用于自己的经营活动中。现实中,他们往往采取以下两条路径:


一是隐瞒收集个人信息的功能、类型、范围等,偷偷地收集个人信息。这方面不仅直接面向用户的网络运营者会这么做(即直接欺瞒用户),那些给app提供功能模块或组件的第三方开发者也会偷偷嵌入收集个人信息的指令或功能,试图“搭便车”收集个人信息(即同时欺瞒app开发者和用户)。


二是强迫用户同意授权其收集个人信息,即通过“一揽子协议”强制用户授权。如果细究起来,“一揽子协议”还可分为两个方面:服务或功能捆绑,以及故意扩大服务或功能所必需的个人信息。面对这样的“一揽子协议”,用户要么只能全盘接受,要么只能退出走人。


那现有的法律提出了应对之策吗?目前,在《个人信息保护法》还未出台前,《网络安全法》提出了对个人信息最为完整、全面的保护设计。如下表所示:


细分行为

《网安法》对应条款

过度收集个人信息

隐秘收集

直接面向个人用户的网络运营者欺瞒收集行为

1.   22条第2款:“网络产品、服务具有收集用户信息功能的,其提供者应当向用户明示并取得同意;涉及用户个人信息的,还应当遵守本法和有关法律、行政法规关于个人信息保护的规定。”

2.   41条第1款:“网络运营者收集、使用个人信息,应当遵循合法、正当、必要的原则,公开收集、使用规则,明示收集、使用信息的目的、方式和范围,并经被收集者同意。”

向上述网络运营者提供功能模块或组件的第三方开发者隐瞒收集行为

强制收集

服务或功能强制捆绑

无直接对应的条款

扩大单个功能必需收集的信息类型、数量等

41条第1款:“网络运营者不得收集与其提供的服务无关的个人信息


一、对隐秘收集的分析


从上表可知,针对隐秘收集,《网安法》有直接规范该行为的条款。无论是直接面向个人用户的开发者(以下简称“第二方开发者”),还是第三方开发者,均需要明示其收集的功能,不能偷偷摸摸地收集。具体情况如下:


如果第三方开发者承当个人信息控制者的角色(即有权决定个人信息处理目的和方式),则第三方开发者所明示的用户有两类,分别是个人用户和嵌入其服务的第二方开发者。此时明示的方式可以又分为两种:第一种是第三方开发者直接向个人用户明示并取得同意;


第二种是第二方开发者在其向个人用户的告知文本中明确点出第三方开发者的存在,明确说明第三方开发者收集个人信息的目的、规则、范围等,并代替第三方开发者取得个人用户的同意。


实践中,在第二种明示方式下,往往个人用户只能一次性给出对第二方开发者和第三方开发者的同意授权,因此存在“服务或功能强制捆绑搭售”(对其分析见下文)的情况,个人用户的同意实际上被架空。


还要注意的是:第三方开发者如果不决定其所收集的个人信息的处理目的和方式,仅仅依照控制者的指令行事,且绝不截留私自存储个人信息另做它用,其仅仅承当个人信息处理者的角色(此处借用欧盟GDPR的定义)。此时,第二方开发者在向个人用户的告知文本中,可以自主选择是否披露第三方存在,因为本质上其需要承担的法律责任并不会转移给个人信息处理者。


二、对强制收集的分析


强制收集是民众非常厌烦的问题,但如何破解却又是非常困难的课题。第一,按照《网安法》第41条第1款从字面上,可理解为仅要求第二方开发者明示其提供的服务或功能即可(无论这些功能或服务有多少)。


第二,该条款将“必要”作为基本原则,“必要”原则又可以理解为仅提供必要功能(及服务),还可以理解为要求单个功能中仅收集必要的信息。但对于“必要功能”或“必要信息”,开发者往往能提出各种各样的理由来证明必要性,同时由于存在严重的信息不对称,个人用户基本无法辩驳。


第三,当服务或功能捆绑在一起了,或者每个服务或功能所明示的是一种“扩大版”的必要信息后,个人用户面临的是要么接受,要么走人的局面(take it or leave it)。


由于存在上述三点,第二方开发者只需要修改隐私政策文本,强制用户点击同意,即在表面上完成了《网络安全法》的合规,就可以大肆收集个人信息了。因此,要过度收集个人信息,最重要的议题就是破解强制收集,实际上则是要遏制两种行为:一是强制捆绑服务或功能;二是夸大单个服务(或功能)所必要的个人信息。很可惜,我国现行的法律法规在这方面并没有给予足够的指导。


三、外国经验的分析


1、欧盟《通用数据保护条例》


在破除服务或功能强制捆绑方面,GDPR主要通过个人信息处理的合法事由的设计来实现。GDPR第六条规定了个人信息处理合法的六项事由:一是数据主体对出于单个或多个特定目的而处理其个人数据表示同意;二是处理是为向身为合同当事人的数据主体履行合同所必须的,或在缔约前,应数据主体的要求所必须采取的步骤;三是因履行数据控制者承担的法律义务而必须处理个人数据的;四是为保护数据主体重大利益或其他自然人重大利益而必须处理个人数据的;五是为公共利益而执行任务,或数据控制者履行赋予的公共职能时,必须处理个人数据的;六是因数据处理者正当利益或第三方正当利益而必须处理个人数据的,但当数据主体的利益或基本权利和自由(特别当数据主体尚未成年时)高于上述正当利益时,不得使用该事由。


个人信息控制者基于特定目的而开始收集个人信息之前,需要事先确定自己所依赖的合法事由,且不能在后期随意更改。而且每项合法事由使用有着严格的限制,不同合法事由后期搭配的个人信息主体的权利也不尽相同。因此,可以说选择合法事由,是个人信息控制者开展业务前最核心的工作。


合法事由的选择,在很大程度上破除了服务或功能的强制捆绑。例如当个人用户要求物流公司送货到其住所时,这是用户主动要求的服务,因此物流公司处理个人信息(个人用户的姓名、地址、电话等)的合法事由是“合同所必需”。这是如果物流公司将其特定时期其收集的个人信息汇总分析,目的是优化其配送服务,此时物流公司不能够再依赖“合同所必需”,转而应该要求“个人信息主体的同意”或者其“正当利益”这两个选项。


换句话说,通过强制个人信息控制者为不同的处理目的(包括目的所涵摄的一系列处理行为)来选择不同的合法事由,GDPR自然打破了服务或功能的强制捆绑。因为不同功能或服务,很可能需要不同的合法事由,不能混为一谈,一次性征求个人同意。反过来看我国,上述物流公司的例子在我国目前的商业实践中,基本是将所有的个人信息用途打包在一起,征求个人用户的同意。


我国目前的法律法规中,关于个人信息处理的合法事由是个人同意,缺乏像GDPR那样的设计。因此欧盟破解强制捆绑的路径在我国无法借鉴。


2、美国FTC的路径


美国并没有欧盟上述的合法事由的设计,但美国联邦贸易委员会(FTC)事实上区分了三个层次的同意和退出机制,也在一定程度上遏制了功能或服务强制捆绑的问题:


首先,对于个人用户在具体场景中能够合理预期(reasonable expectation)到会被收集、使用的个人数据,可以推定为用户已经明确授权同意。但对于这个场景中按照推定收集所获得的数据,转做它用,或者提供给与具体场景中无关的第三方做其他用途时,个人用户很可能无法合理预期,这时候还出现以下两种路径:一是对于个人敏感信息,需要用户自主选择同意(opt-in)是否专做其他用途或者提供给第三方;二是对于非敏感信息,用户通过选择退出的途径(opt-out)来形式选择权。


其次,第二方开发者需要收集在具体场景用户可合理预期之外的个人敏感信息时,最开始就需要用户自主选择同意(opt-in)。


再次,第二方开发者需要收集在具体场景用户可合理预期之外的非敏感信息时,需要给用户提供选择退出(opt-out)的机制。


以上三层次的同意和退出机制,均不能免除向用户告知的义务。只不过告知的形式,按照FTC的要求,也应该根据符合或偏离用户预期的程度、个人信息敏感程度、时机等方面综合考虑。同时,FTC还非常强调,当个人用户在市场上选择较少时,服务提供者不得以提供服务为条件强迫用户同意不合理条款。例如用户选择宽带服务时,宽带服务提供者不得强迫用户同意其记录、追踪用户所有的上网行为并用于推送广告目的,特别是用户如选择不同意就不提供宽带服务。


将上述路径对照欧盟GDPR的设计,可发现很大程度的重合。在具体场景中符合合理预期,与GDPR中的“合同所必需”异曲同工。个人用户自主选择进去某个服务或者功能场景,与用户主动要求签订合同相近。在这样的场景中,用户应当知道,也愿意提供完成服务或功能所必需的信息。


对于这之外的场景,如果是个人敏感信息,美国要求自主选择同意,与GDPR中的同意相近。对于非敏感信息,美国要求选择退出,与GDPR合法事由中的“正当利益”相近。


但美国FTC的路径为中国所借鉴存在困难,原因主要有两点:一是我国法律中并没有明确区分自主选择同意、选择退出、个人敏感信息等实施美国路径所必需的核心概念。二是合理预期这个概念难以落地,在实践中,(不同群体、特征的)用户、第二方、第三方、监管机构、消费者保护组织、律师、咨询机构、媒体等,对某个场景下合理预期都可能存在各自的理解。这就意味着,作为FTC路径中的核心要素,落实起来需要很高的外部条件。我国目前的监管资源和条件(如理解难以统一、管理水平不一、央地同时管辖等)似乎不足以支撑以不确定的法律概念开展个人信息保护的路径。


3、收费和非收费的路径


国内外具有学者提出可采用区分收费和非收费服务的路径,来开展个人信息保护。该路径基本逻辑如下:


首先,开发者提供服务或功能是有成本的,只能通过对个人用户的信息进行商业化开发利用(目前主要形式是通过推送个性化广告)取得回报,以对免费提供服务或功能进行补贴。其次,如果个人用户愿意付费,贴补开发者提供服务或功能的成本,则开发者就应当避免对付费用户的个人信息进行商业化开发利用。再次,对于不愿意付费的用户,则开发者保持对其个人信息开发利用的权利。


仔细分析上述模式,可知该路径并不避免个人信息的收集。为完成个人用户所需要的服务或功能,个人用户应当同意开发者收集、使用某些类别和数量的个人信息。只不过,由于用户付费了,开发者不得再将提供服务或功能过程中所必需的个人信息转而用于商业化开发利用。


从这个角度来看,这个路径和欧盟GDPR有很强的共通之处。为完成用户所需要的服务或功能,都需要允许收集、使用一定的个人信息,类似于GDPR中“合同所必需”。但是由于用户付费了,所以开发者不得再向用户提出将信息转于它用的请求,也就是说在收费路径中,开发者不得再采取GDPR中“用户同意”和“正当利益”这两个合法事由。


落实上述路径,应主要通过市场竞争的方式细分出愿意采取收费路径的商业模式。因此国内外鲜见通过公权力推行该路径的例子。


四、目前我国类似的法律规定


实际上,我国法律法规存在着类似的GDPR和FTC的路径区分。以下以《中国人民银行关于银行业金融机构做好个人金融信息保护工作的通知》(银发〔2011〕17号),以及《中国人民银行金融消费者权益保护实施办法》(银发〔2016〕314号)为例。其主要规定总结如下:


目的

具体要求

规定条目

1、建立业务关系

可以使用格式条款;

银发〔2016〕314号第30条

1)格式条款应明确(消费者要求的)金融产品和服务所必需的个人金融信息;

2)不得收集与业务无关的信息。

银发〔2016〕314号第28条

1)在格式条款中明确该授权或者同意所适用的向他人提供个人金融信息的范围和具体情形;应当在协议的醒目位置使用通俗易懂的语言明确向金融消费者提示该授权或者同意的可能后果,即必须明示

2)对于(消费者要求的)金融产品和服务所必需的向他人提供个人金融信息的(以及他人获得个人金融信息后的使用),可以用概括授权的方式取得消费者同意,即可以一揽子概括授权; 

3)金融机构可以将“该业务关系的性质决定需要”所必需向他人提供个人金融信息的(以及他人获得个人金融信息后的使用),作为“与金融消费者建立业务关系的先决条件”,即可以强制要求消费者同意

银发〔2016〕314号第30条

 

 

 

 

 

 

银发〔2016〕314号第31条

 

1) 对于(消费者要求的)金融产品和服务无关的向他人提供个人金融信息的(包括他人获得个人金融信息后的使用),不得以概括授权的方式取得消费者同意,只能单独要求授权

2) 对于与(消费者要求的)金融产品和服务无关的向他人提供个人金融信息(包括他人获得个人金融信息后的使用),金融机构不得将金融消费者授权或者同意其将个人金融信息对外提供等作为与金融消费者建立业务关系的先决条件,即不得强制要求消费者授权或同意

银发〔2016〕314号第30条

 




银发〔2016〕314号第31条

 

 

 

2、办理相关业务过程中

使用个人金融信息时,应当符合收集该信息的目的,并不得进行以下行为:

1) 出售个人金融信息;

2) 向本金融机构以外的其他机构和个人提供个人金融信息,但为个人办理相关业务所必需并经个人书面授权或同意的,以及法律法规和中国人民银行另有规定的除外;

3) 在个人提出反对的情况下,将个人金融信息用于产生该信息以外的本金融机构其他营销活动。

银发〔2011〕17号第四点

3、第一方营销

1) 对于与(消费者要求的)金融产品和服务相关的营销,如果该营销为“该业务关系的性质决定需要”,可以直接通过格式条款获得“概括性授权”,也可以强制要求消费者同意

2) 对于与(消费者要求的)金融产品和服务相关的营销,如果该营销不为“该业务关系的性质决定需要”,不得直接通过格式条款获得“概括性授权”,不得强制要求消费者同意

3) 对于与(消费者要求的)金融产品和服务无关的营销,金融机构不得将金融消费者授权或者同意其将个人金融信息对外提供等作为与金融消费者建立业务关系的先决条件,即不得一揽子概括授权,且不得强制要求消费者授权或同意

4) 对于将个人金融信息用于与(消费者要求的)金融产品和服务不相关的(即“产生该信息以外的”  金融产品和服务的)营销,如果个人前期选择同意了,但是后期个人提出反对,金融机构应当停止相关营销活动,即应当给予个人反对或退出的权利

银发〔2016〕314号第31条

 

 

 

 

 

 

 

 



银发〔2011〕17号第四点

4、业务之外的非营销事项

1)  必须明示;

2)  不得概括性授权;

3)  不得强制授权。

银发〔2016〕314号第20条

 


上述要求总结如下:

 

  1.   对于(消费者要求的)业务所必需的个人金融信息的收集、(机构内部办理业务所必需的)使用,金融机构应当明示,可以通过格式条款要求概括性授权,可以要求用户必须给予同意或授权;

  2. 对于(消费者要求的)业务所必需的对他人提供(包括他人获得个人金融信息后的使用),金融机构应当明示,可以通过格式条款要求概括性授权,可以要求用户必须给予同意或授权;

  3. 对于(消费者要求的)金融产品和服务相关的营销活动,如果该营销为“该业务关系的性质决定需要”,可以直接通过格式条款获得“概括性授权”,也可以强制要求消费者同意;

  4. 对于与(消费者要求的)金融产品和服务相关的营销,如果该营销不为“该业务关系的性质决定需要”,不得直接通过格式条款获得“概括性授权”,不得强制要求消费者同意;

  5. 对于与(消费者要求的)金融产品和服务不相关的营销,不得一揽子概括授权,且不得强制要求消费者授权或同意;如果前期个人选择同意但后期反对,金融机构应当停止营销活动;

  6. 对于(消费者要求的)金融产品和服务之外的非营销事项,必须明示、不得概括性授权、不得强制授权。

 

可以看出,人民银行的上述规定,基本上遵循了GDPR中“依合同所必需”以及“同意”两项合法性事由的区分,以及FTC关于“合理预期”和“合理预期”之外的个人敏感信息收集的要求。


五、《个人信息安全规范》所选择破解强制收集的路径


在国家标准《个人信息安全规范》的制定过程中,标准编制组充分研究了国内现行的法律法规,以及国外破解强制收集的主要路径(如前所述),最终标准编制组决定避免直接照搬国外的做法,而是借鉴国外路径的本质思路,创设出产品或服务核心功能(或称为基本功能)、附加功能(或称为拓展功能)的概念,做出了如下制度设计:


首先,产品或服务应当自行区分核心和附加功能。其次,对于核心功能或服务,个人用户应当允许运营者收集实现该功能或服务所必需的个人信息,否则该功能或服务无法完成。此时如果用户选择不同意,则允许运营者不向用户提供功能或服务。但对于附加功能,应当允许用户逐一选择是否需要。同时标准要求,“当个人信息主体拒绝时,可不提供相应的附加功能,但不应以此为理由停止提供核心业务功能,并应保障相应的服务质量”。


上述核心功能和附件功能的设计,意在打破“强制收集”的行为。本质上,核心功能仿造了GDPR中的“合同所必需”,以及FTC的“合理期待”;附加功能仿造了GDPR中的“个人同意”,以及FTC要求的“合理期待”之外的个人敏感信息的收集。


实践中,企业经常询问如何区分核心和附件功能?这个问题,是打破强制收集的关键。有些投机取巧的开发者会将所有的功能全纳入核心功能的框中,然后还是强迫个人用户授权同意。如此一来,核心和附加功能的区分将流于形式。为避免这个问题,我们存在两种思路:


一是通过市场竞争或者社会监督的路径来解决。比如说,同样是通信软件,有一家企业把核心功能定义得特别大,附加功能定义得特别小;另外一家把核心功能定义得很小,附加功能定义得很大。对如此大的差别,相信一定会有社会监督机构(如消费者保护组织、媒体、高校研究人员等)或监管机构对此展开调查或约谈,要求企业对自己的划分给出合理的解释。如此一来,通过市场上的竞争和比较,逐渐能够形成各行业关于核心功能和附加功能区分的惯例。换句话说,在这个思路下,标准只要求企业自主划分功能,并对划分提出具体、合理的解释,然后交由市场和外部力量来对企业的划分和解释进行监督。概括起来,该思路提倡通过自下而上,形成对功能的合理划分,打破强制收集的行为。


另外一种思路是由标准化机构针对民众经常使用的应用程序,提出各类应用程序的基础功能和拓展功能的划分指引,并提出具体功能或服务所必需收集、使用的个人信息的最小集合。如此一来,指引能够打破前文所述的强制收集所存在两类行为。而且这样的指引,在通过广泛参与、广泛征集意见、反复试点验证的基础上形成,并定期修订更新。虽然指引不具备法律上的强制力,但是企业对于偏离指引的做法,应当承当具体的解释义务。(完)


------------------------------------------------------------------------------


在2020版本的《个人信息安全规范》的正文部分,并没有要求明确区分核心功能或附加功能(也就是《常见类型移动互联网应用程序必要个人信息范围规定》要求的基本功能服务,以及其他功能服务),而是将所有的功能服务一视同仁,平等要求。这背后主要参考了当时编制组成员企业代表的意见。


在正文中最后达成了一个compromise——


对《常见类型移动互联网应用程序必要个人信息范围规定》的再理解


大家可以看到,《个人信息安全规范》正文中:所有功能服务一视同仁的同时,用户应该能够随时开启或关闭各个功能服务。其实公号君认为这个要求更加难以实现。


相反,如果区分基本功能服务和其他功能服务,如果用户不同意收集必要个人信息的话,确实APP可以停止运行或退出,因为基本功能服务无法实现。在公号君看来,这样的方式相对容易实现。


但当时出于在工作组内部达成合意的考虑,最终选择了“所有功能服务一视同仁”的方案,将“区分基本功能服务和其他功能服务”的方案,放到了附录C。


现在来看附录C中相关要求——


对《常见类型移动互联网应用程序必要个人信息范围规定》的再理解


很多企业代表很不理解如何划分基本功能服务,因为目前APP大多为平台型的APP,同时承载了很多功能服务。


公号君认为,在注1和注2中阐释得很清楚。最最核心的是,站在用户角度做划分,而非是从企业自身的角度做出划分。


其实大家只要打开自己手机,查看已经安装的各个APP,都会发现,当初下载时,都是为了一个主要功能。这个主要功能,或是从APP的名字,或是从APP的推广等,都能够很容易的辨识。毕竟APP运营者在推广时,一定会希望自己的APP的名字和图片非常醒目和传神,就如和文章取名一样。


其实无论是安卓还是苹果的开发者文档,也都要求开发者确定APP具备core functionality. 


而且希望大家多读几遍注1和注2,里面传递了很多的信息和内容。(完)



数据保护官(DPO)社群主要成员是个人信息保护和数据安全一线工作者。他们主要来自于国内头部的互联网公司、安全公司、律所、会计师事务所、高校、研究机构等。在从事本职工作的同时,DPO社群成员还放眼全球思考数据安全和隐私保护的最新动态、进展、趋势。2018年5月,DPO社群举行了第一次线下沙龙。沙龙每月一期,集中讨论不同的议题。目前DPO社群已超过300人。关于DPO社群和沙龙更多的情况如下:


域外数据安全和个人信息保护领域的权威文件,DPO社群的全文翻译:

  1. 印度《2018个人数据保护法(草案)》全文翻译(中英对照版)(DPO沙龙出品)

  2. 巴西《通用数据保护法》全文中文翻译(DPO沙龙出品)

  3. “美国华盛顿哥伦比亚特区诉Facebook“起诉书全文翻译(DPO沙龙出品)

  4. 法国数据保护局发布针对与商业伙伴或数据代理共享数据的指南

  5. 德国联邦反垄断局对Facebook数据收集和融合行为提出严格限制(DPO沙龙出品)

  6. 德国联邦反垄断局审查Facebook数据收集融合行为的背景情况(DPO沙龙出品)

  7. “108号公约”全文翻译(DPO沙龙出品)

  8. 美国司法部“云法案”白皮书全文翻译(DPO社群出品)

  9. 新加坡《防止网络虚假信息和网络操纵法案》中文翻译(DPO沙龙出品)

  10. 英国ICO《广告技术和实时竞价的更新报告》中译文(DPO社群出品)

  11. “FTC与Facebook达成和解令的新闻通告”全文翻译(DPO社群出品)

  12. CJEU认定网站和嵌入的第三方代码成为共同数据控制者(DPO沙龙出品)

  13. FTC与Facebook“2019和解令”全文翻译(DPO社群出品)

  14. 英国ICO《数据共享行为守则》中译文(DPO社群出品)

  15. “hiQ Labs诉LinkedIn案上诉判决”中译文(DPO社群出品)

  16. 法国数据保护监管机构(CNIL)有关cookies和其他追踪方式的指引(全文翻译)

  17. 美加州消费者隐私法案(CCPA) 修正案汇总中译文(DPO沙龙出品)

  18. FTC“首次针对追踪类App提起诉讼”的官方声明中文翻译(DPO社群出品)

  19. ICDPPC关于隐私和消费者保护、竞争维护交叉问题决议的中文翻译(DPO社群出品)

  20. 德国关于确定企业GDPR相关罚款数额官方指南的中文翻译(DPO社群出品)

  21. 亚洲十四个国家和地区数据跨境制度报告中译本(DPO社群出品)

  22. 印度《个人数据保护法》(2019年草案)全文翻译(DPO社群出品)

  23. 法国数据保护局(CNIL)关于人脸识别报告的中译文(DPO社群出品)

  24. AEPD和EDPS | “哈希函数简介——用于个人数据假名化技术”中译文(DPO社群出品)

  25. 欧盟基本权利局“人脸识别技术”报告中文翻译(DPO社群出品)

  26. 联合发布 |《2020数字医疗:疫情防控新技术安全应用分析报告》

  27. 技术主权视野下的欧盟数字化转型战略探析(DPO社群出品)

  28. 意大利数据保护机关就新冠疫情联防联控中个人信息问题的意见(DPO社群出品)

  29. 新版《个人信息安全规范》(35273-2020)正式发布

  30. 英国ICO | 《儿童适龄设计准则:在线服务实业准则》全文翻译之一

  31. 英国ICO | 《儿童适龄设计准则:在线服务实业准则》全文翻译之二

  32. 《个人信息安全影响评估指南》(GB/T 39335-2020)正式发布

  33. 《英国ICO人工智能与数据保护指引》选译 | 如何保护人工智能系统中的个人权利?

  34. 《英国ICO人工智能与数据保护指引》选译 | 如何评估AI的安全性和数据最小化?

  35. 西班牙数据保护局《默认数据保护指南》全文翻译(DPO社群出品)


DPO线下沙龙的实录见:

  1. 数据保护官(DPO)沙龙第一期纪实

  2. 第二期数据保护官沙龙纪实:个人信息安全影响评估指南 

  3. 第三期数据保护官沙龙纪实:数据出境安全评估

  4. 第四期数据保护官沙龙纪实:网络爬虫的法律规制

  5. 第四期数据保护官沙龙纪实之二:当爬虫遇上法律会有什么风险

  6. 第五期数据保护官沙龙纪实:美国联邦隐私立法重要文件讨论

  7. 数据保护官(DPO)沙龙走进燕园系列活动第一期

  8. 第六期数据保护官沙龙纪实:2018年隐私条款评审工作

  9. 第八期数据保护官沙龙纪实:重点行业数据、隐私及网络安全

  10. 第九期数据保护官沙龙纪实:《个人信息安全规范》修订研讨

  11. 第十期数据保护官沙龙纪实:数据融合可给企业赋能,但不能不问西东

  12. 第十一期数据保护官沙龙纪实:企业如何看住自家的数据资产?这里有份权威的安全指南

  13. 第十二期数据保护官纪实:金融数据保护,须平衡个人隐私与公共利益

  14. 第十三期DPO沙龙纪实:厘清《数据安全管理办法》中的重点条款

  15. 第十四期DPO沙龙纪实:梳理《个人信息出境安全评估办法(征求意见稿)》的评估流程

  16. 第十五期DPO沙龙纪实:SDK非洪水猛兽,但如果“作恶”乱收集信息,谁来管?

  17. 第十六期DPO沙龙纪实:查询App收集个人信息类型、禁止收集IMEI号是未来监管趋势

  18. 与欧美一流数据保护专家面对面(DPO沙龙特别活动)

  19. 第十七期DPO沙龙纪实:数据统一确权恐难实现 部门立法或是有效途径

  20. 第十八期DPO沙龙纪实:生物识别信息的安全保护

  21. 第十九期DPO沙龙纪实:《个人信息保护法(草案)》专题研讨会之一

  22. 第二十期DPO沙龙纪实:《个人信息保护法(草案)》专题研讨会之二


美国电信行业涉及外国参与的安全审查系列文

  1. 美国电信行业涉及外国参与的安全审查(一):基本制度介绍

  2. 美国电信行业涉及外国参与的安全审查(二):国际性的第214节授权

  3. 美国电信行业涉及外国参与的安全审查(三):建立外国参与安全审查的行政令

  4. 美国电信行业涉及外国参与的安全审查(四):FCC对中国企业的陈述理由令


中国的网络安全审查系列文章:

  1. 网络安全审查制度利刃出鞘

  2. 对《网络安全审查办法(征求意见稿)》的几点观察

  3. 网络安全审查制度吹响了向网络安全强国迈进的号角

  4. 我国网络安全审查制度走向前台

  5. 网络安全审查的中欧比较:以5G为例

  6. 网络安全审查 | 中国《网络安全审查办法》的逻辑和要旨:以5G安全为例


自动驾驶系列文章:

  1. 自动驾驶数据共享:效用与障碍

  2. 自动驾驶数据共享:效用与障碍(附文字实录)

  3. 北京市关于自动驾驶车辆道路测试的立法综述及动态(DPO社群成员观点)

  4. 自动驾驶的基建工程 — 高精地图产业促进与国家管控的平衡(DPO社群成员观点)

  5. EDPB《车联网个人数据保护指南》全文翻译(DPO社群出品)


数据安全法系列文章:

  1. 对《数据安全法》的理解和认识 | 立法思路

  2. 对《数据安全法》的理解和认识 | 数据分级分类

  3. 对《数据安全法》的理解和认识 | 中国版的封阻法令

  4. 对《数据安全法》的理解和认识 | 重要数据如何保护


个人数据与域外国家安全审查系列文章

  1. 个人数据与域外国家安全审查初探(一):美欧概览

  2. 个人数据与域外国家安全审查初探(二):CFIUS实施条例详解

  3. 个人数据与域外国家安全审查初探(三):从美国《确保ICT技术与服务供应链安全》        

  4. 个人数据与域外国家安全审查初探(四):从美国《2019年安全与可信通信网络法案》看

  5. 个人数据与域外国家安全审查初探(五):禁止中国公司对StayNTouch的收购

  6. 个人数据与域外国家安全审查初探(六):《2019国家安全和个人数据保护法案》

  7. 个人数据与域外国家安全审查初探(七):美国众议院荒唐的决议草案

  8. 个人数据与域外国家安全审查初探(八):《2020安全的5G和未来通信》法案

  9. 个人数据与域外国家安全审查初探(九):澳大利亚《协助和访问法》

  10. 美国司法部狙击中国内幕(Inside DOJ's nationwide effort to take on China)

  11. 美国司法部“中国计划”的概况介绍

  12. 突发 | 特朗普签署关于TIKTOK和WECHAT的行政令

  13. 理解特朗普禁令中的Transactions

  14. 白宫决策内幕 | TIKTOK的命运是由一场"击倒、拖出"的椭圆形办公室争斗所形塑

  15. 《国际紧急经济权力法》(IEEPA)的起源、演变和应用

  16. 个人数据与域外国家安全审查 | 美国安局对地理位置信息的建议(全文翻译)

  17. 外媒编译 | 诡秘的美国外国投资委员会如何成为贸易战的有力武器?


围绕着TIKTOK和WECHAT的总统令,本公号发表了以下文章:

  1. 突发 | 特朗普签署关于TIKTOK和WECHAT的行政令

  2. 理解特朗普禁令中的Transactions

  3. 白宫决策内幕 | TIKTOK的命运是由一场"击倒、拖出"的椭圆形办公室争斗所形塑

  4. TikTok和甲骨文合作中的“可信技术提供商” | 微软和德国电信合作的模式

  5. TikTok和甲骨文合作中的“可信技术提供商” | 苹果和云上贵州合作模式

  6. 外媒编译 | TikTok 零点时间:最后一刻的交易

  7. TikTok和甲骨文合作中的“可信技术提供商” | 来自EPIC的质疑和两家公司的回复


中国个人信息保护立法系列文章

  1. 中国个人信息保护立法 | 《个人信息保护法(草案)》与GDPR的比较

  2. 中国个人信息保护立法 | 合同所必需:魔鬼在细节之中

 

第29条工作组/EDPB关于GDPR的指导意见的翻译:

  1. 第29条工作组《对第2016/679号条例(GDPR)下同意的解释指南》中文翻译(DPO沙龙出品)

  2. 第29条工作组“关于减轻对处理活动进行记录义务的立场文件”(DPO沙龙出品)

  3. 第29条工作组《第2/2017号关于工作中数据处理的意见》(DPO沙龙出品)

  4. 第29条工作组《关于自动化个人决策目的和识别分析目的准则》(DPO沙龙出品)

  5. 第29条工作组《数据可携权指南》全文翻译(DPO沙龙出品)

  6. 第29条工作组关于GDPR《透明度准则的指引》全文翻译(DPO沙龙出品)

  7. EDPB《关于GDPR适用地域范围(第3条)的解释指南》全文翻译(DPO沙龙出品)

  8. EDPB“关于《临床试验条例》与GDPR间相互关系”意见的全文翻译(DPO沙龙出品)

  9. EDPB《车联网个人数据保护指南》全文翻译(DPO社群出品)

  10. EDPB关于GDPR中合同必要性指引的中文翻译(DPO沙龙出品)

  11. EDPB关于“疫情场景中使用位置数据和接触追踪工具”指南:全文翻译(DPO沙龙出品)

  12. EDPB | 《对第2016/679号条例(GDPR)下同意的解释指南v1》中文翻译(DPO社群出品)

  13. 第29条工作组 | 《关于匿名化技术的意见》中文全文翻译(DPO社群出品)

  14. 欧盟委员会关于GDPR实施两周年评估报告中文翻译(DPO社群出品)

  15. EDPB | 《GDPR下数据控制者及数据处理者概念的指南(07/2020)》全文翻译

  16. EDPB | 《针对向社交媒体用户定向服务的指南(第8/2020号)》全文翻译

  17. 数据安全的法律要求 | DPB关于数据泄露通知示例的01/2021号指引


关于美国出口管制制度,本公号发表过系列文章:

  1. 美国出口管制制度系列文章之一:对“外国生产的产品”的相关规则

  2. 美国出口管制制度系列文章之二:适用EAR的步骤

  3. 美国出口管制制度系列文章之三:苏联油气管道的“华为”事件

  4. 美国出口管制制度 | 允许华为和美国公司共同制定5G标准

  5. 美国出口管制 | BIS发布针对“基础性技术”出口管制的“拟议制定规则预先通知”

  6. 《华盛顿邮报》披露《美国对中国的战略路径》背后的决策博弈

  7. 美国出口管制 | ARM+美国公司收购=更强的出口管制?


供应链安全文章:

  1. 供应链安全 | 白宫发布关于降低依赖外国对手的重要矿产的行政令

  2. 供应链安全 | 美国从科技供应链中剔除中国行动的内幕(外媒编译)

  3. 供应链安全 | 英国政府推进《电信(安全)法案》以确保供应链安全


人脸识别系列文章:

  1. 欧盟基本权利局“人脸识别技术”报告中文翻译(DPO社群出品)

  2. 法国数据保护局(CNIL)关于人脸识别报告的中译文(DPO社群出品)

  3. 零售门店使用人脸识别技术的主要法律问题(DPO社群成员观点)

  4. 人脸识别技术的规制框架(PPT+讲稿)

  5. 人脸识别技术运用的六大场景及法律规制框架的适配(DPO社群成员观点)

  6. 人脸识别技术的法律规制研究初探(DPO社群成员观点)

  7. 美国联邦隐私保护立法草案研究(四):“生物识别信息”

  8. 美国华盛顿州人脸识别服务法案中文翻译(DPO社群出品)

  9. PAI | 《理解人脸识别系统》全文翻译(DPO社群出品)

  10. 解读世界首例警方使用人脸识别技术合法性判决二审判决(DPO社群成员观点)

  11. 人脸识别技术研究综述(一):应用场景

  12. 人脸识别技术研究综述(二):技术缺陷和潜在的偏见

  13. 美国人脸识别技术的法律规范研究综述 | 拼凑式(Patchwork)的范式

  14. 美国《2020年国家生物识别信息隐私法案》中译文

  15. 人脸识别技术是潘多拉盒子还是阿拉丁神灯?


数据跨境流动政策、法律、实践的系列文章:

  1. 构建数据跨境流动安全评估框架:实现发展与安全的平衡

  2. 构建数据跨境流动安全评估框架:实现发展与安全的平衡(二)

  3. 构建数据跨境流动安全评估框架:实现发展与安全的平衡(三)

  4. 构建数据跨境流动安全评估框架:实现发展与安全的平衡(四)

  5. TPP对跨境金融数据“另眼相看”?

  6. 马来西亚拟将我国认定为个人数据跨境流动“白名单”地区

  7. 美国ITIF关于数据跨境流动的研究报告简介

  8. Chatham House举办Cyber 2017大会,关注中国数据跨境流动

  9. 俄罗斯个人信息保护机构对隐私政策和数据跨境流动的新举措

  10. 看清APEC“跨境隐私保护规则”体系背后的政治和经济

  11. 敬请关注“闭门会-数据跨境流通”

  12. “闭门会:数据跨境流动政策分析” 总结

  13. 欧盟个人数据跨境流动机制进展更新(截止201810)

  14. 俄罗斯数据本地化和跨境流动条款解析

  15. 亚洲十四个国家和地区数据跨境制度报告中译本(DPO社群出品)

  16. 《个人信息和重要数据出境安全评估办法》实现了安全与发展的平衡

  17. 数据出境安全评估:保护我国基础性战略资源的重要一环

  18. 个人信息和重要数据出境安全评估之“境内运营”

  19. 《数据出境安全评估:保护我国基础性战略资源的重要一环》英文版

  20. 个人信息和重要数据出境安全评估之“向境外提供”

  21. 数据出境安全评估基本框架的构建

  22. 银行业金融数据出境的监管框架与脉络(DPO社群成员观点)

  23. 《网络安全法》中数据出境安全评估真的那么“另类”吗

  24. 解析《个人信息出境安全评估办法(征求意见稿)》实体保护规则背后的主要思路

  25. 《个人信息出境安全评估办法(征求意见稿)》解读:从中外比较的角度

  26. 数据跨境流动 | 澳大利亚政府提出新的数据本地化要求

  27. 数据跨境流动 | 美欧“隐私盾协议”被判无效背后的逻辑

  28. 数据跨境流动 | 欧盟EDPB对欧盟隐私盾协议被判无效的相关问答(全文翻译)

  29. “清洁网络计划”下的APEC跨境隐私保护(CBPR)体系

  30. 数据跨境流动 | 爱尔兰DPA即将禁止FACEBOOK的数据跨境传输

  31. 数据跨境流动 | 最新判决将显著影响英国与欧洲大陆之间的数据自由流动

  32. 数据跨境流动 | 爱尔兰高等法院暂时允许Facebook继续个人数据跨大西洋传输

  33. 数据跨境流动 | 中国公司基于SCCs开展数据跨境流动的基本策略

  34. 数据跨境流动 | 美国三位高官就Schrems II判决公开向欧盟喊话

  35. 数据跨境流动 | 欧盟EDPS官员敦促美国强化个人救济以达到“实质等同”

  36. 数据跨境流动 | 美国政府白皮书正式回应欧盟Schrems II判决

  37. 数据跨境流动 | EDPB关于标准合同条款之外的“补充措施”的指南终于问世

  38. 数据跨境流动 | EDPB提出“评估目的国法律环境”的指南(全文翻译)

  39. 数据跨境流动 | 微软率先提出对欧盟数据的专属“保护措施”

  40. 数据跨境流动 | 欧盟新版标准合同条款全文翻译

  41. 数据跨境流动 | EDPB和EDPS通过了关于新的SCCs的联合意见

  42. 数据跨境流动 | “法律战”漩涡中的执法跨境调取数据:以美欧中为例

  43. 数据跨境流动 | 东盟跨境数据流动示范合同条款(全文翻译)

  44. 数据跨境流动 | 东盟数据管理框架(全文翻译)


传染病疫情防控与个人信息保护系列文章

  1. 传染病疫情防控与个人信息保护初探之一:个人信息的性质

  2. 传染病疫情防控与个人信息保护初探之二:同意的例外

  3. 传染病疫情防控与个人信息保护初探之三:数据技术的应用路径

  4. 传染病疫情防控与个人信息保护初探之四:接触追踪的数据共享安全规范

  5. 传染病疫情防控与个人信息保护初探之五:电信数据的安全规范

  6. 传染病疫情防控与个人信息保护初探之六:GDPR框架下的公共卫生数据共享

  7. 传染病疫情防控与个人信息保护初探之七:美国公共卫生机构的数据调取权力

  8. 传染病疫情防控与个人信息保护初探之完结篇:解读中央网信办通知

  9. 欧盟国家和英国的数据保护部门对疫情防控的官方意见汇总(DPO社群出品)

  10. 美国疫情防控中的关键基础设施的识别和认定(DPO社群出品)

  11. 意大利数据保护机关就新冠疫情联防联控中个人信息问题的意见(DPO社群出品)

  12. 欧委会关于新冠疫情中利用移动数据和应用官方建议的全文翻译(DPO沙龙出品) 

  13. 漫画图解苹果和谷歌联手开发的接触追踪应用的基本原理  

  14. 澳门关于疫情防控中进出场所人员个人资料保护的通告

  15. 疫情防控常态化中的接触追踪:中国方案

  16. 欧委会“支持抗击新冠疫情的APP的数据保护指引”全文翻译(DPO社群出品)

  17. 来自欧洲的接触追踪协议(ROBERT Protocol)的基本原理:漫画图解

  18. 英国信息专员对苹果谷歌接触追踪项目的官方意见:全文翻译(DPO社群出品)

  19. 三百名学者关于接触追踪APP的联合声明

  20. EDPB关于“疫情场景中使用位置数据和接触追踪工具”指南:全文翻译(DPO沙龙出品)

  21. 新冠疫情防控常态化下的个人信息保护工作的思考和建议 

  22. 韩国利用ICT抗疫经验总结:接触追踪部分(中文翻译)

  23. 全文翻译 | 欧盟新冠肺炎“接触追踪”APP 共同工具箱(DPO沙龙出品)

  24. EDPB | 关于在COVID-19疫情背景下为科研目的处理健康数据指南(全文翻译)


人脸识别系列文章:

  1. 欧盟基本权利局“人脸识别技术”报告中文翻译(DPO社群出品)

  2. 法国数据保护局(CNIL)关于人脸识别报告的中译文(DPO社群出品)

  3. 零售门店使用人脸识别技术的主要法律问题(DPO社群成员观点)

  4. 人脸识别技术的规制框架(PPT+讲稿)

  5. 人脸识别技术运用的六大场景及法律规制框架的适配(DPO社群成员观点)

  6. 人脸识别技术的法律规制研究初探(DPO社群成员观点)

  7. 美国联邦隐私保护立法草案研究(四):“生物识别信息”

  8. 美国华盛顿州人脸识别服务法案中文翻译(DPO社群出品)

  9. PAI | 《理解人脸识别系统》全文翻译(DPO社群出品)

  10. 解读世界首例警方使用人脸识别技术合法性判决二审判决(DPO社群成员观点)

  11. 人脸识别技术研究综述(一):应用场景

  12. 人脸识别技术研究综述(二):技术缺陷和潜在的偏见

  13. 美国人脸识别技术的法律规范研究综述 | 拼凑式(Patchwork)的范式

  14. 美国《2020年国家生物识别信息隐私法案》中译文

  15. 人脸识别技术是潘多拉盒子还是阿拉丁神灯?

  16. 人脸识别 | “第108号公约+”咨询委员会发布《关于人脸识别的指南》(全文翻译)

  17. 人脸识别 | EDPB“关于通过视频设备处理个人数据的指南”(全文翻译)


关于欧盟技术主权相关举措的翻译和分析:

  1. 技术主权视野下的欧盟数字化转型战略探析(DPO社群出品)

  2. 欧盟委员会主席首提“技术主权”概念

  3. 推进欧洲可持续和数字化转型:《欧洲新工业战略》解读(DPO社群成员观点)

  4. 欧盟“技术主权”进展 | 德国和法国推出欧盟自主可控的Gaia-X云平台计划

  5. 欧盟“技术主权”进展 | 欧盟如何在科技领域能主导下一个十年

  6. 欧盟“技术主权”进展 | 关于数字平台监管的建议

  7. 欧盟“技术主权”进展 | 欧洲共同数据空间治理立法框架

  8. 欧盟《数字市场法》选译之一:解释性备忘录

  9. 欧盟《数字市场法》选译之二:序言和条文

  10. 欧盟《数字服务法》选译之一:解释性备忘录

  11. 欧盟《数字服务法》选译之二:序言

  12. 欧盟《数字服务法》选译之三:(实体规则方面的)条文

  13. 欧盟《数字服务法》《数字市场法》简评

  14. 欧洲法院:欧盟成员国的数据保护机构都可对Facebook提出隐私方面的诉讼

  15. 欧盟技术主权 | 《电子隐私条例》(e-Privacy Regulation)全文翻译



版权归原作者所有,如若转载,请注明出处:https://www.ciocso.com/article/604.html

发表评论

登录后才能评论
跳至工具栏