SmartScreen called an app “unknown publisher.” Since when is that a deal-breaker?

You download a preview build, launch the MSI, and Windows throws the blue “Windows protected your PC” wall. If you're evaluating a newer, not-yet-published tool, this screen is not a verdict. It's an absense-of-history message. This post shows what sits behind the warning and how to verify the file anyway.

What SmartScreen actually measures

SmartScreen's application check is reputation-based. Roughly, Microsoft learns “this exact file (by hash) is commonly installed and hasn't caused trouble,” and separately, “this code-signing identity (by certificate) has a track record.” Two facts on day one explain the whole UX:

• A new file hash has no downloads yet — no reputation.
• An unsigned file has no publisher identity at all — no reputation can even start accumulating on the cert side.

Every legitimate new tool passes through this window. Certificate signing is what shortens it: known identity instead of per-file lottery. That's why previews are common-unsigned and releases are common-signed.

What “unsigned” does and doesn't mean

Signing proves custody: bytes produced by a verified identity, unchanged since. Unsigned means that proof is absent — not that the bytes are bad. The installed-Windows distinction:

The dialog collapses the second and third rows. Your job is to separate them.

The two-command verification workflow

Any honest vendor of an unsigned build publishes a SHA-256 with each candidate. Given that, two commands are the entire audit:

# 1) Hash what you downloaded (either works)
Get-FileHash .\ProofTune-0.1.0-preview.1-win-x64.msi -Algorithm SHA256
certutil -hashfile ProofTune-0.1.0-preview.1-win-x64.msi SHA256

# 2) Compare against the published value
#    — PowerShell publishes one already formatted for this:
(Get-FileHash .\ProofTune-0.1.0-preview.1-win-x64.msi).Hash  # should match the site exactly

Two behaviors worth hard rules:

1. On any mismatch: delete the file. One character off means the bytes differ — redownload from the original source and re-check. Do not “try it anyway.”
2. Publish and fetch hashes from different channels than the file. If the hash lives right next to the download on the same untrusted page, a tampered file can come with a tampered hash. Ideally the vendor pins a build-manifest JSON or repeats the hash in release notes.

Signals that should stop you

• No hash published anywhere a candidate is distributed.
• Hash matches, but the app then asks for elevation you weren't told about on first run — scope creep, possible trojanized build.
• The prompt mentions a name you didn't download (repackaged MSI under a different identity).

ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.