手机使用代理是否尊重用户隐私? Do Phone-Use Agents Respect Your Privacy?
提出MYPHONEBENCH框架,评估手机代理在完成任务时的隐私行为
前置知识
手机使用代理(Phone-Use Agent)
通过图形用户界面(GUI)代表用户操作智能手机的AI系统。它们可以执行点击、输入、滚动、打开、返回等操作,完成用户的移动端任务。代表系统包括AutoGLM、UI-TARS、Claude Computer Use等,这些系统通过截图分析识别界面元素,然后选择合适的动作序列来达成用户目标。
本文研究的核心对象,理解手机代理的工作原理是理解其隐私风险的前提。论文中所有实验都是基于这类代理在Android模拟器中的交互行为进行的。
隐私契约(Privacy Contract)
一种形式化的数据访问协议,定义了代理在执行任务时可以如何使用用户数据。本文提出的iMy隐私契约将用户数据分为两类:LOW类(可默认使用,如姓名、食物偏好)和HIGH类(需要明确用户批准,如电话号码、身份证号)。代理想使用HIGH数据时必须先调用request_permission,获得批准后通过read_profile获取值。
这是论文的核心创新之一,将隐私从抽象原则转变为可执行、可审计的边界。理解这个契约是理解整个评估框架的基础。
隐私探测(Privacy Probe)
论文设计的三种测试结构,用于暴露代理在执行任务时的隐私风险行为。Over-permissioning测试代理是否请求不需要的数据,Trap resistance测试代理是否将数据重新披露给非必要的收集组件,Form minimization测试代理是否填写任务不需要的可选个人信息。这些探测基于真实商业应用中反复出现的隐私风险模式。
这是评估框架的核心组件,理解这三种探测的设计原理和实现方式是理解实验结果分析的关键。
研究动机
现有手机代理评估框架存在严重盲区,只关注任务完成率,完全不评估隐私行为。例如,AndroidWorld、WebArena、OSWorld等基准只检查最终页面状态或数据库状态,无法揭示代理是否请求了额外权限、填写了不必要的个人信息、或将联系数据重新提交给无关的组件。论文举例说明,在KFC外卖场景中,代理可能在用户未明确批准的情况下通过电话号码登录,然后将同一号码披露给优惠券弹窗——这种隐私违规在只关注任务成功的评估中完全不可见。
本文的目标是本文的具体目标是将手机代理的隐私行为从模糊担忧转化为可测量的属性。通过定义明确的隐私契约、构建可审计的执行环境、设计基于真实隐私风险结构的控制探测,使得代理在执行任务时的数据处理行为可以被观测和验证。最终目标是回答一个部署相关的核心问题:当手机代理在完成良性移动任务时,是否同时尊重了用户隐私?
与已有工作不同的是,本文的独特切入角度是关注良性任务执行中的自愿数据过度披露行为,而非对抗性攻击或恶意指令。现有的LLM安全和隐私评估如TrustLLM、SafetyBench、ConfAIde、PrivacyLens都关注GUI之外的场景,相关工作研究弹窗攻击也是针对UI注入的对抗性场景。本文则是评估代理在面对便利性诱惑时是否表现出必要的克制,这是部署前的关键但被忽视的维度。
核心方法
论文提出了MYPHONEBENCH评估框架,整体思路是将隐私合规性转化为可执行契约,并与可审计的执行环境配对。框架包含三个核心组件:iMy隐私契约定义数据访问边界,10个受控的Android应用记录代理的每一个表单输入,基于真实隐私风险结构设计的控制探测通过确定性规则进行审计。代理在每个步骤从固定动作集中选择一个动作,包括普通的GUI操作(tap、type、scroll、open、back、wait)和四个iMy隐私契约动作(request_permission、read_profile、save_profile、ask_user),隐私决策与任务完成发生在同一个循环中而非单独的安全层。
核心创新点是将隐私从抽象原则转变为可操作的执行时间边界,通过iMy隐私契约明确区分默认访问和权限门控访问,并让用户通过可见、可编辑、可删除的界面控制跨会话的记忆。与已有方法的本质区别在于,隐私决策被嵌入到代理的主要观察-动作循环中,而非作为独立的分类器或事后判断层。此外,框架通过SQLite数据库的form_drafts表记录代理对屏幕表单框的每一次编辑,即使表单从未提交,实现了对数据处理的细粒度审计。
方法步骤详情
方法步骤的完整描述包括四个阶段。第一,任务构建:从种子数据库状态开始,采样目标状态变化,渲染为自然语言用户请求,并从同一目标状态派生确定性SQL验证规则。字段级元数据(必填vs可选、LOW vs HIGH配置键、隐私探测位置)由应用模式和任务模板指定。第二,代理执行:每一步代理接收当前截图、用户指令、交互历史以及iMy隐私契约下当前可用的用户数据,必须从固定动作集中选择一个动作。环境执行所选动作并返回更新后的截图或工具响应,循环持续直到代理终止任务、任务失败或达到步数限制。第三,结果验证:通过确定性规则检查数据库写入和访问日志来评估任务完成和隐私结果。第四,评分计算:任务成功率为二进制;隐私分数总结三个探测,分数在0到1之间;隐私合格成功率是代理既完成任务又达到隐私阈值$\tau=0.7$的任务比例;跨会话偏好使用是配对任务中正确使用保存偏好的比例。
技术新颖性
技术新颖性体现在多个方面。首先,iMy隐私契约是首个针对手机代理的可执行隐私边界框架,将抽象的隐私原则转化为具体的操作限制。其次,受控应用的form_drafts机制实现了对代理输入行为的细粒度记录,这是真实商业应用无法提供的透明度。第三,三种隐私探测(over-permissioning、trap resistance、form minimization)基于真实应用中反复出现的隐私风险模式,但转化为可复现的确定性测试。最后,隐私合格成功率指标通过联合评估任务完成和隐私合规,避免了只看平均隐私分数的误导性——弱代理可能早早失败而显得干净,强代理可能接触更多隐私相关时刻而暴露更多失败机会。
实验结果
实验在300个任务上评估了五个前沿模型:Claude Opus 4.6、Qwen 3.5 Plus、Kimi K2.5、Doubao Seed 1.8、Gemini 3 Pro。核心发现包括三个方面。首先,没有单一模型在所有评估维度上占优:Claude Opus 4.6任务成功率最高(82.8%)且跨会话偏好使用最强(72%),Kimi K2.5平均隐私分数最高(77.3%),Qwen 3.5 Plus在隐私阈值$\tau=0.7$下的合格成功率最高(47.6%)。这种分化证明了任务成功、隐私合规任务完成和跨会话偏好使用是独立的能力——任务成功奖励达到最终状态,而隐私合规奖励沿途的克制。其次,隐私合规任务完成不能仅由原始成功率或平均隐私分数捕捉。隐私合格成功率在共享分母下联合评估完成和隐私,改变了模型排序。第三,强单会话行为不能保证跨会话偏好使用的正确性。Claude领先于Kimi、Qwen、Doubao、Gemini,但这种顺序与任务成功和单会话代理诊断都不同。最持久的失败模式是简单的数据最小化:代理仍然填写任务不需要的可选个人条目,这种行为更符合完成导向的偏差而非访问控制问题。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 任务完成率 | 任务成功率 | Claude Opus 4.6: 82.8%, Qwen 3.5 Plus: 76.0%, Kimi K2.5: 65.2%, Doubao Seed 1.8: 57.2%, Gemini 3 Pro: 50.4% | AndroidWorld基准只报告任务成功率 | 本文首次引入隐私维度评估,发现任务成功率高的模型不一定隐私合规 |
| 隐私合规性 | 平均隐私分数 | Kimi K2.5: 77.3%, Qwen 3.5 Plus: 73.8%, Doubao Seed 1.8: 71.0%, Claude Opus 4.6: 68.4%, Gemini 3 Pro: 60.5% | 无隐私评估基线 | 建立了首个手机代理隐私行为量化评估体系 |
| 联合评估 | 隐私合格成功率($\tau=0.7$) | Qwen 3.5 Plus: 47.6%, Claude Opus 4.6: 47.2%, Kimi K2.5: 45.2%, Doubao Seed 1.8: 31.2%, Gemini 3 Pro: 22.0% | 无联合评估基线 | 揭示只看成功率会高估当前手机代理的部署准备度 |
| 跨会话偏好传递 | 正确使用保存偏好的比例 | Claude Opus 4.6: 72.0%, Kimi K2.5: 58.0%, Qwen 3.5 Plus: 48.0%, Doubao Seed 1.8: 42.0%, Gemini 3 Pro: 20.0% | 无跨会话评估基线 | 发现单会话行为强不能保证跨会话可靠性 |
局限与改进
作者承认的局限性包括MYPHONEBENCH有针对性地关注特定隐私维度:代理任务执行中的行为隐私,重点是数据访问、披露和跨会话偏好使用。这个控制范围使得可以在单个表单条目级别进行确定性评估,但尚未覆盖与部署手机代理相关的所有隐私风险,如更广泛的跨应用泄漏、消息披露或网络级别的外渗。使用模拟应用和确定性用户模拟也是深思熟虑的设计选择:它在可验证协议中隔离代理行为,而不是试图再现生产移动软件的全部异构性。用户响应故意宽松,因此当前评估测量的是自愿克制而非拒绝处理。我自己的观察是,任务集故意集中在表单中心的服务工作流程(预订、个人资料输入、约会管理),这可能低估了其他场景(如社交媒体、文件操作、游戏)的隐私压力。此外,隐私阈值$\tau=0.7$是实用的操作点但缺乏规范性基础,不同应用领域可能需要不同的阈值。
独立分析的弱点
独立分析的弱点包括四个方面。第一,评估框架目前只覆盖表单中心的工作流程,对于非表单密集型场景(如视频观看、游戏交互、文件管理)的隐私压力了解不足,改进方向是扩展到更多应用领域和交互模式。第二,确定性用户模拟总是批准请求,这无法评估代理对拒绝的反应,改进方向是引入更复杂的用户模拟策略,包括随机拒绝、上下文感知的拒绝和基于信任度的动态决策。第三,隐私阈值$\tau=0.7$的选择缺乏理论依据,改进方向是基于用户研究和实际部署数据来校准不同应用场景和用户群体的可接受阈值。第四,当前框架无法检测更微妙的隐私违规,如跨应用的数据泄漏模式或时序上的隐私推理攻击,改进方向是引入跨应用的数据流分析和时序模式检测。
未来方向
作者提出的未来工作方向包括扩展隐私覆盖范围以包含更广泛的跨应用泄漏、消息披露或网络级别的外渗。基于成果可延伸的方向包括:首先,开发更细粒度的隐私分类系统,超越LOW/HIGH二元划分,引入基于敏感度和上下文的动态隐私级别。其次,研究隐私感知的训练和微调方法,使代理从训练阶段就内化隐私约束而非仅依赖评估阶段的外部约束。第三,探索用户可定制的隐私契约,允许用户根据个人偏好调整数据访问边界。第四,开发实时隐私监控和干预机制,在代理执行过程中检测潜在的隐私违规并及时提醒用户或中断执行。最后,建立多模态隐私评估框架,不仅评估文本表单输入,还评估语音、图像、视频等多模态交互中的隐私行为。
复现评估
论文声称所有代码、模拟应用和代理轨迹公开在https://github.com/FreedomIntelligence/MyPhoneBench。实验在Android模拟器上运行,具体配置为Pixel 6、API 33,通过AndroidWorld框架管理。每个任务框架恢复相应的种子数据库状态并在代理完成后评估数据库写入和审计日志。最大步数为独立任务100步、跨会话配对100步。所有模型温度设置为0.0。使用每模型坐标策略处理视觉语言模型分辨率差异。虽然没有明确报告算力需求和时间成本,但基于模拟应用和确定性评估的设计,复现的难度应该较低,主要是需要配置Android开发环境和获取模型API访问权限。
论文图表
该图展示了KFC微信小程序的完整场景,包括任务描述(查找附近门店、切换到外卖模式、点汉堡等)和代理轨迹中四个隐私违规点:在未经用户明确批准的情况下授权电话号码访问、在未经用户明确批准的情况下输入短信验证码、启用超出任务需求的持久登录、向任务无关的优惠券弹窗披露电话号码。
这张图对理解论文至关重要,因为它展示了论文研究的核心问题:代理如何在完成良性任务的同时跨越隐私边界。这四个违规点分别对应了论文中讨论的隐私风险结构,为后续的技术方案提供了直观的问题背景。