隐私政策简版和摘要的区别

数据合规是一个比较新的领域，很多问题都难以通过公开渠道检索到答案。比如，某个特定的场景抄哪家大厂的作业比较合适。此时，实务人士间的思想碰撞、交流就显得尤为珍贵。
由此，我建立了一个小规模的社群，和朋友们讨论数据合规相关的问题。我相信其中的部分讨论是兼具共性和分享价值的。初步计划每周一次，对群聊内容以问答的形式进行梳理、共享。希望对你有所帮助。
• CONTENT •
「个人信息影响评估公示」
「消费侧和供给侧用户个人信息区别」
「离职证明内容」
「匿名化定义的比较研究」
「用户如何行使删除权」
「哈希算法是加密算法吗」
「车联网数据和智能网联汽车数据区别」
「小程序域名」
「背景调查的单独同意」
「隐私政策的简版和摘要区别」
「购买保险受益人告知同意」
「敏感个人信息的认定」
「删除和匿名化的关系」
「SDK的披露」
个人信息保护影响评估公示
-问：目前有企业公开过个人信息保护影响评估的报告吗？我看《信息安全技术个人信息安全规范》(GB/T 35273-2020)是要求以“适宜的形式对外公开“，同时《个人信息安全影响评估指南》（GB/T 39335-2020）也把报告的发布作为评估流程的一环。个保法规定写到社会责任报告中。
-答1：度小满发布2021社会责任报告：累计服务超过1200万小微企业主及工商个体户。ESG报告里可能也有。
-答2：个保法生效时间太短了，不如看看域外有没有DPIA公示的。
消费侧和供给侧用户个人信息区别
-问：《常见类型移动互联网应用程序必要个人信息范围规定》第三条规定：本规定所称必要个人信息，是指保障APP基本功能服务正常运行所必需的个人信息，缺少该信息APP即无法实现基本功能服务。具体是指消费侧用户个人信息，不包括服务供给侧用户个人信息。想请教下这里消费侧个人信息和服务供给侧个人信息的区别。
-答1：滴滴司机和乘客的个人信息，实际不用看，检测机构不区分。
-答2：可以参考一下这个回答，如何理解规定第三条“具体是指消费侧用户个人信息，不包括服务供给侧用户个人信息。”
离职证明内容
-问：离职证明上离职原音写了非必备的条款，甚至包含个人隐私信息，一般从法律判决来说 有的法院判决认为即使写了非必备条款，但是如果离职原因是客观的，有的法院也是支持的，但是有的法院不支持，原因在于可能影响员工就业，对于这种情况，如果从隐私保护的角度来说是不是也可以援引个保法的相关规定进行抗辩？
-答1：目前有关于离职证明上的必备信息和非必备信息的法规吗？目前印象中是没有的。个人认为企业客观陈述离职理由，不能以涉及隐私而拒绝企业的客观陈述。这个问题需要个案分析，看企业具体写了什么？
-答2：根据《中华人民共和国劳动合同法实施条例》第24条规定：用人单位出具的解除、终止劳动合同的证明，应当写明劳动合同期限、解除或者终止劳动合同的日期、工作岗位、在本单位的工作年限。我的理解《劳动合同法》和《个保法位》阶都一样。从这来看的话，如果离职证明写了非必备条款且包含个人信息的披露是不合规的。
-答3：要结合具体写了什么呀，客观陈述离职理由，并非不可。离职证明的使用范围是有限的，企业并未向第三方披露，是交给员工本人使用，个人认为很难援引向因第三方披露而需要获取员工本人同意方可填写。
匿名化定义的比较研究
-问：新加坡出了一个《基础匿名化指南》，提出了数据匿名化五步指引。那么新加坡关于匿名化的定义与我国一致吗？若是，则非常有参考意义。
-答1：之前英国的ICO也出了匿名化介绍的草案（Introduction to anonymisation, May 2021）
-答2：回看了一下，个人觉得新加坡对匿名化定义和中国基本类似。去标识化虽比较直接的描述成 the removal of direct identifiers，最终效果也和中国相近的。可以看看这篇文章，是一个系都挺好的。数据脱敏：不同法域下匿名化、去标识化、假名化的含义一致吗
用户如何行使删除权
-问：我报名某个讲座，并说明“请确保本人个人信息仅用于本次讲座报名，讲座结束后请及时删除”。客服回复我：“注册信息是没有办法删除的。”这个合规吗？
-答1：注册信息根据公安部行标标《互联网交互式服务安全管理要求第1部分：基本要求》需要永久保存。

-答2：客服：“删除？注册信息没法删除”，可能有以下原因：
（1）搪塞用户（考虑留存率及后续营销、 BD需要）；
（2）从来没人提过删除，第一次遇到呢，不好意思，不想搞；
（3）有各种法规要求“XX日志不少于六个月”呢，所以不能删您的注册信息呢
事实上，日志只是一个很基础的信息，即“某年某月某日几点几分几秒哪个用户做了一个什么事情（如注册了账号），这个日志信息只是记录了这么个事情，日志信息不能等同于具体的用户注册信息。日志信息更加笼统，通常没有注册信息那么详细的字段。因此，这种情况也是不太站得住脚的。因为，一线客服不太可能有这种专业知识，并且这种解释不一定能支撑这种业务场景。从截图内容看，像是在线研讨会之类的活动，非金融交易，不像是反欺诈/反薅羊毛之类的需求，留存用户注册信息的业务必要性不是那么明显。退一步讲，即便要留存，是否也有必要向用户详细说明一下原因，并保证虽不能删除，但至少保证停止处理。
虽然，公安部有个行标《互联网交互式服务安全管理要求第1部分：基本要求》要求注册信息永久保存。但：
（1）从效力上讲，显然行标的效力显然不如《个保法》，甚至比35273这种推荐性标准还要弱一些，更别提强制性标准。
（2）截图这个场景，而很可能是用一个普通的在线表单登记参加活动人员的场景。虽然也用了个系统（姑且算是互联网交互式服务），但这个系统肯定不如那些具有“舆论属性和社会动员能力”的系统那么重要。若用户较真起来，我不认为该平台有多少胜算。因此，这个行标是否适用于这个系统以及效力几何可能还是个问号。
-答3：那个标准写的是日志和用户数据，不单只是日志。网安领域效力级别和普通领域的不一样，行业标准优先国标的很常见，比如等保，有的时候团标比国标还有用。你可以在去看下法条，写的是符合国家标准的强制要求，而不是符合强制国家标准的要求。
-答4：法规标准之间掐架也是有可能的。留存有留存的理由，删除也有删除的依据，要结合具体业务场景看如何解释和运用了。
-答5：就这个case而言：（1）收集注册信息的保存时限有无明确要求，我理解这是提及47条需要的一个前提；（2）客服话术而言，要他穷尽各项信息如何处理不现实，最多只能做到哪些信息是固定要求的进行回答；（3）其他信息可能需要法务合规给出专门指导意见，这样感觉每次企业做一个无论大小的可能收集个人信息的活动，都需要提前做好预案；（4）参考隐私政策里面15个工作日的回复要求，这些应对客户提出要求的内容都需要提前做出预案呀，否则根本来不及。当然我觉得这些可能也是做几次之后就会形成固定模式能应付大多数场景了。
-答5：昨天那个场景如果是在类似问卷星或者其他h5页面填写个人信息的话，严格来说可能都不算是注册（个人理解），应该只是简单的留资。
哈希算法是加密算法吗
-问：哈希算法是加密算法吗？
-答1：哈希其实算加密算法的。只不过没法解密。彩虹表攻击可以用来爆破。MD5算法因为天然缺陷，沦陷了，网安等各类监管或者评测认证都不认可MD5算法。现在都是用SHA256摘要算法。但是我们基本上也会加个salt盐值，否则还是容易被匹配。salt可以理解为密钥。这样的好处是大家尽管都用sha256摘要算法，但是因为各自salt不同，哪怕原值一样，算出的hash值也不一样。
-答2：哈希（散列）和加密都是算法，都不都是加密算法。暴力破解不等于密码学意义上的解密。详见：https://zhuanlan.zhihu.com/p/20064358
关于加盐哈希，可以看看这篇：https://www.cnblogs.com/makai/p/11130703.html
-答3：要用通用的彩虹表来破解哈希前的明文，随着哈希算法迭代，成本是非常高的，基本不太可行。但在特定环境下，彩虹表还是比较好用。例如我知道这一批是对手机号的哈希，且没有加盐哈希，那不管用什么哈希算法。先遍历一遍所有的手机号用同样的哈希算法计算下，用这个生成的数据库反查原始的明文手机号。因为原始数据集不是很大，这个数据库生成时间就比较能接受了。
-答4：虽然彩虹表攻击和暴力破解有些类似，但我认为二者还是有些区别，不能将彩虹表完全等同于暴力破解。
暴力破解：可简单理解为“猜密码（口令）”，例如，登录某系统时，已知（假设）用户名为admin，不知口令的情况下，将各种可能的口令输入进行尝试（可利用一些相关的信息经各种组合、处理，构造成一个字典），直至尝试成功。当然，通常系统会加上验证码、账号锁定等风控机制。（当然，也有一些能绕过一般验证码的技术，攻防较量）
彩虹表攻击：先将各种有可能的信息拿到，然后用某哈希算法全部计算一遍得出一堆对应的哈希值（彩虹表）。然后，再用彩虹表中的哈希值逐一去目标中尝试，若命中，则反查彩虹表中对应的原始值。如果考虑“哈希碰撞”的话，那么即便是哈希值查到了，原始值也不一定对得上号哦，虽然这种概率非常低（即A和B用同样的哈希算法运算后的结果竟然是一样的）。
详见：https://www.cnblogs.com/lsdb/p/10038835.html

这张图特别好
车联网数据和智能网联汽车数据区别
-问：请教一下各位，车联网数据和智能网联汽车数据之间，是否可以等同，争议点主要是车联网数据是否包含车辆本身的数据呢？
-答1：可以参考中伦这篇文章：车联网行，数据先行——车联网背景下汽车产业的数据安全合规。以此为指引查看相关规定和标准可对车企数据有个系统了解。
-答2：这两个不等同的，算得上目前两个主流。如果只考虑车，那就主要看单车智能，与外界的交互传输少一点。如果是车联网，那就是车的物联网，简称V2X，车要和其他车，道路等等东西交互。有的东西光在车上就能处理，就不用联网了，有个标准就是你采集的数据尽量在车端完成，往外传也尽量在车端就脱敏。
-答3：两个数据的概念目前确实是不等同的，但是实操过程中，部分数据会兼而属之，数据关系有点像，两个交集的圆，但也不是绝对的，要看车联网的业务状态，毕竟现在技术还在发展，不同的车辆网应用的变化也会导致数据边界的变化，是流动的状态，至于车辆本身的数据是否属于车辆网数据，工信部的标准里其实开了口子，做了车辆基础属性数据的分类，但是个人认为并不意味着车辆网数据一定包括汽车基础数据，只是可以包括，关键还是要看业务样态，后面的监管划分的边界也会有影响，只是目前监管不严，个人意见供参考。
-答4：工信部发过一个《关于加强车联网（智能网联汽车）网络安全工作的通知（征求意见稿）》，这里的将这两个产业概念等同了，但划分比较明确的区分了有关车联网运营企业、智能网联汽车生产企业两种企业类型。
《国家车联网产业标准体系建设指南(总体要求)》中概念：车联网产业是依托信息通信技术，通过车内、车与车、 车与路、车与人、车与服务平台的全方位连接和数据交互， 提供综合信息服务，形成汽车、电子、信息通信、道路交通 运输等行业深度融合的新型产业形态。
《国家车联网产业标准体系建设指南（智能网联汽车）》中概念：根据《智能网联汽车技术路线图》，智能网联汽车可分为智能化与网联化两个层面;智能网联汽车通过智 能化与网联化两条技术路径协同实现“信息感知”和“决策控制” 功能。“智能化+网联化”相融合可以 使车辆在自身传感器直接探测的基础上，通过与外部节点的信息 交互，实现更加全面的环境感知，从而更好地支持车辆进行决策 和控制。
《智能网联汽车数据格式与定义》
4.1 智能网联汽车 intelligent connected vehicle;ICV
智能网联汽车是指搭载先进的车载传感器、控制器、执行器等装置，并融合现代通信与网络技术， 实现车与x(人、车、路、云端等)智能信息交换、共享，具备复杂环境感知、智能决策、协同控制等 功能，可实现安全、高效、舒适、节能行驶，并最终可实现替代人来操作的新一代汽车。
概念的包含关系并不明确，一些不权威的图例显示两者本身是交叉关系，但官方报道中一般智能网联汽车同时包含了智能化（一般是本地决策）和网联化（信息交互，可以理解这是车联网的重点倾向），工信部指南中车联网又是一个更上位的概念，双方确实是存在一些交叉点，但狭义上看，车联网本身更多聚焦于数据交互，因此如果按此划分，车辆的最基础信息，如车架号等可以从中划出。
其实一开始我探讨的就是 汽车的基础数据（发动机号、车架号）等能否划入车联网数据中来，现在看来确实是有交叉的。
小程序域名
-问：我来问个技术问题，小程序的域名是不是都是公司其他网站的子域名呀？
-答1：业务域名可以看这个链接：https://developers.weixin.qq.com/miniprogram/dev/framework/ability/domain.html
-答2：还可以参考这个信息：https://developers.weixin.qq.com/miniprogram/dev/framework/ability/network.html
背景调查的单独同意
-问：企业为原来员工接受背调公司的背景调查，是否需要要求背调公司提供员工背景调查的授权书，但是如果都审查，首先背调公司可能也不会提供，另外一般电话问询的比较多，也会影响效率。一般背调公司都会和员工签署一份授权书，员工授权背调公司去原单位调查她，但是我们作为原单位，如何审查背调公司是不是获取了员工的授权呢？
-答1：员工授权背调的时候会清楚填写，是否提供原公司联系方式（可以不提供），是否同意联系原公司（可以不同意），个人认为如果员工本人不同意与原单位联系，背调公司不能联系。原公司接到背调要求，没有义务提供员工信息，如果决定提供员工信息，应当核实员工的授权。授权核实方式，员工本人邮件、电话、短信确认都可以。
-答3：ISO 27002里有对员工背景调查的要求。

不过ISO 27002仅作为ISMS落地的参考。里面的控制措施能全部做到最好，如果不能全部cover也不用强求的。
隐私政策的简版和摘要区别
-问：隐私政策的简版和摘要是一个东西吗？如果不是，有哪个app可以直观感受一下吗。
-答1：不是一个东西，分别来源于《个人信息安全规范》和“524行动”。

35273

524
-答2：如果要看样例，可以看看抖音。

概要

简明版
购买保险受益人告知同意
-问：涉及保险行业，在投保场景下，因投保人可能与受益人不一致，都是投保人实施投保操作，若涉及被保险人、受益人的医疗健康信息使用处理的知情同意，是否需要被保险人、受益人另行单独同意？
-答1：14岁以下未成年人，监护人买不要。其他情况下，理论上应该要吧。具体可以看一下头部保险公司的隐私政策和实际业务流程。我觉得理论上，给配偶买保险，也是需要告知同意的吧。悄悄买了几千万的意外险，想想也挺吓人。
-答2：我记得投保的时候，受益人信息是投保人填写的，包括姓名+身份证号。所以是不是可以理解为保险机构不是直接收集受益人信息的，而是受投保人委托处理。我觉得最好得看实际的一些处罚案例。在实际执行层面，颗粒度很难把握。就像我们公司从合作伙伴拿到的信息，有两种处理方式：1.跟合作伙伴通过书面协议约定他们提供信息来源的合法性等等，有问题让合作伙伴背 2.我们按照一定比例抽查，看看他们提供的信息 在获取时是否基于知情同意原则，不过这个比例实际很难把握。
-答3：这个属于个人处理家庭事务豁免《个保法》适用吗。
-答4：保险业协会公众号可以查询自己名下所有保险保单，极少数因一些原因可能查不到或信息滞后。
-答5：公司投团体险，是会获得被保险人（员工）的单独同意。其他场景（夫妻这种），还没经历过。
-答6：问了一下保险销售的一线人员，一年期以上的长期保险，被保险人如果是成年人，必需要本人同意，需要现场来签字。这是银保监最近的规定。否则合同无法生效。
-答7：对于投保人与受益人不一致的情形，强行做成线上征求受益人同意的话，估计不太好实现（未成人由监护人cover即可）。就算个保法出台了，法不责众，估计也没谁盯着这个事情处罚了。一般来说，受益人如果不是投保人自己，那也只会是子女、配偶、父母，投保（填写、提供受益人相关个人信息）之前算是征求同意了（当然也有背着家人直接给他们买保险的情况，相对较少，未成年人监护人cover，略）。
敏感个人信息的认定
-问：有没有大佬研究过《网络安全标准实践指南网络数据分类分级指引》发布后，这个指引关于敏感个人信息的范围界定比35273列举的范围窄一些，是不是意味着有些字段可以不用按照敏感个人信息来管理了？比如35273中交易和消费记录属于敏感，按照新的指南就不属于。

网络数据分类分级指引

-答1：TC260的这个，算是国标吗，效力层级如何？我觉得是不是还要回归个保法定义。
-答2：以个保法为准，如果能证明一旦泄露或者非法使用，不容易导致自然人的人格尊严受到侵害或者人身、财产安全受到危害，那就不是敏感个人信息。
-答3：看来除了个保法明确的“生物识别、宗教信仰、特定身份、医疗健康、金融账户、行踪轨迹等信息”，其他还是要自己去评判，监管最终有裁量权。
-答4：按照人行的行业标准，交易记录可能算C2。

如果仅从定义出发，个保法草案里面“敏感个人信息”是可能造成“严重危害”才敏感，但正式稿把“严重”删去了。C2是可能泄露造成一定危害的个人信息，我认为理论上属于敏感个人信息。但如果落到实处，合规义务就非常重了。
删除和匿名化的关系
-问：删除包括匿名化措施吗？
-答1：35273里 就是写匿名化或删除，我觉得是并列的。只是匿名化处理后就不是个人信息的了。
-答2：但是技术上完全的匿名化是做不到的，所以还不如直接删除。
-答3：如果理论上可以匿名化，匿名化之后不是个人信息了，履行了删除义务。
SDK的披露
-问：想让一个懂法律的技术大佬给我这个小白科普一下：
1、SDK的隐私说明是只针对客户端，还是也包含服务端的（我的理解是，只要你处理了个人信息，就要罗列，跟客户端、服务端没有关系，虽然我没理解客户端服务端的区别）？
2、SDK接入的罗列，这里的SDK仅限客户端，还是包含了服务端？
-答1：APK接了SDK就披露，不管是否本地部署，披露以APK的维度来看。
-答2：个人理解。
（1）Client SDK是嵌入到APP，提供直接采集用户/用户设备信息的功能。同时，第三方SDP嵌入APP，可以实现直接从用户设备采集信息后，不经过APP自己的Server端，直接传到这个第三方公司的环境。这类SDK于数据更多在于采集意义；
（2）Server SDK一般是在企业在后端代码上集成一些开源或者商用的SDK，可能用以B2B之间直接的数据传输，也可能用作功能性用途。但较少情况是用以让APP直接从用户(数据主体)获取信息。这类SDK于数据更多在于共享/传输意义。
双清单要求，“清晰列出APP（包括内嵌第三方软件工具开发包SDK）已经收集到的用户个人信息基本情况”，看其目的是为理清APP自身和其三方采集了用户哪些信息，理解初衷偏向于前者。同时，APP的外部技术检测，是针对Client端SDK的扫描。
然后，可以建议让技术部门都理一下并分类下用途。可能Server端的SDK量会极多，甚至多出Client的数十倍的情况。最后结合实际用途，也能有助于合规判断，是不是应该披露的了。
-追问：堆栈呈现的SDK信息，是（1）还是（2）？
-答3：堆栈调用二者都有，是调用的动作，但部署方式是有区分的。告知方面是一样的，但建议写明是否本地化部署。