Poco 使用手册
平台说明

本地浏览器同步登录态方案

将用户电脑本地浏览器的所有网站登录状态与 Agent 端保持同步

当前方案待实现...

1. 背景

当前 Poco 已将远程浏览器和任务浏览器的登录态统一为 Backend 管理的 Auth State,稳定覆盖 Cookie + localStorage。现有链路可以解决 Poco 内部浏览器之间的登录态复用,但无法直接复用用户本机 Chrome/Edge 中已经登录的网站状态。

为降低用户重复登录成本,需要支持用户将本地浏览器登录态同步到 Poco Auth State,使后续远程浏览器和任务浏览器可以恢复对应站点的登录状态。

2. 目标与范围

2.1 目标

  • 支持用户主动选择站点,并将本地浏览器中的登录态导入 Poco。
  • 复用现有 Backend Auth State 作为唯一持久化真相源。
  • 继续沿用现有三方合并规则,避免旧状态覆盖新状态。
  • 满足 Chrome 扩展能力边界和 Chrome Web Store 用户数据政策要求。
  • 降低隐私风险,避免静默全量采集用户浏览器数据。

2.2 范围

  • 使用 Chrome/Edge 浏览器扩展作为本地登录态同步入口。
  • 当前仅同步 Cookie + localStorage
  • 仅同步用户显式授权的 domain/origin。
  • 默认只支持从本地浏览器导入到 Poco,不反向写回用户本地浏览器。
  • 不直接读取本机 Chrome profile 文件。

3. Chrome 能力与合规边界

3.1 技术能力

Chrome 扩展技术上允许读取并上传用户授权范围内的登录态数据:

  • Cookie:扩展可通过 chrome.cookies API 读取 Cookie,但必须声明 cookies 权限和对应站点的 host 权限。
  • localStorage:扩展可通过 content script 注入到用户授权页面,在页面上下文中读取该 origin 的 localStorage。
  • 网络上传:扩展可通过 fetch 请求 Poco Backend,但需要对 Poco API 域名具备访问权限。

相关官方文档:

3.2 合规要求

Chrome Web Store 政策不禁止扩展上传用户数据,但要求满足以下约束:

  • 必须有明确、用户可见的产品功能。
  • 必须向用户清楚说明收集哪些数据、用途、保存位置和删除方式。
  • 必须取得用户明确同意。
  • 只能收集实现功能所必需的数据。
  • 数据传输必须使用 HTTPS。
  • 敏感认证数据必须安全保存,不能公开披露。
  • 不得将登录态数据用于广告、画像、数据交易、无关分析或第三方共享。

相关官方政策:

4. 总体架构

本地浏览器同步作为 Auth State 的一个外部导入入口,不改变当前远程浏览器和任务浏览器之间的同步机制。

用户本地 Chrome/Edge
        |
        | Browser Extension
        | - 用户授权站点
        | - 读取 Cookie
        | - 读取 localStorage
        v
Poco Backend Auth State
        |
        | snapshot / commit
        v
远程浏览器 / 任务浏览器

核心原则:

  • Backend Auth State 仍是唯一长期保存位置。
  • 本地扩展只负责采集用户授权范围内的状态并提交。
  • Executor Manager 和 Executor 不需要感知数据来自远程浏览器、任务浏览器还是本地浏览器。
  • 合并、加密、清空逻辑继续复用现有 Auth State 服务。

5. 组件职责

5.1 Browser Extension

  • 负责用户本地浏览器侧的授权和采集。
  • 使用 optional_host_permissions 让用户按站点授权。
  • 使用 chrome.cookies.getAll 读取授权 domain 的 Cookie。
  • 使用 content script 读取授权 origin 的 localStorage。
  • 维护本地同步基线 base_versionbase_state
  • 调用 Backend 用户态 Auth State 接口提交变更。

5.2 Frontend

  • 提供“同步本地浏览器登录态”入口。
  • 展示功能说明、隐私说明和风险提示。
  • 生成一次性配对 token,用于扩展绑定当前 Poco 用户。
  • 展示已同步站点和清除入口。

5.3 Backend

  • 提供用户态 Auth State 读取、提交和清空接口。
  • 复用现有 Auth State 加密存储和三方合并逻辑。
  • 校验用户身份,确保只能操作当前用户自己的 Auth State。
  • 记录 updated_by_run_id,区分本地浏览器导入来源。
  • 提供一次性配对 token 的生成、校验和失效机制。

6. 数据模型

本地浏览器同步继续使用现有 Auth State 结构:

{
  "cookies": [
    {
      "name": "sid",
      "value": "...",
      "domain": ".example.com",
      "path": "/",
      "expires": 1767225600,
      "httpOnly": true,
      "secure": true,
      "sameSite": "Lax"
    }
  ],
  "local_storage": {
    "https://example.com": {
      "token": "...",
      "user_id": "123"
    }
  },
  "observed_scopes": {
    "cookie_domains": [".example.com"],
    "local_storage_origins": ["https://example.com"]
  },
  "tombstones": {
    "cookies": [
      {
        "name": "sid",
        "domain": ".example.com",
        "path": "/"
      }
    ],
    "local_storage": [
      {
        "origin": "https://example.com",
        "key": "token"
      }
    ]
  }
}

扩展本地仅保存同步基线:

{
  "base_version": 12,
  "base_state": {}
}

说明:

  • base_state 用于生成增量变更和 tombstone。
  • 扩展本地不得长期保存 Poco 访问令牌明文。
  • 如果需要保存扩展会话凭据,应使用 Chrome extension storage,并尽量使用短期 token。

7. Backend 接口建议

7.1 生成配对 Token

POST /api/v1/browser-sync/pairing-token

用途:

  • 前端在用户登录后生成一次性配对 token。
  • 用户复制或通过扩展跳转完成绑定。
  • token 应具备短有效期,并且使用后立即失效。

返回:

{
  "pairing_token": "pst_xxx",
  "expires_at": "2026-05-03T10:00:00Z"
}

7.2 读取当前用户 Auth State 快照

GET /api/v1/auth-state/snapshot

说明:

  • 用户态接口使用当前登录用户身份,不允许通过 query 参数指定任意 user_id
  • 返回结构可与内部 snapshot 接口保持一致。

7.3 提交本地浏览器状态

POST /api/v1/auth-state/commit

请求:

{
  "base_version": 12,
  "base_state": {},
  "new_state": {},
  "run_id": "local_browser:device_xxx"
}

说明:

  • run_id 使用 local_browser:{device_id} 格式,便于审计来源。
  • Backend 继续执行现有三方合并。
  • 返回最新版本和合并后的 state,供扩展刷新本地基线。

7.4 清空本地同步登录态

DELETE /api/v1/auth-state

说明:

  • 清空当前用户的 Auth State。
  • Frontend 和扩展都应提供清空入口。
  • 清空后远程浏览器和任务浏览器不再恢复旧登录态。

8. 扩展设计

8.1 Manifest 权限

建议使用 Manifest V3:

{
  "manifest_version": 3,
  "name": "Poco Browser Sync",
  "permissions": ["cookies", "storage", "scripting"],
  "host_permissions": ["https://api.poco.example.com/*"],
  "optional_host_permissions": ["https://*/*", "http://*/*"],
  "background": {
    "service_worker": "background.js"
  },
  "action": {
    "default_popup": "popup.html"
  }
}

说明:

  • host_permissions 默认只包含 Poco API 域名。
  • 目标站点权限通过 optional_host_permissions 在用户操作时申请。
  • 不建议默认申请 <all_urls> 并后台静默同步。

采集规则:

  • 仅调用 chrome.cookies.getAll 读取用户已授权 domain。
  • 过滤过期 Cookie。
  • 保留 httpOnlysecuresameSiteexpires 等字段。
  • 删除语义只能来自已观测 domain 的差异。

8.3 localStorage 采集

采集规则:

  • 仅对用户授权 origin 注入 content script。
  • 在页面上下文读取 localStorage
  • 读取失败不生成 tombstone。
  • 未打开或未成功注入的 origin 不参与删除判断。

8.4 同步模式

MVP 只支持手动同步:

  1. 用户打开扩展 popup。
  2. 用户选择当前站点或输入需要同步的站点。
  3. 扩展申请站点权限。
  4. 用户点击“同步”。
  5. 扩展读取 Cookie 和 localStorage。
  6. 扩展提交到 Backend。
  7. 扩展刷新本地 base_version/base_state

后续如需自动同步,可以在用户显式开启后,仅对已授权站点做低频增量同步。

9. 关键时序

9.1 首次配对

  1. 用户在 Poco Frontend 打开“同步本地浏览器登录态”。
  2. Frontend 调 Backend 生成一次性 pairing token。
  3. 用户在扩展中输入或自动带入 pairing token。
  4. 扩展调用 Backend 完成绑定。
  5. Backend 返回扩展可用的短期会话凭据。
  6. 扩展拉取当前 Auth State snapshot,保存为本地基线。

9.2 手动导入本地站点登录态

  1. 用户在扩展中选择需要同步的站点。
  2. 扩展申请该站点 host permission。
  3. 扩展读取 Cookie。
  4. 扩展注入 content script 读取 localStorage。
  5. 扩展生成 new_stateobserved_scopes 和必要 tombstones。
  6. 扩展调用 Backend commit。
  7. Backend 合并并加密保存。
  8. 扩展更新本地基线。

9.3 后续任务浏览器复用

  1. Executor Manager 在任务启动前拉取 Auth State snapshot。
  2. Executor 将状态注入任务浏览器。
  3. 用户本地导入的登录态在任务浏览器中生效。
  4. 任务结束后继续按现有 Auth State 流程提交最终状态。

9.4 清空同步数据

  1. 用户在 Frontend 或扩展中点击清空登录态。
  2. Backend 清空当前用户 Auth State。
  3. 扩展清理本地同步基线。
  4. 后续远程浏览器和任务浏览器不再恢复旧登录态。

10. 合并与删除规则

本地浏览器同步必须沿用现有三方合并规则:

  • Cookie 主键:(name, domain, path)
  • localStorage 主键:(origin, key)
  • new 相对 base 未变:保留 Backend 当前状态。
  • new 相对 base 有变:应用本地浏览器状态。
  • 删除必须来自 tombstones
  • 只有已观测的 domain/origin/key 才允许产生 tombstone。
  • 读取失败、权限缺失、页面无法注入时,不生成删除语义。

该规则可以避免本地浏览器扩展因为权限不足或页面未打开而误删 Poco 中已有的其他站点登录态。

11. 安全与隐私控制

必须实现:

  • 用户显式触发同步。
  • 用户显式授权站点范围。
  • UI 展示将同步的站点和数据类型。
  • HTTPS 传输。
  • Backend 加密保存 Auth State。
  • 当前用户隔离,不能跨用户访问或提交。
  • 提供清空 Auth State 的入口。
  • 配对 token 短有效期、一次性使用。
  • 扩展本地最小化保存数据。

不允许:

  • 静默扫描所有网站。
  • 默认后台上传全部 Cookie/localStorage。
  • 直接读取本机 Chrome profile 文件。
  • 将登录态数据用于广告、画像、分析、交易或第三方共享。
  • 在日志中输出 Cookie value 或 localStorage value。

12. 非目标

  • 不实现完整 Chrome profile 同步。
  • 不读取 IndexedDB、ServiceWorker、CacheStorage、sessionStorage 和浏览器缓存。
  • 不反向写回用户本地浏览器。
  • 不实现跨用户共享登录态。
  • 不同步浏览历史、书签、密码、表单、支付信息。
  • 不默认支持所有网站自动后台同步。

13. 实施步骤

  1. Backend:新增用户态 Auth State snapshot/commit/clear 接口,复用现有 Auth State Service。
  2. Backend:新增 browser sync pairing token 生成、校验和失效逻辑。
  3. Frontend:新增本地浏览器同步入口,展示隐私说明、配对 token、已同步站点和清空入口。
  4. Extension:实现 Manifest V3 扩展骨架、配对流程和本地基线保存。
  5. Extension:实现站点授权、Cookie 采集、localStorage 采集和手动提交。
  6. 联调:验证本地导入后远程浏览器和任务浏览器能复用登录态。
  7. 安全检查:确认日志脱敏、HTTPS、最小权限、删除语义和用户隔离。
  8. 文档:补充用户隐私说明、扩展权限说明和删除数据说明。

14. 验收标准

  • 用户安装扩展并完成配对后,可以选择指定站点同步登录态。
  • 未授权的站点不会被读取或上传。
  • 本地浏览器同步后,Poco 远程浏览器可以恢复该站点登录态。
  • 本地浏览器同步后,Poco 任务浏览器可以恢复该站点登录态。
  • 扩展读取某个 origin 的 localStorage 失败时,不会误删 Backend 中已有状态。
  • 用户清空 Auth State 后,后续远程浏览器和任务浏览器不再恢复旧登录态。
  • Backend 日志和扩展日志不输出 Cookie/localStorage 明文值。
  • 并发任务和本地浏览器同步同时提交时,不会整包覆盖彼此状态。

15. 风险评估

15.1 隐私风险

登录态属于高敏数据,扩展必须做到用户可见、站点级授权、最小化采集,并提供清空能力。

15.2 误删风险

localStorage 依赖页面注入,可能因为权限、CSP、页面未打开或脚本失败导致读取不完整。处理策略是读取失败不生成 tombstone,未观测范围不参与删除。

15.3 兼容风险

不同站点登录态实现不一致,部分站点依赖 IndexedDB、ServiceWorker、CacheStorage、设备指纹或二次校验。当前方案只承诺 Cookie + localStorage 范围内的复用能力。

15.4 上架合规风险

Chrome Web Store 对用户数据用途、权限申请和隐私政策要求严格。扩展上架前必须准备隐私政策,清楚说明数据用途,并避免申请过宽权限。

16. 推荐结论

本地浏览器登录态同步应采用 Chrome/Edge 扩展方案,由用户手动选择站点并显式授权后,将 Cookie + localStorage 导入 Poco Backend Auth State。

不建议直接扫描用户本机 Chrome profile 文件,也不建议默认后台全量同步所有站点。该方案技术上可行,架构上能复用现有 Auth State,合规上更容易满足 Chrome 扩展政策要求。

On this page