Technical details

What lands on your machine

Installing writes to these locations. The installer is per-machine, so the program itself needs administrator rights; everything it creates while running belongs to your Windows account alone.

Logging is off unless you set the CM_PANEL_LOG environment variable, and even then it only writes to the terminal — never to a file.

What uninstalling leaves behind

Uninstalling removes the program, the shortcuts and the registry keys above. It deliberately does not touch your data — reinstalling should bring your accounts back, and an update must never wipe them. The consequence is that a plain uninstall is not a clean sweep:

To leave nothing behind, do it from inside the app before uninstalling: avatar menu → Backup & Restore → Delete data. "Erase everything on this device" deletes every local account, every .bak file, and every key this app placed in the Credential Manager. Export a backup first if you might want the data back — nothing about it is recoverable afterwards.

Being straight about this one: the uninstaller has a "also delete my data" checkbox, and in practice you will never see it. It sits on a wizard page that only Windows' "Change" flow reaches, and we hide the Change button. Rather than leave a promise that does not fire, the real control now lives in the app, and the checkbox is a leftover we still need to clean up.

What deleting actually deletes

Two different operations, both under avatar menu → Backup & Restore → Delete data. Deleting an account is scoped to the account you are signed in as; erasing takes the whole device. Here is the exact reach of each.

That last row is the one worth reading twice. Both operations write a line to activity.log in the data folder, and erasing everything deliberately leaves that file behind — a record of a wipe is worth nothing if the wipe takes it with it. Each line holds the time, the action, the Windows account that performed it, and how many accounts were affected. No usernames of remote servers, no hostnames, no credentials.

This is a record, not a safeguard. Anyone who can run an erase can also delete or edit activity.log — it is an ordinary file owned by that Windows account. It exists so a shared machine can answer "who wiped this, and when", which is usually the real question. It cannot stop someone determined to cover their tracks; that would need the Windows Event Log or a server-side sink, and we do not currently do either.

The account rows are removed in one database transaction, so a deletion either completes or does not happen at all — it cannot leave an account half-erased with orphaned connections behind.

"Best effort" on the escrowed key means exactly that: if you have email recovery enabled and your machine is offline at that moment, we ask the server to drop the escrowed key but do not block the deletion when the request fails. What would remain is a ciphertext blob whose local half no longer exists. To be certain it is gone, disable email recovery first (Account Recovery → disable), which only reports success once the server confirms.

A leftover like that does not get in your way later. The device identifier lives only in the database that was just deleted, so a reinstall generates a new one; binding the same email address again creates a fresh binding alongside the stale one rather than colliding with it, and recovery works normally. The stale entry is also unreachable — redeeming a recovery key requires the exact device identifier it was stored under, and that value no longer exists anywhere. What it is is clutter we do not currently expire on our side, which is a retention shortcoming rather than a security one.

Erasing everything is armed immediately but carried out at the next launch, because nothing may hold the database file open while it is deleted. Until you restart, nothing has been removed and you can still cancel. The escrow release for every account happens during that restart, not at arming time — arming is cancellable, and releasing early would destroy email recovery for a wipe you went on to call off. Those requests run in parallel under a ten-second budget, so an unreachable server delays the launch briefly rather than blocking the wipe.

How the encryption is arranged

Each account has one data encryption key. Everything sensitive — passwords, private keys, passphrases — is encrypted with it using AES-256-GCM before it reaches the database. The key itself is never stored in the clear.

• Password accounts: your password goes through Argon2id (64 MiB memory-hard) and the result wraps the key. The database on its own is unreadable — no password, no key, and no way to derive one.
• Remember me: after a successful login, a copy of the key is handed to the Windows Credential Manager so the next launch can skip the password. Windows hands it back only to the same Windows account that stored it.
• Passwordless accounts: the Credential Manager copy is the only copy. There is no password-wrapped version in the database. Your Windows login is the entire lock — which is the point for a shared duty station, and also means anyone who can log into Windows as you can open the app as you.

Deleting an account also deletes its Credential Manager entry, and vice versa: the key and the data it protects are never allowed to outlive one another. If you lose access to a password account and set up no recovery in advance, the data is gone — we cannot reset it, because we never had the key.

What the app sends

There is no telemetry, no analytics, no usage reporting and no automatic update check. Apart from the servers you yourself connect to, the app contacts exactly one host, and only if you turn on email account recovery:

• remote-panel.complexmission.com/api/recovery — binding an email address, verifying its code, escrowing the recovery key, releasing a binding, and redeeming a recovery code. Off until you enable it.
• Opening the website or the recovery page from the app hands the URL to your default browser; the app does not fetch it.

Downloads from this site are served through short-lived signed links after a captcha, and each download is logged with a timestamp, IP and user agent so we can spot abuse of the release bucket.

Known rough edges

Things we know about and have not fixed yet. This list is the reason the page exists.

• The uninstaller's data-deletion checkbox is unreachable, as described above. The in-app control replaces it; removing the dead checkbox is still pending.
• Erasing data from inside the app cannot delete the WebView2 cache folder, because the window is using it at that moment. It holds no account data, and you can remove the folder yourself after uninstalling.
• Restoring from a backup leaves the previous data.db as a dated .bak file and never cleans those up. They are full, equally sensitive copies of the vault. Erasing all data removes them; otherwise they accumulate.
• On Linux the key store is the kernel keyring, which forgets everything at reboot. Remember me and passwordless accounts therefore do not survive a restart there. Windows is the supported platform for those features.
• A transfer killed by force (process termination, power loss) can leave a scratch folder under %TEMP%. Nothing sensitive is in it beyond the file being uploaded, and Windows clears %TEMP% eventually.

Something missing?

If there is a behaviour you expected to find documented here and it is not, ask through the contact form in the Help Center and we will either answer it or add it to this page.