windows-internals

Why you can't script default-browser changes: the UserChoice hash

Windows deliberately makes default app assignment tamper-hardened. The hash format, what it proves, and how legitimate tools live with it instead of fighting it.

ProofTune Project··6 min read
Windows internals illustration Windows internals

The design

Since Windows 8, the “default app for .pdf, .html, HTTP, …” associations live under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\<ext>\UserChoice — and the ProgId there is guarded by a Hash value computed from the extension, the user's SID, the ProgId, and the write timestamp.

The rule that makes it honest

Write the ProgId without a matching recomputed hash and Explorer declines the association and falls back. The hash key isn't a bug workaround; it's a deliberate lock: only the interactive dialog (which computes the hash through a private path) and the documented Settings → Defaults page may set defaults. Result: no tool can silently steal your browser behind your back — not even with your consent on your own admin account, programmatically.

How legit tools cooperate

  • Show, don't set: a tool can enumerate current defaults read-only and point to the Settings page for changes.
  • Per-user alternatives: app-level “open with this internally” options (browsers handling their own links) leave UserChoice untouched.
  • Never hash-forge: private hash parameters changed within Windows versions before; forging broke apps on updates and always will.

Tamper-evidence at the user's own keys is where the platform draws the line — a useful benchmark: tools that respect it even when it inconveniences them tend to respect the rest of your system too.

ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.
ProofTune logo

See these exact settings inside the real tool

The browser replica runs the same strings and states as the installed app — click around before you ever install anything.