Problem
README.md:1087-1089 tells prospective sponsors: "Sponsorships go toward a code-signing certificate, so Windows stops warning on first launch". This overpromises the deliverable. SmartScreen application reputation attaches to a publisher identity and accrues over download volume; a freshly issued standard (OV) or individual code-signing certificate does not grant immediate SmartScreen clearance, so the "Windows protected your PC" prompt can persist for weeks after signing begins. Immediate reputation was the property of EV code-signing certificates, which are not obtainable by an individual on the same terms (they require organization validation plus hardware/HSM key storage). SECURITY.md:138-141 and README.md:984-986 correctly describe the current unsigned state, but neither hedges the outcome of signing - so the only forward-looking statement in the repo is the one made to people being asked for money.
Expected behavior
Reword README.md:1087-1089 to state the outcome honestly, e.g. "Sponsorships go toward a code-signing certificate. Signing removes the "unknown publisher" status and lets Windows attribute the build to a verified publisher; SmartScreen reputation then builds up over downloads, so warnings fade rather than vanish overnight." Whichever route is chosen (see the signing-options finding), state the expected behaviour for that route specifically - Azure Trusted Signing behaves differently from a self-purchased OV certificate.
Rationale
This is the single sentence in the repo that asks a user for money in exchange for a specific technical outcome. If a sponsor pays, signing ships, and the SmartScreen prompt still appears for weeks, that reads as a broken promise from a project whose entire positioning is trustworthiness (local-first, no telemetry, auditable). Correcting the claim costs one sentence and protects the maintainer's credibility on the exact axis - trust - that the project competes on.
Evidence
Read README.md with numbered output: line 1085 is the Sponsor badge, lines 1087-1089 read "Sponsorships go toward a code-signing certificate, so Windows stops warning on first launch, plus the build pipeline and time to fix bugs...". Cross-checked the two other SmartScreen mentions in the repo (grep -rniE smartscreen --include=*.md excluding CHANGELOG -> exactly two hits: README.md:984, SECURITY.md:138), both of which describe only the present unsigned state and make no claim about post-signing behaviour. Confirmed zero signing steps exist today: grep -ci "signtool|sign" .github/workflows/release.yml -> 0.
Risk / trade-off
A more hedged pitch is marginally less compelling to a casual reader. That is outweighed by not setting a deliverable the maintainer cannot control (SmartScreen reputation is Microsoft's, not the certificate vendor's).
Affected area
Docs
Effort: S | priority: value 3/5, fit 5/5
Identified during the trust, distribution and reach audit audit.
Problem
README.md:1087-1089 tells prospective sponsors: "Sponsorships go toward a code-signing certificate, so Windows stops warning on first launch". This overpromises the deliverable. SmartScreen application reputation attaches to a publisher identity and accrues over download volume; a freshly issued standard (OV) or individual code-signing certificate does not grant immediate SmartScreen clearance, so the "Windows protected your PC" prompt can persist for weeks after signing begins. Immediate reputation was the property of EV code-signing certificates, which are not obtainable by an individual on the same terms (they require organization validation plus hardware/HSM key storage). SECURITY.md:138-141 and README.md:984-986 correctly describe the current unsigned state, but neither hedges the outcome of signing - so the only forward-looking statement in the repo is the one made to people being asked for money.
Expected behavior
Reword README.md:1087-1089 to state the outcome honestly, e.g. "Sponsorships go toward a code-signing certificate. Signing removes the "unknown publisher" status and lets Windows attribute the build to a verified publisher; SmartScreen reputation then builds up over downloads, so warnings fade rather than vanish overnight." Whichever route is chosen (see the signing-options finding), state the expected behaviour for that route specifically - Azure Trusted Signing behaves differently from a self-purchased OV certificate.
Rationale
This is the single sentence in the repo that asks a user for money in exchange for a specific technical outcome. If a sponsor pays, signing ships, and the SmartScreen prompt still appears for weeks, that reads as a broken promise from a project whose entire positioning is trustworthiness (local-first, no telemetry, auditable). Correcting the claim costs one sentence and protects the maintainer's credibility on the exact axis - trust - that the project competes on.
Evidence
Read README.md with numbered output: line 1085 is the Sponsor badge, lines 1087-1089 read "Sponsorships go toward a code-signing certificate, so Windows stops warning on first launch, plus the build pipeline and time to fix bugs...". Cross-checked the two other SmartScreen mentions in the repo (
grep -rniE smartscreen --include=*.mdexcluding CHANGELOG -> exactly two hits: README.md:984, SECURITY.md:138), both of which describe only the present unsigned state and make no claim about post-signing behaviour. Confirmed zero signing steps exist today:grep -ci "signtool|sign" .github/workflows/release.yml-> 0.Risk / trade-off
A more hedged pitch is marginally less compelling to a casual reader. That is outweighed by not setting a deliverable the maintainer cannot control (SmartScreen reputation is Microsoft's, not the certificate vendor's).
Affected area
Docs
Effort: S | priority: value 3/5, fit 5/5
Identified during the trust, distribution and reach audit audit.