IT deployment (managed Chrome and Edge)

For IT teams rolling TraceGist out by policy. Managed browsers in many companies block both the zip install and the developer-mode toggle, so individual users cannot install the extension themselves. This page gives you what a policy-based deployment needs: the extension ID, an update URL, and the policy snippets to paste.

Status: the extension is distributed today as a zip from this website, and the ID is not pinned yet, so it cannot be allowlisted by ID on any install path. The pinned ID lands with an upcoming release; every <extension-id> on this page is filled in then. The intended store route is an unlisted Chrome Web Store listing; it is not live yet, so the update URL below is Google’s real endpoint with nothing behind it, and force-install from the store is not yet possible. Self-hosting the CRX (below) does not depend on the store.

What the extension is, in one paragraph for your security review

TraceGist records a browser session on the employee’s own machine: screen, clicks, console logs, network requests, and voice notes the employee chooses to add. Nothing leaves the machine unless the user explicitly exports a package or starts a live session, which is end-to-end encrypted with a key the relay never sees. There is no account, no telemetry, and no phone-home. The privacy policy, security policy, license and SBOMs are public.

Extension ID

The ID is pinned by a public key in the manifest, so it is the same whether the extension is loaded unpacked, from a CRX, or from the store:

<extension-id>

To verify it yourself: unzip the download, open chrome://extensions, load it unpacked, and compare the ID shown on the card.

Permissions the extension requests

Where exports are written, for a review. By default, and always as the fallback, the export zip goes to the browser’s Downloads directory through chrome.downloads. A user can also choose an export folder in Chrome’s own folder dialog:

• When a folder is chosen, the extension saves two small test files through chrome.downloads, one to Downloads and one to Downloads/<folder name>/, and deletes them again, to find out whether the chosen folder is that one. This can leave an empty Downloads/<folder name> behind.
• A folder inside Downloads is then written through chrome.downloads. The download policies govern it (DownloadDirectory, PromptForDownloadLocation, DownloadRestrictions), the File System Access policies do not.
• A folder anywhere else, which may be a synced or shared one, is written through the File System Access API. Chrome asks the user for that access and refuses protected folders; DefaultFileSystemWriteGuardSetting set to 2 blocks it. Without access, exports go to Downloads/<folder name>.

Confirm the effect of these policies on extension pages in your managed build.

Scope, for the record: the video is the one tab the user chose to record; console, network and error capture cover every tab open in that browser profile while a recording runs. The privacy policy states this and what is redacted before anything leaves the machine.

Chrome refuses the debugger permission at runtime under any of these policies, and TraceGist then keeps recording without deep diagnostics:

• DeveloperToolsAvailability = 2 (DevTools disabled)
• an ExtensionSettings runtime_blocked_hosts entry for the recorded host (a common setting for SSO and banking hosts; note it switches deep diagnostics off on exactly those hosts)
• DisableScreenshots
• a data-loss-prevention restriction on the tab

Any of these is a supported way to switch deep diagnostics off org-wide. Do not put debugger in blocked_permissions: it is a required permission, and Chrome and Edge disable an extension outright when a required permission is blocked.

Policy snippets

Chrome: ExtensionSettings (recommended)

Allows the extension without forcing it. Users who can see chrome://extensions can install it from the store link. Merge the entry into your existing ExtensionSettings value; the snippet deliberately omits the "*" default so it does not replace whatever you already block or allow.

{
  "ExtensionSettings": {
    "<extension-id>": {
      "installation_mode": "allowed"
    }
  }
}

Force-install on every managed profile instead (update_url is required for force_installed and normal_installed, and ignored for allowed):

{
  "ExtensionSettings": {
    "<extension-id>": {
      "installation_mode": "force_installed",
      "update_url": "https://clients2.google.com/service/update2/crx"
    }
  }
}

Chrome: legacy list policies

{
  "ExtensionInstallAllowlist": ["<extension-id>"],
  "ExtensionInstallForcelist": ["<extension-id>;https://clients2.google.com/service/update2/crx"]
}

Self-hosted update manifest (no store dependency)

If your environment blocks clients2.google.com, or you want to run a build you verified yourself, host the signed CRX and an update manifest on an internal HTTPS server and point the force-install policies at it:

{
  "ExtensionSettings": {
    "<extension-id>": {
      "installation_mode": "force_installed",
      "update_url": "https://intranet.example.com/tracegist/updates.xml"
    }
  }
}

The same works for normal_installed and for ExtensionInstallForcelist (<extension-id>;https://.../updates.xml). update_url is ignored for allowed, and on Windows and macOS Chrome only installs off-store CRX files that policy installs, so allowed plus a self-hosted CRX does not give users a self-service install: for that you need ExtensionInstallSources with the URL pattern of the host, or the store listing.

The manifest is Google’s update manifest XML; its appid must be the pinned ID above and the CRX must be CRX3 format, signed with the key that pins the ID. TraceGist will publish a signed CRX and updates.xml at https://tracegist.com/extension/ with the release that pins the ID; until then, only the zip exists.

Microsoft Edge

Edge runs the same extension. The policies have the same names under the Edge policy tree (ExtensionSettings, ExtensionInstallAllowlist, ExtensionInstallForcelist) and accept the Chrome Web Store update URL above unchanged, so the force-install snippet works as is. If users should be able to install it themselves from the Chrome Web Store, Edge additionally needs ControlDefaultStateOfAllowExtensionFromOtherStoresSettingEnabled set to enabled; force-install does not need it.

Where to put them

• Windows (GPO): Computer Configuration > Administrative Templates > Google > Google Chrome > Extensions (install the Chrome ADMX templates), or > Microsoft Edge > Extensions for Edge.
• Windows (Intune): Settings catalog > Google Chrome or Microsoft Edge > Extensions, or a custom OMA-URI with the JSON above.
• macOS: a configuration profile with the com.google.Chrome (or com.microsoft.Edge) domain. ExtensionSettings is a dictionary policy and mandatory-only, so set it through a profile rather than defaults write, which can land at the recommended level and be ignored.
• Linux: a JSON file in /etc/opt/chrome/policies/managed/ (Chrome) or /etc/opt/edge/policies/managed/ (Edge).

chrome://policy shows what is applied and flags syntax errors.

Optional: pre-configuring the extension (managed storage)

The same policy mechanism can push settings to every install through chrome.storage.managed: the relay URL for self-hosted relays, redaction defaults, and consent settings. TraceGist does not read managed storage yet; the schema and the supported keys will be documented here when the org configuration layer ships.

For the works council and the DPO

The people who need to sign off will want, in this order: the privacy policy, the permission table above, the fact that recording is started by the employee and never remotely, and the end-to-end encryption of live sessions. The security policy covers vulnerability disclosure, and the SBOMs list every bundled component. A DPIA template and a Betriebsvereinbarung template are in preparation; contact us if you need them earlier.