Security and privacy

At a glance

Read-only guarantees

PortWho never stops processes, never touches sockets or services, and never writes to the registry or any other system state. The command line writes nothing at all: its only output is a table, a details listing or a JSON document on standard output, and diagnostics on standard error. The desktop app writes only its own settings file (and an error log if something unexpected happens) in its own folder, and exports only where you save them; see Data retention.

This is not a policy layered on top of a more capable engine; the engine has no code paths for mutation. The Windows calls it makes are all queries:

Native memory stays inside the interop layer: table buffers are copied into managed memory and decoded from the documented row layouts.

No network, no telemetry, no account

Neither the command line nor the desktop app contains networking code. Signature verification, the one step where Windows components might otherwise reach out, is forced offline: revocation checking is disabled and the certificate chain engine is restricted to cached URL retrievals. A machine without internet access gets the same answers as one with it.

PortWho has no telemetry, no crash reporting, no usage statistics and no account. The project rule is no product telemetry by default; if a reliability-reporting feature were ever considered, it would have to be documented, minimal, privacy-reviewed, preferably optional and technically separable from the core tool, and it would be labeled as planned here before it existed. Neither the command line nor the desktop app performs an update check.

Least privilege

PortWho runs as the user who started it. It carries no manifest requesting elevation and never prompts for it. Each process is opened with the limited query right, and the service control manager with enumerate rights only.

The consequence is visible rather than hidden: a process that Windows refuses to open is shown as name (access denied) with a note explaining that it is protected or runs with higher privileges, and its executable path and signature stay unknown. PortWho reports what the current user is allowed to see instead of escalating to see more. If you choose to run it from an elevated prompt, that is your decision for that one run.

What the signature verdict does and does not tell you

The SIGNATURE column and the signature object in JSON describe the executable file on disk at the time of the check:

• signed: a valid embedded Authenticode signature;
• catalogSigned: the file is listed in a valid Windows security catalog, which is how most operating-system binaries are signed; the signer shown is the catalog’s signer;
• unsigned: neither an embedded signature nor a catalog entry;
• invalid: a signature or catalog entry exists but failed verification (bad digest, untrusted chain, expired, and so on), with the Windows error text and code;
• unavailable: the file could not be read, so there is no verdict;
• notChecked: --no-signature was given or no path was available.

Because verification is offline, a certificate revoked after the fact is not detected, and a chain that needs a download to complete can be reported as invalid. A signature verdict is evidence about a file’s origin and integrity, not a statement about what the program does.

Data retention

The portwho command line keeps nothing between runs: no log files, no cache on disk, no settings, no history. Service and signature lookups are cached in memory for the duration of a single run so that one process hosting many endpoints costs one lookup, and that memory is released when the process exits.

The desktop app, PortWho.exe, writes only to %LOCALAPPDATA%\PortWho:

• settings.json: theme, auto-refresh, window position and size, details pane width, and whether you dismissed the restricted-processes notice;
• error.log: only if PortWho hits an unexpected error (at most 256 KB), so you can attach it to a bug report.

It does not write through a junction or symbolic link in that folder, keeps no history of what it listed, and caches signature verdicts in memory only. A packaged single-file build also unpacks its WPF libraries once per version into %TEMP%\.net\PortWho, which is how .NET single-file applications work. Delete %LOCALAPPDATA%\PortWho to reset the app.

What you do with the output is yours: a JSON document can contain process names, executable paths and signer names from your machine, so treat saved output like any other system inventory before sharing it.

Signing plan for releases

PortWho has no public release yet, so there is nothing to download and nothing to verify. The release pipeline that every Utility Forge application will follow is defined and includes:

• a clean Windows build from a tagged commit;
• a published SHA-256 checksum for every artifact;
• immutable release paths (a version is never republished with different bytes);
• a mirror of each release on GitHub Releases, once the repository is public;
• SBOM and build metadata;
• the owner’s explicit approval of the exact version, commit and checksums.

No code-signing certificate exists and no signing provider has been chosen. If trustworthy free signing becomes available and the owner approves it, signing uses Authenticode with RFC 3161 timestamps, checked against a pinned expected signer. Otherwise the first PortWho release for Windows x64 may be published unsigned, but only after a separate reviewer has rebuilt it from the approved source, matched the published bytes exactly and the owner has approved those exact files. Later versions and Arm64 are not covered by that exception.

An unsigned release is labelled unsigned on the PortWho tool page and in its bundled documentation before you download it. Windows then shows no verified publisher: SmartScreen may warn that the app is unrecognised, Smart App Control on Windows 11 may block it, and organisation policy may stop it from running. Do not turn these protections off to run PortWho; if you are unsure, do not run it. The security page explains how to verify a download and what a checksum does and does not prove.

Reporting a vulnerability

Please do not report security issues in any public issue tracker. The security page lists the current reporting channel and what to include. For ordinary bugs and questions, the support page lists the current channels.

PortWho’s source is in a private repository during development, so the claims on this page cannot yet be checked against the code by outsiders. Publishing the repository is part of the transparency plan; once it is public, the engine, the Windows interop and the command line can be reviewed under apps/portwho/.