Last updated:
no-gdid, added a clear AI-assistance and hand-verification disclosure rather than a new technical claim.GlobalDeviceId as an internal Microsoft identifier, historical Joe Sandbox artifacts still independently preserve Content Delivery Manager requests carrying the field family, and the multi-context PUID model remains an upstream researcher finding that Source Potato treats as attributed work pending independent reproduction of each claimed server-side relationship./v1/a/impression and /v1/a/hover requests to ris.api.iris.microsoft.com.wlidsvc.dll was a Windows 10 version 1803 file. The artifact therefore does not establish GDID machinery in Windows 7.cdp.dll shipped in the base Windows 10 version 1507/build 10240 image. Version 1511/build 10586 retained the service but disabled it by default; version 1607/build 14393 enabled it automatically.GLOBALDEVICEID transmissions we have located.paws-off-my-gdid and gd03gd031’s July 23 update to Windows-GDID-Changer.DeviceVersionRepresentation, without treating mitigation scripts as proof of privacy or unlinkability..DEFAULT, and SYSTEM.We were introduced to the Global Device ID through public reverse-engineering work. That led us down a much larger rabbit hole: where the value exists locally, which Windows components place it into requests, what travels beside it, and how an ordinary computer owner can observe the same behavior without decrypting network traffic.
This investigation did not begin with us. It began with unusually thorough public work by independent researchers who exposed the identifier, documented ways to observe it, and openly corrected and expanded their model as new evidence appeared.
SmtimesIWndr connected a federal court filing to Windows internals, used public symbols and Event Tracing for Windows to trace the identifier, and published a reproducible technical account in gdid-reversal.
The follow-up project, We-running-GDID-back, expanded the investigation beyond a simple one-account/one-identifier explanation and helped shape what our own collector watches.
Prophet001 raised the important no-Microsoft-account question. mayanksh3khar added an independent Windows 10 LTSC/VMware reproduction. MicahZoltu framed the still-unresolved question of how GDID-bearing traffic may be correlated with browsing activity. The original author also credits NullZeroX with flagging the anonymous/no-MSA path that prompted a correction.
Those contributions matter because good research becomes stronger when unexpected results change the explanation.
Our role: Source Potato is extending that foundation with independent local capture, repeatable tooling, and longer-running observation. We are not claiming the original discovery.
A 64-bit identity value represented locally as 16 hexadecimal characters. The original reverse engineering describes values beginning with the 0018 class prefix as device PUIDs. A prefix identifies a class; it is not itself a unique device identifier.
The unsigned decimal representation of a device PUID when used as a global device identifier. Our capture matched the complete decimal value in a request to the decimal conversion of local IdentityCRL state without publishing either raw value.
g:<decimal>A prefixed GDID representation found in Microsoft documentation, the federal complaint, and captured request data. The prefix changes how the identifier is labeled, not the underlying numeric value.
We reviewed the source, scripts, experiments, and stated limitations of nine projects published around the original research. We then performed a read-only check on our Windows 11 test machine. Nothing was deleted, replaced, blocked, or restarted during this validation.
The test machine contained the current user's 16-hex-digit LID under IdentityCRL\ExtendedProperties. That exact value also appeared as the value name under the current-user Immersive Property key and in all six current-user Immersive Token DeviceId values inspected.
Additional populated IdentityCRL state existed under HKEY_USERS\.DEFAULT and HKEY_USERS\S-1-5-18 (SYSTEM), including ExtendedProperties, Immersive Property, and Immersive Token records. Those SYSTEM-context identifiers were not the same value as the signed-in user's LID on this machine.
We also confirmed the presence of machine-level NegativeCache, ThrottleCache, and IdentityStore\Providers trees. This establishes that the local identity state is broader than one HKCU value.
Presence is not proof of purpose. This read-only check does not, by itself, prove which copy is authoritative, which copy can recreate another, which service wrote each record, or whether every identifier is transmitted as a GDID.
deGDID reports controlled VM experiments involving anonymous minting, persistence, protection, and reminting. Windows-GDID-Changer reports a destructive remint procedure. Those are valuable, testable leads; we will label them as external findings until Source Potato reproduces the behavior in a disposable VM.
Likewise, service and endpoint associations reported by community mitigation projects are investigative context—not automatic proof that a particular request contained GDID.
Observed by Source Potato: the signed-in user, .DEFAULT, and SYSTEM contained populated identity state, and the SYSTEM-context values inspected were not the same as the signed-in user's LID. Current-user Immersive Property and Token records repeated the current-user value, while machine-level IdentityCRL trees contained additional caches and provider state.
Reported by the original researchers: one Windows installation can hold multiple device PUIDs associated with different security contexts. Their follow-up work also reports a user-context Windows component transmitting a SYSTEM-associated device PUID. We have confirmed the existence of distinct contexts locally, but we have not independently reproduced every selection and switching behavior described upstream.
This is why “one permanent ID per PC” is too simple. The evidence supports a set of related identity records whose selected value can depend on the Windows component, token, account state, and security context involved.
IdentityCRL\NegativeCache: machine-level PUID/SID records; the decimal conversion of one locally stored device PUID matched our transmitted GDID.IdentityCRL\ExtendedProperties: populated user and SYSTEM-context identity properties, including LID state.Property and Token records: repeated device-identity state associated with the corresponding context.IdentityCRL\ThrottleCache and IdentityStore\Providers: supporting machine-level identity trees whose presence we confirmed but whose complete roles are not established by a read-only inventory.DeviceVersionRepresentation identified by two independent community implementations as part of device-registration refresh behavior.Paths and field names are published because they are necessary for independent verification. Every raw value, SID-bearing record name, and participant-specific identifier remains withheld.
A new project, Metrix187’s paws-off-my-gdid, separates a quiet local HKCU substitution from a much more disruptive attempt to make Windows request a fresh server-issued device identifier. Its source adds backup, restore, dry-run, and managed-device safeguards around changes to SYSTEM-context IdentityCRL and Windows Push Notification state.
On the same day, Windows-GDID-Changer added a Push Notification cache reset. Both projects identify HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\PushNotifications\<old GDID> and DeviceInfo\DeviceVersionRepresentation as state involved when refreshing a device registration.
Why this matters to our work: two independently published implementations now give us exact registry surfaces and service activity to observe during a controlled test. They may help us trigger and recognize identity lifecycle events in GDID Usage Discovery.
What remains unproven: deleting local state, changing the presented value, or receiving a new server-issued value does not establish that Microsoft cannot correlate the old and new records through account, certificate, hardware, network, or other machine information. We have reviewed these scripts but have not executed their destructive operations. They are test leads, not privacy guarantees.
wlidsvc, and Windows Update registration.Microsoft’s Intune feature-update troubleshooting documentation defines DeviceRegistrationInvalidGlobalDeviceId as a failure to register or authenticate with Windows Update because of an invalid Global Device ID. Microsoft says an unavailable Microsoft Account Sign-In Assistant service may prevent Global Device ID assignment and recommends making that service able to run.
This is important first-party corroboration. It independently supports the reverse-engineered role of wlidsvc, establishes that GDID participates in Windows Update registration or authentication, and explains why disabling identity services can damage ordinary update functionality. It does not disclose every service that receives GDID or every field transmitted beside it.
ZeroTrace Lab’s live patching experiments, using the implementation published by 5mukx in GDID-Extractor, separate four layers: the plaintext registry LID, a DPAPI-protected DeviceTicket containing a Microsoft-signed certificate and PUID, hardware descriptors, and Microsoft’s server-side record.
Replacing only the plaintext LID changes what a local registry reader reports. The DeviceTicket still presents the original certificate-backed identity when wlidsvc authenticates again, and the visible value can revert. This experimentally supports treating registry-only “rotation” as a cosmetic local substitution, not a demonstrated change to Microsoft’s authoritative identity or historical records.
Claims about the exact hardware inputs and Microsoft’s server-side linkage remain partly inferred because the backend cannot be inspected from the client.
A detailed field report against gdid-privacy identified reproducible firewall-rule construction defects, success messages printed after failed rule creation, rapidly changing Microsoft endpoint addresses, and elevated scheduled tasks launched from a user-writable path. A separate Windows 10 report shows its rotated value immediately returning to the original GDID.
An updated no-gdid compatibility report describes Windows Update, Microsoft Store updates, and DISM source retrieval failing after relevant services were disabled on Windows 11 Pro 25H2 build 26200.8875. That is a community report rather than a controlled Microsoft test, but it is consistent with Microsoft’s own update-registration documentation.
Practical conclusion: a tool saying “blocked” or “rotated” is not evidence. A defensible mitigation requires before-and-after capture, correct rule verification, functionality testing, and proof that the server-observed identity changed or disappeared.
David Swan changed gdid-privacy so blockCDP defaults to enabled. The change disables CDPSvc and CDPUserSvc and explicitly warns that Nearby Share, cross-device clipboard, and Continue on PC will stop working.
The project also says this makes the real GDID “never reported” and eliminates the tracking vector entirely. We cannot validate that universal claim. Our controlled capture below used Windows Content Delivery Manager and backgroundTaskHost.exe to send a locally matched GDID to the IRIS service. That demonstrated path is distinct from merely observing CDP/DDS traffic.
Evidence-based interpretation: disabling CDP may block or disrupt a documented part of the identity ecosystem. Only a controlled before-and-after test across each known sender can establish which transmissions it actually prevents.
A July 24 script posted to the foundational repository disables CDP and Microsoft Account services, deletes local identity state, changes Activity Feed policies, and blocks a domain list. It does not include a before-and-after GDID-bearing capture proving that every transmission path stops, and its rollback cannot recreate every identity artifact it deletes.
We therefore classify it as an unverified and potentially disruptive community experiment. We have not executed it, and its presence in an issue on the original research repository does not make it an endorsed fix.
Neowin’s July 23 overview, IBTimes UK’s July 23 coverage, and Lenta.ru’s July 24 report expanded public awareness but did not add a new packet capture, binary trace, Microsoft disclosure, or court filing. They largely restate the federal complaint, prior reporting, and community reverse engineering.
Some public summaries continue to describe one identifier per PC; the evidence reviewed here instead supports multiple device PUID/GDID values associated with different security contexts on one Windows installation.
Publication date and popularity do not turn a summary into independent technical confirmation. Our evidence hierarchy continues to place court records, captured request data, reproducible local observations, and source-level analysis above derivative news coverage.
The answer depends on whether we mean the older identity foundation, the Windows machinery that resembles the current GDID system, or a captured request that actually contains GLOBALDEVICEID. Those are related facts, but they are not interchangeable.
Microsoft Passport and Windows Live used persistent PUIDs for accounts before current versions of Windows. This is the identity family from which device PUIDs developed, but an old account PUID is not by itself proof of the modern Windows-installation GDID or its transmission.
A Hybrid Analysis report executes a wlidsvc.dll sample inside a Windows 7 SP1 build 7601 guest, but the file metadata identifies the sample itself as Windows 10 version 1803, file version 10.0.17134.523. The guest operating system is the analysis environment, not the sample's provenance. This artifact therefore cannot establish DevicePUID or modern GDID behavior in Windows 7.
Windows 8 made Microsoft Accounts a first-class Windows sign-in, and publicly preserved 2013 registry material contains IdentityCRL device identities and certificates. We have not yet established the originating Windows edition and build strongly enough, nor located a period request containing the exact modern GLOBALDEVICEID field. It remains a historical lead rather than a dated GDID finding.
Indexed Windows binaries show that cdp.dll shipped in the base Windows 10 version 1507 image, build 10240, with file version 10.0.10240.16384. Historical service records describe CDPSvc as present but disabled by default in Windows 10 version 1511, build 10586, and automatic by default in Windows 10 version 1607, build 14393. Its role is to authenticate users and devices and connect them through local or cloud-backed device scenarios. Together with wlidsvc, IdentityCRL, DDS, Windows reporting, and Microsoft content services, this is the earliest Windows generation whose architecture closely resembles the GDID system under current investigation.
This supports a cautious conclusion that the present cross-service infrastructure took shape during the Windows 10 rollout, not that every Windows 10 component or request necessarily carried GDID.
The earliest outgoing evidence we have located was recorded on November 24, 2020 in a Windows 10 version 1803 environment. Both the sandbox description and request metadata identify OS build 17134.1. The request contains a decimal GLOBALDEVICEID in an MSN/IRIS impression pattern. Separate December 2021 and January 2022 captures preserve the same field and request family on the same version 1803/build 17134.1 test baseline. These artifacts predate the 2026 public controversy and were generated independently of our investigation.
Microsoft's later Managed Desktop API and Windows Update reporting schemas show globalDeviceId or GlobalDeviceId as an established device-record field. The archived API placed it beside device, tenant, assigned-user, operating-system, management, and compliance information. That proves broad internal record context; it does not prove every GDID-bearing request included every neighboring field.
The same Windows build can have several historically meaningful dates. Availability rows explain when it reached manufacturers, consumers, and independent PC builders. Technical rows explain what GDID-related evidence exists. Shipping a component is not treated as proof that it transmitted an identifier.
GDID-specific control: we found general controls for Microsoft Account connections, wlidsvc, CDPSvc, and diagnostic-data levels, but no reviewed Windows release documents a user-facing choice specifically naming GDID, Device PUID, or GLOBALDEVICEID. “Disabled by default” below describes a service configuration, not informed consent. “Diagnostic data reduced” is not treated as proof that GDID transmission stops.
cdp.dll 10.0.10240.16384wlidsvc.dll 10.0.17134.523GLOBALDEVICEID field locatedGLOBALDEVICEID field.System Builder/OEM product reached resellers through a commercial distribution channel rather than one universal worldwide shelf date. The timeline therefore identifies the 2015 launch period without asserting an unsupported day for every region or distributor.
The earliest version boundary currently supported for the recognizable GDID infrastructure is Windows 10. The CDP binary shipped in version 1507/build 10240, CDPSvc was disabled by default in version 1511/build 10586, and it became automatic by default in version 1607/build 14393. The earliest preserved outgoing GLOBALDEVICEID evidence we have located is Windows 10 version 1803/build 17134.1 on November 24, 2020.
We have not found sufficient evidence to claim that Windows 7 transmitted the modern field, to assign Windows 8 a defensible GDID build, to identify one exact collection start date, or to show that the complete present-day correlation capability existed in every earlier version. Establishing an earlier transmission date requires a period-correct binary or installation plus preserved network or ETW evidence—not a filename, registry name, or sandbox guest label alone.
The clearest public example is the 2026 superseding criminal complaint in United States v. Peter Stokes. The document is a sworn FBI agent's probable-cause affidavit. It describes what investigators say Microsoft records showed and how those records contributed to identifying a device user.
According to the complaint, Microsoft records associated one GDID with the creation of an ngrok account allegedly used in a corporate intrusion. The records indicated that the same GDID-bearing device visited the ngrok signup page and the victim company's website through the same proxy address.
The affidavit then compared IP addresses recorded for that GDID with access to Apple, Facebook, Google, and Snapchat accounts, residential connections, government travel records, and publicly or privately shared travel images. The FBI agent presented those overlaps as part of the probable-cause basis for attributing the device and related activity to Peter Stokes.
The Justice Department case announcement says Stokes was arrested in Finland, extradited to the United States, and charged with conspiracy, computer intrusion, and fraud offenses arising from alleged Scattered Spider activity. The DOJ says the FBI Chicago Field Office investigated the matter.
Legal-status warning: a criminal complaint contains allegations and a probable-cause presentation. It is not a trial finding or proof of guilt. The defendant is presumed innocent unless proven guilty in court. We therefore say GDID records contributed to an FBI attribution case—not that GDID alone “caught” or convicted anyone.
The filing demonstrates a real investigative use of GDID-indexed Microsoft records. It describes those records connecting a persistent Windows-installation identifier with website visits, timestamps, IP addresses, and other account and location evidence. GDID was one link in a larger evidentiary chain, but it gave investigators a stable pivot where VPN and proxy addresses changed.
Read the primary complaint — especially paragraphs 25 through 30 — and the Justice Department case announcement.
Investigating serious cybercrime is a legitimate public interest. That does not erase the civil-liberties question created by an operating system assigning a durable identifier, transmitting it with rich device context, and enabling records about changing network activity to be joined back to one installation.
IP addresses rotate. People travel, use cellular networks, share connections, and use VPNs. A stable device-level pivot can reconnect those otherwise separate sessions and locations after the fact.
Our capture did not show GDID traveling alone. It appeared with other persistent identifiers, public-network information, detailed machine characteristics, locale, preferences, and activity context. Combined data is more identifying than any single field.
Trust in Microsoft's current intentions, access controls, retention rules, legal review, and government relationships cannot guarantee how the capability will be governed tomorrow—or how another jurisdiction might compel its use.
People should not have to grant blind trust merely because the collector is their operating-system vendor or because one documented use served a criminal investigation. A capability powerful enough to help identify a suspect is powerful enough to affect journalists, whistleblowers, activists, abuse survivors, political opponents, researchers, and ordinary users.
The answer is not to hide legitimate evidence or excuse crime. It is meaningful disclosure, data minimization, clear controls, narrow retention, auditable access, due process, and independent scrutiny. Users deserve to know that the identifier exists, when it leaves their machine, what accompanies it, who can obtain the resulting records, and how to disable or delete it.
Documented fact: the FBI affidavit describes Microsoft GDID records being used as one component of a real device-attribution chain. Our demonstrated fact: a Windows test machine constructed GDID-bearing requests containing extensive accompanying data. Our risk assessment: that combination creates a powerful, opaque correlation capability with foreseeable misuse, breach, overreach, and mistaken-attribution consequences. The first two points are evidence; the third is our stated conclusion from that evidence.
The block below is a field-for-field sanitized rendering of the MSN ARC impression request from our test computer. It is not a fabricated example and it is not a list assembled from documentation. The field order, repeated fields, endpoint, field names, and non-identifying configuration values come from the captured event.
We replaced the raw GDID, public IP address, PUID-derived and advertising identifiers, request/session/event IDs, timestamps, exact OEM model, precise hardware fingerprint, storage measurements, and experiment assignments with descriptive bracketed placeholders. Repeated placeholders represent repeated appearances of the same original value where applicable.
We retained ordinary booleans, enumerations, locale, operating-system family/build, architecture, channel, and field order when they do not independently identify the owner. This gives readers the guts of the evidence without publishing a reusable fingerprint of the test computer.
Addressed endpoint:
https://arc.msn.com/v3/Delivery/Events/Impression?
PID=[REDACTED_CONTENT_ID]
TID=1
CID=[REDACTED_CORRELATION_ID]
BID=[REDACTED_CONTENT_ID]
PG=[REDACTED_PAGE_PLACEMENT]
TPID=[REDACTED_CONTENT_ID]
REQASID=[REDACTED_REQUEST_SESSION_ID]
ASID=[REDACTED_REQUEST_SESSION_ID]
SLOT=1
REQT=[REDACTED_REQUEST_TIMESTAMP]
MA_Score=0
WFIDS=
QFIDS=
ANID=[REDACTED_ADVERTISING_ID]
PERSID=[REDACTED_PERSONALIZATION_ID]
GLOBALDEVICEID=[REDACTED_16_DIGIT_GDID]
LOCALID=[REDACTED_LOCAL_DEVICE_ID]
DS_EVTID=[REDACTED_EVENT_ID]
BCNT=1
PG=[REDACTED_PAGE_PLACEMENT]
UNID=[REDACTED_CONTENT_ID]
MAP_TID=[REDACTED_MAPPING_ID]
NCT=1
ASID=[REDACTED_REQUEST_SESSION_ID]
REQASID=[REDACTED_REQUEST_SESSION_ID]
ARC=1
EMS=1
AUTH=1
LOCALE=EN-US
COUNTRY=US
HTD=-1
LANG=1033
DEVLANG=EN
CIP=[REDACTED_PUBLIC_IP_ADDRESS]
ID=[REDACTED_ADVERTISING_OR_DEVICE_ID]
OPTOUTSTATE=256
NGPAGEGROUPOPTOUT=0
ADSOPT=0
HTTPS=1
DEVOSVER=10.0.26200.8875
DEVOSMAJ=10
DEVOSMIN=0
DEVOSBLD=26200
DEVOSMINBLD=8875
LOD=[REDACTED_INSTALL_OR_AGE_VALUE]
LOH=[REDACTED_INSTALL_OR_AGE_VALUE]
LO=[REDACTED_INSTALL_OR_AGE_VALUE]
MARKETBASEDCOUNTRY=US
CLR=CDMLITE
ISU=0
CFMT=
H=0
W=0
FESVER=1.3
MSATICKETTYPE=1
LC=EN-US
PL=EN-US
PO=1
MX_FLIGHTIDS=[REDACTED_EXPERIMENT_ASSIGNMENTS]
ANDOPTIN=1
ARCH=AMD64
CONCP=1
D3DFL=D3D_FEATURE_LEVEL_12_1
DEVFAM=WINDOWS.DESKTOP
DEVFM=0
DINST=[REDACTED_INSTALL_TIME_VALUE]
DMRET=0
FLIGHTBRANCH=
FLIGHTRING=RETAIL
ICLUC=0
IEPE=1
ISTE=1
OEM=[REDACTED_OEM_MODEL_CODE]
OEMMSF=[REDACTED_MANUFACTURER_AND_MODEL]
OEMN=[REDACTED_MANUFACTURER]
OEMNAME=[REDACTED_MANUFACTURER]
OSBRANCH=GE_RELEASE
OSLOCALE=EN-US
OSRET=1
OSSKU=PROFESSIONAL
OSSKUID=48
PRCCN=[REDACTED_LOGICAL_PROCESSOR_COUNT]
PRCCS=[REDACTED_PROCESSOR_VALUE]
PRCMF=[REDACTED_PROCESSOR_MANUFACTURER]
PROCM=[REDACTED_FULL_PROCESSOR_MODEL]
RAM=[REDACTED_MEMORY_AMOUNT_MB]
SMBIOSDM=[REDACTED_SMBIOS_MODEL]
TINST=CLIENT
TL=1
WASCA=0
WASCP=0
USRI=-2
PAT=1
SAC=0
DISPHORZRES=[REDACTED_DISPLAY_WIDTH]
DISPSIZE=[REDACTED_DISPLAY_SIZE]
DISPVERTRES=[REDACTED_DISPLAY_HEIGHT]
LDISPHORZRES=[REDACTED_LOGICAL_DISPLAY_WIDTH]
LDISPVERTRES=[REDACTED_LOGICAL_DISPLAY_HEIGHT]
MONCNT=[REDACTED_MONITOR_COUNT]
CPDSK=[REDACTED_DISK_CAPACITY_MB]
FRDSK=[REDACTED_FREE_DISK_MB]
TSU=[REDACTED_SYSTEM_OR_USAGE_VALUE]
RULES_SCHEMA=1
WINDOWSBACKUPPAGE=ODPURCHASE
WINDOWSBACKUPVARIANT=2
CHNL=CFD
UIT=A
GLOBALDEVICEID=g:[REDACTED_SAME_16_DIGIT_GDID]The GDID appeared twice: once as an unprefixed decimal value and again in the documented g: representation. The same request also carried several other identifiers capable of correlating content, advertising, personalization, sessions, events, and local-device activity.
It shows the content Windows constructed and submitted to its networking stack for the addressed endpoint. It does not independently establish successful server receipt, retention, internal interpretation, or the undocumented meaning of every abbreviated field.
We inventoried Windows IdentityCRL state and found a local hexadecimal PUID whose unsigned decimal representation matched the transmitted GLOBALDEVICEID.
We used Windows-native diagnostic events to preserve the request, process ID, package attribution, path, and timing before short-lived background processes disappeared.
The identifier appeared beside persistent correlation values and, in one request, a detailed hardware, operating-system, locale, storage, display, experiment, preference, and public-network profile.
A roughly three-hour searchable capture window recorded four logical HTTPS request operations containing the same 16-digit decimal GLOBALDEVICEID. The computer was unattended for the capture. Duplicate ETW records belonging to the same HTTP operation were removed before counting.
microsoft.windows.contentdeliverymanager_cw5n1h2txyewy constructed three requests addressed to:
ris.api.iris.microsoft.com/v1/a/impression
Alongside GDID, the observed field names included content, audience, placement, local-device, advertising, personalization, request, session, event-time, Windows version, OEM, and experiment/feature-flight values.
MicrosoftWindows.Client.CBS_cw5n1h2txyewy constructed one request addressed to:
arc.msn.com/v3/Delivery/Events/Impression
That request contained GDID twice and included more than 100 named parameters describing the machine, its Windows environment, network context, content event, preferences, and other correlation-capable identifiers.
GLOBALDEVICEID, ANID, ASID, CID, ID, LOCALID, PERSID, REQASID, DS_EVTID, and MAP_TID.
OEM and model, processor and vendor, logical processor count, architecture, RAM, disk capacity and free space, graphics capability, display dimensions, monitor count, Windows edition, build, branch, and device family.
Public IP address, country, locale, language, retail flight ring, feature experiments, opt-out and advertising state, content placement, impression identifiers, and request time.
The captured decimal GDID and the decimal conversion of a 16-character hexadecimal PUID stored beneath HKLM\SOFTWARE\Microsoft\IdentityCRL\NegativeCache produced the same complete SHA-256 digest. That establishes a match between the transmitted value and locally stored Windows identity state without publishing either value.
Privacy note: this public account intentionally omits the raw GDID/PUID, public IP, account identifiers, exact machine model, evidence timestamps, temporary process IDs, and other values that could point back to the test computer or its owner. Field names, counts, packages, destinations, methods, and non-identifying conclusions are retained.
The searchable portion of the unattended capture contained three closely grouped Content Delivery Manager impression requests to the IRIS endpoint, followed later by one Client CBS impression request to MSN ARC. We publish the order, package identities, destinations, and logical request count while withholding exact timestamps, temporary process IDs, request/session identifiers, and the identifier values themselves.
ris.api.iris.microsoft.com/v1/a/impressionris.api.iris.microsoft.com/v1/a/impressionris.api.iris.microsoft.com/v1/a/impressionarc.msn.com/v3/Delivery/Events/ImpressionThe unattended state matters: no person needed to open a browser or intentionally visit either endpoint during the recorded activity. It does not establish that every idle Windows computer will produce the same requests on the same schedule.
IdentityCRL supplied locally stored identity state. Windows packages constructed GDID-bearing request operations, and WinINet diagnostic events exposed the request data before HTTPS encryption. Package attribution tied the IRIS operations to Content Delivery Manager and the ARC operation to Client CBS.
That is the directly observed portion of our evidence chain. An executable host name such as backgroundTaskHost.exe is not sufficient attribution by itself; the hosted package and process context are necessary.
The original reverse engineering associates wlidsvc, IdentityCRL helpers, Connected Devices Platform (CDP), and Device Directory Services (DDS) with device-identity creation, lookup, transport, or synchronization. Community work adds Windows Push Notification registration state to the lifecycle picture.
Those associations are valuable technical evidence, but our request capture did not independently execute and prove every internal call in that complete chain. We preserve the distinction between our dynamic observation and externally reported internals.
GLOBALDEVICEID was the field we matched to local PUID state. LOCALID, ANID, PERSID, session/request IDs, advertising values, and other opaque fields accompanied it but are not automatically alternative names for GDID. Their ability to correlate activity may still matter even when their undocumented semantics remain unknown.
Microsoft's separately documented SQM MachineId is another durable Windows identifier stored under SQMClient; it should not be conflated with the IdentityCRL PUID/GDID family. Likewise, a Store-style identifier or a GUID-shaped local value is not a GDID merely because it is persistent.
Independent pre-2026 sandbox and privacy-analysis artifacts contain the same GLOBALDEVICEID field and IRIS/MSN impression patterns. Those historical records corroborate that the request behavior was not introduced for this investigation or created by our test. They do not prove which local PUID supplied every historical value.
After many non-results, we isolated the difference between creating a real content event and asking Windows to deliver it. We repeated the complete sequence twice on the same Windows 11 test computer. Both runs produced new operating-system beacon data, drained that queue through the registered Content Delivery Manager task, and generated new GDID-bearing requests captured by our watcher.
Subscription 338387 represents Windows Spotlight lock-screen content. We backed up and cleared only the current creative’s event-history values, locked the workstation, allowed the current Spotlight item to remain visible, and unlocked it. Windows then recreated event-cache values and wrote fresh beacon data beneath:
%LOCALAPPDATA%\Packages\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\LocalState\ContentManagementSDK\Creatives\338387\
The relevant queue files are imprbeacons.dat and eventbeacons.dat. No URL was manually replayed and no request payload was fabricated.
We used Microsoft’s documented IPackageDebugSettings interface to enumerate the installed package’s registered background tasks, then activated ContentDeliveryManager.Background.MaintenanceTask. Microsoft also documents the same package-lifecycle capability through PLMDebug.
The queue drained, backgroundTaskHost.exe hosted Content Delivery Manager, and the watcher preserved requests addressed to ris.api.iris.microsoft.com.
HKCU\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager\Subscriptions\338387 value ShortContentId.HKCU\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager\CreativeEventCache\SubscribedContent-338387, then remove only history values whose names contain that current creative ID.ContentDeliveryManager.Background.MaintenanceTask.In both controlled runs, the resulting requests used /v1/a/impression and /v1/a/hover. The captured outbound data contained an exact local GLOBALDEVICEID representation together with LOCALID, PERSID, and ANID. Every unique value remains withheld.
Create a real Spotlight presentation event, verify that Windows queued it, and then invoke the registered Content Delivery Manager maintenance task.
Lock/unlock, network cycling, generic scheduled-task batches, cache refresh tasks, and the maintenance task without a newly queued event did not reliably produce another disclosure.
It does not establish server receipt or retention policy, and it does not mean every Spotlight display transmits immediately. It does prove repeatable local request construction and submission to the Windows networking stack.
Joe Sandbox analysis 557237 independently preserves the same Content Delivery Manager package family, subscription 338387, backgroundTaskHost.exe, an IRIS /v1/a/impression path, and the GLOBALDEVICEID/LOCALID field family. That older artifact supports the behavior’s independent existence; our controlled test adds a repeatable trigger and a locally verified identifier match.
Timing caution: ETW records can carry provider timestamps that do not align perfectly with the moment a watcher finishes enrichment or writes its incident file. We therefore correlate raw event time, detection time, enrichment time, queue-file changes, process ID, and file-append time instead of treating one displayed timestamp as the entire chronology.
Windows packages constructed requests containing a decimal representation of local IdentityCRL state and submitted those operations to the Windows networking stack for Microsoft service paths.
Client-side ETW does not independently prove successful server receipt, how Microsoft interpreted or retained the data, or whether every field name has the meaning it appears to suggest.
A short trace may record nothing. The behavior can be scheduled, cached, disabled, account-dependent, feature-dependent, or simply outside the observation window.
Community experiments provide leads for several of these questions. Until independently reproduced under controlled conditions, they remain reported behavior or hypotheses—not conclusions from our capture.
This procedure is intended for a Windows computer you own or are authorized to examine. It does not install a proxy certificate, decrypt TLS, alter an identifier, or modify traffic. The resulting ETL and XML can contain private URLs, tokens, IP addresses, account metadata, and identifiers. Keep them private.
You do not need to install PowerShell or download a packet-capture program. These commands use tools included with Windows. The test does require administrator access.
$workFolder = Join-Path $env:USERPROFILE 'Desktop\GDID-Reproduction'
New-Item -ItemType Directory -Force -Path $workFolder | Out-Null
Set-Location $workFolder
"Working folder: $((Get-Location).Path)"
"Administrator: $([Security.Principal.WindowsPrincipal]::new(
[Security.Principal.WindowsIdentity]::GetCurrent()
).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))"Expected result: PowerShell prints a folder ending in Desktop\GDID-Reproduction and Administrator: True. If it says False, close the window and reopen PowerShell using Run as administrator.
Keep this same PowerShell window open through the start step. The later stop commands use the session's explicit name, so the trace can still be stopped from a new elevated PowerShell window if Windows restarts the terminal.
This writes only each candidate's four-character class prefix and the SHA-256 hash of its decimal representation. It does not write the SID or raw PUID.
$candidateHashes = @()
$path = 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IdentityCRL\NegativeCache'
if (Test-Path $path) {
Get-ChildItem $path -ErrorAction SilentlyContinue | ForEach-Object {
if ($_.PSChildName -match '^(?<puid>[0-9A-Fa-f]{16})_S-.+$') {
try {
$decimal = [Convert]::ToUInt64($Matches.puid, 16).ToString()
$sha = [Security.Cryptography.SHA256]::Create()
try {
$digest = ([BitConverter]::ToString(
$sha.ComputeHash([Text.Encoding]::UTF8.GetBytes($decimal))
)).Replace('-', '')
} finally { $sha.Dispose() }
$candidateHashes += [pscustomobject]@{
Prefix = $Matches.puid.Substring(0, 4)
DecimalSHA256 = $digest
}
} catch {}
}
}
}
$candidateHashes | ConvertTo-Json |
Set-Content '.\local-id-hashes.json' -Encoding UTF8
"Candidate local identifiers recorded: $($candidateHashes.Count)"
Get-Item '.\local-id-hashes.json' | Select-Object Name, LengthExpected result: the command reports one or more candidate identifiers and shows a small file named local-id-hashes.json. A result of zero is possible on some systems, but it means this procedure will not be able to prove the local-value match even if a network request is later found.
The circular trace is limited to 256 MB. It enables the Windows WinINet and WinHTTP ETW providers.
$session = 'GDID-Public-Reproduction'
logman create trace $session -ow -o '.\gdid-user.etl' -f bincirc -max 256 -ets
# Microsoft-Windows-WinINet
logman update trace $session `
-p '{43D1A55C-76D6-4F7E-995C-64C711E5CAFE}' 0xFFFFFFFFFFFFFFFF 0xFF -ets
# Microsoft-Windows-WinHttp
logman update trace $session `
-p '{7D44233D-3055-4B9C-BA64-0D47CA40A232}' 0xFFFFFFFFFFFFFFFF 0xFF -ets
logman query $session -etsExpected result: each setup command prints The command completed successfully. The final query should list GDID-Public-Reproduction with a running status and show the two provider GUIDs.
If Windows reports that the data collector already exists, run the cleanup block under Troubleshooting and safe cleanup, then repeat this step.
Leave the machine idle. If you deliberately open Windows content surfaces such as Widgets, Start recommendations, or Windows Backup prompts, write down the time so you can distinguish those actions from unattended behavior.
Return to an elevated PowerShell window after the observation period. If this is a new window, run the first three setup lines again to return to the correct folder. Then paste this block:
$workFolder = Join-Path $env:USERPROFILE 'Desktop\GDID-Reproduction'
Set-Location $workFolder
logman stop 'GDID-Public-Reproduction' -ets
logman delete 'GDID-Public-Reproduction'
tracerpt '.\gdid-user.etl' -of XML -o '.\gdid-user.xml' -yExpected result: the stop and delete commands complete successfully. tracerpt reaches 100 percent and creates gdid-user.xml. The XML may be much larger than the original ETL file; that is normal.
Get-Item '.\gdid-user.etl', '.\gdid-user.xml', '.\local-id-hashes.json' |
Select-Object Name, Length, LastWriteTimeAll three files should be listed. Keep them private.
Paste the complete block below. It reads the XML, finds absolute HTTP or HTTPS URLs containing a decimal GLOBALDEVICEID, and prints only the destination, identifier length, and parameter names. It keeps the raw identifier in memory for the next validation step but does not display it.
$xmlText = Get-Content '.\gdid-user.xml' -Raw
$pattern = '(?i)(?<url>https?://[^\s"<>]*?GLOBALDEVICEID=(?<id>[0-9]{8,20})[^\s"<>]*)'
$urlMatches = [regex]::Matches($xmlText, $pattern)
$candidateRequests = foreach ($match in $urlMatches) {
$decodedUrl = [Net.WebUtility]::HtmlDecode($match.Groups['url'].Value)
try {
$uri = [Uri]$decodedUrl
$fieldNames = [regex]::Matches($uri.Query, '(?:^|[?&])([^=&]+)=') |
ForEach-Object {
[Net.WebUtility]::UrlDecode($_.Groups[1].Value)
} | Sort-Object -Unique
[pscustomobject]@{
Destination = $uri.Host + $uri.AbsolutePath
GDIDLength = $match.Groups['id'].Value.Length
Fields = $fieldNames -join ', '
PrivateGDID = $match.Groups['id'].Value
}
} catch {}
}
"Raw matching URL records: $($candidateRequests.Count)"
$candidateRequests |
Select-Object Destination, GDIDLength, Fields -Unique |
Format-ListExpected result when activity was captured: the count is greater than zero and at least one block lists a destination and GDIDLength. Multiple raw records may describe the same logical request, so the raw count is not a reliable count of separate transmissions.
If the count is zero: first confirm that gdid-user.xml is not empty. If it contains data, the machine simply may not have produced a matching request during this window. Repeat a longer capture. A zero result does not show that the computer never sends GDID.
Run this block in the same PowerShell window immediately after step 4. It hashes every distinct captured GDID in memory and compares those hashes with the local inventory. It prints no raw identifier.
if (-not $candidateRequests -or $candidateRequests.Count -eq 0) {
Write-Warning 'No candidate request is available to validate.'
return
}
$inventory = @(Get-Content '.\local-id-hashes.json' -Raw | ConvertFrom-Json)
$validation = foreach ($observedGdid in (
$candidateRequests.PrivateGDID | Sort-Object -Unique
)) {
$sha = [Security.Cryptography.SHA256]::Create()
try {
$digest = ([BitConverter]::ToString(
$sha.ComputeHash([Text.Encoding]::UTF8.GetBytes($observedGdid))
)).Replace('-', '')
} finally { $sha.Dispose() }
[pscustomobject]@{
GDIDLength = $observedGdid.Length
GDIDSHA256 = $digest
MatchesLocalDecimalPUID = [bool](
$inventory.DecimalSHA256 -contains $digest
)
}
}
$validation | Format-List
$candidateRequests = $null
$observedGdid = $null
$xmlText = $nullThe core result is reproduced when: at least one result says MatchesLocalDecimalPUID: True. The destination printed in step 4 identifies where that GDID-bearing request was addressed. Save the hashes and redacted output if you want to report the reproduction; do not publish the XML or raw URL.
tracerpt cannot find the ETL: run the working-folder setup again and confirm that gdid-user.etl exists with Get-ChildItem.This cleanup is safe to run after an interrupted attempt. Errors saying the collector does not exist can be ignored.
logman stop 'GDID-Public-Reproduction' -ets
logman delete 'GDID-Public-Reproduction'
# Confirm that the named trace is no longer running.
logman query -ets | Select-String 'GDID-Public-Reproduction'If the final command prints nothing, the named trace is no longer active. Deleting the GDID-Reproduction folder later removes the local test files; do that only after you have finished reviewing or preserving your evidence.
GLOBALDEVICEID field.The native procedure establishes request construction, destination/path, field presence, and local-value equivalence. Exact process/package attribution requires structured ETW parsing and careful timestamp/PID correlation, which our collector automates.
Our original ETW data contains identifiers, URLs, account context, and unrelated diagnostic material belonging to the test computer. We retain that evidence privately but do not distribute it. Publishing fingerprints of files that readers cannot obtain would not let them inspect the evidence or validate our interpretation.
The standalone procedure above uses Windows' built-in ETW facilities to inventory privacy-preserving identifier hashes, capture client-side request activity, and test whether a locally stored PUID representation appears as GLOBALDEVICEID. A successful independent run creates new evidence on the verifier's own system rather than asking them to trust ours.
Keep the resulting ETL, XML, URLs, identifiers, and hashes private. A verifier can publish sanitized field names, destinations, package attribution, method, counts, and conclusions without exposing the computer's unique values.
These are separated by evidentiary role. A news article repeating the original work is useful context, but it is not independent proof of the underlying technical claim.
cdp.dll: indexed Microsoft binary metadata showing base-image CDP files for Windows 10 version 1507/build 10240.GlobalDeviceId field.IPackageDebugSettings documentation: the official interface used to enumerate and activate a packaged application’s registered background tasks during our controlled Spotlight test.globalDeviceId within a broader managed-device record.GlobalDeviceId, device name, scan times, and update context.wlidsvc.dll sample: the file is version 10.0.17134.523; Windows 7 SP1 build 7601 is only the sandbox guest in which it was analyzed.These machine-generated analysis records are valuable because they preserve older occurrences of GLOBALDEVICEID independently of the 2026 discussion.
These pages demonstrate international reach and interpretation. They are not treated as additional independent technical proof.
Listing a project acknowledges relevant surrounding work; it does not endorse its conclusions, safety, or implementation. We inspected these projects but did not execute their code.
We are building a small Windows application that gives the computer owner visibility into activity that is normally buried inside operating-system diagnostics. Its purpose is to answer four practical questions: which identifier appeared, what application or Windows component used it, what other data accompanied it, and where the resulting request was addressed.
Read the machine's relevant GDID and PUID representations so later events can be tested against exact local values.
Monitor selected Windows ETW, identity, registry, and network activity without decrypting unrelated traffic.
Save the matching event first, then gather the process tree, command line, executable, package, handles, modules, sockets, destination, and nearby evidence while it still exists.
Show a readable incident summary alongside all evidence retained by the research system, with the matched identifier visibly called out.
The watcher records incidents locally and can alert the user when one is found. It can be used without sending research data to Source Potato. Reporting is a separate opt-in choice: the application displays the full disclosure, requires affirmative agreement, and records the disclosure version and consent event before reporting begins. Only new incidents after consent are eligible.
The application filters candidates through an exact identifier test so ordinary Windows network noise does not automatically become a GDID incident. When an event is too short-lived for every enrichment step, the record says what was captured and what could not be recovered in time.
Participants who opt in receive private installation access to review and download everything the research system retains for their installation. They can delete individual incidents, choose categories of retained data to remove, stop future reporting, or permanently purge the installation, its data, and its credentials.
Submitted evidence may contain sensitive information if that information was part of the GDID-bearing activity. Authorized researchers can inspect the complete submitted record; public findings are redacted or aggregated to avoid exposing a participant's unique data.
GDID Usage Discovery is not currently offered as an unrestricted public download. Prospective testers should read the participation disclosures and submit a request. Approved participants receive the appropriate research build and setup guidance directly from Source Potato.
Our Windows watcher shows a computer owner when an exact local GDID or related PUID representation appears in meaningful system or network activity. It preserves the strongest evidence first, then adds as much application and operating-system context as the short life of the event allows.
The watcher inventories relevant local identifier representations, then looks for those exact values in selected Windows diagnostic activity. Broad contextual events may help with attribution, but they do not become incidents unless they pass the final identifier test.
Current limitation: a registry ETW event may identify a path and value name without including the value's data. The current exact-value test can therefore miss a read of ExtendedProperties\LID even though the path is meaningful. We are adding narrowly scoped, operation-aware path detection for the independently validated IdentityCRL surfaces rather than returning to broad substring matching.
When a match occurs, the triggering event is saved immediately. The collector then gathers best-effort process lineage, executable path and command line, package identity, user and session context, signatures, modules, handles, sockets, destination evidence, and nearby activity.
The application turns dense request fields into a labeled human-readable view. Server ingestion may remove or summarize unresolved handles, environment values, embedded manifests, and duplicated enrichment that do not improve the finding. A researcher or participant can examine both the interpretation and every retained source record rather than trusting only a simplified summary.
Running the watcher does not require submitting incidents to Source Potato. Local collection and research participation are separate choices. The project is in closed initial testing before public release. Reporting is explicitly opt in, requires acceptance of the displayed disclosure, and begins with new incidents from that point forward; previously collected local history is not silently uploaded.
A participant can continue using the application locally without contributing anything to the shared research database. Turning reporting off stops future submissions but does not prevent local observation.
The participant system is designed around reciprocal transparency: researchers should not be able to study a person's submitted record while hiding that same retained record from the person who supplied it.
When reporting is enabled and consent is accepted, the service creates a unique participant credential for that installation. The application can open or copy a private access link, allowing the participant to view and download all retained incidents associated with that installation.
That credential grants access only to the participant's own installation data. It does not expose another participant's incidents, identity, notes, or research record.
A participant can delete an individual incident or select categories such as incidents and evidence, messages, researcher-added profile information, operational heartbeat history, consent history, and research-access history. A separate full-purge control permanently removes the installation record, retained data, and access credentials. “Delete” means removal from the active research system, not merely hiding an entry.
The access credential is controlled separately. A person may erase all incident data while retaining the credential for later review or participation, or explicitly request deletion of the credential as well.
Turn reporting off at any time. Future incidents remain local and are not added to the research pool.
Review, download, selectively remove, or erase all data associated with the participant credential.
A person who opted out may opt back in later. If a deleted credential is rejected, the client removes it and returns reporting to an off state until the person chooses to enroll again.
The purpose of this project is to learn what accompanies GDID use, including fields and event shapes we did not anticipate. Therefore, authorized Source Potato researchers can inspect all data retained from a participating installation—not only the friendly summary shown in an incident list.
A submitted event may contain public or private IP addresses, machine and account identifiers, usernames, URLs, request parameters, hardware details, process command lines, file paths, handles, package information, tokens, content fragments, or other confidential material present in the captured event and its immediate attribution context.
We do not want passwords, financial information, health information, addresses, private communications, legal material, or other privileged or highly personal content. But if a GDID-bearing operation contains or exposes such material, preserving the complete evidence is part of determining what the observed software collected or transmitted. Reporting should be enabled only with that understanding.
Opting in does not authorize indiscriminate collection of unrelated documents, browsing history, keystrokes, clipboard contents, passwords, or arbitrary files. The collector is aimed at exact identifier events and the evidence needed to understand them.
However, no static list can promise what an unknown future event will contain. If sensitive material is embedded in the triggering event, request, process context, or related evidence we capture, it may be submitted and visible to authorized researchers until the participant deletes it.
We will make every reasonable effort to minimize unnecessary collection, restrict researcher access, protect credentials, secure data in transit and at rest, log administrative access, isolate participant records, honor deletion requests, and remove personal values from public reports. Public findings will use redacted, aggregated, or otherwise de-identified evidence unless a participant has knowingly agreed to a different use.
We cannot promise zero risk. No internet-connected service, database, software system, administrator, or security control is infallible. Vulnerabilities, mistakes, credential theft, insider abuse, legal demands, service failures, and data breaches can happen. Participation is optional precisely because contributing complete evidence carries a real privacy risk. We will be candid about that risk, respond seriously to incidents, and never describe “best effort” security as a guarantee.
Our current collector prioritizes exact local GDID/PUID representations, preserves the triggering event first, then gathers process lineage, command line, executable identity, package context, sockets, handles, modules, signatures, and nearby activity on a best-effort basis. It explicitly excludes its own reads and reporting traffic so the observer does not become its own evidence.
As new event shapes appear, we will preserve more evidence first and narrow the routine capture only after the pattern is understood. Public findings will continue to distinguish directly captured facts, time/process correlation, external attribution, and unanswered questions.
Our initial evidence comes from a limited number of systems. We are looking for informed volunteers with Windows 10 or Windows 11 computers across different countries, account types, technical environments, and everyday workloads. A broader test group can help identify which behaviors are common, which are unusual, and what data accompanies a GDID-bearing event.
GDID Usage Discovery can operate as a local-only observer. Contributing captured incidents is a separate opt-in choice, and participants who contribute can inspect, download, selectively delete, or erase their submitted data.
The application page explains the administrator requirement, the possibility of sensitive evidence, researcher access, participant controls, and the information we need to evaluate a test environment before providing the current research build.