Block any app from accessing the internet on Windows

Why outbound control is a real gap

Microsoft’s own documentation states that Windows Firewall blocks unsolicited inbound traffic by default but allows outbound traffic unless a matching rule blocks it. That default is sensible for most users, but it means any program on your machine (an updater, a tracker bundled with freeware, or malware) can phone home unless you write a blocking rule yourself. Creating and maintaining those rules in Windows Defender Firewall with Advanced Security is manual: one rule per executable path, no process-attributed view of what is currently connecting, and no audit trail of what a rule would block before you enable it.

What WinSight does instead

WinSight’s outbound firewall enforces per-application block/allow decisions through the Windows Filtering Platform (WFP) (the same kernel filtering layer Windows Firewall itself uses) via an opt-in LocalSystem service. The workflow is deliberately conservative:

• Install the service explicitly. Setup never installs it for you; registering a LocalSystem service that mutates WFP should be a decision, not a side effect.
• Start in audit mode. The service observes and records what your policies would block. Nothing is filtered yet, so a mistaken policy cannot cut a program off.
• Arm enforcement from the dashboard. Only an elevated operator can arm it, through an authenticated IPC channel. There is deliberately no command-line path to arming.
• Trust the reported state. WinSight separates the mode you asked for from the state it can prove against the live filtering engine. If it cannot verify enforcement exactly, it reports Degraded, never Active.

A concrete workflow

Say a screen-recorder you trialled keeps connecting to a host you don’t recognize. In WinSight you open Connections & DNS to confirm which process owns the connection, add a block policy for that executable in the firewall view, watch audit mode confirm the policy matches only that program, then arm enforcement. The block persists across reboots, and its effective state is re-verified on every status read.

Requirements and limits

• Windows 11 or Windows 10 22H2 (x64; the Arm64 privileged runtime is not yet qualified: that is stated, not hidden).
• Installing and arming the firewall service requires an elevated console and an elevated operator. Everything else in WinSight runs per-user without administrator rights.
• Policy is per application. WinSight does not currently show per-connection interactive prompts the way Little Snitch does on macOS.
• It complements Windows Firewall rather than replacing it: inbound protection remains Windows’ job, and WinSight’s read-only rules view links you to the Windows Firewall console for inbound work.