WatcherWall is intended for local endpoint visibility. The primary risks are accidentally creating a remote control surface, leaking sensitive process/traffic data, over-collecting packet contents, or making destructive actions too easy.

The design response is:

• No network listeners.
• No inbound communications.
• No telemetry or analytics.
• No cloud services.
• No updater in the initial version.
• No IPC, named pipe, HTTP API, WebSocket server, or local service.
• Normal-user execution by default.
• Privileged actions only after explicit user interaction.
• Minimal local audit logs, disabled by settings if desired.
• Firewall changes are limited to clearly named WatcherWall-owned block rules unless Windows reports existing external block rules for display.

WatcherWall does not bind sockets. It does not start a local web server. The WPF UI is a native desktop window. Network data comes from local Windows IP Helper API reads.

Firewall control in v2 also avoids listeners. It uses the local Windows Firewall COM interfaces and does not expose HTTP, WebSocket, IPC, named pipe, or remote-control endpoints.

Recommended verification:

Get-NetTCPConnection -State Listen | Group-Object OwningProcess

WatcherWall should not add a listener for its own PID.

The app starts as a normal user. Socket enumeration and basic process names generally work without elevation. Access-denied process metadata is shown explicitly instead of being hidden or treated as suspicious.

Administrator rights may be needed for protected process metadata, TCP connection deletion, or killing processes outside the current user's rights. WatcherWall does not auto-elevate.

Creating, deleting, and sometimes verifying Windows Firewall rules may require administrator rights. WatcherWall reports Needs admin instead of silently relaunching elevated.

WatcherWall-created rules use the WatcherWall v2 name prefix and include a description marker:

• Created by WatcherWall v2
• action ID
• direction
• protocol
• local port or range
• profile
• rollback group ID

Unblock and rollback operations remove only WatcherWall-owned rules. External rules may be shown as matching block rules, but WatcherWall does not delete or weaken them.

Firewall rules are created through HNetCfg.FwPolicy2 / HNetCfg.FWRule. The app does not shell out to PowerShell, netsh, or localized command output for firewall control.

Lockdown mode creates reversible firewall block rules. It does not disable Wi-Fi, network adapters, DHCP, DNS, or the Windows Firewall service.

Default inbound lockdown skips loopback-only ports and common essential networking ports. Strict lockdown can include more entries and is presented with a stronger preview. Sensitive administration or infrastructure ports such as 22, 53, 67/68, 445, 3389, 5985, and 5986 produce explicit warnings.

Every multi-rule firewall action records a rollback group. Rollback removes WatcherWall-created rules from that action and never removes unrelated firewall policy.

Live Traffic can use tshark when tshark/Npcap are detected and the user explicitly confirms capture. If external capture cannot start, WatcherWall falls back to a rolling socket-table event view scoped to the selected port/process.

External capture behavior:

• Checks common Wireshark/tshark/dumpcap paths and PATH.
• Checks whether Npcap appears installed.
• Prompts before starting tshark.
• Starts tshark directly without shell expansion.
• Uses -n to avoid DNS lookups.
• Uses a selected-port BPF capture filter.
• Keeps rows in memory with a bounded UI buffer.
• Does not write PCAPs.
• Does not transmit captured data.

Future packet capture work should require explicit opt-in, strict capture filters, ring-buffer limits, no default disk writes, and clear privilege prompts.

WatcherWall prefers specific TCP connection termination where Windows supports it. This uses SetTcpEntry and is limited to established IPv4 TCP rows.

If connection termination is not available, the app offers process kill only as a dangerous action:

• Requires explicit user confirmation.
• Requires an exact phrase: KILL <PROCESS> PID <PID>.
• Re-checks process name for the PID before killing.
• Does not kill process trees.
• Refuses system-critical processes such as PID 4, lsass, wininit, services, csrss, and related core Windows processes.
• Logs local action history if audit logging is enabled.

Settings and optional audit logs are stored under the user's local application data folder. The audit log is intentionally small and action-oriented. It should not include packet contents or secrets.

Snapshot export is explicit user action through a save dialog. Packet capture export is not implemented.

For security bugs, include:

• OS version.
• Whether WatcherWall was elevated.
• Exact action performed.
• Whether any listener, file write, or process termination happened unexpectedly.

Do not include packet contents, credentials, tokens, or private keys in reports.