Il GDID, ovvero il Global Device Identifier, è quell’identificatore persistente che Windows 11 e Windows 10 associano a ogni installazione del sistema operativo. Serve a riconoscere lo stesso computer anche quando cambia indirizzo IP oppure quando ci si collega attraverso proxy e VPN. La cosa interessante, emersa da una vicenda giudiziaria, è che proteggere il traffico di rete non basta a impedire al sistema di comunicare dati capaci di distinguere il dispositivo in modo univoco.
L’aspetto che sorprende molti è che il GDID non nasce soltanto quando si usa un account Microsoft. Le prove disponibili raccontano una storia diversa: l’identificatore può comparire anche con un semplice account locale, dopo il primo collegamento ai servizi Microsoft. In pratica, la scelta di restare offline durante l’installazione fa la differenza, ma appena il PC tocca la rete la situazione cambia.
Da un punto di vista tecnico, il valore non deriva da un calcolo fatto in locale sulla base dell’hardware. Durante le prime comunicazioni con l’infrastruttura Microsoft, i servizi di identità di Windows contattano endpoint come login.live.com e ricevono un identificatore numerico assegnato dal server, riconducibile alla famiglia dei Device PUID. Questo valore finisce salvato nel profilo utente, dentro la chiave HKEYCURRENTUSERSOFTWAREMicrosoftIdentityCRLExtendedProperties, nella voce LID. Nel registro appare in formato esadecimale e, convertito in decimale con il prefisso g:, diventa proprio il GDID che compare nei log.
Vale la pena ricordare che il GDID non è una novità di Windows 11. Microsoft utilizzava già identificatori persistenti legati alla telemetria e alla registrazione dei dispositivi ai tempi di Windows 10. Il nome è emerso pubblicamente soprattutto grazie agli atti di un’indagine su Scattered Spider, un gruppo cybercriminale internazionale noto per attacchi a grandi aziende basati su social engineering, phishing e telefonate ai servizi di assistenza per farsi resettare password o sistemi di autenticazione multifattore.
Come controllarlo e perché cancellarlo non serve
Per vedere se Windows sta usando il GDID basta premere Windows+X, aprire Terminale o Windows PowerShell senza diritti amministrativi e incollare un comando che legge la chiave IdentityCRL e restituisce il valore in formato g:. Se la chiave o il valore non esistono, PowerShell segnala un errore. L’assenza del dato di solito significa che il profilo non ha ancora completato la registrazione, che la macchina è offline oppure che un filtro di rete ha bloccato il contatto con i server Microsoft. Trattandosi di una chiave sotto HKCU, la verifica riguarda soltanto l’utente con cui si lancia il comando.
Cancellare il valore LID dal registro sembra la soluzione più ovvia, ma non funziona. Elimina solo la copia locale presente in quel momento. L’identificatore resta associato al dispositivo sui server Microsoft e Windows può richiederlo di nuovo alla prima occasione. Dopo un riavvio o una riconnessione la voce ricompare. Lo stesso vale per chi prova a mettere autorizzazioni restrittive sulla chiave: l’associazione lato server rimane e in più si rischiano anomalie nei componenti di autenticazione.
Ci sono due livelli di blocco con conseguenze molto diverse. Il più radicale consiste nel bloccare login.live.com prima che una nuova installazione tocchi Internet. Nei test pubblicati, senza la risoluzione di quel dominio il GDID non compare. Il prezzo però è alto: login.live.com gestisce l’autenticazione degli account Microsoft e interviene su OneDrive, Microsoft Store, Microsoft 365, Xbox e tutte le app che usano l’identità Microsoft. Un blocco permanente porta a finestre di login vuote, errori di autenticazione e richieste continue di credenziali.
La seconda strada lascia attivo il servizio di identità e prova a interrompere solo la registrazione del dispositivo. I domini su cui intervenire sono dds.microsoft.com, cdpcs.access.microsoft.com, activity.windows.com e la famiglia do.dsp.mp.microsoft.com. Qui il GDID può continuare a esistere, ma si riducono i servizi che lo usano.
Bloccare gli endpoint con un resolver DNS
Uno strumento come AdGuard Home, Pi-hole o Technitium DNS Server è il modo più pratico per filtrare intere famiglie di nomi. Applicano regole a tutti i PC della rete e registrano ogni richiesta, dettaglio prezioso per capire cosa Windows tenti di raggiungere. Con la sintassi di AdGuard Home si possono bloccare login.live.com, dds.microsoft.com, cdpcs.access.microsoft.com, do.dsp.mp.microsoft.com e activity.windows.com reindirizzandoli a 0.0.0.0. Chi vuole tenere l’account Microsoft attivo deve escludere la prima regola e concentrarsi sugli endpoint di registrazione, attività condivise e Delivery Optimization. La regola su do.dsp.mp.microsoft.com copre anche i nomi regionali e i sottodomini generati dall’infrastruttura.
Dopo aver applicato le regole conviene svuotare la cache con ipconfig /flushdns, riavviare il computer e controllare il registro delle query del resolver. Il comando Resolve-DnsName login.live.com verifica la risposta ricevuta dal PC, mentre Get-DnsClientServerAddress mostra quali server DNS sono configurati sulle interfacce di rete. Va detto chiaramente che non si parla di anonimizzazione garantita. Microsoft gestisce molti servizi, endpoint e identificatori, e indirizzi e flussi possono cambiare con gli aggiornamenti. Il blocco resta una misura di contenimento verificabile, non la certezza che nessun componente comunichi mai un identificatore del dispositivo.


