我最近安装了歌剧浏览器处于无人值守模式（使用 Chocolatey: choco install opera）。当我第一次打开它时，Opera 已将我的所有书签从 Chrome 导入（不需要，但没问题）。
然后我点击了GMailOpera 书签栏，令我大吃一惊的是，它加载了我的 Gmail 帐户，而没有要求我先进行身份验证。我可以像使用 Chrome 一样阅读电子邮件。
显然，Opera 以某种方式从我的 Chrome 配置文件中导入了我的 Google 帐户 OAuth2 令牌"%LOCALAPPDATA%\Google\Chrome\User Data\..."，并且能够使用它们，也许是因为它也使用 Chromium 作为其渲染引擎。
在我看来，这是 Chrome 保护本地用户配置文件数据的方式存在问题。对我来说，这既令人讨厌又令人恐惧。我至少希望 Chrome 使用类似Windows 数据保护 API (DAPI)加密其敏感数据。
除了不安装其他程序（例如 Opera）之外，还有什么方法可以阻止它们窥探我的 Chrome 本地配置文件吗？
已更新，我向 Chrome 团队报告了此问题，他们出于以下原因驳回了该问题：为什么 Chrome 的威胁模型中没有物理本地攻击？
讽刺地，补救措施如蛋白激酶已采取措施保护访问令牌免受 OAuth2 授权流程中的本地恶意行为者的攻击。我很难理解 PKCE 的存在如何与 Chrome 对本地攻击的立场一致。
我个人认为，不应完全忽视缓解该攻击媒介。从用户的角度来看，一旦我将密码提供给 Chrome 进行加密数据同步，我希望它能够使用底层操作系统 API 来存储机密。
数据处理应用程序接口作为适用于 Windows 的 API，它无法完全保护应用程序免受彼此攻击，但它在缓解攻击方面做得相当不错。它为用户预设了一个标准的操作系统对话框，请求授权访问：
此屏幕截图来自运行来自在线 DPAPI 文档的示例。请注意系统 UI 如何显示尝试访问机密的应用程序的位置，因此，作为知情用户，我可以选择是否授予访问权限。
当然，恶意软件仍然可以欺骗该 UI，但这不是 Opera 等合法、经过代码签名且普遍受信任的软件会做的事情。如果 Chrome 使用 DPAPI，那么 Opera 也必须使用它，才能使从 Chrome 导入功能正常运行。由 Opera 调用时，DPAPI UI 会提示我授权访问 Chrome 的本地数据，并且我可以选择拒绝。
更新，有一个迹象Chromium 团队可能会在未来解决这个问题。