SECURITY POSTURE

A security tool that overstates its protection is worse than one that admits a gap.

WinSight distinguishes the desired mode you persisted from the effective runtime state it can actually prove against the live filtering engine. If it cannot verify enforcement exactly, it reports Degraded, never Active.

No telemetry, no analytics, no account

The only outbound connection is an explicit, user-initiated VirusTotal hash lookup: a hash, never file contents. VirusTotal is disabled by default and user-keyed.

The privileged boundary is authenticated IPC, not the UI

The dashboard is an unprivileged IPC client and cannot change policy on its own. An unelevated administrator is refused exactly like a standard user.

Enforcement is opt-in and starts audit-only

Nothing is filtered until an elevated operator arms it, and there is no command-line path to arming: that is the security property, not a missing feature. Direct WFP mutation aliases are disabled.

Desired intent and effective state are never conflated

WinSight claims filtering only from the service's proven effective Active state, re-verified on every status read rather than assumed from what was persisted.

Enforcement survives reboots

Through service boot persistence, and the state is re-verified against the live filtering engine on every read.

Path-trust hardened installation

The service refuses to install from any path an unprivileged principal can write, and re-checks the file's 128-bit NTFS identity before use so it cannot be swapped in between.

No kernel driver

Driver-backed interception is deferred rather than half-built, because a production driver needs signing and a separate safety programme.

What WinSight can and cannot protect against

In scope

  • Visibility into persistence, outbound connections, DNS, camera/mic use, hijack surfaces and signatures.
  • Blocking a chosen application's outbound traffic at the Windows Filtering Platform, once you arm it.
  • Alerting on new startup items and on decoy-file ransomware activity.
  • Reporting whether Windows' own protections are actually on, including Microsoft Defender Controlled Folder Access and the vendor-neutral antivirus inventory, read without elevation and never modified.

Out of scope

  • It is not antivirus or EDR, and does not guarantee detection of kernel rootkits, memory-only implants or every persistence technique.
  • Real-time persistence blocking and ransomware interception (would require a signed kernel driver, which is not shipped).
  • Changing any Windows or Defender setting on your behalf. WinSight reports posture and links to the Windows control.
  • It complements Windows Defender and backups; it does not replace them.

Whether Windows' ransomware blocker is genuinely enforcing is a check of its own: how WinSight reads that posture →

The full threat model with trust boundaries and explicit exclusions: THREAT_MODEL.md →

Two privacy policies, stated separately

The WinSight application

No telemetry, no analytics, no account. Scan results stay on your device. The only outbound connection is the optional, user-initiated VirusTotal hash lookup, disabled by default, requiring your own API key, sending a SHA-256 hash and never file contents. Updates are manual: you download a new release and verify it yourself.

This website

This marketing site uses Vercel Web Analytics (cookie-free, aggregate-only) to count page views and anonymous conversion events such as download clicks. No advertising pixels, no cross-site tracking, no fingerprinting, no session replay, and no attempt to identify you. The site never collects executable paths, process names or anything from the WinSight application. The two are entirely separate systems: analytics here says nothing about what any scan found on your machine.

Qualified with evidence, not claims

x64 candidate 8486155 was qualified on a native-x64 Windows 11 VM with a separate isolated control VM. Results are bound to exact artifact hashes; successor CI and CodeQL also passed.

35

checks, 0 failures

WFP/SCM transitions, rollback, connectivity and per-app scoping

13

checks, 0 failures

Path trust, ACLs and hostile TOCTOU scenarios

7

checks, 0 failures

Local IPC with elevated and restricted tokens

7 + 3

checks, 0 failures

Remote Network Logon and independent observer

19

checks, 0 failures

ETW lifecycle, recovery and session cleanup

This technical qualification applies only to x64 candidate 8486155 and does not retroactively qualify public release v0.11.5. Independent human EN/FR/ES presentation review remains required before release. Native Arm64 CI passes build, tests, packaging and installer checks, but privileged Arm64 runtime and x64-on-Arm64 still require suitable hardware qualification.

Sources: docs/validation/2026-08-23-x64-qualification-8486155.md · docs/PRODUCTION_READINESS.md, checked 2026-08-24

Release verification and code signing

  • Every release ships per-asset SHA-256 checksums, an SPDX SBOM and GitHub build provenance you can verify with gh attestation verify.
  • Released binaries are not yet Authenticode-signed: the project holds no code-signing certificate, so Windows warns on first run. The signing chain is implemented and activates the moment a certificate is supplied.
  • The build script verifies both the official SHA-256 and the Authenticode signature of its pinned Inno Setup compiler before using it.

Reporting a vulnerability

Security issues go through GitHub private vulnerability reporting, never public issues.

Report privately →

Read the full documents

Threat model, trust boundaries, what is explicitly out of scope, and every validation record.