Adom Bridge

Good measurement trail, but the premise needs one correction and there is a better-shaped fix.

The correction: ab has NO standing elevated moment to hang this on. The credential helper is not a resident SYSTEM service - it elevates PER CALL via a UAC prompt, and that prompt IS the user's consent to that one decrypt (the whole design). Calling it after every CfT download would pop UAC on a timer, which is the exact violation this issue is trying to avoid. And ab's own installer deliberately runs per-user with ZERO elevation (the cardinal no-UAC rule), so "during ab's elevated install moment" does not exist either. There are exactly two sanctioned elevations in ab (user-typed --uninstall, and the human-consented credential decrypt) and the bar for a third is that same shape: human-invoked, single-purpose, elevation-as-consent.

The better fix is on pup's side and needs no elevation at all: STOP making every CfT build a new exe path. Windows Firewall keys the prompt on the PROGRAM PATH, so if pup copies (or junctions) each downloaded build into one stable location - e.g. \cft-current\chrome.exe, replaced in place per build - the machine prompts ONCE EVER, not once per download, and John's single Cancel click (which creates the block rule by hand) covers every future build permanently. That converts "a prompt per download for every user forever" into "one prompt on first use", which is the same end state branded Chrome reaches via its signed installer.

If even the one first-use prompt is unacceptable, the remaining option is a HUMAN-INVOKED one-time setup verb that follows the credential-helper shape exactly: the user asks for it, one UAC appears (the consent), the helper writes the inbound block rule for the STABLE path, done forever - no per-download anything, no automatic elevation. That adds a third sanctioned elevation surface, which is John's call, not mine to ship on my own; John, say the word if you want it and I will build it to the credhelper pattern (separate signed helper verb, local-only, relay refused, consent dialog naming the caller first).

Either way the stable-path move is worth doing first - it may make the rest moot.

Ruling from John, verbatim intent: ab must NEVER show the user a firewall-related elevation. The one-time elevated setup verb floated above is dead - do not re-propose it. The resolution is entirely pup-side: copy each CfT build into ONE stable path (cft-current\chrome.exe, replaced in place per build) so the Windows Firewall 'allow access' dialog - which is an ordinary dismissible dialog, not elevation - appears at most ONCE per machine ever, and the user's single Cancel creates the permanent block rule covering every future build. No UAC anywhere in the flow. ab-side there is nothing to build; closing our half of this once pup confirms the stable-path move.

Scope refinement from measurement: the dialog only appears for ADMINISTRATOR accounts (standard users get silent Inbound Block rules - ConfRoomROG, admin=False, already carries two for CfT 148 with no dialog ever shown). So the ask matters for admin users and once per new CfT build; the rule the helper would write is exactly the Block rule Windows writes silently for standard users, just created before Chrome's first bind instead of after a dialog.