Find out when Windows last changed your privacy settings — and whether an update did it.
You turned off diagnostic data six months ago. Is it still off? Did that feature update put it back? Most tools answer by setting things again. This one answers by reading what is already on your disk.
Windows stamps every registry key with the moment it was last written. Windows Update keeps a timestamped record of everything it installed. privacy-drift reads both, throws out the antivirus-definition noise that arrives several times a day, and lines up what is left. The first run needs no baseline — the timestamps are already there. It then saves a snapshot, so every later run also reports exactly what changed and to what: Diagnostic data: Optional (Full) → Security, in that language, not a wall of registry paths.
Read-only. No admin rights. One script, no install.
Real first-run output, no baseline, unelevated. Full transcript in examples/forensic-run.txt.
privacy-drift 1.0.0
Windows 26200.9168 | PowerShell 5.1.26100.9168 | elevated: False
inventory 1.0.0, last validated against build 26200
Timeline — when these settings were last written
------------------------------------------------
2026-08-21 10:21 HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced
+ Copilot button on taskbar 0
+ App launch tracking (Start suggestions) 0
+ Widgets on taskbar 0
2026-08-20 00:15 HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection
+ Diagnostic data level (policy) 0 — Security (Enterprise/Edu only)
+ Diagnostic log collection 1
^ 9 keys written in the same second — that is the signature of a script
or a manual change, not an update
2026-08-19 23:07 HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager
+ Start menu suggestions 0
! Windows Spotlight on lock screen 1
! Tips and suggestions after updates 1
+ means the setting holds a privacy-preserving value, ! means it does not, blank means it is not set at all.
That run is from a machine where a debloat script had been used the night before — which is why the timeline shows a burst rather than an update. On a machine where an update did rewrite settings, that block instead reads:
^ high confidence: KB5060842 finished 6 min earlier
2026-06 Cumulative Update for Windows 11
Once a snapshot exists, later runs report the difference:
Drift since last snapshot
-------------------------
Baseline: 2026-08-21 12:01
Diagnostic data level (policy)
3 — Optional (Full) -> 0 — Security (Enterprise/Edu only)
key written 2026-08-20 00:15
Service start type changed
--------------------------
Connected User Experiences and Telemetry (DiagTrack): Automatic -> Disabled
git clone https://github.com/Thominho/privacy-drift.git
cd privacy-drift
powershell -ExecutionPolicy Bypass -File .\privacy-drift.ps1That is the whole thing. Add -Report Both to also write a markdown report you can paste somewhere.
This section is deliberately before the feature list.
- Timestamps are per key, not per value. Windows records when a key was last written, not which value inside it changed. If ten settings live in one key, they share one timestamp. The output groups them so this is visible rather than hidden.
- Correlation is not causation. An update finishing shortly before a key was written does not prove it made the change. The tool labels its confidence and stays quiet when it cannot tell — see below.
- Coverage is a curated list. 76 settings, 8 services, 10 scheduled tasks. It is not everything, and it carries a
lastValidatedBuildstamp that produces a warning when your build is newer. - It never writes. No registry changes, no "fix" mode. See detector, not fixer below.
Naive nearest-update matching is worse than useless — it produces confident, wrong answers.
Three things keep it honest:
Definition updates are excluded. On a typical machine, antivirus definitions are the large majority of update history and arrive several times daily. They never touch these settings, so blaming one would be pure noise. They are filtered by KB number, never by title — titles are localised and pattern-matching English words breaks on every other system language.
The window is tight. High confidence means the update finished within 10 minutes of the write. Medium means 30. Beyond that the tool says nothing rather than guessing.
Bursts are called out, not attributed. A configuration script rewrites many keys within the same second. Windows Update does not work that way. When several keys share one timestamp, the tool reports that pattern instead of blaming whichever update happens to sit nearest in time.
That last rule earned its place: during development on the author's own machine, the tool initially blamed a .NET security update for changes that a debloat script had made an hour later. The burst rule now catches exactly that case.
Timeline — every watched key, newest first, with what it currently holds and any update that plausibly explains the write.
Drift — once a snapshot exists, what changed since, in named values rather than raw numbers, plus service start types and scheduled task states.
Unknown values — values sitting in watched keys that the curated inventory does not recognise. This is what stops a hand-maintained list from quietly going stale: when Microsoft adds a setting, you see it appear here instead of being silently unwatched.
76 registry settings across eleven categories — telemetry, AI features (Recall, Copilot, Click to Do), advertising, input and speech collection, suggested content, search, app permissions, location, error reporting, network — plus 8 services and 10 scheduled tasks.
The full list with paths is in inventory/settings.json. It is plain JSON on purpose: adding a setting is a one-entry edit, not a code change.
See docs/COVERAGE.md for what is deliberately not covered and why.
There are good tools that change these settings. Win11Debloat is the obvious one, and the author's own windows-privacy-debloat does it with backups and a documented list.
This one deliberately does not. Applying settings is a crowded category; knowing whether they stayed applied is not. Use whichever applier you like, then use this to check it held.
Open inventory/settings.json, copy an entry, fill in the hive, path, value name and what a privacy-preserving value looks like. That is the whole contribution — no PowerShell required.
If your machine shows something under Unknown values that looks privacy-relevant, that is exactly the kind of issue worth opening.
- Windows 10 (1809+) or Windows 11
- PowerShell 5.1 — ships with Windows, nothing to install
- No admin rights, no dependencies, no network access
Tested on Windows 11 25H2 (build 26200) with PowerShell 5.1.