Gaavala 如何保护你的会议音频:隐私优先的架构

每个工作日,都有数以百万计的专业人士坐进讨论敏感信息的会议——并购谈判、患者问诊、法律策略、季度业绩预览、人事决定。当这些会议跨越语言障碍时,实时翻译就成了必需品。但大多数会议翻译工具都要求你把原始音频发送到某个供应商的云端,而这恰好制造出法务、合规和安全团队越来越无法批准的那种数据暴露面。

Gaavala 的架构设计目标,是把自己整个从音频路径上移除。当你通过我们的 Chrome 扩展程序跑一场会议时,你的音频不会流经 Gaavala 的服务器。它通过一条加密 WebSocket,从你的浏览器直接流向 Soniox 语音转文字引擎——而我们的后端从头到尾看不到其中的任何一个字节。

本文完整讲清这套机制如何运作、哪些数据会经过网络,以及这套架构如何对应到常见的合规框架。

核心隐私原则

大多数 SaaS 翻译工具遵循一条熟悉的数据流:

  1. 你的浏览器采集会议音频
  2. 音频被上传到供应商的后端
  3. 供应商的后端把音频转发给一个语音转文字引擎
  4. 转录结果经由供应商的后端返回
  5. 供应商的服务器往往会在这条路径上记录、缓存或留存音频

这条链路上的每一跳都是一道信任边界。每一跳都是一个可能因为一个日志 bug、一次凭据泄露、一张传票或一名心怀不轨的工程师而暴露你会议内容的位置。碰过音频的方越多,你就越难向审计人员证明没有任何一方留存过它。

Gaavala 彻底去掉了中转这一步。数据流是这样的:

  1. 你的浏览器从标签页采集会议音频
  2. 你的浏览器向 Soniox 打开一条直连 WebSocket
  3. 音频直接通过这条 WebSocket 流出
  4. Soniox 把转录结果直接返回给你的浏览器
  5. Gaavala 的后端从不参与

运行在你机器上的这个 Chrome 扩展程序,是我们的代码中唯一碰到你音频的部分——而它不会把这些音频发送给我们。

我们为什么选择这套架构

当我们把 Gaavala 重建为一个 Chrome 扩展程序时,我们做了一个有意为之的架构决定:扩展程序通过我们的后端完成用户身份验证、管理订阅状态、提供元数据——但它绝不进入音频路径。理由很直接:

数据流详解

我们来看看,你在一场会议中启动转录时究竟发生了什么。

第 1 步:身份验证

你第一次登录 Gaavala 时,扩展程序使用 Chrome 的 chrome.identity.launchWebAuthFlow API,与 Google 或 Microsoft 完成一次 OAuth Authorization Code 流程。身份提供方把授权码返回给你的浏览器,扩展程序再用它向我们的后端换取一个 Gaavala 会话 JWT。这个 JWT 保存在 chrome.storage.local 中,用于验证后续发往我们后端的 API 调用。

这一切都不涉及音频。OAuth 流程只有文本——令牌、声明、资料字段。

第 2 步:临时 Soniox 密钥

当你在一场会议中点击 Start(开始)时,扩展程序会调用我们的后端 API,请求一个短时效的 Soniox 临时密钥。这个密钥有三条重要性质:

临时密钥这个模式对整个隐私叙事至关重要。如果 Gaavala 把一个长期有效的 Soniox API 密钥打包进扩展程序,任何人都能把它提取出来。因此我们改为签发一次性的密钥:按需铸造、绑定到你已通过验证的会话,并在会话结束后不久失效。

我们的后端只记录这次请求的元数据——哪个用户、什么时间、什么套餐档位。它看不到任何音频,因为此时还没有任何音频被采集。

第 3 步:标签页音频采集

你在一个 Chrome 标签页中加入 Microsoft Teams、Zoom、Google Meet 或 Webex 通话。Gaavala 扩展程序打开侧边面板,提示你开始采集音频。你确认之后,扩展程序调用 Chrome 的 tabCapture API——这是一个仅供扩展程序使用的 API,需要明确的用户授权,并带有一个可见的采集指示。

Chrome 把采集到的音频送入 Gaavala 在后台运行的一个 offscreen 文档。offscreen 文档是一个沙箱化的页面,扩展程序可以用它处理音频,而不必保留可见界面。在这个 offscreen 文档内部,Gaavala 打开一个 MediaStream,把它接入一个 AudioContext,并为流式传输做好准备。

关键的一点是:音频同时经过一个本地音频图回灌到你的扬声器。这意味着 Gaavala 在采集的同时,你依然能正常听到会议——没有任何声音被静音或改道。

第 4 步:直连 Soniox 的 WebSocket

随后,offscreen 文档直接向 Soniox(wss://stt-rt.soniox.com/...)打开一条 WebSocket 连接。这条连接:

从标签页采集到的音频帧被编码为 PCM,通过这条 WebSocket 发送出去。Soniox 实时处理它们,并通过同一条连接把转录 token 流式传回。这些 token——带时间戳、带说话人标签的文本片段——直接抵达 offscreen 文档,再由它转发给侧边面板显示。

在这整个回路中,没有任何一个音频数据包会到达由 Gaavala 运营的服务器。你可以用 Chrome DevTools 自己验证这一点:在 Gaavala 运行时打开 Network 面板并开启 WS 筛选,你会看到恰好一条 WebSocket——指向一个 soniox.com 主机——以及零条发往 gaavala.com 的、包含音频的出站流量。

第 5 步:转录稿显示与可选的摘要

转录 token 会渲染到三个界面:侧边面板、会议标签页上的悬浮覆盖层,以及用于导出的内存缓冲区。这些界面都不会序列化音频,它们只处理文本。

当你在会议结束时触发 AI 摘要,这份摘要完全由 Chrome 内置 AI(Gemini Nano)在你的设备上生成。转录文本从不离开你的机器——它不会被发送到 Gaavala 的后端,也不会被发送给任何第三方。会议内容,无论是音频还是文本,从来都不经过 Gaavala 的后端;唯一经过的,始终只有身份验证和订阅元数据。

Gaavala 服务器能看到哪些数据

以下是我们的后端在所有功能中处理的数据的完整清单:

数据 何时 留存 说明
Gaavala 会话刷新令牌 登录时 令牌的有效期——已过期的记录每天清理一次 我们从不存储你的 Google/Microsoft OAuth 令牌
用户资料(邮箱、姓名) 登录时 账户生命周期 用于计费与支持
订阅状态 始终 账户生命周期 套餐档位、试用状态
临时 Soniox 密钥请求 每次会话 仅请求日志 不含音频
转录分钟计数器 每次会话 账户生命周期 按月分桶,用于配额执行
匿名网站分析 仅在你接受 Cookie 之后 由 Google Analytics 保存,不在我们的数据库中 仅限网站——扩展程序上报的是不含用户 ID 的匿名错误计数

以下是我们的后端看不到的数据的完整清单:

如果法院向 Gaavala 传票索要某一场特定会议的音频,技术上诚实的回答会是:我们没有它,也无法取回它。它从未在我们的系统上存在过。

自己动手审计

以 Chrome 扩展程序的形态运行,好处之一是整个运行时都可以被检视。你的 IT 团队无需相信本文的任何一个字,就能验证我们的隐私声明:

**方法 1——网络检查。**打开 chrome://extensions,找到 Gaavala,点击 “service worker” 或 “inspect views > background page”。在 DevTools 中切到 Network 面板,按 WS(WebSocket)筛选。开始一场会议。你会看到恰好一条被打开的 WebSocket,指向一个 soniox.com 主机。没有任何音频发往 gaavala.com

**方法 2——清单检查。**在 chrome://extensions 中展开 Gaavala 的 “Details”(详细信息),查看它的权限。host_permissions 精确声明了扩展程序能够访问哪些来源。你会看到用于流式传输的 Soniox 端点,以及用于认证和订阅的 Gaavala 端点。没有通配符主机权限,也没有未声明的网络访问。

**方法 3——源码检查。**扩展程序附带一个 service worker、一个 offscreen 文档、侧边面板和内容脚本。Chrome 通过开发者工具把这些全部开放给检视。你的安全团队可以随时挂载到后台页面或 offscreen 文档上,读取运行时状态——包括确认音频流对象从未被序列化进任何指向我们域名的 fetch 或 XHR。

我们把清单和主机权限作为 Chrome Web Store 列表的一部分公开,也欢迎第三方安全审查。

合规对应

GDPR 与数据最小化

GDPR 第 5(1)(c) 条确立了数据最小化原则:个人数据必须“充分、相关,并限于必要范围”。在 GDPR 之下,语音数据属于个人数据;若被用于识别身份,则属于生物特征数据。

Gaavala 的架构与这条原则直接对齐。通过把音频完全挡在我们的系统之外,我们把所处理的个人数据压到了运营一门订阅生意所需的绝对下限——邮箱、姓名、计费状态。对于要做 DPIA 的客户而言,我们的后端在音频处理这一项上实质上是透明的:没有什么可评估的,因为没有任何东西到达我们这里。

在你的合规链路中,Soniox 是一个独立的处理方。你可以独立审阅它的隐私姿态;Soniox 也公布了适用于你的浏览器与它之间那条直连的数据处理条款。

HIPAA 与包含 PHI 的音频

在 HIPAA 之下,任何处理、存储或传输受保护健康信息的供应商都必须签署业务伙伴协议。医疗问诊经常包含 PHI——患者姓名、诊断、治疗方案。

由于 Gaavala 的后端从不接收会议音频,音频管线不在 Gaavala 的 BAA 范围之内。你需要为这段音频处理评估的关系,是你与 Soniox 之间的直接关系——Gaavala 不是这份数据的业务伙伴,因为这份数据根本不接触我们。如果你生成 AI 摘要,它们由 Chrome 内置 AI 在设备端产生——转录文本留在你的机器上,因此摘要功能同样不会把 Gaavala 或任何额外的供应商带进 PHI 处理链路。

SOC 2 供应商风险

SOC 2 审计要求组织记录并评估其数据处理链路中的所有第三方供应商。每多一个供应商,你的系统说明就更复杂一分,风险评估的范围也随之扩大。

在 Gaavala 的架构中,Soniox 是你直接打交道的数据处理方,而不是通过 Gaavala 打交道。你的供应商风险登记表应当按 Soniox 自身的条件来评估它——许多安全团队认为这比评估一层次级处理方关系更直截了当。Gaavala 在你风险登记表中的范围更窄:我们处理身份与计费,不处理原始音频,也不处理转录稿或摘要文本——那些从不离开用户的机器。

为什么 Chrome 扩展程序这种形态很重要

上面很多隐私保证,都依赖于 Gaavala 以 Chrome 扩展程序的形态运行,并采用直连供应商的网络模式。我们考虑过、也否决了几种替代方案:

Chrome 扩展程序这种形态,独一无二地成全了我们想要的这套隐私架构。tabCaptureoffscreen 文档和 Manifest V3 的 service worker 模型合在一起,让扩展程序可以完全在用户的机器上处理音频、直接向外部服务打开连接,并维持长会议所需的后台状态——而不必让任何东西经过我们。

我们仍然必须做对的那些事

隐私架构不会止步于“我们不碰音频”。还有一些相邻的问题,我们同样认真对待:

会议翻译工具横向对比

Gaavala 的隐私模型与其他常见的会议翻译工具相比如何?

特性 Gaavala Otter.ai Zoom AI Companion Teams Copilot Interprefy
音频到达供应商后端 否(直连 Soniox) 是(Otter 服务器) 是(Zoom 服务器) 是(M365 服务器) 是(平台服务器)
会后留存音频 是(默认) 可选 可选 视情况而定
用于模型训练 可选择退出 可选择退出 企业级管控 未知
自己审计网络 可以(DevTools) 不可以 不可以 不可以 不可以
以扩展程序形态运行(可审计)
跨 Teams/Zoom/Meet/Webex 通用 部分 视情况而定

真正起决定作用的那点差别是:在这张表的其他每一行里,你都是在相信供应商关于音频如何在其服务器上被处理的说法。而在 Gaavala 这里,音频没有需要你去信任的服务器,因为我们的服务器上根本没有音频。这个说法可以用标准的 Chrome 开发者工具验证。

隐私是默认项,不是付费档位

Gaavala 的免费档位提供同样的直连 Soniox 架构、同样的说话人分离、同样的 60 语言覆盖。Pro 解锁的是每天 120 分钟、Speak Mode 和声音克隆——不是隐私。我们不认为在意隐私的用户应该为了保护自己的数据而多付钱。

如果你的组织过去一直拒绝会议翻译工具,因为合规部门不同意把音频发到供应商的云端,那么 Gaavala 正是为这场对话而建的。这条管线的设计意图,是让你的法务、安全和合规团队要审的东西更少,而不是更多。

把 Gaavala 添加至 Chrome →

一次性免费试用:5 分钟转录,永不重置。无需信用卡。网站上无需注册。


相关文章

更多 Gaavala 指南