first commit

outputs/01a0b6c2-22ad-7b62-9a5a-4a09014a9b42/Windows-privacy-blog-draft.md

@@ -0,0 +1,73 @@
+# Why I started building a more private Windows setup
+
+*Draft, 19 September 2026. The accompanying register separates completed development from untested plans and changes actually applied.*
+
+The idea began with a screenshot about the arrest of an alleged Scattered Spider member. It described a Windows identifier I had barely heard of: GDID. What caught my attention was the gap between the privacy controls people recognize and the records an operating-system ecosystem can produce.
+
+I wanted to understand that gap before downloading another “disable all telemetry” script.
+
+## Following the screenshot back to evidence
+
+The complaint against Peter Stokes describes Microsoft records associating an installation identifier with URLs, IP addresses and times. It is an allegation, not a conviction, and it does not identify every component responsible for collection. It also does not establish that every Windows computer reports every browser's history. [Primary complaint, paragraphs 25–29](https://www.justice.gov/usao-ndil/media/1450651/dl?inline=).
+
+That distinction matters to me. I can be concerned about collection without turning an incomplete technical account into a universal claim.
+
+Microsoft documents a `GlobalDeviceId` field in its Delivery Optimization reporting schema. The existence of that field does not make that table a complete web-history database. [UCDOStatus schema](https://learn.microsoft.com/en-us/windows/deployment/update/wufb-reports-schema-ucdostatus).
+
+Independent research gave me additional leads. I reviewed [gdid-reversal](https://github.com/SmtimesIWndr/gdid-reversal) and its [follow-up](https://github.com/SmtimesIWndr/We-running-GDID-back), including their corrections. They are useful starting points for experiments, not a certification that a particular script makes Windows anonymous. The project review records pinned revisions so readers can distinguish the material examined from later edits.
+
+## The parts I had underestimated
+
+There is more than one identifier and more than one data channel. Microsoft's required-diagnostic schema describes PCFP, calculated from hardware identifiers, and CensusId, a hardware identifier. A published field does not prove that it was emitted by my machine, but it makes “turn off the advertising ID and you are done” an inadequate model. [Windows diagnostic schema](https://learn.microsoft.com/en-us/windows/privacy/required-diagnostic-events-fields-windows-11-24h2).
+
+Optional diagnostics are also separate from the data used by connected features and essential services. Turning off one category does not turn off account synchronization, security services and every application's reporting. [Windows service-data explanation](https://learn.microsoft.com/en-us/windows/privacy/essential-services-and-connected-experiences).
+
+Some of the most consequential information is not hidden behind an obscure device ID. Crash reports can contain fragments of memory. Browser accounts can synchronize activity. Installed applications have their own analytics choices. These deserve individual decisions. [Windows diagnostic configuration](https://learn.microsoft.com/en-us/windows/privacy/configure-windows-diagnostic-data-in-your-organization).
+
+## Privacy with working security
+
+My goal is to reduce unnecessary collection while keeping the machine defended and maintained. The standard design keeps antivirus, security updates, the firewall, disk encryption and supported boot protections.
+
+That comes with a real tradeoff. Defender's cloud protection can send security metadata; disabling sample submission does not necessarily stop that metadata and can reduce protection. I want this explained plainly, with any optional change presented separately. [Defender cloud protection and samples](https://learn.microsoft.com/en-us/defender-endpoint/cloud-protection-microsoft-antivirus-sample-submission).
+
+The same principle applies to blocking domains. I do not want an impressive-looking blocklist that silently stops certificate maintenance, application updates or Windows servicing. A restriction earns its place when it reduces an identified unwanted flow and passes the security workflows I intend to keep.
+
+## What I am preparing
+
+One question changed the architecture: could I download updates without sending anything to Microsoft? A direct download still needs outbound requests and connection metadata. An exception that lets Windows Update through the firewall also lets its update requests through.
+
+For a protected Windows environment that must make no direct Internet connections, the plan is a separate collector: another machine downloads reviewed publisher packages, then transfers them for local installation. The protected environment stays isolated. The collector still contacts the publishers; a VPN or transparent proxy would not erase the information inside forwarded requests.
+
+This option needs a maintenance process for more than Windows itself. Defender, browser updates, certificate trust, firmware and recovery components need attention too. Windows 11 packages may have checkpoint prerequisites. Offline operation also gives up online cloud analysis and reputation checks, even when local antivirus remains active. I want that cost visible beside the privacy benefit. [Checkpoint updates](https://learn.microsoft.com/en-us/windows/deployment/update/catalog-checkpoint-cumulative-updates), [Defender updates](https://learn.microsoft.com/en-us/defender-endpoint/microsoft-defender-antivirus-updates).
+
+The first layer is a small set of documented controls: the supported diagnostic minimum, advertising-ID restrictions, Windows location and sensor permissions, online speech, cloud clipboard, cloud search and Delivery Optimization choices. Every label should describe its actual scope. Denying microphone access to covered Windows apps is different from physically disconnecting a microphone.
+
+The second layer is optional feature removal: unused cloud integration, Widgets, Copilot-related applications, Recall retention and selected consumer/OEM apps. OneDrive needs a local-data and backup check before removal. Edge and WebView2 need separate treatment. Removing a package should not silently remove the tools needed to maintain another application.
+
+The browser choices are Tor Browser, Zen and Helium. Tor is the option for sessions where unlinkability matters; Zen and Helium are everyday browser choices. Separate installations alone do not separate identities, especially when I sign into the same accounts. I will preserve browser updates and review sync, permissions and retention individually. [Tor guidance](https://support.torproject.org/tor-browser/security/using-tb-safely/), [Zen privacy](https://zen-browser.app/privacy-policy/), [Helium privacy](https://helium.computer/privacy).
+
+Mullvad and VeraCrypt are optional parts of the setup. A VPN installation still needs configuration and leak testing. An encryption tool still needs a correctly created volume and a recovery plan. Neither installation deserves an “anonymous” badge.
+
+## What cleanup can realistically do
+
+I want less unnecessary local retention: temporary files with sensible age limits, browser-owned cleanup settings and explicit choices about history. I do not want a cleaner that quietly deletes Downloads, active application data or every troubleshooting log.
+
+Windows locking also needs an honest description. The proposed session-lock actions are application locking, clipboard clearing and graceful unmount of selected non-system encrypted volumes. They cannot promise to erase every password, token or decrypted document from RAM. VeraCrypt's own documentation explains that other applications can retain decrypted data. [VeraCrypt memory considerations](https://veracrypt.io/en/Unencrypted%20Data%20in%20RAM.html).
+
+That is why general registry cleaners, RAM trimming and blanket log deletion are excluded from this project.
+
+## My own behavior belongs in the threat model
+
+I cannot solve every privacy problem through an operating-system setting. The accounts I reuse, the things I post, the people I tell, and the identifying details inside a screenshot or document can reveal more than a technical identifier.
+
+I do not have evidence to rank people as the single largest source of exposure in every situation. I do know that my habits are part of the system I am trying to improve. Before publishing something, I want to consider its metadata, visible account details and how it connects to things I have already shared.
+
+## What is finished, and what is not
+
+The project has a PowerShell prototype with audit, planning, guarded application and restoration, plus five optional application choices. Its 23 transaction/recovery tests passed in both tested PowerShell versions. Those tests concern the engine; they do not establish real-world telemetry suppression.
+
+It now also has a local OS inventory and offline bundle-integrity verifier, with 19 additional tests passing in PowerShell 7 and 5.1. The verifier checks transferred files against a manifest and refuses unsafe paths, mismatched targets and invalid declared dependencies. It does not download or install updates, and matching hashes are not proof of publisher authenticity or complete patch coverage. Real offline installation and containment tests are still ahead.
+
+No operating-system privacy settings or network blocks have been applied by this project to the development host. The host is Windows Home, and the prototype currently declines unsupported automatic policy enforcement there. The next evidence comes from controlled Windows testing, measured connections, security-update checks and restoration tests.
+
+The accompanying workbook records the individual controls, excluded approaches, sources and remaining tasks. I want readers to be able to see exactly what was prepared, what was applied and what was demonstrated. That is the standard I want this project to meet before I recommend it to anyone else.