英语原文共 12 页，剩余内容已隐藏，支付完成后下载完整资料

Android上的用户互动和权限使用

Kristopher Micinski，Daniel Votipka，Rock Stevens，Nikolaos Kofinas，Michelle L.Mazurek和Jeffrey S.Foster

马里兰大学帕克分校

{micinski, dvotipka, rstevens, nkofinas, mmazurek, jfoster}@cs.umd.edu

摘 要

Android和其他移动操作系统在允许应用访问敏感资源

（例如联系人和位置）之前，要求用户进行授权。我们假设可以通过与应用程序的用户界面更加集成来改进此类自动配置系统。在本文中，我们进行了两项研究以检验我们的假设。首先，我们使用App-Tracer（我们开发的动态分析工具）来衡量现有应用中用户交互和敏感资源使用的相关程度。其次，我们进行了一次在线调查， 以检查与UI的不同交互如何影响用户对应用程序是否访问敏感资源的期望。我们的结果表明，用户交互（例如按钮单击）可以解释为授权，从而减少了对单独请求的需求；但是与访问权限没有直接关系的访问应该单独授权，可能是在首次启动应用程序时。

ACM分类关键字

H.5.m信息接口和表示（例如，HCI）：其他

作者关键词

Android;权限；上下文安全；应用

介 绍

Android有一个权限系统，该权限系统会在应用使用敏感 资源（例如联系人或GPS位置）之前要求用户进行授权。这种授权系统中的一个关键挑战是在使用户中断与使敏 感资源使用透明化之间取得平衡。我们假设Android现 有的自动化系统（安装时权限列表或运行时对话框，具 体取决于版本）可以通过与应用程序的用户界面（UI） 集成来实现更好的平衡，因为该UI可以深度告知用户用 户对应用行为的心理模型，包括与安全相关的行为。

特别是，在本文中，我们询问是否可以将用户交互（按钮单击，页面更改，对话框等）视为使用某些敏感资源的授权证据。如果是这样，则可以减少对单独授权请求的需求。相反，我们询问是否使用敏感资源

只要不为牟利或商业利益而制作或分发副本，并且副本载有本通知和第一页的完整引用，则可免费提供允许将本作品的全部或部分制作为个人或教室使用的数字或纸质副本，以供免费使用. .必须尊重作者以外的其他人拥有的本作品组件的版权。允许使用信用摘要。要以其他方式复制或重新发布以发布在服务器上或重新分发到列表，需要事先获得特定的许可和/或费用。请求来自的权限Permissions@acm.org.

2017年5月6日至11日，美国科罗拉多州丹佛市，CHI。

版权由所有者/作者拥有。授权给ACM的出版权。ACM 978-1-4503-4655- 9/17/05 ... $15.00

DOI：http://dx.doi.org/10.1145/3025453.3025706

没有关联的交互，则表明需要其他授权请求。请注意， 尽管我们的研究在很大程度上受到Android的影响，但我们相信我们的结果将推广到相关的移动操作系统以及类似的设置（如网络应用）。

为了回答这些问题，我们进行了两项相关研究。首先， 我们回顾了150个流行的Android应用程序，以确定敏感资源的使用是否与现有应用程序中的用户交互有关。如果是这样，则与UI集成的授权机制可以很好地与现有应用程序设计配合使用。为了进行这项研究，我们开发了

AppTracer，这是一种动态分析工具，可对Android应用进行记录，以记录UI操作和资源使用情况，然后将记录可视化为图形，以显示记录事件的时间顺序。我们使用

AppTracer来确定每个应用程序中每个观察到的资源使用是否是交互式的，这意味着它是紧随其后的是相关的UI 事件（例如，单击标记为“联系人”的按钮后访问联系人），还是它的主要焦点。当前屏幕（例如，使用地图屏幕上的位置）。

我们发现，在我们的主题应用程序中，几乎完全以交互方式使用了几种资源（微型电话，相机，外部存储和日历）。其他几种（包括蓝牙和电话状态）大多是非交互使用的（即使应用本身在屏幕上，我们也会在后台调用）；并且一些资源（最著名的是联系和位置）展示了交互和背景使用的结合。这些结果表明，交互使用和后台使用可能要求使用不同的授权机制，并且这些机械机制不一定必须严格按资源划分。

这些结果为我们第二项研究的设计提供了依据，这项研究是一项961名参与者的在线调查，旨在调查参与者对互 动和背景许可用途的期望。每个参与者观看了一个模拟移动应用程序的两种使用情况的幻灯片演示，其中每个场景都显示了短暂的交互（例如，启动应用程序，单击按钮等），然后询问参与者是否需要麦克风，位置和/或 交互后要使用的联系人。我们选择了这些资源，以反映在我们的应用研究中测得的一系列交互性。我们旨在深入了解不同因素如何影响用户的期望，从而了解哪种授权机制可能适用于不同的使用模式。

正如我们所预期的，我们发现用户比相关后台更可能期望在相关交互之后访问资源。但是，我们还发现，看到一种交互用途并不能使用户期望将来的背景用途，这表明Android M首次使用请求授权模型存在潜在的缺陷。相反，我们的调查结果表明，启动时有授权请求

确实增加了对交互式访问和后台访问的期望，这可能是因为它更好地传达了可以随时访问资源的想法。

根据我们的研究结果，我们提出了三个设计建议。首先， 应该在关联的交互之后尽可能多地利用资源。考虑到当 前应用程序的组成，对于许多常用资源而言，无需花费 大量精力即可实现这一目标。其次，对于大多数以交互 方式访问的资源，可能不需要单独的授权对话框（例如， 参见[27]). 最后，对后台资源使用的授权应与对交互用途的授权不同，并且这些后台授权在启动应用程序时可能 最有效。

背景及相关工作

在早期版本的Android中，系统会在安装时向用户提供 应用程序请求的权限列表。然后，用户可以授予应用程 序这些权限的完全使用权，或者根本不安装该应用程序。该模型存在许多问题：很少有用户理解甚至看不到权限 列表[12], 并且许多应用程序请求的权限比他们使用的更多[10]. 由于这些问题，Android M[14] 切换到应用首次请求权限的模型；然后无限期地授予该许可。

在我们的工作中，我们询问是否可以通过考虑用户界面来改进类似于Android的授权系统。请注意，我们的工作与权限是否处于正确的粒度级别正交[6, 17] 或保护正确的资源[11].

移动设备上的上下文安全

可以更好地将授权与UI集成在一起，这是我们工作的动 力，体现了上下文安全性[22], 这表明安全决策应考虑到上下文。几位研究人员研究了移动设备上的上下文安全 性。Almuhimedi等。人[3] 向用户显示了有关应用如何访问其位置的历史数据。他们发现95％的用户重新评估了 应用对位置的需求，其中58％的用户进一步限制了位置 访问权限。国王[19] 当上下文建议时，发现用户更可能期望敏感的资源访问。毛毡等。人[1] 提出了一种基于权限在上下文中的使用来确定权限的适当授权机制的过程。几位研究人员[5, 13, 33] 找到的用户会对应用程序在后台发生的某些敏感资源访问感到惊讶。在与Wijesekera等 人的野外研究中，与本文最密切相关的内容。[33] 发现上下文是确定资源使用期望的重要因素。我们的工作基 于此发现，通过使用受控实验来区分不同的上下文因素

（包括连续的交互）如何促进用户期望。

刚才提到的作品主要将上下文定义为应用是在屏幕上还是在屏幕外。相反，我们基于UI动作序列使用了更丰富的上下文概念。

实施上下文安全

已经提出了许多系统来强制应用程序中的上下文安全性。陈等人[8] 目前的天马座，静态分析

图1：App评估调查程序。基于应用程序分析和执 行策略的系统

权限事件图（PEG）。例如，Pegasus可以检查是否仅在单击某个按钮后才能访问联系人。PEG启发了AppTracer 的设计。但是，AppTracer使用动态（而非静态）分析来减少误报的问题-AppTracer日志中的所有行为都是在实际运行中发生的，而静态分析可能会报告实际上从未发生过的敏感资源访问。

杨等。[34] 提出了AppIntent，它使用符号执行来确定导致信息泄漏的UI事件序列。Micinski等。人[21] 使用符号执行来基于UI事件强制实施安全的信息流属性。虽然这两个系统都有希望，但实际上，由于对Android框架建模的复杂性，符号执行很难在Android应用程序上大规模运行。

斯蒂格勒等。开发的CapDesk[30] 然后是北极星[29], 两个基于功能的桌面系统，它们利用用户交互来驱动访问 控制。但是，CapDesk和Polaris的重点仅限于文件访问。罗斯纳（ Roesner ） 等。人[27] 使用访问控制小工具

（ACG）扩展用户驱动的访问控制，该工具将资源访问绑定到某些UI元素，例如，ACG可能只允许在单击特定按钮后才使用位置。ACG后来扩展到可以在Android上运行， 并且在以后无需修改操作系统的情况下[25, 26]. ACG的原始论文包括一项用户研究，该研究测量了与交互式许可使用相关的期望。我们的工作扩展了这一思想，以研究各种因素和用例。尽管当前的论文没有直接实现或衡量

ACG，但我们的发现确实支持ACG的使用。

应用程序测量调查方法

在我们的第一项研究中，我们回顾了一组流行的Android 应用程序，以确定UI动作和资源使用之间的关系。数字1 概述了我们的审核过程，最终将产生一组资源使用代码， 这些代码针对每种资源使用指示导致使用的事件（如果 有）。例如，我们可能确定在某些应用中，单击按钮后 立即访问了联系人，或者在应用启动时立即使用了位置。

接下来的小节将详细介绍审阅过程。

二进制重写和执行日志

我们流程的第一步是使用AppTracer，这是我们开发的动态分析工具。AppTracer对主题应用程序进行检测

（a）点

（b）不确

（c）启

（d）外部背景

图2：我们代码书中的AppTracer图和相应的资源访问模式。

因此，在运行时，它将编写UI事件和权限使用的日志。AppTracer 使用Redexer 添加检测[17], Dalvik 字节码

（Android应用程序所编译的语言）的重写工具。一般而言，AppTracer通过在字节码上附加一个log方法并在与

UI相关的回调（例如，用于按钮事件的onClick处理程序） 的开头以及在对权限受保护的方法（例如， getLastLocation）的调用之前插入对log的调用来对代 码进行编码。

我们使用An-droid文档确定了与UI相关的方法。我们使用PScout数据集确定了受权限保护的方法[4], 它试图列出所有对安全敏感的方法及其相关权限。PScout还包括有关敏感内容提供者，意图等的信息。请注意，尽管

PScout相当详尽，但我们发现了一些遗漏的情况。例如， 我们观察到SD卡使用的多个视觉指示器，这些指示器没 有相应的日志条目AppTracer。在研究了应用程序的反编 译代码之后，我们发现SD卡是通过PSCout省略的Java IO 方法使用的。每当发现这种情况时，我们都会将缺失的 方法添加到PScout数据库的副本中，然后重新运行评估 后的应

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[236054]，资料为PDF文档或Word文档，PDF文档可免费转换为Word