平台型应用案例
案例分析
实现缺陷
有一些平台型应用无意识地对自己的权限进行再代理， 并为子应用提供不合理的容器。 例如， com.qihoo.loan 将自己作为几个子应用的唯一容器，这意味着不仅这些子应用共享同一个容器，它们甚至与平台型应用本身共享容器。
同时更重要的是，它提供了一个作为 JSBridge 的接口，而接口参数就是执行的本地原生方法，子应用能通过调用接口并带上方法名来执行一个本地原生方法。根据现有的流量分析实验结果，该应用存在泄露 PII 的可能性。
自定义的保护措施
我们在 com.reddit.frontpage 中发现，第三方网页可以通过 Chrome Custom Tabs 在 Chrome 的内部标签中打开。这是 Chrome 提供的一种外部标签服务, 有了它,就可以用 Chrome 浏览器打开网页，而不用跳转到外部浏览器。 但大多数平台型应用仍然选择自定义 WebView 作为第三方页面的容器。
对于 com.autonavi.minimap 中的子应用，来自第三方的动态代码都是由 alipay-eco.com 缓存和分发的，我们发现没有一个子应用调用任何特权的 API。然而，我们仍然发现一些直接从子应用接收的页面，这意味着这种子应用的在线代理机制并不完善。可见目前平台型应用中的保护机制对于权限再代理来说是不够安全和私密的
广告
广告是平台型应用中一个常见的案例，平台型应用可能会出于增加营收或别的目的使用广告 SDK。 这种 SDK 通常会为广告页面提供一个容器，Adlib: analyzer for mobile ad platform libraries 中也提到了这种现象。例如在 com.didapinche.booking 中，广告商以 ToutiaoJSBridge 这一接口进行设备标识和粗粒度地理位置信息的获取。
此外，一些平台型应用也会使用一些第三方的 SDK，这些 SDK 会通过定制的 HTTP 传输组件（如 OkHttp）而不是 Android WebView 泄露可标识个人信息
合作
很多平台型应用包含有第三方的网页，特别是在中国，热门的平台型应用将积极整合来自第三方的服务。这种情况可以被认为是合作性质的数据或利益交换驱动的。因为在这种情况下的子应用获取隐私的行为可能是被默许的。例如， 在 cmb.pb、com.chinamworld.main 和 com.MobileTicket 中，平台型应用甚至会直接将位置传输给合作者的子应用。
无意识的外部服务
除了对第三方页面的有意包含，也有一些无意识行为产生的后果。例如， 我们在 com.didapinche.booking 中发现一个案例。这一应用发起了一个使用第三方服务的问卷调查，这使得第三方页面可以在与应用程序本身相同的容器中操作网页代码。尽管在这个案例中并没有发现明确的 PII 泄露情况，但是这一行为还是存在相当大的隐私风险。
服务聚合
例如 com.baidu.BaiduMap、 com.autonavi.minimap这样的应用提供了功能较为完善的容器为基于网页的二次开发提供支持，以聚合各种服务。这些二次开发的 SDK 通常可以提供类似于原生开发的能力。同时，这种现象并不局限于移动领域，驾驶平台中也存在这种现象，比如百度的开放性自主驾驶平台 Appollo。这意味着风险可能存在于驾驶系统中，并且在不久的将来也会流行起来。
潜在的平台型应用
本次实验所需的应用请参见 Gitlab 仓库「materials/lab3」