MeetKB — Privacy Policy

AI Meeting Intelligence — record, transcribe, and answer questions against your own knowledge bases.

Last updated: May 26, 2026

What MeetKB Is

MeetKB is delivered through two coordinated surfaces that share a single user account and a single backend at meet.brilworks.com:

• The Chrome extension — runs in your browser while you are in a Google Meet call. It captures the video and audio from your Meet browser tab into a .webm file on your own machine, and (when signed in) streams a live transcript, detects questions, extracts action items, auto-summarizes on stop, and lets you ask questions grounded in your knowledge bases.
• The web app at meet.brilworks.com — serves the same user account a hosted admin panel (/admin), a member dashboard (/dashboard), a meeting drilldown (/admin/history), a profile editor (/profile), and the sign-in page (/login). Admins can manage their team's users, knowledge bases, provider keys, usage, audit log, and AI feedback entirely from the web app without installing or opening the extension.

Audio recordings never leave your machine. The hosted service holds only the transcripts, summaries, action items, knowledge bases, detected questions, provider API keys, and account metadata for signed-in users. Owners can optionally generate a public read-only share link for any meeting (see Public share links below).

What We Collect — At a Glance

When you sign in, MeetKB collects the following categories of data, using the same taxonomy Chrome Web Store uses for its data-use disclosure. Detailed treatment of each appears in the sections below.

• Personally identifiable information — your email address, display name, and (for Google sign-in) Google subject ID and avatar URL.
• Authentication information — bcrypt-hashed passwords (for email + password sign-in), short-lived JWT access tokens and hashed refresh tokens, and Fernet-encrypted provider API keys provisioned by your admin (Groq, Deepgram, Ollama Cloud).
• Personal communications — meeting transcripts (the text of what was said during meetings you record), auto-generated summaries, extracted action items, and questions you asked the assistant. Stored to enable history replay, auto-summary, Q&A grounding, and (if you choose) sharing.
• Location (IP address) — the IP address you connect from is logged in our audit log for sign-in events, permission changes, and admin actions. We do not collect GPS, device location, or precise geolocation.
• Website content — files you upload into knowledge bases (.txt, .md, .pdf, .docx) and the text extracted from pages crawled at admin-supplied URLs. Stored as chunks for retrieval at Q&A time.

We do not collect health information, financial or payment information, web browsing history, or low-level user activity (clicks, keystrokes, mouse position, scroll). We do not sell or transfer your data to third parties outside the approved use cases listed under "Outbound Calls Made by the Server" below. We do not use your data for advertising, profiling, or determining creditworthiness.

Two Tiers of Use

The extension operates in two distinct modes. Which mode you are in determines what data, if any, leaves your device. The web app is only meaningful in the authenticated tier — the marketing landing page at meet.brilworks.com/ and the privacy policy itself are public; everything else (/admin, /dashboard, /profile, /admin/history) requires sign-in.

Anonymous tier (no sign-in)

Without signing in, the extension records the Meet tab locally and saves a .webm file to your browser's default downloads folder. No data leaves your device. No transcript, no Q&A, no server contact, no telemetry. The web app's authenticated routes refuse to load until you sign in.

Authenticated tier (hosted SaaS)

Once you sign in (Google OAuth or email + password — on either the extension's sidepanel or the web app's /login page), the same backend at meet.brilworks.com serves both surfaces. The extension sends meeting metadata, transcript segments, and Q&A history; the web app sends admin actions (user invites, key assignments, KB management) and profile edits. From the server, transcription and answer-synthesis requests fan out to the providers listed below. The server holds your provider API keys encrypted at rest; the keys are never returned to either client.

Admin-Managed Access Model

MeetKB uses an admin-managed model. Knowledge bases and knowledge-base access grants are created and assigned by your organisation's MeetKB admin from the web admin panel (meet.brilworks.com/admin). Provider API keys (Groq, Deepgram, Ollama Cloud) live in an admin-managed key pool: admins add named entries once and assign them to individual users with a single click. End users cannot add their own keys or KBs; they see only the KBs their admin has granted them access to. The GET /me/keys endpoint returns only metadata ({provider, label, configured: true}) — encrypted key values are never returned in plaintext from any endpoint.

Admins also use the web admin panel to view the audit log, per-user usage, the AI-feedback feed, and all meetings across the organisation. Each such admin view is recorded in the audit log so the organisation can review who accessed which data.

Independently of the admin model, every signed-in user can edit their own display name at any time via the web profile editor at meet.brilworks.com/profile. The avatar_url tracks your Google account picture when you sign in with Google and otherwise displays initials. Profile fields are user-controlled; admin permission is not required.

Data Sent to the MeetKB Server (signed-in users only)

• Account profile — email address, display name, and (for Google sign-in) Google subject ID and avatar URL. Used for login, audit logging, and admin access control.
• Sign-in credentials — for email + password sign-in, your password is hashed with bcrypt before storage; the plaintext is never persisted. For Google sign-in, your ID token is verified against Google's JWKS and discarded. After successful sign-in the server issues a short-lived JWT (15 min) and a hashed refresh token (14 day); the refresh-token hash is what we store, not the token itself.
• Provider API keys — Groq, Deepgram, and Ollama Cloud keys provisioned by your admin. Encrypted with Fernet before storage. The server uses them on your behalf when calling the respective provider; they are never sent back to your browser or any third party other than the provider they belong to.
• Knowledge-base content — text you paste, files you upload (.txt, .md, .pdf, .docx — 25 MB cap per file), or pages crawled from a URL you specify. Stored as chunks in the server's database and used to retrieve context for your Q&A queries. Semantic-search embeddings are generated by OpenAI and the cross-encoder reranker is run on Cloudflare Workers AI (see below).
• Meeting transcripts — live caption segments, with timestamps and the speaker's display name when Google Meet exposes it. The primary source is Meet's own caption stream (decoded from the meeting's WebRTC data channel); Deepgram or Groq is used only as a fallback when Meet's caption stream is unavailable. Each segment may also carry an internal Meet device identifier (an opaque spaces/…/devices/… token, scoped to the meeting) so we can correct a speaker label after the fact if their name resolves later in the call. The device identifier is not used outside the meeting and is purged when the meeting is deleted.
• Detected questions — questions auto-detected from your transcript during the meeting, stored so you can review them later in the meeting history. Detection runs on the server (regex scoring + LLM cleanup); no detection state lives on third-party services.
• Meeting summary — a structured auto-generated recap produced on Stop via Ollama Cloud. Stored with the meeting.
• Action items — a short bullet list (maximum 8) auto-extracted from your transcript via Ollama Cloud after each meeting finalises. Each item contains an owner, the text of the action, and an optional due hint. Stored with the meeting for display in the history popup.
• Profile updates — you may edit your display name or trigger a Google re-sync via PATCH /me and POST /auth/google/refresh-profile. Both update only the name and avatar_url fields on your own row.
• Pin and share state — per-meeting flags (pinned, share_token) set by you. Pin gives a meeting priority over unpinned siblings in the FIFO history cap's eviction order (oldest unpinned goes first); share mints a public read-only token (see next section).
• Q&A history — questions you ask, the retrieved source chunks, and the model's answers. Stored so the side panel can rehydrate past conversations and the history popup can show threaded follow-ups.
• AI content ratings — your thumbs-up / thumbs-down ratings on AI-generated content (answers, meeting summaries, action items, detected questions, and Insights tab outputs). Each rating is stored as +1 or -1 per content item against your account so we can spot model regressions and improve retrieval quality. Ratings are never associated with the names or contents of other meeting attendees. The MeetKB admin for your organisation can view aggregate ratings and (for meetings owned by users in their organisation) the per-meeting ratings you submitted, for quality review. Each such admin view is recorded in the audit log.
• Audit and security logs — sign-in events, permission changes, KB ingest, profile edits, and admin actions, including IP address and user-agent string. Used for security review.

Public Share Links (optional, owner-controlled)

You can mint a public, read-only link for any meeting you own via the history popup. When active, anyone who knows the link can read the meeting-content view without signing in. This is opt-in, per-meeting, and revocable at any time.

The public page exposes:

• Meeting title and start / end timestamps.
• The auto-generated summary.
• The extracted action items (owner, text, due hint).
• The meeting owner's email address — surfaced as a "Shared by" attribution near the title so recipients know who handed them the link.

The public page does not expose:

• Raw transcript segments or any transcript content beyond what the summary already paraphrases.
• Detected questions — questions our pipeline pulled from the transcript stay private to the meeting owner.
• The Q&A thread — your questions and the assistant's answers about this meeting are private to you and never leave the owner's authenticated view.
• Your account ID, the share token's audit trail, knowledge-base content, any other meeting you own, or any data belonging to other users.

Anyone in possession of the link can read the content while the link is active. Forwarding the link forwards access. Revoke the link from the history popup at any time and the URL becomes a 404 immediately. Tokens are long random strings (secrets.token_urlsafe(32), 32 bytes of entropy) so they cannot be guessed. Share responses are served with Cache-Control: no-store so intermediate proxies and browser back-buttons cannot resurrect a revoked link.

Audio Recordings — Never Server-Side

The MeetKB server has no audio storage. The .webm recording and any .vtt / .txt sidecars are saved to your browser's default downloads folder only. The server endpoint that used to accept audio uploads has been removed, and the database column that used to reference an audio key has been dropped.

Outbound Calls Made by the Server

1. Groq

Used only for batch Whisper transcription of recorded audio when live transcription is unavailable. Question cleanup, question detection, action-item extraction, Q&A answer synthesis, and summary generation have all moved to Ollama Cloud and no longer reach Groq. The server calls api.groq.com with your Groq key. The Groq privacy policy applies.

2. Deepgram

Used for live streaming transcription when configured. The server proxies a WebSocket to api.deepgram.com with your Deepgram key, forwarding 16 kHz mono PCM audio of the meeting. The Deepgram privacy policy applies.

3. Ollama Cloud

Primary and fallback LLM provider for all language-model tasks: question detection, question cleanup, Q&A answer synthesis, on-demand in-meeting summary, post-meeting summary, action-item extraction, and pre-retrieval typo correction. The server calls ollama.com with your Ollama key. Depending on the task, the payload includes your meeting transcript (up to ~16 000 characters of recent context, truncated head + tail for longer meetings), the top-ranked KB chunks for Q&A, the cleaned question text, and the recent conversation history. The Ollama privacy policy applies.

4. OpenAI

Used to generate semantic-search embeddings (text-embedding-3-large, 3072-dim) for KB chunks at ingest time, for the query at retrieval time, and for the semantic-dedup pass over detected questions. The server calls api.openai.com with server-owned credentials — no per-user key is required. The OpenAI API data usage policy applies. OpenAI does not train on data sent via the API.

5. Cloudflare Workers AI

Used to run the second-stage cross-encoder reranker (@cf/baai/bge-reranker-base) over the top retrieval candidates for your /ask queries. The server calls api.cloudflare.com with server-owned Cloudflare account credentials — no per-user key is required. The Cloudflare privacy policy applies.

6. URL crawl

If your admin creates a KB by entering a URL, the server fetches pages from that host (sitemap first, then same-host BFS) and stores the extracted text as KB chunks. No crawling is performed unless an admin initiates it.

Data That Stays Local

• The session JWT (15-minute access token) and refresh token (14-day, used once and then rotated) — held in chrome.storage.local by the extension, and in the browser's localStorage on meet.brilworks.com by the web app. Both stores are scoped per-extension and per-origin respectively; unrelated sites cannot read them. Used to authenticate to the MeetKB server.
• A short-lived state / nonce in the web app's sessionStorage during a Google OAuth redirect, cleared as soon as the callback completes.
• Transient recording state (in chrome.storage.session), cleared when the browser closes.
• In all modes, the recorded .webm file (and any .vtt / .txt sidecars) in your browser's default downloads folder.

Cross-Surface Session Sync

To avoid forcing you to sign in twice, the extension and the web app share the same JWT through a tightly scoped messaging bridge:

• When you sign in on the web app, the page calls chrome.runtime.sendMessage to push the access token, refresh token, and minimal user object into the extension's chrome.storage.local. The extension instantly recognises the same session.
• When the web app loads with no local session, it asks the extension (same message channel) whether it already has one. If yes, the web app hydrates its own localStorage from the extension's tokens so the next click opens /admin or /dashboard without bouncing through the login page.
• Signing out from the web app pushes a clear-session message to the extension. Signing out from the extension does not yet push back to open web-app tabs — instead, the next API call from the web app sees the revoked refresh token, the server returns 401, and the web app redirects to /login automatically (within the 15-minute access token TTL).

The bridge is locked down by the externally_connectable.matches manifest entry — only pages served from https://meet.brilworks.com (and the developer http://localhost:8000) can reach the extension's message handler. The background worker also re-checks sender.origin on every incoming message as defense-in-depth. No third-party site, content-script injection, or page outside that allowlist can read or write the extension's session.

No new data is sent to the server by the bridge — both surfaces already had this same JWT. The bridge only moves a token that already existed in one browser context into the other, on the same machine, between two surfaces of the same product.

Retention and Deletion

• Audio recordings never leave your machine. The .webm (and any .vtt / .txt sidecars) are saved to your browser's default downloads folder only.
• Meeting history cap — at most 20 meetings per account are retained server-side, pinned or not. When you start a 21st meeting, the oldest unpinned meeting is evicted first; if every existing meeting is pinned, the oldest pinned meeting is evicted to make room. Pinning gives a meeting priority over unpinned siblings in the eviction order but does not grant unbounded retention.
• Public share links — if you have minted a share link for a meeting, revoking the link (DELETE /meetings/{id}/share) invalidates the URL immediately and removes the share token from the database. Deleting the parent meeting also revokes any associated share token as part of the cascade.
• Transcripts, summaries, detected questions, action items, Q&A history, KBs, and KB chunks are retained until you (or your admin) delete them, the parent meeting, or your account.
• Session tokens — expired or revoked sign-in sessions are purged from the database after a 7-day grace window by a daily cleanup job.
• Audit logs — retained for 180 days by default, then purged. Retention windows are configurable by the operator.
• Per-meeting deletion — DELETE /meetings/{id} removes the meeting, its transcript, summary, detected questions, action items, Q&A history, and any active share token.
• Account deletion — DELETE /me cascades to remove your sessions, KB access grants, key-pool assignments, meetings, transcript segments, detected questions, action items, share tokens, and Q&A. KBs you created remain accessible to other granted users (their user_id is cleared rather than deleted). Key-pool entries you created remain available to the admin pool unless explicitly deleted. Audit-log entries are retained for security review.
• Account export — GET /me/export returns a JSON dump of everything you own.

Permissions

• Active Tab: identify the current Google Meet tab.
• Storage: remember session tokens, recording state, the rolling transcript, detected questions, and the active KB selection.
• Offscreen: host the audio capture, MediaRecorder, and proxy WebSocket. Service workers cannot hold long-running work.
• Side Panel: render the in-call UI (transcript, questions, Ask box) next to the Meet tab.
• Identity: Google OAuth sign-in.
• Scripting: inject the caption-reader scripts into the Meet tab.
• Host access to meet.google.com: inject the recording scripts and the recording indicator.
• Host access to meet.brilworks.com: sign-in and all server traffic for signed-in features. The extension also opens new browser tabs at meet.brilworks.com/admin, /dashboard, and /profile when you click the Settings, History, or Profile actions in the sidepanel.
• Externally Connectable (https://meet.brilworks.com/*): the manifest allowlist that scopes the cross-surface session bridge described above. Only pages served from that origin can send messages to the extension's background worker; every other site is rejected by Chrome before our code runs.

Opting Out

• Don't sign in → the extension records locally only and sends no data anywhere.
• Don't use a KB → Q&A queries fall back to general-knowledge mode (clearly labelled in the UI); no document content is sent to any LLM.
• Turn off Deepgram → live captions still work via Google Meet's own caption stream (the extension reads them from the meeting's data channel). Without a paid-STT key the only thing you lose is the fallback path used when Meet's captions become temporarily unavailable mid-meeting.
• Sign out at any time → from the extension's sidepanel or the web app's account menu. The web app's sign-out also clears the extension's stored session via the message bridge; the extension's sign-out invalidates the refresh token server-side so any open web-app tab loses access within the 15-minute access-token window.
• Uninstall the extension → everything in chrome.storage.local is removed by Chrome. Any server-side data tied to your account (transcripts, KBs, meetings) is retained until you ask an admin to deactivate the account or you call DELETE /me from the web app or via the API.

Changes to This Policy

If this privacy policy changes, the updated version will be published at meet.brilworks.com/privacy-policy.html (the same URL referenced by the extension and the Chrome Web Store listing) and the "Last updated" date above will be revised. Material changes to data collection or sharing will additionally be announced through the web app.

Contact

For questions about this privacy policy, email support@brilworks.com.