[分享创造] 写了个自托管的 Chrome 同步服务器，书签密码再也不经过 Google

你用 Chrome 的时候，有没有意识到自己其实是在给 Google “写日记”？

每一条存下的书签、每一个自动保存的密码、甚至你此时此刻开着哪些标签页，全都在往 clients4.google.com 发送 POST 请求。想把这些隐私数据从大厂硬盘里拿回来？其实原理很简单：利用 Chromium 内置的 --sync-url 隐藏参数，把流量导向自建后端。

这就有了 selfsync：一个用 Rust 写的、基于 GPL-3.0 协议的自托管 Chrome 同步服务器。

仓库：https://github.com/loyalpartner/selfsync

中文 README：https://github.com/loyalpartner/selfsync/blob/master/README.zh-CN.md

核心实现：两步搞定私有同步

这套方案的高明之处在于它不改变你的任何使用习惯。你依然用 Chrome，依然登录 Google 账号，只是数据流的终点变了。

直接用 Docker Compose 压榨性能，一行命令起飞：

docker compose up -d

修改 Chrome 的启动参数，强行把同步地址指向你的私有服务器：

google-chrome-stable --sync-url=http://你的服务器IP:8080

(Windows 用户直接在快捷方式属性的“目标”后面空格加上这段就行)。

很多人用 Floccus 或 xBrowserSync，但那些只是“书签同步”的插件，底层走的是 WebDAV。selfsync 接管的是 Chrome 原生同步总线。

多用户自动隔离：别看配置简单，Chrome 每次同步的 protobuf 字段里其实带了登录邮箱。selfsync 会自动按邮箱切分数据空间，家里人共用一套服务完全不打架，实现零配置多租户。
端到端加密 (E2EE)：这步非常关键。Chrome 的密码在上传前会用你的账号密钥在本地加密。换句话说，selfsync 的 SQLite 数据库里存的全是密文。就算服务器被黑，没你账号密钥，别人也看不了明文密码。(实测安全强度等同于 Bitwarden)。
全量覆盖：不仅是书签，HISTORY (历史记录)、OPEN_TABS (打开的标签页)、EXTENSION (扩展)、AUTOFILL (自动填充) 几十种数据类型全部支持。

这里有个目前绕不过去的坑：移动端没戏。
Android 和 iOS 的 Chrome 不支持自定义启动参数。如果你有移动端同步的刚需，可以尝试 Kiwi Browser，或者干脆只在桌面端享受这种“数据回家的爽感”。

selfsync 核心逻辑就是照着 Chromium 源码里的 .proto 文件把请求拆开再装回去。它比翻 Chromium 源码简单得多，如果你对 Chrome Sync 协议感兴趣，直接看它的 Rust 实现就能摸清门路。

把数据从加州机房搬回自家 NAS 的感觉确实难形容。如果你也在折腾自托管（Self-hosted），会为了这最后一块数据隐私拼图去折腾个私有同步服吗？