Dommedia Sign-in Guard for Gemini

The problem

An anonymous Gemini session sits outside every control that made the tool acceptable in the first place: no account, no attribution, no policy, no audit. The gap is not that Gemini exists — it is that the same URL behaves completely differently depending on whether anyone is signed in. Sign-in Guard closes exactly that gap, and nothing else.

How it works

1. Blocked at the network layer, by default. A static declarativeNetRequest ruleset redirects Gemini main-frame requests to the extension's own blocked page. The ruleset is enabled in the manifest, so it is live from the moment the browser loads the extension — before any of the extension's own code has run. Anonymous Gemini is never requested at all, not opened and then closed.
2. Signing in lifts the block. When a Google session is present, a higher-priority allow rule is added and Gemini loads normally.
3. Every navigation is re-checked. Each top-level navigation is re-evaluated, which covers the cases the network rule cannot see.
4. Losing the session re-locks. When the Google session ends, any tab sitting on Gemini is sent back to the blocked page.

The design principle is fail-closed: if the session cookies cannot be read at all, the answer is “signed out”, and Gemini is blocked rather than let through.

How it decides whether you are signed in

The extension checks Google's session cookies for the google.com domain: __Secure-1PSID must be present and non-empty, together with at least one of SAPISID, __Secure-3PAPISID, APISID, SID, HSID or SSID. The second cookie is a corroboration rather than a second hurdle — it stops the decision resting on a single name while tolerating Google dropping or renaming any one of them.

• Only presence is used. The values are never stored, logged, or transmitted.
• These cookies are httpOnly, which is precisely why the extension reads them through the browser's cookie API rather than from the page — and why the cookies permission is unavoidable.

Getting back to Gemini after signing in

• The sign-in link carries a continue target, so Google returns you to Gemini rather than to your account page.
• The blocked page re-checks on load and takes the tab on to Gemini once a session exists — which covers a sign-in that finished in another tab.
• The URL the tab was blocked from is preserved, so a blocked conversation link is where you return to, not Gemini's front door.

What it does not do

For administrators

Force-install by policy

Force-installing is what makes the rule binding: a force-installed extension cannot be disabled or removed by the user. This is the guarantee a desktop application cannot offer. It is supported on both Edge and Chrome via ExtensionInstallForcelist, either from the store or from a self-hosted signed package.

• Chrome extension ID: TODO — assigned when the Chrome Web Store listing is approved
• Edge extension ID: TODO — assigned when the Edge Add-ons listing is approved

Identifiable traffic

Requests to Gemini carry the header X-GeminiAuthOnly: GeminiAuthOnly/0.1, and the same product token is appended to the User-Agent, so an existing proxy or CASB rule can single out traffic from a managed browser. The token identifies the extension, not the user. A proxy only sees either of these if it terminates TLS.

InPrivate / Incognito

The extension declares "incognito": "split", giving a private window its own instance and its own cookie jar. It must be granted “Allow in InPrivate” (Edge) or “Allow in Incognito” (Chrome) on the extensions page, or it does not run there at all. See the private-window limit below.

What the extension reads and why is set out in full in the privacy policy.

Limits

• Only the browser it is installed in. A user with a second browser is out of reach. That is what a network-level proxy rule is for; Sign-in Guard complements it rather than replacing it.
• One request in a private window. In an InPrivate or Incognito window the block is enforced by the navigation handler rather than at the network layer, so a single request for the Gemini page reaches Google before the tab is locked. The user ends on the blocked page with no usable Gemini session, but that first request does happen. This is a limit of the browser's extension API, not an oversight: every mechanism that could carry “signed in” state is shared with the private instance, so none can express “allowed in this profile only”. Organisations for whom that first request matters can disable InPrivate by policy.
• It is not a DLP tool. It decides whether Gemini may be opened. It does not inspect prompts, responses, or anything a user types.
• It is a beta. This is version 0.1.0.

The companion Windows client

There is a separate Windows application, Gemini Auth Only, that opens a single managed Gemini window with the same sign-in rule. The extension is an as-well-as, not a replacement: the client secures one window, the extension covers every tab. They share no code.