Why I started taking Windows privacy more seriously

“There is a sacred realm of privacy for every man and woman where he makes his choices and decisions—a realm of his own essential rights and liberties into which the law … must not intrude.”

Those are the words of Geoffrey Fisher, quoted by Patrick Devlin in The Enforcement of Morals, Chapter 7, “Mill on Liberty in Morals.”

Recently I began reading more material from CISA, the U.S. Department of Justice and MITRE ATT&CK. What pushed me further was a vx-underground post about Peter Stokes, an alleged member of Scattered Spider, and the court papers behind it.

The case made me think less about the privacy switches Windows shows to users and more about the records that exist behind those switches.

The criminal complaint is an allegation, not evidence of guilt. Stokes is presumed innocent unless proven guilty. That legal distinction matters, and so does the technical distinction between what one investigation describes and what every Windows computer necessarily does.

The identifier that caught my attention

The federal complaint describes Microsoft records that associated an installation identifier with URLs, IP addresses and timestamps. The identifier was referred to as GDID, or Global Device Identifier.

I had barely heard of GDID before this. It sounded like one more obscure value hidden somewhere inside Windows, but the important part was the association: an identifier becomes much more revealing when it is connected to network addresses, activity and time.

Microsoft does publicly document a GlobalDeviceId field in its Delivery Optimization reporting schema. The same table includes fields such as device name, ISP, approximate location derived from IP address and the last time the device sent data to Microsoft. Microsoft describes the field as an identifier used internally. Microsoft UCDOStatus reference.

That official documentation proves that a Microsoft global device identifier exists in at least that reporting context. It does not prove that the UCDOStatus table produced the web records described in the complaint, or that every Windows installation reports the same information in the same way.

While looking for more information, I found gdid-reversal, its follow-up We-running-GDID-back, and the ZeroTrace Lab GDID article. These projects discuss local LID values, PUID formatting, Microsoft identity services and possible hardware associations.

They are useful reverse-engineering leads, but they are not Microsoft specifications. Their results should be reproduced on controlled Windows builds before being turned into universal claims.

My current GDID understanding

Question	Current answer
Does Microsoft use something called GlobalDeviceId?	Yes. Microsoft documents the field in its reporting schema.
Is GDID just one registry value?	The independent research identifies a local LID representation, but the local value should not be treated as the complete server-side identity.
Can changing that value make a device anonymous?	There is no evidence that changing it alone removes Microsoft’s backend associations. A service may restore it or correlate the device through other signals.
Would generating a new value every minute help?	Only if every relevant service trusted the new value and discarded every other signal. That has not been demonstrated, and continuous mutation could damage authentication, licensing or updates.
Can a reinstall or virtual machine guarantee a fresh identity?	It can change local observations, but it does not prove that a remote provider cannot recognize the physical device, account or network.
Can previously collected records be deleted locally?	No. Local cleanup cannot recall records already transmitted to a provider.

The most defensible conclusion is that GDID is one signal inside a larger identity and telemetry system. Treating it as a single registry switch would give me more confidence than evidence.

GDID is only one part of the problem

Microsoft’s own optional-diagnostics documentation says covered data can include browser IDs, URLs and search terms, page titles, notification text, and processed typing, inking or speech context. The browsing examples are scoped to Microsoft browsers and the data is described as pseudonymized. Those qualifications matter, but so does the breadth of the documented categories. Optional diagnostic data.

Windows also uses other installation, hardware, account, network and event-correlation fields. Connected experiences, cloud synchronization, application analytics and security services have different data paths. Turning off an advertising ID or one diagnostic setting cannot address all of them.

Some of the strongest identifiers are also the least mysterious. An email account, phone number, payment, recovery address, browser synchronization profile or repeated username can join activity more reliably than an obscure operating-system field.

Privacy without abandoning security

I want to reduce unnecessary collection without turning the computer into an unmaintained target.

Windows Update, browser updates, antivirus, the firewall, disk encryption and supported boot protections still matter. A large blocklist can look impressive while silently breaking certificate maintenance, malware reputation, application updates or operating-system servicing.

There is no way to download an update directly from Microsoft while sending literally nothing to Microsoft. The connection itself exposes an address and timing, and the request contains information needed to deliver the correct package. A VPN changes who sees the source connection, but it does not erase identifying content carried inside a request.

A machine that must make no direct Internet connections needs a different operating model: another maintained computer downloads reviewed, signed packages and transfers them for offline installation. That model has costs. It needs a repeatable process for Windows, Defender, browsers, certificates, firmware and recovery components. It also gives up live reputation and cloud-analysis features.

Privacy controls should therefore state what they disable, what they preserve and what evidence would show that they worked.

The person remains part of the system

The more I read about Scattered Spider, the more obvious it became that endpoint settings are only part of the threat model. CISA describes social engineering, SIM swapping, stolen personal information and help-desk manipulation as central parts of the group’s operations.

People reveal information through conversations, screenshots, documents, usernames, writing style, posting times, contacts and account-recovery choices. Reusing the same identities across supposedly separate environments reconnects them. Signing into a personal account through Tor identifies the session to that account even if the network path is hidden.

This does not make technical privacy controls pointless. It means my habits, account boundaries and published content must be reviewed alongside the operating system.

Before publishing a screenshot or document, I now want to ask:

Does it contain account names, notifications, metadata or a unique directory path?
Does the language, time zone or posting schedule connect it to another identity?
Am I reusing an email address, phone number, recovery account, avatar or username?
Will opening a downloaded file cause another application to connect outside the protected browser?
Am I about to describe a privacy result that I configured but never measured?

A small tool grew out of the research

I started building ms-private to turn this research into a reviewable Windows configuration instead of another opaque “disable everything” script. It has an automatic Fresh Install or conservative Established PC starting point plus four manual intensity presets, a graphical wizard, an arrow-key terminal interface, exact app and sensor selection, recovery journals, network capture, cleanup and security-preservation checks. The normal release is one elevated Windows executable with the reviewed runtime embedded and verified before launch.

The tool reduces documented collection, connected features, application identity state and local retention. It can remove selected applications, purge current-user Microsoft application sign-ins, disable reviewed privacy services, apply supported policies, restrict optional endpoints, disable exact sensors and use timed network isolation. It does not claim to delete Microsoft’s server-side GDID records or make Windows anonymous.

The detailed presets, commands, recovery behavior, GDID scope and validation status live in the separate ms-private tool breakdown. Keeping that material outside this post lets the article remain about why I started the project and what the evidence changed in my thinking.

What I took from this

Privacy is not one button, one browser or one identifier. It is a maintained boundary between the information a device produces, the services it contacts, the accounts I use and the details I reveal myself.

My goal is not to promise invisibility. It is to remove collection I do not need, reduce local traces I can responsibly control, keep the machine secure, separate identities where that matters, and describe every result with enough precision that someone else can test it.

11 KiB Raw Blame History Unescape Escape