The registry key we removed, and why it was there

Builds of SoftGlaze Browser before September 2026 wrote a Windows registry policy every time a Chrome-for-Testing profile launched:

HKCU\Software\Policies\Chromium\ExtensionInstallForcelist

An ExtensionInstallForcelist entry tells any Chromium that reads that policy key to install an extension and keep it installed. Not our browser, any Chromium-based browser on the user’s machine that honours the Chromium policy path. The extension in question was our own screen recorder.

The comment in the source said why it was there: so the Chrome Web Store would count active users of the extension.

Why that was indefensible

It force-installed software into browsers that had nothing to do with SoftGlaze. Someone who installed an anti-detect browser to keep their sessions separate got an extension pushed into their everyday browser, without being asked, as a side effect of launching a profile.

It also inflated a Web Store metric, which is a Web Store policy problem on its own. And it was being done by a product sold on the promise that your data stays on your machine and nothing is reported anywhere. The privacy claim and the telemetry trick could not both be true.

None of that needed a long discussion. It needed deleting.

What changed

The policy writer is gone. In its place, every launch on Windows now checks for that registry value and removes it if it is present, so an existing install cleans up after the old behaviour without the user doing anything. The extension is still there when you want it. It is installed into SoftGlaze’s own profile data directories, along with the other three, where it belongs.

What it means for “no telemetry”

The site says the app sends no telemetry. That claim is only true from the commit that removed this code onwards, so:

• The first public release will include it. There is no release yet, which means no build carrying the old behaviour has been distributed through a release.
• If any earlier build reached anyone, including testers, the honest position is the one written on the security page: earlier builds registered this policy, this is what it did, and current builds remove it on launch.

That paragraph is on the security page rather than in a footnote, because the alternative was somebody reading the git history of a public repository and finding it themselves. A product whose main trust asset is “you can read the source” cannot then rely on nobody reading it.

The general rule

The same review that caught this one also corrected in-app copy that overstated things: “your data never leaves this device” and “nothing is synced to a cloud” were both written before the app contacted IP-lookup services on launch, and “the app keeps working” after the trial was never true. Those strings are fixed.

The rule that came out of it, and which the site now enforces at build time, is simpler than a policy: every number and every product claim on this site has to point at a line of source code, and a build fails if the line moves. It does not prevent mistakes like the registry key. It does make the gap between what we say and what the code does small enough to see.