- 启动 Mail ,再启动 Lark - 在 Mail 里登录 Google 账号(重连失效账号,或在偏好设置里添加账号,这两种操作理论上都能复现) - 等待 Mail 启动 Safari - 此时 Lark 内置的 Apollo 进程( Chromium )会劫持登录请求,Safari 窗口未能显示,而登录请求会在 Apollo 窗口内打开 - 登录后将在 Google Accounts 的最近活动里看到刚刚有一个 Windows 设备用 Safari 登录了账号
## Lark 创建的 Apollo 窗口
## 正常的 Safari 窗口
我把复现过程大致录了下来。其中通过 Apollo 的地址栏菜单打开了它的 Chromium 本体。可以看到 version 信息以及证明 Apollo 从属于 Lark 的信息。视频链接见 TL;DR 部分。
# 疑问
- Lark 为什么「要」以及是如何「能」感知系统里其他 app 的 Google 登录的请求? - 假设这次「劫持」是研发 bug 导致的意外,那么 Apollo 的设计职责和工作流程应该是怎样的? - Apollo (和其他用户尚无感知的 Lark 组件)是否会把非 Lark 业务的数据传到我电脑之外的地方?
# 延伸
其实对 Lark 客户端很早就有一个 Google 鉴权过程的疑问:如果通过点击 Google 按钮登录,那么 Lark 会不同于正常 OAuth 流程,也就是在用户的默认浏览器里打开 Google 登录页面,Lark 会在 app 窗口内直接跳转到 Google 登录页。若能成功登录,在 Google Accounts 里留下的记录也会显示为 Windows 平台登录。
这种流程的坏处显而易见,1 )请求都发生在 app 内部,等于把 Google 账号的所有令牌都暴露在了 app 的上下文中; 2 )用户无法使用默认浏览器里现有的 Google 登录状态,因为对于 Google 而言 Lark 内置的 webview 启动的是一个全新的 session ; 3 )无法正常使用 1Password 等工具进行自动填充,毕竟让 1Password 信任 Lark.app 并把我的 Google 账号自动填充进去,怎么看都不是个合理的事。
Q:Lark 为什么「要」以及是如何「能」感知系统里其他 app 的 Google 登录的请求? A:Lark 无意主动参与到 Mail 调起 webview 的请求当中,目前研发团队在排查问题的具体原因。初步判断是在注册 Apollo 为 webview 的过程中,错误地配置了 macOS 系统参数,导致 Mail 调起 webview 时意外地启动了 Apollo 内核。