“隐语”是开源的可信隐私计算框架，内置 MPC、TEE、同态等多种密态计算虚拟设备供灵活选择，提供丰富的联邦学习算法和差分隐私机制
开源项目
github.com/secretflow
gitee.com/secretflow
11月25日，「隐语开源社区 Meetup·西安站」顺利举办，本文为大家带来的是西安交通大学网络空间安全学院副教授、博士生导师 范铭 在本次活动中的精彩演讲回顾——《小程序中用户隐私数据合规分析》。
👉 戳我查看现场视频：直播视频
本次活动更多分享实录可点击这里查看。
我今天分享的题目是《小程序中用户隐私数据合规分析》，主要分为三个部分：
-
小程序数据合规背景
-
隐私政策内容合规检测
-
小程序行为一致性分析
小程序数据合规背景
这是去年根据小程序统计平台统计的结果，可以看到小程序全网数量已经超过了700万，手机APP全网数量只有300万，目前小程序的数量甚至已经超过了移动应用 APP ，且小程序细分的行业已经非常广泛，不管大家在用微信、支付宝、淘宝还是抖音，其实中间都会涉及到小程序的应用。微信小程序的日活量也高达4亿多。可见，现在我们的衣食住行都会涉及到小程序的应用。
统计数据来源：阿拉丁小程序统计平台
我们认为小程序将会成为中国移动互联网新的基建，也是数字化经济蓬勃发展的基础条件。参考小黄车的小程序版本和移动应用版本，从功能上来讲，小程序的功能和移动应用的功能可以说是等同的，并且相比于APP 需要下载安装，小程序实现了触手可及、无需安装的特点，基本上用完就可以直接关掉。因此，我们认为小程序从功能上是几乎可以替代手机版APP的，它是具有中国特色的中国式的操作系统。
小程序在给我们日常生活带来便捷的同时，其实也会带来一些数据隐私隐患。比如说我们平时经常外出用餐，桌上都会有一个二维码，我们需要进行扫码点餐。大家用到扫码点餐的时候会发现它需要进行相关的关注或者授权，授权会获取我们的手机号码、昵称和额外信息。相关媒体也指出了扫码点餐现存的一些问题，虽然扫码对商家、用户能产生便利，但是我们牺牲的是个人信息。
深圳市消委会做了一个志愿者调查，用户在扫码的时候要填的一些信息，如生日、手机号码、职业等等，这个数据相对来说是很隐私的。深圳消委会的调查结果显示，260个商家中有97%的商家进行强制性扫码，98.5%强制性进行关注授权。900多名消费者在问卷当中指出，他们中的95%是需要进行会员注册，并且97%是非常介意信息收集的。那么问题就出现了，为什么我们点餐必须要提供个人信息？商家是否有权利来利用点餐收集我们的个人信息？以及我们的个人信息被收集后会如何使用，是否会被泄露？
早期移动应用隐私治理工作主要以 APP 为主，小程序相关配套的法律法规比较少，一些小程序应用治理是参考 APP 的治理条例。
随着移动应用隐私安全治理工作地不断推进，小程序的领域逐渐从依赖和参照APP违规治理条例，发展为进一步完善细化和引导当前的治理工作。比如说2022年修订移动互联网应用程序信息服务管理规定，完善分发平台的规章制度。今年2月份有关于进一步提升移动互联网应用能力的通知，要细化分发平台管理责任。近两年各个省市逐渐开展关于小程序个人信息专项治理行动，有一些相关的应用会被通报批评。
我们团队早在2021年已经对这块做了一些相关的分析，对7个平台6000多个小程序围绕隐私政策及代码安全，展开半自动化分析的工作，发现99%的小程序都存在一些隐私安全的问题，没有问题的仅仅只有5%。这些问题多种多样，比如说像隐私政策白屏，链接指向错误，申请授权未告知目的，存在一些跨境传输风险等等。
隐私政策内容合规检测
大家在使用小程序的时候都会遇到隐私政策的问题，在使用时会弹出一个对话框，我们需要同意这个隐私政策。这个隐私政策其实是一个文本，它的作用相当于开发者告诉用户这个应用会做哪些事情，会收集哪些信息，这些信息会被用来干什么。它的相关描述是需要遵循现有的一些相关规定的。
我们的隐私政策会去描述收集信息的方式、类型，用户如何访问处理，以及运营者该如何保护信息等等。一篇完整的隐私政策包含了非常多的内容，但是现在隐私政策的撰写，比如一些小的开发者对这块并不是足够关注，其隐私撰写就相对来说比较模糊。随着个保法和其他一些相关法规的推出，它对个人的一些信息应该遵守公开透明原则，以及要明示处理的目的、方式和范围，对隐私政策做出了一些明确的规定。
我们发现现在隐私政策多多少少存在一些维护问题，比如说会收集一些敏感信息，例如地理位置、相册等，但并不会去将收集的信息一一进行描述，而会用一些模糊的词语进行概述。以及可能包括描述语，这相当于打了一个擦边球。除此之外，现有的法律法规要求的力度也不太一样，因此对我们做分析会造成一定的困难。
我们对这类隐私政策内容进行合规监测。对于文本的爬取和标注，我们需要获取小程序应用对对应隐私政策的描述。因为它是一个文本描述，我们后续会采用单元处理的方式进行它的政策合规检测。
在文本爬取这一块，现在隐私政策的方式比较多，除了在应用商店，大部分是APP，会附带隐私政策的单独链接。除此之外，在程序运行过程中会弹出对话框或者弹出一个链接，这里面我们会采取不同的爬取方式来获取它对应的隐私政策。
在获取隐私政策过后，我们发现这个隐私政策的文本描述是非常长而且对我们普通人而言是比较难读懂的。因此我们需要去自动化的将这个隐私政策的语义做一个解析。我们需要对这个隐私政策当中的语句到底具体描述什么内容做一个具体的标注，我们构建了这样一个文本的标注系统，相当于给这个文本打上它对应的标签。
我们定义了27个法规所要求的必要标签，并且将这个必要标签出现的比例作为隐私政策完整性的评估指标，以及目的完整性，我们对单个语句做语法分析，或者他的主谓宾，最后通过字典来匹配它的类型、操作目的要素值，看看它的描述是否是完整的。
这里面我们归纳了5种模糊性表述模式，我们会视情况而定来收集信息，还有不确定的描述，设计了5种模糊的匹配规则。
最后，我们在这块做了一些实证研究，会涉及到多边集分类，这个结果是我们标注的数据集上能够实现94%以上的文本识别精度。
我们对三类应用的1200份隐私展开了具体的分析，存在内容缺失的有950篇，占比达到79%。并且不同类的隐私缺失的标签非常集中，主要是对第三方共享和数据安全等相关描述的缺失，也就是说他在隐私政策当中并没有描述他的数据是否会和第三方进行共享，以及他是否采取一定必要的措施来保护他的数据安全。
最后针对模式这部分，400份样本当中，存在目的缺失有250多篇，仅仅描述会收集你这些数据，并没有详细说收集这些数据是干什么的，这其实和我们法规当中最小必要收集相关原则是违背的。
关于模糊项描述，存在模糊表述的隐私权声明占比是94%，也就是说明现在的隐私政策表述存在着比较严重的不清晰的问题。根据我们之前的一些工作，比如微信，因为微信的小程序体量比较大，之前我们分析的大部分样本当中根本就没有隐私政策描述的，但是在今年加强了这一块的管控，强制要求开发者要提供这一项政策。
小程序行为一致性分析
隐私政策是去描述我这个应用程序不会干什么事情，但是这个描述和他具体自己真正干了什么事情会存在不一致的情况。比如图中这样一个小程序，他是点击这个按钮，会弹出地图收集用户的位置信息。隐私政策当中只声明了收集用户的手机号码、银行卡号，第三方用户账号，并没有描述位置信息，因此二者会存在不一致的行为，也就是说实际做的事情比声明的事情要多。
图示隐私政策就是用文本分析的技术分析，左边是代码行为这一块，这里边用到的是程序分析的技术，也就是说我们会去分析这个代码当中的数据传输行为，也就是从 API 获取我的地理位置之后，这个数据到底在你的代码当中是怎么去流转的，以及他最终是否会通过网络形式发送出去。
目前的现状存在的难点问题是小程序和安卓是不一样的，主要采取 JavaScript 的动态编程语言所编写的，这种语言的差异以及不同平台的小程序会有自己的特性，这就会导致我们现在没有一个针对小程序非常好用的数据流分析的工具，这个数据流分析的工具实际上就是我们刚才提到的分析一个数据，在程序代码当中的流转过程，
我们的整体方法包含三大块，一是污点分析，在代码当中数据分析的过程。下面实体抽取是之前刚才提到的文本分析，最后会做一致性比较。
首先在数据流分析这一块，我们会根据污点源头的不同可以分为同步型 API、异步 API 及 UI 事件，根据数据传播规则，可以分为过程内数据流、过程间数据流和跨文件过程间数据流，编程有很多数据查询形式，数据有时候查询在实际执行的时候才知道数据到底传向哪，我们通过静态分析将他潜在的可能传播的路径都给找出来。
基于抽样语法树的污点分析，先构建抽样语法树，定位关键实体，构建数据之间的依赖关系，定位我们污点源和汇聚点，进行数据流搜索。大家在写代码过程当中会经常碰到，比如我一开始定义了一个数据，在数据定义之后，数据会存在复制传递，以及函数调用等等这样一些行为，这些行为就会导致我的数据在代码当中会有一些这样的传播过程，整个流程就是去找这个数据在代码当中的流转。
前面我们针对隐私政策去分析这个隐私政策当中描述的信息收集的一些实体，通过前面训练好的模型会识别到数据收集相关的语句，在语句当中识别出来他会收集哪些信息，并且哪些信息会被发送出去。
这里面涉及到一些相关的 Source APIs、SinkAPIS，Source API 就是我们常规获取数据的关键敏感 API。SinkAPIS 就是数据会发送出去的一些目的 API。
因为语言的描述是多样化的，因此我们会构造一些字典将他的描述进行对齐。
最后我们会将这个不一致行为分为强不一致和弱不一致。强不一致是指数据类型已经存在不匹配。我实际收集了 A 数据，你的描述当中没有 A 数据。而这个弱不一致是指，我仅仅是收集但是没有用，这是在数据类型是匹配的，但是数据操作是不匹配的。根据两个集合的关系，我们分成了五种情况。
我们在实验当中，在数据流分析这一块提出一个新的数据流的分析方法，选择了14个小程序，人工标了1000多条的数据流，方法的准确率为83.9%，中间会存在一些断裂的情况，造成断裂情况比如说嵌套函数、指针动态地址等等，这些如果感兴趣的话可以去深入研究一下。
在实体对齐这一块，这个用的是传统的分类方法，准确率可以达到98%以及88%，这一套目前随着大模型的推出，我们希望用大模型做隐私政策的具体的语义分析。
在真实环境当中不一致的情况，我们先爬了1万个小程序，发现其中只有2996个是包含隐私政策的，其他是没有的。在2996个当中有2680个都存在不一致的现象，占比89.4%，这种不一致的问题主要集中在位置信息、登录信息还有相机、相册这几个主要数据类型上。
最后我们把不一致性的情况存在的原因做了归纳总结，主要包含三类。一是代码开发者和隐私政策的撰写者两个不是同一波人，也就是说我在写隐私政策的人对代码当中具体的功能和行为并不是非常清楚，因此他的描述会相对比较模糊一些。二是同质化模板，现在很多小程序的功能是非常相近的，都是套用了同一个模板，隐私政策也会有一个同质化的模板，没有去针对具体应用功能做定制化的撰写。三是实际上是拷贝了同名 APP 的隐私政策文档，并没有进行相应的调整，APP 和其对应版本的小程序在数据收集的时候会存在一些差异，这也会导致他不存在不一致情况的原因。
总体而言，首先，个人开发者缺少足够的隐私政策撰写的经验，目前也有一些相关的研究给定一个应用怎么去自动化地生成他的这个对应符合国家标准的隐私政策。第二，小程序会拷贝造成失配现象，也是我在最后面提到的原因。
🌟 关注「隐语Secretflow」B 站， 获取更多演讲回顾及相关资讯。
🏠 隐语社区：
github.com/secretflow
gitee.com/secretflow
www.secretflow.org.cn （官网）
👇 欢迎关注：
公众号：隐语小剧场
B站：隐语secretflow 文章来源：https://www.toymoban.com/news/detail-774614.html
邮箱：secretflow-contact@service.alipay.com文章来源地址https://www.toymoban.com/news/detail-774614.html
到了这里，关于技术探索｜范铭：小程序中用户隐私数据合规分析的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
