Hardening eclean's Windows Architecture

Not every part of eclean should need administrator privileges.

Opening the app, reviewing scan results, signing in, changing preferences, reading system information, and deciding what to clean or optimize are normal desktop tasks. They should run in the user's session, without asking Windows for more power than they need.

Some maintenance work is different. Windows protects machine-wide settings, services, scheduled tasks, network repair, and certain cleanup locations for good reasons. If eclean is going to work in those areas, it needs a safe way to cross that boundary.

That was the problem: keep the app familiar and unelevated for everyday use, while still supporting the protected maintenance users expect from eclean.

The line we needed to draw

The simplest technical answer would have been to run the whole desktop app as administrator.

It would also have been the wrong answer.

The interface does not need elevated rights to show a page. Account flows do not need elevated rights to sign in. A settings screen does not need elevated rights to save a preference. Even many scans and current-user optimizations can run without a privileged process.

Giving the entire app elevated rights just because a few actions need them creates a larger trust problem than necessary. It also makes startup more fragile: launching eclean at login should be a normal per-user behavior, not something tied to an elevated launch path.

We had wanted to fix this for a while. The work touched installer behavior, service lifecycle, Windows trust checks, feature flows, and target validation, so we treated it as a dedicated architecture track rather than a small feature change.

The new model

eclean's visible desktop app now runs unelevated.

When a protected action needs elevated access, the app talks to a local privileged service broker. The broker starts on demand and handles only reviewed maintenance actions.

The flow is deliberately narrow:

The user chooses a supported action in eclean.
The app sends a typed request to the broker.
The broker verifies the caller.
The broker checks whether the operation is allowed.
The broker resolves the Windows target itself.
The broker performs the action and returns a structured result.

The app does not send arbitrary command lines to run as administrator. It does not hand the service a raw path and ask it to delete it. It does not pass a registry key, service name, or uninstall string and ask the broker to trust it.

The broker accepts reviewed eclean actions, not generic privileged instructions.

Why that matters

This is not an exotic security idea. It is how Windows applications should behave.

Microsoft's User Account Control documentation describes standard-user execution as the normal path for applications: "Most applications, including the ones included with the operating system, are designed to work properly this way." Its newer administrator protection guidance follows the same principle: users should stay at lower privilege and elevate only when an operation genuinely needs it.

That should be the boring default. In practice, Windows maintenance tools often drift away from it. Some run the whole interface as administrator because it is easier. Some keep a privileged helper around without a narrow command model. Some expose an elevated path that accepts too much from the unelevated side.

The broker work is our line against that drift.

Local privileged helpers are risky when they are too flexible.

A helper that can run any command, delete any file, edit any registry key, or execute any uninstall string is not really a broker. It is an elevation mechanism. That is exactly what we wanted to avoid.

The broker uses a closed catalog instead. Every elevated action has to be known, reviewed, authorized, validated, and handled as a product operation. If a future feature needs elevated access, it has to be designed as a specific broker action. There is no general "run this as admin" escape hatch.

That makes privileged work slower to add, but easier to trust.

The service owns target resolution

One of the most important decisions was to resolve protected targets inside the service, not in the interface.

For Optimizer, machine-scope changes are resolved from eclean's supported optimization catalog. The request is for a known optimization, not an arbitrary registry write.

For Booster, the broker works from current Windows state: startup entries, services, scheduled tasks, and network adapters. The service still applies eclean's rules for what can and cannot be changed.

For protected Junk Cleaner cleanup, the broker uses scan receipts and item IDs. The app can request cleanup for items found by a scan, but the service reloads and validates that scan data before touching protected locations.

This keeps user intent in the app and privileged target decisions inside the boundary built to handle them.

Trust before action

Connecting to a local service should not be enough to use it.

Before the broker handles privileged work, it verifies that the request came from the installed eclean app and checks the relationship between the app and service binaries. Command policy then has to allow the specific action, and the resolved target still has to be valid.

If any of those checks fail, the broker fails closed before changing anything.

What we will not broker

The exclusions are part of the design.

The broker does not support:

Generic process execution.
Generic shell execution.
PowerShell execution.
Arbitrary file deletion.
Arbitrary registry editing.
Arbitrary Windows service control.
Arbitrary scheduled task editing.
Package removal.
MSI execution.
Vendor uninstall string execution.
Silent SYSTEM-level Uninstaller execution.

The Uninstaller boundary is especially important. Uninstall strings are executable instructions supplied by other installers and vendors. Running them silently as LocalSystem would turn the broker into a general privileged execution path.

So we do not do that.

What users get from this

The best version of this work is mostly invisible.

eclean should launch cleanly, start from the user's session, show information, collect choices, and explain changes without carrying administrator privileges through the whole interface.

When eclean needs to touch protected parts of Windows, it now goes through a dedicated broker designed for that job.

That gives users a cleaner trust model: less privilege in the everyday app, and a tighter path for the maintenance actions that genuinely need elevation.

It also gives us a better foundation for future Windows work. Before adding an elevated capability, we have to answer the right questions: does it truly need elevation, how is the target resolved, who can request it, what blocks it, and what should the user see afterward?

That friction is intentional.

For software that works near protected Windows settings, the safe path should be the default path.

Jack Holmes & Amy (He3als)
eclean Engineering