Security & privacy¶

Glassdocs is a zero-data control plane: your Markdown lives in your GitHub repos, your published sites live on your Cloudflare account, and Glassdocs never stores document content, prompts, or model responses. This page explains the authentication model, exactly what data flows where (and when), what the managed backend can and cannot see, how private sites are gated, and what Glassdocs will never do with your data.

The zero-data model¶

Glassdocs orchestrates; it does not host your data. The data plane — content, access rules, published sites, build compute — stays in your GitHub and Cloudflare accounts.

Editing keeps the same invariant: edits go through the extension (the console offers a read-only page viewer), and the page body only transits the control plane — no document body is ever written to Glassdocs storage. Unsaved edits live in your browser.

The free tier stores nothing about you¶

On the free tier, Glassdocs keeps no records about you at all — no account rows, no per-request logs. If you use the extension with your own AI key, Glassdocs is not in the path and stores nothing. If you use the managed no-key AI, no record of your requests is kept either: the only trace is a set of anonymous daily rate counters used for abuse control — derived with a keyed hash (HMAC) so they cannot be mapped back to your GitHub login, unlinkable from one day to the next, and self-expiring at the end of each UTC day. The free tier includes unlimited published KBs — they run on your own Cloudflare account with your own AI key, so there is no reason for us to cap them.

Authentication¶

GitHub is the identity. There is no Glassdocs password or separate account — every actor proves who they are with a GitHub token, and every write is attributed to their own GitHub user.

Humans in the extension — GitHub App device flow¶

The extension signs you in with the GitHub App device flow (no client secret, no redirect). You authorize on github.com; GitHub returns a short-lived user token (about 8 hours) plus a rotating refresh token (about 6 months) that the extension renews transparently. If the refresh token is truly dead — expired, revoked, or the app uninstalled — the stored token is cleared and you're prompted to sign in again.

These tokens are stored in your browser's chrome.storage and are never sent to any Glassdocs server, with one exception: in Managed mode the token is presented as a bearer credential so the backend can verify who you are (below). A power user can paste a Personal Access Token instead of using the device flow.

Org admins in the dashboard — GitHub OAuth¶

The admin dashboard uses a standard GitHub OAuth flow (scope read:org) with defense in depth:

• A server-generated state value, held in an HttpOnly, Secure, SameSite=Lax cookie, protects the flow against CSRF.
• Your admin session is an AES-GCM-encrypted, HttpOnly cookie with expiry checking.
• Post-login redirects derive from the request origin, never from a request parameter — no open redirect.

Every admin route verifies you are a GitHub admin of the org in question before doing anything on that org — authorization is checked before any org-scoped credential is minted, so tokens cannot be used cross-tenant.

The server acting on your repos — installation tokens¶

To configure or deploy a KB, the backend acts as the GitHub App installation on your org — never with an admin's personal token. It mints short-lived (1-hour) installation tokens scoped to your installation, and only after the org-admin check above. The app's footprint: read and write repo contents (scaffolding commits the KB starter files), read/write Actions variables, workflows, and secrets (the Cloudflare connect flow seals your token into repo secrets), and pull requests (protected-branch setup PRs); it never creates or deletes repos. Uninstalling the app revokes everything.

How page content reaches AI backends¶

Nothing is sent anywhere until you act. The extension reads the active tab only, and only when you send a message — there is no background collection. What it reads: the page's URL, title, visible text and HTML, plus any text you selected. Where it goes depends on the backend you choose:

Reads and writes to your repos (fetching source files, commits, pull requests) go from your browser to the GitHub API with your own token, and are attributed to your GitHub identity.

Audio never reaches a speech vendor¶

Both ways of listening to a KB are built so that no document text is handed to a third party.

For readers. The ▶ Listen control on every published page makes no network request of any kind. Speech is produced by the reader's own browser and operating system, using a voice the browser marks as installed on the device, and that voice is pinned on every utterance rather than left to a default that might be a cloud service. If no on-device voice exists the control refuses to speak rather than falling back. The ▶ AI control fetches one file, only on a press, from the KB's own address inside its own Access gate. Neither control contacts Glassdocs, and neither reports anything about what is being read.

For the admin generating narration. Synthesis runs in the admin's browser, in WebAssembly, on their own machine. There is no inference API, no model host, and no other third party in the path. Page text is read from your GitHub repo and passed to the browser through the control plane in the same passthrough way editing works: never written to Glassdocs storage. Nothing but the finished audio is uploaded, and it goes straight through to a GitHub Release on your own repo. Even a generation failure reports a code from a fixed list rather than a free-text message, so a failing sentence cannot escape in an error string. The voice model itself is served from Glassdocs' own storage.

See Listening for the full behaviour.

Key and token custody¶

Secrets never appear in logs or URLs; error messages carry provider error text, not tokens.

Private sites: Cloudflare Access, fail-closed¶

Published KBs are gated by Cloudflare Access on your own account: visitors must pass SSO (staff email domain) or an explicit client grant (external domain or listed emails) before seeing any content. The design is deliberately fail-closed:

• No default access. A blank access field grants no one; a KB with nothing set deploys locked to nobody — never public by accident.
• Gate before content. On first deploy, if the Access application can't be created, the deploy aborts before any content is published.
• Pre-flight check. If the site is already publicly reachable, the deploy fails rather than proceed without an active gate.
• Verify, and act on what's proven. After each deploy the workflow probes the site. The only accepted proof the gate is up is an Access login redirect — success is never reported without it. If the site instead serves content to an unauthenticated request, that is proof of exposure and the deploy is undone: production is rolled back to the previous good build, or, where that deploy created the Pages project and there is nothing to roll back to, the project is deleted. If the site simply isn't reachable yet — common in the first minutes of a brand-new project — nothing has been served to anyone, so the gate is confirmed against the Cloudflare Access API instead, which doesn't depend on the site being live. A gate that can't be confirmed either way fails the run.
• Policy reconciliation. Every deploy deletes the Access app's existing policies and recreates them from the repo's declared variables, so the live policy always matches what the repo declares — a manual dashboard edit is overwritten on the next deploy.
• Preview deployments are never created by the publish flow — only the production site is deployed. (No Pages setting disables previews outright yet; that hardening is tracked in Glassdocs/publisher#3.)

"Nothing public by default" is enforced end-to-end, not at any single layer: making a KB public requires a strict explicit opt-in at every step — the wizard checkbox defaults off, the API accepts only a strict boolean, and the workflow input defaults to false. The admin's choice is authoritative over any pre-existing workflow state (a gated setup over a leftover public workflow restores the gate), and a deploy is never dispatched ahead of an unapplied access-mode change.

You can verify the gate yourself any time: open your site's URL signed out and confirm you're redirected to the Cloudflare Access login. See Hosting.

What Glassdocs does not do¶

• No analytics, telemetry, tracking pixels, or advertising.
• No selling or sharing of your data with third parties for their own purposes.
• No use of your content to train AI models by Glassdocs.
• No background collection — page content is read only when you actively send a message.
• No repo creation or deletion on your org, ever.

Your controls¶

• Revoke Glassdocs's access to your org by uninstalling the GitHub App — the installation record is all Glassdocs keeps.
• Clear keys, tokens, and chat history any time from the extension's Options page, or by removing the extension.
• Avoid the managed backend entirely by choosing a bring-your-own-key backend.
• Rotate the Cloudflare token per KB from the admin dashboard; it re-seals into your repo.
• Data handled by the AI providers and by GitHub is governed by their own privacy policies.

If your organization deploys the extension via Chrome enterprise policy, an administrator may push a read-only shared configuration (such as which backend to use); that config is set by your organization, not collected by Glassdocs, and GitHub sign-in remains per-user. See Enterprise.

Privacy policy¶

The full privacy policy for the browser extension, now listed as GlassDocs and originally published as "Docs Chat", is at glassdocs.site/privacy.html.

Related pages¶

• How it works — the architecture behind these guarantees.
• Admin dashboard — the org-level controls described above.
• Listening — what listening and generating narration do and do not send.
• Extension · Publishing · Hosting · API