How Gaavala Protects Your Meeting Audio: A Privacy-First Architecture

Every workday, millions of professionals join meetings where sensitive information is discussed — merger negotiations, patient consultations, legal strategy, quarterly earnings previews, personnel decisions. When those meetings cross language barriers, real-time translation becomes essential. But most meeting translation tools require sending your raw audio to a vendor cloud, creating exactly the kind of data exposure surface that legal, compliance, and security teams increasingly cannot approve.

Gaavala is architected to remove itself from the audio path entirely. When you run a meeting through our Chrome extension, your audio does not travel through Gaavala servers. It streams directly from your browser to the Soniox speech-to-text engine over an encrypted WebSocket — and our backend never sees a single byte of it.

This post walks through exactly how that works, what data crosses the wire, and how the architecture maps to common compliance frameworks.

The Core Privacy Principle

Most SaaS translation tools follow a familiar data flow:

1. Your browser captures meeting audio
2. Audio is uploaded to the vendor's backend
3. The vendor's backend proxies the audio to a speech-to-text engine
4. Transcripts return via the vendor's backend
5. Vendor servers often log, cache, or retain the audio along the way

Every hop in that chain is a trust boundary. Every hop is a place where a logging bug, a credential leak, a subpoena, or a rogue engineer could expose your meeting content. The more parties touch the audio, the harder it is to prove to an auditor that nobody retained it.

Gaavala eliminates the proxy step entirely. The data flow is:

1. Your browser captures meeting audio from the tab
2. Your browser opens a direct WebSocket to Soniox
3. Audio streams directly over that WebSocket
4. Soniox returns transcripts directly to your browser
5. Gaavala's backend is never involved

The Chrome extension running on your machine is the only piece of our code that ever touches your audio — and it does not send that audio to us.

Why We Chose This Architecture

When we rebuilt Gaavala as a Chrome extension, we made a deliberate architectural decision: the extension would authenticate users through our backend, manage subscription state, and serve metadata — but it would never be in the audio path. The reasoning was straightforward:

• Compliance surface: Every byte of customer audio we process is a byte we have to account for in DPIAs, SOC 2 reports, and BAA negotiations. The cleanest way to keep that surface at zero is to never touch the audio in the first place.
• Security blast radius: A breach in a server that processes audio is fundamentally worse than a breach in a server that processes text metadata. We would rather have our most sensitive systems handle the least sensitive data.
• Latency: Every proxy hop adds round-trip time. Direct browser-to-Soniox streaming removes a full hop, giving us noticeably better caption latency.
• Costs that align with privacy: Running our own audio proxy would mean paying for bandwidth and compute on every meeting. Not running one saves money and protects customers. When incentives align, the architecture tends to stay honest.

The Data Flow in Detail

Let's look at what actually happens when you start transcription in a meeting.

Step 1: Authentication

When you first sign in to Gaavala, the extension uses Chrome's chrome.identity.launchWebAuthFlow API to complete an OAuth Authorization Code flow with either Google or Microsoft. The identity provider returns an authorization code to your browser, which the extension exchanges with our backend for a Gaavala session JWT. That JWT is stored in chrome.storage.local and is used to authenticate subsequent API calls to our backend.

None of this handles audio. The OAuth flow is text-only — tokens, claims, profile fields.

Step 2: Temporary Soniox Key

When you click "Start" on a meeting, the extension calls our backend API to request a short-lived Soniox temporary key. This key has three important properties:

• It is scoped to speech-to-text only — nothing else in the Soniox API surface
• It expires in minutes, not days
• It is issued once per session and is not persisted on your device

The temporary key pattern is critical to the privacy story. If Gaavala shipped a long-lived Soniox API key inside the extension bundle, anyone could extract it. Instead, we issue disposable keys that are minted on demand, bound to your authenticated session, and invalidated shortly after the session ends.

Our backend logs only the metadata of this request — which user, what time, what plan tier. It does not see any audio because no audio has been captured yet.

Step 3: Tab Audio Capture

You join your Microsoft Teams, Zoom, Google Meet, or Webex call in a Chrome tab. The Gaavala extension opens the side panel and prompts you to start capturing audio. When you confirm, the extension uses the Chrome tabCapture API — an extension-only API that allows capturing audio from the active tab with explicit user permission and a visible indicator.

Chrome routes the captured audio into an offscreen document that Gaavala runs in the background. The offscreen document is a sandboxed page the extension can use to handle audio processing without keeping visible UI around. Inside that offscreen document, Gaavala opens a MediaStream, connects it to an AudioContext, and prepares it for streaming.

Crucially, the audio also passes through a local audio graph that pipes the sound back to your speakers. This means you can still hear the meeting normally while Gaavala is capturing it — nothing is muted or redirected.

Step 4: Direct WebSocket to Soniox

The offscreen document then opens a WebSocket connection directly to Soniox (wss://stt-rt.soniox.com/...). This connection:

• Uses TLS 1.2 or higher
• Is authenticated with the short-lived temporary key from Step 2
• Originates from your browser's network stack — packets flow from your OS to Soniox, not to Gaavala

The audio frames captured from the tab are encoded as PCM and sent over the WebSocket. Soniox processes them in real time and streams transcription tokens back over the same connection. Those tokens — timestamped text fragments with speaker labels — arrive directly in the offscreen document, which forwards them to the side panel for display.

At no point in this entire loop does an audio packet reach a Gaavala-operated server. You can verify this yourself using Chrome DevTools: open the Network tab with WS filter on while Gaavala is running, and you will see exactly one WebSocket — to a soniox.com host — and zero outbound traffic to gaavala.com containing audio.

Step 5: Transcript Display and Optional Summary

Transcription tokens are rendered in three surfaces: the side panel, a floating overlay on the meeting tab, and the in-memory buffer used for export. None of these surfaces serialize audio. They handle text only.

When you trigger an AI summary at the end of a meeting, the summary is generated entirely on your device by Chrome's built-in AI (Gemini Nano). The transcript text never leaves your machine — it is not sent to Gaavala's backend, and it is not sent to any third party. Meeting content, whether audio or text, never crosses Gaavala's backend at all; the only thing that ever does remains authentication and subscription metadata.

What Data Gaavala Servers See

Here is the exact list of data our backend handles, across all features:

Here is the exact list of data our backend does not see:

• Raw meeting audio (any format, at any point)
• Compressed audio streams
• Audio buffers or intermediate representations
• Voice biometric data
• Speaker identity beyond the anonymous speaker IDs Soniox assigns
• Transcript text — summaries are generated on-device; transcripts never leave your machine

If a court subpoenaed Gaavala for the audio of a specific meeting, the technically truthful answer would be that we do not have it and cannot retrieve it. It never existed on our systems.

Audit It Yourself

One of the advantages of running as a Chrome extension is that the entire runtime is inspectable. Your IT team can verify our privacy claims without trusting a single word of this post:

Method 1 — Network inspection. Open chrome://extensions, find Gaavala, click "service worker" or "inspect views > background page". In DevTools, go to the Network tab, filter by WS (WebSocket). Start a meeting. You will see exactly one WebSocket opened, to a soniox.com host. No audio goes to gaavala.com.

Method 2 — Manifest inspection. In chrome://extensions, expand "Details" on Gaavala and review the permissions. The host_permissions declare exactly which origins the extension can reach. You will see Soniox endpoints for streaming and Gaavala endpoints for auth and subscription. There is no wildcard host permission and no undeclared network access.

Method 3 — Source inspection. The extension ships with a service worker, offscreen document, side panel, and content scripts. Chrome exposes all of these for inspection via the developer tools. Your security team can attach to the background page or offscreen document at any time and read the runtime state — including confirming that the audio stream object is never serialized to a fetch or XHR toward our domain.

We publish the manifest and host permissions as part of the Chrome Web Store listing, and we welcome third-party security review.

Compliance Mapping

GDPR and Data Minimization

Article 5(1)(c) of the GDPR establishes the data minimization principle: personal data must be "adequate, relevant and limited to what is necessary." Voice data is personal data under GDPR, and biometric data if used for identification.

Gaavala's architecture aligns directly with this principle. By keeping audio out of our systems entirely, we minimize the personal data we process to the absolute minimum required to run a subscription business — email, name, billing state. For customers running DPIAs, our backend is effectively transparent on audio processing: there is nothing to assess because nothing reaches us.

Soniox is a separate processor in your compliance chain. You can review their privacy posture independently, and Soniox publishes data processing terms that apply to the direct connection your browser makes to them.

HIPAA and Audio Containing PHI

Under HIPAA, any vendor that processes, stores, or transmits Protected Health Information must sign a Business Associate Agreement. Medical consultations frequently contain PHI — patient names, diagnoses, treatment plans.

Because Gaavala's backend never receives meeting audio, the audio pipeline is outside Gaavala's BAA scope. The relationship you evaluate for the audio processing is between you and Soniox directly — Gaavala is not a business associate for that data because the data does not touch us. If you generate AI summaries, those are produced on-device by Chrome's built-in AI — the transcript text stays on your machine, so the summary feature does not bring Gaavala or any additional vendor into the PHI processing chain either.

SOC 2 Vendor Risk

SOC 2 audits require organizations to document and assess all third-party vendors in their data processing chain. Every vendor adds complexity to your System Description and increases the scope of your risk assessment.

In Gaavala's architecture, Soniox is a data processor you interact with directly, not through Gaavala. Your vendor risk registry should evaluate Soniox on its own terms, which many security teams find more straightforward than evaluating a sub-processor relationship. Gaavala's scope in your risk registry is narrower: we handle identity and billing — not raw audio, and not transcript or summary text, which never leaves the user's machine.

Why the Chrome Extension Form Factor Matters

A lot of the privacy guarantees above depend on Gaavala running as a Chrome extension with a direct-to-provider network pattern. We considered, and rejected, several alternatives:

• Server-side audio proxy: Straightforward to implement, but it would force us to handle every customer's audio on our own infrastructure. This is what we explicitly wanted to avoid.
• Web app with embedded STT: Tab audio capture from a web page requires getDisplayMedia, which prompts the user with an OS-level picker every session and ties the extension to whichever tab they select. Worse, there is no reliable way for a web page to maintain a background audio stream while the user interacts with other tabs.
• Desktop native app: Would give us more control but add install friction, signing costs, and OS-specific development burden. And it still would not eliminate our role as the audio processor unless we were careful — which means we would reinvent all the same problems.

The Chrome extension form factor uniquely enabled the privacy architecture we wanted. tabCapture, offscreen documents, and the Manifest V3 service worker model together let the extension handle audio entirely on the user's machine, open direct connections to external services, and maintain the background state needed for long meetings — without routing anything through us.

The Things We Still Have To Get Right

Privacy architecture does not end with "we don't touch the audio." There are adjacent concerns we also take seriously:

• Temporary key minting: The short-lived Soniox keys we mint could be abused if our backend mints keys for an attacker. We authenticate every request with your JWT, we rate limit key issuance, and we log anomalies.
• Extension updates: An updated extension version could in theory change the network pattern. We version the manifest, we publish changelogs, and the Chrome Web Store surfaces any new permissions before an update installs.
• Summary text: Summaries are generated entirely on-device by Chrome's built-in AI (Gemini Nano), so the transcript never reaches our backend — this risk does not exist in the current architecture. If even local AI processing is more than a given meeting can tolerate, the summary feature can simply remain unused; nothing else depends on it.
• Voice-clone reference sample (Pro): if you create a personal voice clone, your ~20-second sample is stored encrypted (AES-256-GCM) on Gaavala's servers, used only to build your voice, and deleted on request — see the Privacy Policy.
• Legal requests: We commit publicly to responding to legal requests only for data we actually hold. For audio, that will always be "we do not have it."

Compared Across Meeting Translation Tools

How does Gaavala's privacy model compare to other common meeting translation tools?

The differentiator that matters: in every other row of that table, you are trusting the vendor's claims about how audio is handled on their servers. With Gaavala, there are no servers to trust for audio because there is no audio on our servers. The claim is verifiable with standard Chrome developer tools.

Privacy Is the Default, Not a Paid Tier

Gaavala's free tier gets you the same direct-to-Soniox architecture, the same speaker diarization, the same 60 language coverage. Pro unlocks 120 minutes per day, Speak Mode, and voice cloning — not privacy. We do not believe privacy-conscious users should pay more to keep their data safe.

If your organization has historically rejected meeting translation tools because compliance said no to sending audio to a vendor cloud, Gaavala was built for that conversation. The pipeline is designed so your legal, security, and compliance teams have less to review — not more.

Add Gaavala to Chrome →

One-time free trial: 5 minutes of transcription, never resets. No credit card. No sign-up on the website.

Related Articles

• How to Translate a Zoom Meeting with the Gaavala Extension
• How to Translate a Microsoft Teams Meeting