关于android:隐私合规综合实践

4次阅读

共计 9170 个字符，预计需要花费 23 分钟才能阅读完成。

隐衷合规综合实际

目录介绍

  • 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…
7.2 相干 demo 链接
隐衷合规 demo
正文完
android
发表至： android
2022-10-12
 0
ReactNative063正式版发布LogBox
关于android:在多进程应用中使用-WorkManager
关于android:融云-IM-SDK-集成-刷新会话界面和会话列表界面
关于android:虚拟偶像的歌声原来是这样生成的

站内搜索

-「」