隐衷合规综合实际
目录介绍
01.整体概述介绍
- 1.1 遇到问题阐明
- 1.2 我的项目背景
- 1.3 设计指标
- 1.4 产生收益剖析
02.隐衷合规测什么
- 2.1 隐衷合规是什么
- 2.2 为何做隐衷合规
- 2.3 隐衷合规政策案例
- 2.4 为何做权限合规
04.隐衷合规检测
- 4.1 违规收集个人信息
- 4.2 超范围收集个人信息
- 4.3 违规应用个人信息
- 4.4 适度索取权限
- 4.5 自启动和关联启动
05.隐衷合规实际
- 5.1 整体合规思路
- 5.2 工具检测隐衷API
- 5.3 工具检测权限
- 5.4 敏感信息控频
- 5.5 隐衷协定申明
- 5.6 敏感权限实际
- 5.7 底层依赖库权限阐明
06.合规测试查看重点
- 6.1 合规解决优先级
- 6.2 QA测试查看重点
- 6.3 交互层面合规
- 6.4 服务端敏感收集
- 6.5 隐衷协定筛查
07.其余阐明介绍
- 7.1 参考博客链接
- 7.2 相干demo链接
01.整体概述介绍
1.1 遇到问题阐明
国内对应用程序平安隐衷问题监管变的越来越严格。各个利用市场对APP上架也有比拟严格的查看。呈现隐衷合规平安问题次要有哪些呢？
- 在用户批准隐衷协定之前，不能有收集用户隐衷数据的行为。例如，在用户批准之前不能去获取 Android ID、Device ID、MAC 等隐衷数据
- 在用户批准隐衷协定之后，收集用户隐衷数据的行为不能超出实现服务场景所必须的最低频率。例如，某些利用会在每次网络申请时将以后设施的 Android ID 作为 header 一起上报，如果没有对 Android ID 进行缓存解决的话，收集该数据的行为频率就会十分高，此时一样存在隐衷合规问题。
工信部隐衷合规阐明
- 具体能够看一下这篇文档：工信部隐衷合规文档
1.2 我的项目背景
- 最要害的问题是用户批准隐衷协定之前，不能有收集用户隐衷信息的行为，例如获取deviceId、androidId等信息，除此之外，对于频繁申请权限、超范围申请权限也是须要留神的。
- 除了开迭代针对性整改，从技术角度思考，有没有一劳永逸的方法，杜绝隐衷调用不合规问题呢？
1.3 设计指标
针对提前收集用户隐衷数据。
- 须要统计出整个我的项目中所有波及到隐衷行为的相干代码，依据业务流程来判断该隐衷行为是否正当、以及是否会在用户批准隐衷协定之前被触发。这就须要对整个我的项目进行动态扫描。
针对收集隐衷数据哪里调用。
- 须要在利用运行时动静记录每次触发隐衷行为的工夫点和调用链信息，依据触发工夫来判断该隐衷行为是否适量执行，依据调用链信息来辅助判断具体是哪一块业务在获取隐衷数据。这就须要对利用进行动静记录。
1.4 产生收益剖析
编码排查耗时大
- 如果单纯靠开发人员来肉眼辨认代码和编码统计的话，工作量十分大而且也很不事实，因为一个大型项目往往都会引入多个依赖库和第三方 SDK，能够标准自有代码，但没法批改和无效束缚内部依赖，也很难理分明依赖库的外部逻辑和调用链关系。
进步合规隐衷检测效率
- 当检测有调用隐衷数据时，在控制台打印输出提醒，给出堆栈信息让开发疾速定位调用链路；当检测到隐衷行为后，输入绝对应的记录报告，以便开发人员可能在开发阶段排查问题。
02.隐衷合规测什么
2.1 隐衷合规是什么
- 对客户端而言，权限隐衷可分为 权限 和 隐衷 两个大的方面。
权限为用户通过app内弹窗设置或者手机设置内对应app的权限设置形式给予对应app相应的权限
- 如电话权限，定位权限，相机权限，浮窗权限，读写权限等。在每个申请危险权限前，都须要弹窗阐明权限解释阐明。
隐衷为app应用过程中与用户集体相干的个人信息
- 如所在位置，Mac地址，设施id等。就Android端而言，少数隐衷信息须要对应受权后能力获取，但目前仍存在局部隐衷信息无需受权就能够拿到的。
2.2 为何做隐衷合规
- 公众隐衷意识沉睡，权限隐衷安全性差会间接导致用户不愿应用；日趋严格的权限治理和隐衷平安治理，工信部和市场的严格管控；客户端作为与用户最间接的交互信息收集入口，有任务合规化的收集和应用用户信息。
2.3 隐衷合规政策案例
隐衷合规案例
- 比方获取设施信息：获取设施id，sim，androidId等；比方获取危险权限信息：获取读写存储卡权限，获取电话权限等。
须要有文案形容
- 收集设施id，为了帮忙开发者在进行音讯推送时辨认最终用户设施，保障开发者及最终用户失常应用音讯推送服务，晋升音讯推送服务的效率以及准确率。
- 获取读写权限，帮忙开发者进行最终用户设施辨认，保障开发者及最终用户失常应用音讯推送服务，晋升音讯推送服务的效率以及准确率；更精确定位并解决产品和服务应用问题，改良及优化产品和服务体验。
2.4 为何做权限合规
首先权限合规有两大点
- 第一点：那里应用到了权限就在那里申请；第二点：应用权限的时候须要弹窗阐明该权限的用处。
列举一下我实际案例中的权限合规梳理
04.隐衷合规检测
4.1 违规收集个人信息
场景阐明：
- 未经用户批准，存在收集IMEI、设施id，设施MAC地址和软件装置列表、通讯录和短信的行为。
整改倡议：
- 隐衷政策隐衷弹窗必须应用明确的“批准\回绝”按钮；只有当用户点击“批准”后，APP和SDK能力调用零碎接口和读取收集用户的信息。
客户端如何做？
- ①用户在点击隐衷政策协定“批准”按钮前，APP和SDK不能调用零碎的敏感权限接口，特地是能获取IMEI、IMSI、MAC、IP、Android、已装置利用列表、硬件序列表、手机号码、地位等等信息的零碎接口。
- ②集成的第三方SDK倡议降级到最新版本，用户在点击隐衷政策协定“批准”按钮后，SDK再进行初始化。
- ③技术同学可在“批准”按钮上退出断定函数，当用户点击“批准”后，APP和SDK再执行调用零碎接口的相干函数行为。
4.2 超范围收集个人信息
场景阐明：
- 1.APP未见向用户告知且未经用户批准，在某性能中，存在收集通讯录、短信、通话记录、相机等信息的行为，非服务所必须且无正当利用场景，超出与收集个人信息时所宣称的目标具备间接或正当关联的范畴。
- 2.未经用户批准，SDK存在依照肯定频次读取地位信息等个人信息行为，非服务所必须且无正当利用场景，超出实现产品或服务的业务性能所必须的最低频率。
整改倡议：
- 针对1，当用户点击“批准”后，APP和SDK再执行调用零碎接口的相干函数行为。而后APP隐衷政策内须要补充收集（运行中的过程、【广点通SDK】收集IMSI）信息的规定阐明。
- 针对2，App或者Sdk收集用户信息频率超过合规范畴，尽可能保障全局只收集1次(最多不超过3次)，收集频次不要超过1次/秒。
客户端如何做？
- 举个例子，App在批准隐衷政策前，不会收集android_id。在批准隐衷政策后，有采集行为，然而4分钟采集了12次，则会认为过于频繁。
- App修复该问题，能够对立治理敏感信息采集入口，缓存敏感信息数据，能够设定缓存过期工夫(倡议设置超过5分钟)。获取android_id，缓存下来，下次调用先拿缓存，防止频繁调用零碎api。
4.3 违规应用个人信息
场景阐明：
- 1.APP未见向用户告知且未经用户批准，存在将IMEI/设施MAC地址/软件装置列表等个人信息发送给友盟/极光/个推等第三方SDK的行为。
- 2.APP未见向用户明示分享的第三方名称、目标及个人信息类型，用户批准隐衷政策后，存在将IMEI/设施MAC地址/软件装置列表等个人信息发送给友盟/极光/个推等第三方SDK的行为。
整改倡议：
- 针对1，APP和集成的SDK在用户“批准”隐衷政策，而后在调用初始化sdk操作。
- 针对2，在隐衷政策中补充第三方SDK收集（比方声网sdk收集IMSI）信息的规定阐明。
- 敏感个人信息范畴参考《信息安全技术集体信息安全标准》
4.4 适度索取权限
场景阐明：
- 1.APP首次启动时，向用户索取电话、通讯录、定位、短信、录音、相机、存储、日历等权限，用户回绝受权后，利用退出或敞开（利用陷入弹窗循环，无奈失常应用）。
- 2.向用户索取危险权限(电话、通讯录、定位、短信、录音、相机、存储、日历等权限)，没有增加申请权限目标告知用户。
- 3.APP运行时，向用户频繁弹窗申请开启与以后服务场景无关的权限，影响用户失常应用。
- 4.未见应用权限对应的相干产品或服务时，提前向用户弹窗申请开启通讯录/定位/短信/录音/相机/XXX等权限。
整改倡议：
- 针对1场景，举例说明APP向用户索取（电话）权限，用户回绝后，APP不能退出或敞开，必须保障APP能够持续失常运行。
- 针对2场景，APP须要先通过弹窗向用户阐明申请（电话）权限的目标，用户批准后再申请权限。用户回绝后，APP不能退出或敞开，必须保障APP能够持续失常运行。
- 针对3场景，APP向用户索取（电话）权限，用户回绝后，APP不能反复向用户申请权限。（权限申请弹窗的“禁止后不再询问”是零碎提供的性能，属于治理性能，不是APP本身机制，APP要能做到回绝后不再触发申请权限弹窗）。
- 针对4场景，比方须要用到电话的时候，先通过弹窗向用户阐明申请（电话）权限的目标，用户批准后再申请权限。不要在没有应用到电话性能页面，去申请电话权限。
4.5 自启动和关联启动
场景阐明：
- 1.APP未向用户明示未经用户批准，且无正当的应用场景，存在频繁自启动或关联启动的行为。
- 2.APP尽管有向用户明示并经用户批准环节，但频繁自启动或关联启动产生在用户批准前。
- 3.APP非服务所必须或无正当利用场景，超范围频繁自启动或关联启动第三方APP。
整改倡议：
- 针对1，2，3场景。倡议删除相干自启动函数代码。如APP必须应用（自启动）能力，请在隐衷政策协定中分明阐明自启动的规定阐明，并且获得用户批准后执行。
客户端如何做？
- App没有自启动场景和服务，则删除相干自启动的函数调用代码。
- App有自启动场景和服务，则在隐衷政策中做好残缺规定阐明，在用户批准隐衷政策前不要执行自启动代码，在批准隐衷后才能够执行自启动代码。
4.5 隐衷数据留神项
遇到的问题，每次排查隐衷数据很麻烦
- 因为随着我的项目更迭，随时可能有新的隐衷平安问题被引入进来，而如果每次发版前都要从新走一遍上述流程来排查是否存在问题的话，也是很麻烦。
如何保障隐衷合规相对平安呢
- 个别都是会通过一个标记位来记录用户是否曾经批准过隐衷协定，咱们能够在每次获取敏感数据前均先判断该标记位，如果用户还未批准隐衷协定的话就间接返回空数据，否则才去真正执行操作。
05.隐衷合规检测库实际
5.1 整体合规思路
开发了一个针对 Android APK 的敏感办法调用的动态查看工具。
- 查看关键字，对于一些敏感 API 调用，例如 oaid、androidId、imei 相干的调用。其实只有能检测到这些相干 API 里的一些关键字，找出整个 APP 外面有哪些地方间接调用了这些办法就能够了。
针对的上述的一些场景，这个工具具备两个方向的工作：
- APK 包的扫描，查看出整个APK中，哪些地方有对蕴含下面这些 API 关键字的间接调用。
- 运行时查看。针对运行时频繁调用这个场景，还是须要在运行时辅助查看特定API的调用状况。
5.2 工具检测隐衷API
计划1：Xposed
- 如果你对Xposed比拟相熟，并且手头有个root的设施装置了Xposed框架，那么间接开发一个Xposed模块来hook指定办法就能够了。毛病是须要root权限……
计划2：VirtualXposed
- VirtualXposed 是基于VirtualApp 和 epic 在非ROOT环境下运行Xposed模块的实现（反对5.0~10.0)。
- VirtualXposed其实就是一个反对Xposed的虚拟机，咱们把开发好的Xposed模块和对应须要hook的App装置下来就能实现hook性能。
计划3：epic
- 如果不想折腾 Xposed 或者 VirtualXposed，只有在利用内接入epic，就能够实现利用内Xposed hook性能，满足运行hook需要。
- epic 存在兼容性问题，例如Android 11 只反对64位App，所以倡议只在debug环境应用。
最终抉择：计划3
- 它能够拦挡本过程外部简直任意的 Java 办法调用，可用于实现 AOP 编程、运行时插桩、性能剖析、平安审计等。
应用起来也非常简单：提前设置须要 hook 哪个 java 方，比方，我要 hook TelephonyManager 的 getDeviceId 办法：
//外围办法DexposedBridge.findAndHookMethod(TelephonyManager.class, "getDeviceId", new XC_MethodHook() { @Override protected void beforeHookedMethod(MethodHookParam param) throws Throwable { super.beforeHookedMethod(param); String className = param.method.getDeclaringClass().getName(); String methodName = param.method.getName(); Log.i(PrivacyHelper.TAG, "检测到危险函数被调用: " + className + "#" + methodName); Log.d(PrivacyHelper.TAG, StackTraceUtils.getMethodStack()); } @Override protected void afterHookedMethod(MethodHookParam param) throws Throwable { super.afterHookedMethod(param); Log.d(PrivacyHelper.TAG, "afterHookedMethod getDeviceId"); }});- 在代码中如果有中央调用 TelephonyManager.getDeviceId 的，都会被 epic 的 beforeHookedMethod 给拦挡到，只须要在 beforeHookedMethod 打印出堆栈即可看到是谁调用的。
为何打印堆栈信息
- 在利用运行时记录每次触发隐衷行为的工夫点和调用链信息，依据触发工夫来判断该隐衷行为是否适量执行，依据调用链信息来辅助判断具体是哪一块业务须要来获取隐衷数据。
当检测到了危险函数调用状况，则须要晓得该函数是在哪里调用的？这个该怎么做呢？
- 获取以后线程，而后通过线程获取stackTraces，再而后遍历打印即可。依据堆栈信息，能够看到调用链的类名，办法名称，代码行数等。
对于针对运行期查看隐衷合规api调用
- 具体能够看：MonitorPrivacy
5.3 工具检测权限
应用场景
- 新增三方sdk或开源库，有收集个人信息或者权限的，这个时候须要用工具检测。次要是为了新增的权限在隐衷政策中申请，用工具去保障重要权限避免漏掉隐衷阐明。
敏感权限查看
- 扫描AndroidManifest.xml查看敏感权限，这个能够借助三方工具。
5.4 敏感信息控频
- 敏感设施信息获取是指只有调用零碎API就会认为获取敏感信息，并不关怀有没有获取到敏感信息以及调用零碎API的目标。
次要准则：
- 没有权限不能调用零碎API，如无READ_PHONE_STATE权限调用掉用getImei()、getDeviceId()等API
- 管制调用频次，即便有权限不能频繁调用零碎API
- 控制传输频次，不能频繁传输敏感信息
控频计划：
- App本身零碎隐衷API调用，对立调用根底库，该库对立做内存级别缓存，不反复调用零碎API。
- 传输控频，次要有2种计划：敏感信息对立传送一次，各业务独自对接，业务见相互依赖强；数据对立整包加密
敏感信息次要有那些
- imei(IMEI)，android_id(Android惟一标识符)，provider_name(手机运营商)，operator_id(卡运营商id)，sn(sn设施号)等等
举一个简略例子【利用缓存，防止频繁调用api获取敏感信息】
public static String getAndroidId(@NonNull Context context, String defaultValue) { if (null != Cache.ANDROID_ID) { return Cache.ANDROID_ID; } String androidId = SafePrivateHelper.getAndroidId(); if (!TextUtils.isEmpty(androidId)) { Cache.ANDROID_ID = androidId; } else { androidId = defaultValue; } return androidId;}- 具体的计划能够看这个依赖库：PrivateServer
5.5 隐衷协定申明
隐衷协定申明很重要，能躲避大部分问题，隐衷协定申明要留神几点：
- app本身收集的个人信息、用处须要在隐衷协定中申明
- app申请权限及目标在隐衷协定中申明
- 集成的所有第三方sdk及第三方sdk收集个人信息的用户须要在隐衷协定中申明；包含检测机构检测进去的+三方sdk隐衷协定中申明的
- 在隐衷协定中申明，app及三方sdk在静默和后盾也会收集个人信息
针对危险权限，须要在隐衷协定中阐明一下。具体如下所示：
5.6 敏感权限实际
敏感权限。如下所示，频繁读取敏感权限也会触发合规
android.permission.READ_CALL_LOG：读取通话记录android.permission.WRITE_CALL_LOG：写通话记录android.permission.READ_CONTACTS：读取联系人android.permission.WRITE_CONTACTS：写联系人android.permission.ACCESS_FINE_LOCATION：精确定位android.permission.RECEIVE_BOOT_COMPLETED：开机自启动android.permission.SEND_SMS： 发送短信android.permission.RECEIVE_SMS：承受收短信android.permission.READ_SMS：读取短信
5.7 底层依赖库权限阐明
针对申请隐衷权限须要弹窗阐明
- 比方以前能够在app启动的时候，一下子申请完所有权限。然而这种曾经不符合规范了，要求必须在应用的时候申请权限，并且要有弹窗阐明。一句话概括为那里应用那里申请权限！
举一个例子加深了解
- 比方你有一个二维码扫描库，你在扫描的时候须要申请相机权限，并且先要弹出弹窗阐明文案；比方你有个相册库，你在关上相册的时候，须要申请读写权限。
二维码库和相册库曾经本人申请权限，如何复用壳工程中的权限阐明弹窗？
- 具体计划：采纳接口隔离，具体的实现类放到壳工程中实现。具体能够看看我的这个根底空间通用接口库：EventUploadLib
06.合规测试查看重点
6.1 合规解决优先级
- 合规需要第一优先级，第一工夫跟版上线，不要有任何磋商和幸运，比开发需要还要重要！否则利用市场无奈上架很麻烦……
- 新增需要不合规不容许上线：新增需要如有不合规的中央，但又来不及批改，则延期上线，整改到合规再上
- 发版准出减少，合规确认环节：每次发版，产品、研发、测试 都须要负责查看对应的合规项，对查看后果负责，都确认之后才能够发版
6.2 QA测试查看重点
- 重点手工 check list。研发和测试都要器重这块工作！
- 第一次关上时，各种隐衷协定关上是否失常。
- 第一次关上时，未批准隐衷协定前，不能有任何网络申请收回，可通过手机设置代理查看。
- 第一次关上时，未批准隐衷协定前，不能有任何隐衷 API 调用，通过Xposed的手机是否有隐衷api调用。
6.3 交互层面合规
申请权限弹窗申明
- App上一些用户权限须要有申请弹窗阐明，相干交互内容有特定的交互要求，需qa配合在发版前回归阶段进行无限的查看。
筛查范畴
- 安卓端，app启动时，显著的权限申请弹窗、隐衷协定、个性化举荐等交互流程。
- 权限弹窗管制频次(比方App申请告诉权限弹窗设置用于点击勾销后，频次至多距离48小时)；批准隐衷协定不能默认勾选；个性化举荐反对敞开
权限弹窗管制频次
- 操作步骤：最新下载未关上的安卓包，启动app时，呈现权限弹框任意一个例如：本地存储、相机、定位权限，点击回绝；将app敞开杀死后台程序，再次关上app，查看是否还有上述被回绝的权限弹框，例如：本地存储、相机、定位权限。
- 预期成果：如果回绝之后再弹框就是有问题、不合理，须要上报开发排查起因；如果没有上述三个权限弹窗，则为失常。
批准隐衷协定不能默认勾选
- 关上app时，关注波及隐衷协定页面，查看默认勾选状态。预期成果：默认为：未勾选，则为失常；默认为：勾选，则为有问题，须要上报开发排查起因。
收集与性能无关的个人信息
- 在未应用任何性能的状况，查看是否有弹窗索取手机存储权限。预期成果：不进行弹窗索取手机存储权限。
6.4 服务端敏感收集
背景简略阐明一下
- 禁止APP收集用户信息，比方imei、cuid，oaid等用户设施信息。所以在发版前须要确保客户端内申请不携带imei、oaid等敏感字段，接口返回也不蕴含以上敏感字段。
筛查范畴记录
- APP内客户端/fe发动的接口申请，倡议各APP先彻底筛查一遍，排除隐患，后续迭代版本例行筛查F0性能或新增性能即可。
筛查规定：申请 request body/response中不包含
- imei，imei的值（个别有两种模式，eg：imei失常格局没有加密的 imei=866917034628451，加密过的imei = oC0JwJIxaEiKIWlzkqHO）。
筛查办法阐明
- 连贯代理（全局代理，不是指定某个域名的代理），以charles为例。回到charles界面，ctrl+F，输出关键字“imei”“oaid”以及imei的值进行反查。
- 关注request外面是否携带此三个参数，只有有携带，不论是否传值，都是问题，须要报给客户端；关注response中是否返回此三个参数，如果有，须要上报开发排查起因，是否能够不返回此参数。
6.5 隐衷协定筛查
计划阐明：
- 确保隐衷协定可拜访； 通过脚本主动查看三方 SDK 是否在隐衷协定中申明；法务 + 产品 定期检查；
施行措施：
- 建设隐衷协定可拜访性自动化巡检机制；三方SDK检测，依据检测进去新增的三方SDK扫描隐衷协定，确认该sdk是否在隐衷协定中申明。
开发须要留神点
- 新增三方sdk或开源库，有收集个人信息或者权限的 必须在隐衷政策里申明（找产品和法务）；没收集个人信息或者权限的三方库或者自有库，确定好后将sdk包名和中文名称备注一下。
07.其余阐明介绍
7.1 参考博客链接
腾讯隐衷政策审核标准
- https://wikinew.open.qq.com/i...
腾讯隐衷政策整改办法
- https://wikinew.open.qq.com/i...