● 用户注销后信息删除
-问：平台方收到法院调取当事人信息的调查令 要求平台提供某个用户（侵犯他人名誉权的被告）的个人信息如姓名联系方式等，但是平台查询到该用户5个月前注销了账户，请问平台方可以以用户信息已注销而不提供吗？因为不提供平台会成为侵犯名誉权的责任承担主体吗？大佬们有比较合适的解决方案吗？
-答1：首先，根据《民法典》的避风港原则，平台只有在未及时删除侵权信息时，才会就扩大影响的损害部分承担连带责任。未能提供被告身份信息，仅可能触发类似“拒不配合法院调查”的行政责任。其次，需要进一步检索用户实名制保存是否存在法律法规要求的时限。
-答2：《移动互联网应用程序信息服务管理规定》（2016年版）要求：“记录用户日志信息，并保存六十日”。
-答3：《网络安全法》还要求：“按照规定留存相关的网络日志不少于六个月”。
-答4：公安部的行标《互联网交互式服务安全管理要求第1部分：基本要求》还要求注册信息永久保存。尽管行业标准是否属于法律要求还有待讨论，但是结合上述这么多法规的要求，还是需要提供的。否则可能要承担相关行政责任。
● 隐私政策修改流程
-问：隐私政策中的信息增加和内容更新，跟业务部门如何建立有效的机制？及时性和完整性怎么保障？我们会遇到业务在用某个信息，或者新增加了一个信息，写隐私政策的法务却不知道的情况。最有效的方法就是全部需求都过合规，但是合规承受不了这样的工作量。
-答1：我们是业务和IT先自己改，隐私政策，然后法律合规审，不清楚的再开会讨论。
-答2：法务合规作为安全合规需求的输入方在开发流程设计阶段卡点。
-答3：我们一般是：1.适时召开需求评审会，2.产品方案出现主动问询
3.形成在线表格，制作填写范例，周期性号召填写，4.将数据流问询内化成合规需求评审的固定流程。
-答4：我们是靠问卷，区别后续评审是人工还是自动化的。如果问卷故意选否，就是绕过，只能事后审计。如果结合KPI，会是最有效的办法，但是坑就坑在个人信息保护这个工作，谁都不愿意当牵头方。
● 地理位置算用户标签吗
-问：算法推荐管理规定的“个人特征的用户标签”怎么理解？如果给用户打一个属地标签（例如北京），这个算是其个人特征标签吗？
-答1：个性化推送里地域不属于。《个人信息安全规范》7.3 b）的注说：基于个人信息主体所选择的特定地理位置进行展示、搜索结果排序，且不因个人信息主体身份不同展示不一样的内容和搜索结果排序，则属于不针对其个人特征的选项。
-答2：仅基于地理位置的推送不认定为个性化推送，但实践中往往算法推荐是用到很多维度的数据的，选择同一地理位置的用户页面展示大概率是不同的。所以我个人认为地域信息也可能算是一种标签。
-答3：很难把地理位置排除出标签的范围，我对35273开的这些后门、例外比较警惕。
-答4：《个人信息安全规范》不是说了基于个人主体所选择的地理位置？单纯的城市标签不算特征吧，除非是城市+兴趣爱好什么的。不然像携程、大众点评这种咋做。
● SaaS服务中各方个人信息处理关系
-问：数据处理者和SaaS智能风控服务商之间的业务实质，属于委托处理还是共同处理，还是其他？我只是感觉SaaS风控服务商有可能按照自己的目的去使用数据的，不知道业内目前的实践一般是怎么认为的。而且智能风控，是不是也有算法在里面。算法肯定需要不断投喂数据来优化，感觉很难说绝对在委托处理的范畴里。
-答1：委托处理，SaaS输出你们想要的结果，但是风控具有特殊性，SaaS服务需要数据来丰富他的风控库，所以或存在暗搓搓用的可能。
-答2：一切皆有可能。
-答3：如果这家SaaS服务商 针对类似的公司和业务模式提供同样的处理方式，那他没有太多自主决定的成分，倾向于解释为委托处理，从非技术的角度去解释。
● APP马甲还能做吗
-问：如果担心APP被下架，就搞个APP的复制版本（仅仅变换名称），这样可以起到风险隔离的作用吗（若APP下架，就用复制版本继续展业）？
-答1：看下滴滴家族，那么多APP还是一网打尽了。
-答2：应用市场开始禁止APP马甲上线了。参考Google的上架检测，代码相似度高一律不过。这样逃避监管可能后果很严重的。
-答3：APP直接下架的风险系数不大，注意一下基本不会被下架，而且政府也要考虑对社会影响。
-答4：可以考虑做一个功能简化的APP，只提供基本功能。
-答5：早期可以靠马甲躲猫猫，监管机构（的支撑单位）按行业分类、下载量排序，一波拉500个检测。如果马甲下载量较小，可能不在前几批检查名单里面。
-答6：这个还有很多弊端问题。你这种要不要做等保认证？你搞2个AOO，是不是就算两个系统，得出两份等保认证？问题是你不是不想让监管觉得是一模一样的马甲么。首先，不想让监管觉得马甲和正版是一模一样的系统。其次，又想在等保等认证上面，让监管认同他们是一个系统。做一次就够了。去年上半年，小程序没纳入检查范围时候，其实小程序可以完成这个功能。遗憾的是现在小程序也受监管了。
● APP收集信息的必要性如何评估
-问：工信部通报的违规收集xx信息，是指隐私政策没披露但是收集了，还是披露收集但是违反必要？如果是后者，技术又如何准确去评估这个必要性？像设备收集最小必要这些，作为不懂技术的法务，真的很难判断。我们常问的就是，没有这个信息，目的是不是不能实现。如果技术说不能，其实我们也就过了，但是可能还是面临问题。
-答1：工信部只是用检测工具发现你收集了这些设备信息。做的好点，就是自动和隐私政策做比对。看是否有超范围收集还是人工判定。这次被通报的13个，几个大厂或者商业化SDK不可能不重视超范围这么明显的问题的，结果还是被通报了。面临的问题应该是开发都无法改变的问题吧，比如说SDK超范围收集，你用了就得接受、承担风险。
-答2：靠经验评估，设计流程。
-答3：根据功能和标准产生满足最小必要收集的信息范围，根据检查对照是否超出范围，超出范围的是否政策写明。所谓的技术，从功能侧判断，技术侧合理性。
-追问：实操中难判断的是业务提出基于安全问题：以防诈骗为由，技术或者业务评估是如果采集xx信息可以提升30%安全性，这个时候作为法务我觉得合理。但是提升30%有没有必要，难判断，而且30%本身是个不准确的评估。
-答4：不得不说，这个场景很特殊，标准中最小必要仅是Mac地址和唯一设备识别码。但是风控的精准度会根据维度增加而增加，直接跟收集的信息有关。对于这点，需要参考，例如微信风控、支付宝风控的公开文档来判断是否必要。
● 什么是离线装机量统计
-问：请问离线装机量统计是什么意思？
-答1：商业化软件，根据装机量收费。有些是调用访问次数收费，比如人脸识别这种，有些是sdk嵌入app的量来收费。你说你用户群体1万人，那我就按照1万人给你license。但是后台一查，发现你mac地址50w了。那就要追加费用。
-追问：所以主要为了计费，不是为了跨平台追踪个人？那如果不用Mac地址的话，还可以用别的替代吗？
-答1：之前用IMEI就特别准，但是这两年IMEI差不多不让用了，现在只剩Mac和Android_ID。如果Mac不让用，Android_ID不让用，能用啥呢。
-答2：IMEI和Mac在高版本Android和iOS都系统限制很难收上来了，如果非跨平台的需要，有企业已经更新了自己云发码的归因，client生成随机数存储在端上。但如果基于原有device id归因进行升级，会有跳变的困扰。跨平台的外部归因感觉最近国内外都比较紧张，谷歌刚官宣的topics，和之前被诟病的floc，都是要取缔三方cookie，如果可行，估计app端也会有动作了。推荐阅读：谷歌杀死 FLoC ，官宣新系统 Topics
-答3：只要在设备取都触发系统接口调用，即使做了技术处理并不上传server，外部都可以扫到。Android13貌似对gaid这种广告id也要限制了，从苹果的ATT开始都在关注device的信息了。海外对applist自去年年中已经关注，包括android要求在manifest里要对外声明所有applist以及用途，另外一些大平台都将其也视作敏感信息。但国内可能动作还没那么大。
-答4：国内至少从去年开始应用列表，就是敏感收集行为。尽管应用列表现在不是权限，但属于收集信息。
-答5：记得是不是TAF之前连续发的团标都有特意提到过。但感觉在实践治理层面，相比ID参数采集和治理，效果和力度还没有那么高。
-追问：不可变ID的收集会对用户权益造成什么损害？推行可变ID确实有利，但是不可变ID也不应该违法对么，一定有合规收集的路径。
-答6：可被追踪、可被识别、可被定推，不符合最小必要原则？
-答7：谨慎些好的。风控这种必要用途视情况感觉还是可以商量的，比如特定类型，例如双开，影子。不可变id对用户损害，主要在不可变。无论哪个平台采集对这个id的画像或关联信息泄露后，很容易被其他平台定位关联到个人。广告的转化率和监测效果，因为涉及跨dsp，dmp，广告主和监测商，需要有跨平台id，特定业务安全场景可能用处理的不可变id，而且应该也经过必要技术处理和特定安全保护。所以撇开id而言，看起来谷歌这次topics方案，对广告行业而言颇有点干掉跨平台参数(第三方饭碗)的意思。
-追问：如果处理目的只是统计销量呢？
-答8：如果只统计销量是否可以考虑其他方式，比如生成随机数或传参等其他方式都可行，在这个统计场景用采集不可变id，难免有点感觉杀鸡用牛刀～
注：这个问题我也没太看懂，所以梳理的有点乱。
-问：平台方收到法院调取当事人信息的调查令 要求平台提供某个用户（侵犯他人名誉权的被告）的个人信息如姓名联系方式等，但是平台查询到该用户5个月前注销了账户，请问平台方可以以用户信息已注销而不提供吗？因为不提供平台会成为侵犯名誉权的责任承担主体吗？大佬们有比较合适的解决方案吗？
-答1：首先，根据《民法典》的避风港原则，平台只有在未及时删除侵权信息时，才会就扩大影响的损害部分承担连带责任。未能提供被告身份信息，仅可能触发类似“拒不配合法院调查”的行政责任。其次，需要进一步检索用户实名制保存是否存在法律法规要求的时限。
-答2：《移动互联网应用程序信息服务管理规定》（2016年版）要求：“记录用户日志信息，并保存六十日”。
-答3：《网络安全法》还要求：“按照规定留存相关的网络日志不少于六个月”。
-答4：公安部的行标《互联网交互式服务安全管理要求第1部分：基本要求》还要求注册信息永久保存。尽管行业标准是否属于法律要求还有待讨论，但是结合上述这么多法规的要求，还是需要提供的。否则可能要承担相关行政责任。
● 隐私政策修改流程
-问：隐私政策中的信息增加和内容更新，跟业务部门如何建立有效的机制？及时性和完整性怎么保障？我们会遇到业务在用某个信息，或者新增加了一个信息，写隐私政策的法务却不知道的情况。最有效的方法就是全部需求都过合规，但是合规承受不了这样的工作量。
-答1：我们是业务和IT先自己改，隐私政策，然后法律合规审，不清楚的再开会讨论。
-答2：法务合规作为安全合规需求的输入方在开发流程设计阶段卡点。
-答3：我们一般是：1.适时召开需求评审会，2.产品方案出现主动问询
3.形成在线表格，制作填写范例，周期性号召填写，4.将数据流问询内化成合规需求评审的固定流程。
-答4：我们是靠问卷，区别后续评审是人工还是自动化的。如果问卷故意选否，就是绕过，只能事后审计。如果结合KPI，会是最有效的办法，但是坑就坑在个人信息保护这个工作，谁都不愿意当牵头方。
● 地理位置算用户标签吗
-问：算法推荐管理规定的“个人特征的用户标签”怎么理解？如果给用户打一个属地标签（例如北京），这个算是其个人特征标签吗？
-答1：个性化推送里地域不属于。《个人信息安全规范》7.3 b）的注说：基于个人信息主体所选择的特定地理位置进行展示、搜索结果排序，且不因个人信息主体身份不同展示不一样的内容和搜索结果排序，则属于不针对其个人特征的选项。
-答2：仅基于地理位置的推送不认定为个性化推送，但实践中往往算法推荐是用到很多维度的数据的，选择同一地理位置的用户页面展示大概率是不同的。所以我个人认为地域信息也可能算是一种标签。
-答3：很难把地理位置排除出标签的范围，我对35273开的这些后门、例外比较警惕。
-答4：《个人信息安全规范》不是说了基于个人主体所选择的地理位置？单纯的城市标签不算特征吧，除非是城市+兴趣爱好什么的。不然像携程、大众点评这种咋做。
● SaaS服务中各方个人信息处理关系
-问：数据处理者和SaaS智能风控服务商之间的业务实质，属于委托处理还是共同处理，还是其他？我只是感觉SaaS风控服务商有可能按照自己的目的去使用数据的，不知道业内目前的实践一般是怎么认为的。而且智能风控，是不是也有算法在里面。算法肯定需要不断投喂数据来优化，感觉很难说绝对在委托处理的范畴里。
-答1：委托处理，SaaS输出你们想要的结果，但是风控具有特殊性，SaaS服务需要数据来丰富他的风控库，所以或存在暗搓搓用的可能。
-答2：一切皆有可能。
-答3：如果这家SaaS服务商 针对类似的公司和业务模式提供同样的处理方式，那他没有太多自主决定的成分，倾向于解释为委托处理，从非技术的角度去解释。
● APP马甲还能做吗
-问：如果担心APP被下架，就搞个APP的复制版本（仅仅变换名称），这样可以起到风险隔离的作用吗（若APP下架，就用复制版本继续展业）？
-答1：看下滴滴家族，那么多APP还是一网打尽了。
-答2：应用市场开始禁止APP马甲上线了。参考Google的上架检测，代码相似度高一律不过。这样逃避监管可能后果很严重的。
-答3：APP直接下架的风险系数不大，注意一下基本不会被下架，而且政府也要考虑对社会影响。
-答4：可以考虑做一个功能简化的APP，只提供基本功能。
-答5：早期可以靠马甲躲猫猫，监管机构（的支撑单位）按行业分类、下载量排序，一波拉500个检测。如果马甲下载量较小，可能不在前几批检查名单里面。
-答6：这个还有很多弊端问题。你这种要不要做等保认证？你搞2个AOO，是不是就算两个系统，得出两份等保认证？问题是你不是不想让监管觉得是一模一样的马甲么。首先，不想让监管觉得马甲和正版是一模一样的系统。其次，又想在等保等认证上面，让监管认同他们是一个系统。做一次就够了。去年上半年，小程序没纳入检查范围时候，其实小程序可以完成这个功能。遗憾的是现在小程序也受监管了。
● APP收集信息的必要性如何评估
-问：工信部通报的违规收集xx信息，是指隐私政策没披露但是收集了，还是披露收集但是违反必要？如果是后者，技术又如何准确去评估这个必要性？像设备收集最小必要这些，作为不懂技术的法务，真的很难判断。我们常问的就是，没有这个信息，目的是不是不能实现。如果技术说不能，其实我们也就过了，但是可能还是面临问题。
-答1：工信部只是用检测工具发现你收集了这些设备信息。做的好点，就是自动和隐私政策做比对。看是否有超范围收集还是人工判定。这次被通报的13个，几个大厂或者商业化SDK不可能不重视超范围这么明显的问题的，结果还是被通报了。面临的问题应该是开发都无法改变的问题吧，比如说SDK超范围收集，你用了就得接受、承担风险。
-答2：靠经验评估，设计流程。
-答3：根据功能和标准产生满足最小必要收集的信息范围，根据检查对照是否超出范围，超出范围的是否政策写明。所谓的技术，从功能侧判断，技术侧合理性。
-追问：实操中难判断的是业务提出基于安全问题：以防诈骗为由，技术或者业务评估是如果采集xx信息可以提升30%安全性，这个时候作为法务我觉得合理。但是提升30%有没有必要，难判断，而且30%本身是个不准确的评估。
-答4：不得不说，这个场景很特殊，标准中最小必要仅是Mac地址和唯一设备识别码。但是风控的精准度会根据维度增加而增加，直接跟收集的信息有关。对于这点，需要参考，例如微信风控、支付宝风控的公开文档来判断是否必要。
● 什么是离线装机量统计
-问：请问离线装机量统计是什么意思？
-答1：商业化软件，根据装机量收费。有些是调用访问次数收费，比如人脸识别这种，有些是sdk嵌入app的量来收费。你说你用户群体1万人，那我就按照1万人给你license。但是后台一查，发现你mac地址50w了。那就要追加费用。
-追问：所以主要为了计费，不是为了跨平台追踪个人？那如果不用Mac地址的话，还可以用别的替代吗？
-答1：之前用IMEI就特别准，但是这两年IMEI差不多不让用了，现在只剩Mac和Android_ID。如果Mac不让用，Android_ID不让用，能用啥呢。
-答2：IMEI和Mac在高版本Android和iOS都系统限制很难收上来了，如果非跨平台的需要，有企业已经更新了自己云发码的归因，client生成随机数存储在端上。但如果基于原有device id归因进行升级，会有跳变的困扰。跨平台的外部归因感觉最近国内外都比较紧张，谷歌刚官宣的topics，和之前被诟病的floc，都是要取缔三方cookie，如果可行，估计app端也会有动作了。推荐阅读：谷歌杀死 FLoC ，官宣新系统 Topics
-答3：只要在设备取都触发系统接口调用，即使做了技术处理并不上传server，外部都可以扫到。Android13貌似对gaid这种广告id也要限制了，从苹果的ATT开始都在关注device的信息了。海外对applist自去年年中已经关注，包括android要求在manifest里要对外声明所有applist以及用途，另外一些大平台都将其也视作敏感信息。但国内可能动作还没那么大。
-答4：国内至少从去年开始应用列表，就是敏感收集行为。尽管应用列表现在不是权限，但属于收集信息。
-答5：记得是不是TAF之前连续发的团标都有特意提到过。但感觉在实践治理层面，相比ID参数采集和治理，效果和力度还没有那么高。
-追问：不可变ID的收集会对用户权益造成什么损害？推行可变ID确实有利，但是不可变ID也不应该违法对么，一定有合规收集的路径。
-答6：可被追踪、可被识别、可被定推，不符合最小必要原则？
-答7：谨慎些好的。风控这种必要用途视情况感觉还是可以商量的，比如特定类型，例如双开，影子。不可变id对用户损害，主要在不可变。无论哪个平台采集对这个id的画像或关联信息泄露后，很容易被其他平台定位关联到个人。广告的转化率和监测效果，因为涉及跨dsp，dmp，广告主和监测商，需要有跨平台id，特定业务安全场景可能用处理的不可变id，而且应该也经过必要技术处理和特定安全保护。所以撇开id而言，看起来谷歌这次topics方案，对广告行业而言颇有点干掉跨平台参数(第三方饭碗)的意思。
-追问：如果处理目的只是统计销量呢？
-答8：如果只统计销量是否可以考虑其他方式，比如生成随机数或传参等其他方式都可行，在这个统计场景用采集不可变id，难免有点感觉杀鸡用牛刀～
注：这个问题我也没太看懂，所以梳理的有点乱。