How Electron and Squirrel changed the inventory problem
A packaging convention that made desktop distribution easy also made a large class of software effectively unenumerable.
There is a specific point at which desktop software inventory got harder, and it is not a security event. It is the point at which shipping an application to Windows stopped meaning “produce an MSI” and started meaning “ship a folder and a self-updater.”
The pattern
Squirrel.Windows established the convention that a desktop application could
install itself into %LOCALAPPDATA%, register a shortcut, and update itself on
launch. No elevation, no MSI, and no Windows Installer database entry. Most
importantly there is no stable location, because the pattern includes a
versioned directory. app-1.0.9186 becomes app-1.0.9187 next week.
Electron made this the default experience for a large category of software, and plenty of non-Electron applications adopted the same shape because users preferred it. It is a genuinely good deployment experience. It is also close to the worst case for inventory.
Why it resists enumeration
The uninstall key is per-user. Registration lands in HKCU, not HKLM.
Tooling that reads the machine hive sees nothing, and tooling that reads the
user hive sees only the users it enumerated.
The version sits in the path. Any rule, exclusion or inventory record pinned to a directory goes stale on the next self-update, which may be days away.
The self-updater is itself a program. An Update.exe beside the
application is a separate executable that downloads and runs code, and it is
rarely inventoried as anything at all.
Bundled runtimes multiply the count. An Electron application ships its own Chromium and its own Node. What is on disk is not one program; it is a program, a browser engine, and a JavaScript runtime, any of which can execute arbitrary code.
Where this leaves inventory
The pattern is not going away, and it should not be treated as abuse: it is a supported way to ship software that users like. What it does mean is that an inventory built on installation events is measuring the wrong thing. It records what a packaging system announced, and the announcement is optional.
The alternative is to treat the executable on disk as the primary observation. A file is present or it is not. That fact does not depend on which hive an installer wrote to, which user was logged on when it ran, whether elevation was requested, or how many times the application has updated itself since.
More of this
New posts on what a file tells you before you run it: headers, signatures, manifests, overlays, the fields most inventory never reads. Only when there is something worth the write-up.
We intend to offer a tool that does this across every file on an endpoint. You get one message when you can use it.