If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/builtbybel/privatezilla shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 3y ago

• 6 active contributors
• MIT licensed
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 93% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live builtbybel/privatezilla repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/builtbybel/privatezilla.

What it runs against: a local clone of builtbybel/privatezilla — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in builtbybel/privatezilla | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 1147 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of builtbybel/privatezilla. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/builtbybel/privatezilla.git
#   cd privatezilla
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of builtbybel/privatezilla and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "builtbybel/privatezilla(\\.git)?\\b" \\
  && ok "origin remote is builtbybel/privatezilla" \\
  || miss "origin remote is not builtbybel/privatezilla (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1147 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1117d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/builtbybel/privatezilla"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Privatezilla is a Windows 10 privacy & security audit tool written in C# that performs checks against ~60 privacy-related settings and allows users to enable/disable them via a GUI. It integrates critical Windows 10 privacy controls (telemetry, tracking, data collection) and marks settings as 'Configured' (protected) or 'Not configured' (exposed), with optional advanced PowerShell-based modules for app removal, OneDrive uninstall, and telemetry blocking. Standard WinForms desktop app: src/Privatezilla/ contains the main GUI (MainWindow.cs/MainWindow.Designer.cs), helper utilities in Helpers/ (registry, settings, Windows API wrappers), localization via Locales/*.resx files, and Settings/Apps/ presumably for per-app privacy rules. Separate scripts/ folder holds standalone PowerShell modules for advanced operations (firewall, service disabling, app removal).

Windows 10 users concerned about privacy (both novices and power users), and security-conscious admins who want a simple GUI-based alternative to manual registry/Group Policy editing. The community package targets advanced users comfortable running PowerShell scripts for aggressive debloating.

Actively maintained but modest in scale: available on GitHub with release artifacts, supports Windows 10 versions 1809–2009, but no visible CI/CD pipeline or automated tests in the file list. Last commit recency unknown from provided data, but the project has enough polish (multi-language support via 9 .resx files, structured C# codebase) to be usable for production privacy checks—however, test coverage appears minimal.

Single maintainer (builtbybel) with limited visible automated testing or CI checks. Core functionality relies on direct Windows registry manipulation (via RegistryHelper.cs) and PowerShell script execution (e.g., Disable Services.ps1, Disable Windows Defender.ps1), which carry inherent risk if settings are applied incorrectly. No apparent dependency lock file or version pinning; breaking changes to Windows 10 versions could require manual updates.

Unknown from provided snapshot—no recent commit timestamps or PR data visible. The repository structure suggests mature feature parity with 60 settings implemented, a stable multi-language UI, and established PowerShell integration; new work likely focuses on Windows 10 version compatibility (1809–2009) and community-contributed script templates.

git clone https://github.com/builtbybel/privatezilla.git
cd privatezilla/src
# Open Privatezilla.sln in Visual Studio 2017+ or use:
msbuild Privatezilla.sln /p:Configuration=Release
# Run the compiled .exe from bin/Release/

Daily commands: Open src/Privatezilla.sln in Visual Studio 2017 or later, build the solution (F7 or Build > Build Solution), then run the resulting .exe from bin/Debug/ or bin/Release/. Requires Administrator privileges to read/modify registry and apply settings.

• src/Privatezilla/MainWindow.cs: Core GUI logic: binds privacy settings UI to registry state and handles user interactions (enable/disable toggles)
• src/Privatezilla/Helpers/RegistryHelper.cs: Abstracts Windows Registry read/write operations used by all privacy settings; critical for correctness and safety
• src/Privatezilla/Settings/Apps/: Directory containing per-app privacy rule definitions; expanding this drives the '60 settings' count
• [scripts/Disable Services.ps1](https://github.com/builtbybel/privatezilla/blob/master/scripts/Disable Services.ps1): Example advanced module that disables Windows services for privacy; template for community PowerShell contributions
• src/Privatezilla/Locales/Locale.resx: Master English strings file; all UI text originates here and is translated to 9 languages via satellite .resx files
• src/Privatezilla/Interfaces/ITreeNode.cs: Interface defining the contract for privacy setting tree nodes; enables polymorphic handling of different setting types in the UI
• src/Privatezilla/Helpers/SetttingsBase.cs: Base class for privacy setting objects (note typo in filename: 'Settttings'); all settings inherit from this for consistent behavior

Adding a new privacy setting: Edit the relevant file under src/Privatezilla/Settings/ (or create a new one if category doesn't exist), add registry/policy checks to Helpers/RegistryHelper.cs, and update the main UI binding in MainWindow.cs. Adding a new language: Copy Locales/Locale.resx to Locales/Locale.<culture>.resx (e.g., Locale.ja.resx), translate all keys, and rebuild. Adding a PowerShell module: Create a new script in scripts/ following the naming convention and document it in scripts/readme.txt.

Administrator elevation required: The app must run as Administrator to read/write registry and apply settings; no graceful fallback for non-elevated runs. Registry paths are hardcoded: Privacy setting registry keys are baked into the Settings/*.cs files; changes in Windows 10 cumulative updates may invalidate paths without warning. PowerShell execution policy: Scripts in scripts/ require appropriate ExecutionPolicy; users may hit 'cannot be loaded because running scripts is disabled' errors. No rollback: Applying settings directly modifies the system; there is no built-in undo or restore point creation before changes. Locale encoding: The .resx files must be properly encoded (UTF-8); manual editing can corrupt translations.

• Windows Registry Hive Structure — All 60 privacy settings are stored in registry keys under HKLM or HKCU; understanding predefined hives (SYSTEM, CURRENT_USER, SOFTWARE) is essential to debugging setting reads/writes in RegistryHelper.cs
• Windows Group Policy Object (GPO) Registry Keys — Many privacy settings in Privatezilla map to GPO registry paths under HKLM\Software\Policies\Microsoft\Windows\; understanding GPO-backed registry is critical for applying policies correctly
• PowerShell Execution Policies — The community package relies on executing PowerShell scripts (e.g., Disable Services.ps1); users must understand ExecutionPolicy (Unrestricted, RemoteSigned, Restricted) to run advanced modules
• Windows Telemetry & DiagTrack Service — Privatezilla targets Windows telemetry services (DiagTrack, dmwappushservice, etc.) that many users want disabled; understanding what these services do informs safe configuration choices
• .NET Framework Resource Satellite Assemblies — The multi-language UI is implemented via .resx (XML) satellite assemblies (one per culture); understanding how .NET binds UI strings at runtime via Locale.Designer.cs is essential for adding new languages
• Windows 10 Version Compatibility Matrix (1809–2009) — Privatezilla explicitly supports Windows 10 versions 1809 through 2009 (20H2); registry paths and Group Policy keys vary across major versions, requiring version-aware fallback logic
• P/Invoke (Platform Invoke) for Registry Access — The app uses C# P/Invoke to call native Windows Registry API functions; understanding P/Invoke signatures and marshaling is necessary to safely modify RegistryHelper.cs without memory leaks

• crazy-max/WindowsSpyBlocker — Already integrated into Privatezilla's community package; provides firewall rules and hosts file entries for blocking telemetry IP ranges
• Sycnex/Windows10Debloater — Referenced in community package as an all-in-one PowerShell debloating script that Privatezilla can invoke for aggressive app/service removal
• W4RH4WK/Debloat-Windows-10 — Similar Windows 10 privacy/debloating tool using PowerShell; represents alternative approach to the same problem in the same ecosystem
• laurencedevon/W10Privacy — Another GUI-based Windows 10 privacy audit tool; direct competitor solving the same problem with different UI/language choices
• netdata/netdata — Not directly related, but demonstrates advanced multi-language localization and community-driven feature expansion patterns applicable to Privatezilla's growth

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for Settings classes in src/Privatezilla/Settings/Apps/

The Settings/Apps directory contains 20+ individual setting classes (AccountInfo.cs, AppNotifications.cs, Camera.cs, etc.) that handle critical privacy configurations, but there are no visible test files. These classes likely contain logic for reading/writing registry keys and applying security settings. Unit tests would ensure settings changes are correctly applied and prevent regressions when refactoring.

• [ ] Create src/Privatezilla.Tests/Settings/Apps/ directory structure
• [ ] Add test class for RegistryHelper.cs since it's a core dependency for all Settings classes
• [ ] Write tests for 3-5 representative Settings classes (e.g., Camera.cs, Microphone.cs, DiagnosticInformation.cs) to verify registry read/write operations
• [ ] Use MSTest or xUnit framework and add test project to Privatezilla.sln
• [ ] Add GitHub Actions workflow to run tests on PR (see next idea)

Add GitHub Actions CI workflow for building and testing the C# solution

There is no visible CI/CD pipeline. The repo contains a .sln file and multiple .cs files but no GitHub Actions workflows (no .github/workflows/ directory evident). This means PRs could break the build without detection. A basic CI workflow would compile the solution, run tests, and catch issues early.

• [ ] Create .github/workflows/dotnet-build.yml
• [ ] Add steps to checkout code, setup .NET environment, restore dependencies, build src/Privatezilla.sln
• [ ] Configure the workflow to run on push to main/master and on all PRs
• [ ] Once unit tests exist (from PR #1), add step to run tests and report coverage
• [ ] Consider adding code analysis step using GitHub's MSDN Code Analysis tools or similar

Create comprehensive documentation for the Settings/Apps classes and add inline XML comments

The 20+ Settings/Apps classes lack visible documentation on what each one controls, what registry keys they modify, and their security implications. Contributors and users cannot easily understand which setting class handles which privacy feature. Adding XML documentation comments and a Settings guide would improve maintainability and help contributors add new settings correctly.

• [ ] Add XML documentation comments (/// <summary>) to each public class and method in src/Privatezilla/Settings/Apps/ (e.g., AccountInfo.cs, Camera.cs, Microphone.cs)
• [ ] Create docs/SETTINGS_GUIDE.md documenting each setting class with: class name, what it controls, affected registry keys, and security impact
• [ ] Document the SettingsNode and SetttingsBase base classes in src/Privatezilla/Helpers/ to explain the pattern
• [ ] Add code example in docs showing how to add a new setting class for future contributors
• [ ] Reference this guide in README.md's contribution section

• Add automated unit tests for Helpers/RegistryHelper.cs to verify registry read/write operations don't corrupt keys or values; currently no test files visible in the structure.
• Create a CONTRIBUTING.md guide with detailed instructions on how to add new privacy settings (step-by-step template for Settings/Apps/NewFeature.cs), since community contributions are encouraged but the process is undocumented.
• Build a simple changelog generator or version bump script that syncs the version number across Properties/AssemblyInfo.cs, App.config, and latest.txt to reduce manual release overhead.

• High · Dangerous PowerShell Scripts with Elevated Privileges — scripts/ directory (particularly: Disable Windows Defender.ps1, Disable Services.ps1, Block Telemetry IPs via Windows Firewall.ps1). Multiple PowerShell scripts in the scripts/ directory perform sensitive system operations including disabling Windows Defender, modifying firewall rules, and removing system services. These scripts could be exploited if the repository is compromised or if users execute untrusted versions. Scripts like 'Disable Windows Defender.ps1' and 'Block Telemetry IPs via Windows Firewall.ps1' require administrative privileges and could cause system instability or security degradation. Fix: 1. Implement digital signing of PowerShell scripts. 2. Add execution policy enforcement. 3. Include detailed warnings and confirmations before destructive operations. 4. Consider providing a rollback mechanism. 5. Document security implications clearly in README.
• High · Missing Input Validation in Registry Operations — src/Privatezilla/Helpers/RegistryHelper.cs. The RegistryHelper.cs file handles Windows Registry modifications, which is a critical attack surface. Without proper input validation and sanitization, malicious registry keys or values could be injected, potentially leading to privilege escalation or system compromise. Fix: 1. Implement strict input validation for registry keys and values. 2. Use whitelisting for allowed registry paths. 3. Sanitize all user inputs before registry operations. 4. Add logging for all registry modifications. 5. Consider using WMI or other safer APIs where possible.
• Medium · No Verification of Downloaded Packages — scripts/packages.zip and related distribution mechanism. The scripts/ directory contains a packages.zip file that is distributed without apparent cryptographic verification. If this file is downloaded or updated, there is no hash verification or signature validation mechanism visible. Fix: 1. Publish SHA-256 or SHA-512 hashes alongside binaries. 2. Implement GPG or code signing for all distributed packages. 3. Document verification steps for users. 4. Consider using authenticated delivery mechanisms (HTTPS with certificate pinning).
• Medium · Potential Privilege Escalation via Registry Modifications — src/Privatezilla/Settings/ (all subdirectories, especially Defender/, Edge/, and Services-related modules). Multiple Settings classes modify Windows Registry and system configurations. Without proper privilege level checks and access controls, this could allow unauthorized system-wide setting changes affecting security posture. Fix: 1. Implement explicit privilege level verification before any system modifications. 2. Add audit logging for all privilege-requiring operations. 3. Use principle of least privilege. 4. Implement UAC prompts for sensitive operations. 5. Add rollback capabilities for failed operations.
• Medium · Unencrypted Configuration Storage — src/Privatezilla/App.config, src/Privatezilla/Properties/Settings.settings, src/Privatezilla/Helpers/SetttingsBase.cs. App.config and Settings files may contain sensitive configuration data in plaintext. The Settings/SettingsBase.cs uses standard .NET configuration which is not encrypted by default. Fix: 1. Implement Data Protection API (DPAPI) for sensitive configuration values. 2. Never store credentials or API keys in configuration files. 3. Use encrypted configuration sections for sensitive data. 4. Document security considerations for settings storage.
• Medium · Windows Defender Disabling Script — scripts/Disable Windows Defender.ps1. The 'Disable Windows Defender.ps1' script can completely disable the system's antimalware protection. While this might be intentional for privacy-focused users, it significantly increases attack surface and could be exploited maliciously. Fix: 1. Add explicit warnings about security implications. 2. Require explicit user confirmation. 3. Provide alternatives that disable telemetry without disabling protection. 4. Log all Windows Defender modifications. 5. Consider implementing only partial disabling of telemetry components.
• Low · Lack of Code Signing and Authentication — src/Privatezilla (entire compiled application). The application itself does not appear to be digitally signed, making it vulnerable to tampering and distribution of malicious versions without user detection. Fix: 1. Implement code signing with a valid certificate. 2. Include signature verification in installer. 3. Document signing procedures for

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.