deGDID cancella l'identificativo nascosto di Windows? Abbiamo analizzato come funziona davvero

Una VPN può “sostituire” l’indirizzo IP pubblico visibile su Internet, ma non può impedire a Windows di comunicare ai server Microsoft un identificativo già inserito nelle richieste generate dal sistema operativo. È proprio questo il problema sollevato dal Global Device Identifier, o GDID, l’identificativo persistente emerso con particolare evidenza nel 2026 dopo la pubblicazione di alcuni atti giudiziari relativi al caso Peter Stokes.

Avevamo già ricostruito come Windows genera e utilizza il GDID: dietro la rappresentazione g:... comparsa nei registri forniti agli investigatori si trova un Device PUID (Portable Unique Identifier) assegnato dall’infrastruttura Microsoft, memorizzato localmente in più aree del sistema operativo e sufficientemente stabile da permettere di riconoscere la stessa installazione di Windows anche quando cambiano rete e indirizzo IP.

Windscribe, che non ha caso è un fornitore di servizi VPN, ha deciso di affrontare il problema con deGDID, progetto open source pubblicato su GitHub che si presenta sotto forma di script PowerShell (degdid.ps1) presentato come in grado di rimuovere le copie locali note dell’identificativo e, soprattutto, di impedire a Windows di ottenerne nuovamente uno. Gli sviluppatori descrivono l’approccio come una combinazione tra “continuity breaker” e “mint blocker“: interrompere l’uso dell’identità già presente e bloccare il percorso attraverso il quale Microsoft può assegnarne una nuova.

Abbiamo esaminato in profondità lo script degdid.ps1: la versione analizzata supera le 4.700 righe PowerShell e chiarisce subito una cosa importante: non siamo davanti alla classica modifica di una chiave del registro. deGDID interviene su una parte consistente dell’infrastruttura di identità di Windows! Tutto bene? Così e così.

Immagine tratta da “Windows Tracks You With a Hidden ID. So We Built deGDID to Block It” (Windscribe)

Prima di cancellare il GDID bisogna capire dove si trova

Il Device PUID associato al GDID può comparire nel registro di sistema all’interno della chiave HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties, sotto forma del valore LID. Lo script considera “reale” un PUID quando il valore rispetta il formato 0018XXXXXXXXXXXX ovvero 16 cifre esadecimali con prefisso 0018.

La funzione PowerShell usata per riconoscerlo è estremamente semplice: la si trova nello script con il nome Test-RealPuid. deGDID sa inoltre trasformare il valore esadecimale nella rappresentazione GDID utilizzata nei registri Microsoft. Il principio coincide con quello che avevamo descritto analizzando gli atti dell’indagine statunitense.

Il primo test consiste perciò nell’aprire una finestra PowerShell con diritti amministrativi e utilizzare:

.\degdid.ps1 -Status

L’operazione è di sola lettura: non cambia configurazioni, non cancella chiavi e non modifica il firewall. Attenzione però all’output: gli stessi sviluppatori avvertono che -Status può mostrare nome dell’account locale, percorso del profilo, PUID completo e corrispondente GDID g:...: non è quindi un risultato da copiare “alla leggera” su forum o social network.

Cancellare soltanto il valore LID non rompe necessariamente la continuità dell’identità: per questo motivo, lo script di Windscribe cerca informazioni univoche negli store IdentityCRL, nei token, nei device ticket, nel Credential Manager, nel TokenBroker e nella Connected Devices Platform.

L’esperimento più interessante: un PC con account locale può ottenere comunque un GDID

Una delle conclusioni più rilevanti dei test Windscribe riguarda l’uso di un account locale: l’idea secondo cui un PC privo di account Microsoft sia automaticamente immune da questo identificatore non regge.

Gli sviluppatori affermano di avere preparato una macchina virtuale Windows con un account locale che non aveva ancora ottenuto un GDID. Mantenendo bloccato il percorso di registrazione Microsoft, le aree analizzate restavano prive di un Device PUID. Una volta eliminato il blocco, un valore reale con prefisso 0018 compariva poco dopo, senza la necessità di trasformare l’account Windows locale in un account Microsoft.

Nella documentazione, gli autori riferiscono della comparsa del primo PUID lato macchina circa 2 minuti dopo avere nuovamente consentito la comunicazione con l’infrastruttura Microsoft.

Il vero bersaglio è la procedura di login Microsoft

Nel codice dello script troviamo una variabile particolarmente eloquente: $script:MintHost = 'login.live.com'

deGDID considera infatti login.live.com il nodo critico del percorso che conduce all’assegnazione del Device PUID, con il servizio wlidsvc (Microsoft Account Sign-in Assistant), coinvolto nella gestione dell’identità. Microsoft non documenta pubblicamente ogni passaggio del ciclo GDID, quindi la ricostruzione deriva dall’osservazione del comportamento di Windows più che da una specifica ufficiale completa.

La modalità che Windscribe consiglia per una macchina sulla quale GDID esiste già è la seguente:

.\degdid.ps1 -Protect

Qui, però, lo script deGDID tende a diventare molto più invasivo.

Cosa succede davvero con -Protect

Avviando lo script con l’opzione -Protect, la rimozione del GDID non avviene subito. Prima di tutto, il codice PowerShell crea una sorta di “barriera” a livello di rete.

Il primo muro eretto da Windscribe per evitare la ricezione del GDID consiste nell’aggiunta nel file HOSTS di Windows (%SystemRoot%\System32\drivers\etc\hosts) una nuova sezione delimitata da:

# BEGIN degdid-registration-block
...
# END degdid-registration-block

Tra i domini bloccati troviamo:

login.live.com
account.live.com
cs.dds.microsoft.com
dds.microsoft.com
aad.cs.dds.microsoft.com
fd.dds.microsoft.com
cdpcs.access.microsoft.com
ztd.dds.microsoft.com
activity.windows.com
assets.activity.windows.com
edge.activity.windows.com

Per ciascun nome di dominio, lo script usa la sintassi seguente, così da bloccare qualsiasi connessione tramite protocollo IPv4 e IPv6:

0.0.0.0 dominio
:: dominio

Il blocco tramite Windows Firewall

Il file HOSTS non rappresenta l’unico livello di protezione: quando la configurazione locale lo consente, deGDID usa la funzione Dynamic Keyword Addresses di Windows Firewall per associare regole direttamente agli FQDN.

Microsoft supporta ufficialmente questo meccanismo: PowerShell può creare una keyword dinamica associata a un nome DNS e utilizzarla in una regola in uscita; Windows aggiorna poi gli indirizzi IP corrispondenti durante la risoluzione.

Lo script crea un oggetto dinamico per ciascuno dei domini gestiti e quindi una regola così strutturata:

Direction = Outbound
Action = Block
Profile = Any
Protocol = Any

Lo script aggiunge poi una seconda regola legata direttamente al servizio wlidsvc. Così, anche se Microsoft cambiasse indirizzo IP o utilizzasse un endpoint differente raggiunto da wlidsvc, quella specifica istanza del servizio non dovrebbe comunque riuscire a comunicare verso l’esterno.

L’operazione di rimozione non cancella soltanto il GDID

Una volta verificato che il percorso di registrazione verso Microsoft sia effettivamente bloccato, deGDID passa alla pulizia vera e propria.

Come accennato in precedenza, lo script non elimina soltanto il valore LID ma interviene sulla configurazione di molte altre aree legate all’identità dell’utente.

Alcune operazioni sono piuttosto incisive: la cache di TokenBroker e quella di Connected Devices Platform vengono ripulite, mentre dal Credential Manager sono eliminate credenziali specifiche legate all’identità Microsoft e al dispositivo. Ciò può tradursi in nuove richieste di autenticazione, perdita temporanea del Single Sign-On (SSO) o anomalie in funzioni come Microsoft Store, OneDrive e Collegamento al telefono.

Conclusa l’attività di rimozione, lo script ripristina quando possibile lo stato originario dei servizi, attende alcuni secondi e ripete l’inventario.

Gli autori dello script affermano di aver mantenuto una macchina virtuale Windows 11 25H2 build 26200 attiva per oltre 33 ore utilizzando un account locale, oltre ad avere effettuato test con un account Microsoft connesso comprendenti logout/login, sospensione, riattivazione e riavvio. In nessun caso il GDID è ricomparso.

Ancora più significativo è il comportamento dopo aver impartito il comando .\degdid.ps1 -Unblock, capace di rimuovere le modifiche di rete impostate in precedenza per il blocco di GDID. Una volta ripristinata l’impostazione precedente (deGDID non ricrea le identità, i token e le cache precedentemente cancellati) o la generazione di un nuovo GDID avviene immediatamente dopo il riavvio, in alcuni casi dopo appena una manciata di secondi.

Il prezzo della rimozione del GDID: login e autenticazioni Microsoft non funzionano più

L’avevamo detto nel nostro articolo su come disattivare GDID in Windows 11: bisogna andarci cauti.

Dopo le restrizioni imposte dallo script di Windscribe, qualunque software che utilizzi la normale risoluzione dei nomi di Windows e provi a contattare login.live.com è indirizzato verso un indirizzo inesistente. Lo stesso vale per account.live.com e per gli altri endpoint della lista citata in precedenza. È quindi del tutto prevedibile che alcune procedure di autenticazione Microsoft smettano di funzionare.

Windscribe elenca esplicitamente tra le funzioni che possono rompersi o degradarsi:

Microsoft Account, Microsoft Store, Xbox, OneDrive, Phone Link, sincronizzazione dei dispositivi, passkey e alcune configurazioni Windows Hello legate all’account Microsoft.

Lo script NON blocca direttamente i servizi di Windows Update e non aggiunge i relativi endpoint alla lista. Sia gli aggiornamenti del sistema operativo che Microsoft Defender continueranno a funzionare dopo il “trattamento”. Anche se, gli autori lo evidenziano, lo script è fornito “così com’è” e non sono esclusi comportamenti anomali finora non emersi durante le prove sin qui svolte.

Lo script si rifiuta di lavorare sui PC aziendali

deGDID si rifiuta di applicare le modifiche che alterano lo stato del sistema allorquando il computer in uso risultasse:

• membro di un dominio Active Directory;
• Entra joined;
• registrato come workplace/Entra;
• gestito tramite MDM;
• caratterizzato da più profili utente umani contemporaneamente caricati.

La ragione è che rimuovere DeviceIdentity, token e credenziali su un PC gestito con Entra ID o Intune potrebbe interferire con le registrazioni aziendali, le procedure di autenticazione, l’accesso condizionale e i criteri di gestione.

Vale la pena usare deGDID? Il tema privacy sullo sfondo

Dal punto di vista tecnico, lo script è molto più convincente di quanto si possa immaginare. È infatti molto ben realizzato, ben lontano da un “debloater” assemblato alla buona.

Il problema è un altro: per raggiungere l’obiettivo prefisso, ossia la completa rimozione dell’identificativo persistente GDID, deve interferire deliberatamente con una parte sostanziale dei servizi di identità Microsoft. Purtroppo non esiste, almeno oggi, un interruttore documentato (del tipo DisableGDID = 1) che consenta di mantenere tutta l’integrazione Microsoft limitandosi a rifiutare il Global Device Identifier.

deGDID è costretto a fare qualcosa di molto più radicale: cancellare lo stato locale noto e costruire una barriera attorno al processo che registra nuovamente il dispositivo sui server Microsoft.

Chi utilizza soltanto applicazioni desktop tradizionali e un account locale potrebbe accorgersi relativamente poco della modifica. Chi invece dipende da Microsoft Store, Xbox, OneDrive, Collegamento al tuo telefono, sincronizzazione dell’account e altre funzioni cloud può incontrare problemi ben più evidenti.

Come avevamo osservato nella guida su GDID, spetterebbe a questo punto alle Autorità per la protezione dei dati personali, a partire dal Garante Privacy e dagli organismi europei competenti, valutare la compatibilità di un identificativo persistente di questo tipo con i principi del GDPR: in particolare trasparenza, limitazione delle finalità, minimizzazione dei dati e possibilità per l’utente di esercitare un controllo effettivo sul trattamento.

Nel caso in cui emergessero profili di non conformità alla normativa sulla protezione dei dati personali, le Autorità competenti potrebbero imporre a Microsoft misure correttive, fino alla modifica delle modalità di generazione e utilizzo del GDID, all’introduzione di maggiori garanzie di trasparenza e controllo per l’utente o, nei casi più rilevanti, alla limitazione del trattamento associato a questo identificativo.