Come disattivare GDID, identificatore persistente che crea Windows 11 e Windows 10

Windows 11 e Windows 10 associano a ogni installazione del sistema operativo un identificatore persistente (GDID, Global Device Identifier), utile per riconoscere lo stesso PC anche quando cambia indirizzo IP o si collega alla rete attraverso proxy e VPN. Il caso giudiziario che ha portato alla luce il GDID ha chiarito un punto spesso sottovalutato: proteggere il traffico di rete non impedisce necessariamente al sistema operativo di comunicare informazioni capaci di distinguere il dispositivo e rilevarlo in modo univoco.

Nel precedente articolo dedicato al GDID di Windows e ai limiti delle VPN ci siamo concentrati soprattutto sulla natura dell’identificatore e sui componenti di Windows che possono utilizzarlo. Rimaneva però aperta la domanda più concreta: è possibile bloccare GDID, impedirne la creazione oppure almeno ridurre i flussi con cui Windows lo registra e lo trasmette ai servizi Microsoft?

Il punto da chiarire è che il GDID non nasce soltanto quando Windows usa un account Microsoft: le prove disponibili indicano che può comparire anche con un account locale, dopo il primo collegamento ai servizi Microsoft. ([IT-Connect -][1])

Cos’è GDID e come Windows ottiene l’identificatore

GDID è un identificatore persistente che Microsoft associa alla specifica installazione di Windows, eseguita su un computer fisico oppure all’interno di una macchina virtuale. Non coincide con l’indirizzo IP, con il MAC address o con il numero di serie della scheda madre: serve a distinguere il dispositivo nei servizi Microsoft e rimane normalmente invariato durante gli aggiornamenti del sistema operativo. Una reinstallazione completa di Windows, invece, determina l’assegnazione di un nuovo valore.

L’identificatore non sembra derivare da un semplice calcolo eseguito in locale a partire dalla configurazione 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 lato server, riconducibile alla famiglia dei Device PUID.

Windows salva il valore nel profilo dell’utente, in particolare nella chiave HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties, all’interno della voce LID. Nel registro compare in formato esadecimale; convertito in decimale e preceduto dal prefisso g:, assume la forma utilizzata per il GDID nei log Microsoft.

L’accesso a Windows con un account Microsoft non rappresenta però una condizione necessaria. Su una nuova installazione mantenuta offline e configurata con un account locale, il valore LID risulta assente.

Collegando il PC a Internet, Windows raggiunge comunque i servizi Microsoft e può ottenere l’identificatore nel giro di pochi secondi, senza che l’utente effettui l’accesso con un account online. L’account Microsoft facilita naturalmente l’associazione tra dispositivo e identità personale, ma la sola scelta di un account locale non impedisce la creazione del GDID: per bloccarne l’assegnazione iniziale occorre interrompere le comunicazioni con gli endpoint coinvolti prima del primo accesso alla rete.

Da dove arriva GDID

GDID non nasce con Windows 11: Microsoft utilizzava già identificatori persistenti collegati alla telemetria e alla registrazione dei dispositivi in Windows 10.

Windows 11 ha proseguito e probabilmente ampliato questa architettura, ma Microsoft non ha pubblicato una cronologia tecnica precisa che consenta di stabilire la build esatta in cui il GDID, con questo specifico nome e formato, è comparso per la prima volta.

Il nome GDID è emerso pubblicamente soprattutto grazie agli atti dell’indagine su Scattered Spider richiamata nell’introduzione.

Scattered Spider è un gruppo cybercriminale internazionale, noto soprattutto per gli attacchi sferrati contro grandi aziende. I suoi membri fanno largo uso di social engineering, phishing e telefonate ai servizi di assistenza per convincere gli operatori a reimpostare password o sistemi di autenticazione multifattore.

Fino a quel momento, Microsoft non aveva descritto in modo chiaro e accessibile l’identificatore GDID nella documentazione destinata agli utenti o agli amministratori di sistema. La vicenda giudiziaria ha quindi portato alla luce non tanto la nascita di un nuovo meccanismo, quanto l’uso investigativo di un identificatore già presente nell’infrastruttura di telemetria e registrazione dei dispositivi Windows.

Come controllare se Windows sta usando il GDID

Anziché accedere manualmente al registro di sistema, è possibile premere Windows+X quindi scegliere Terminale o Windows PowerShell (senza diritti amministrativi). Il comando seguente, incollato nella finestra del terminale, permette di estrarre il GDID personale:

$lid = (Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties' -ErrorAction Stop).LID
"g:$([Convert]::ToUInt64($lid,16))"

Se la chiave o il valore non esistono, PowerShell restituisce un errore. L’assenza del dato di solito indica che il profilo utente corrente non ha ancora completato la registrazione, che la macchina si trova offline o che un filtro di rete ha impedito il contatto con i server Microsoft. Inoltre, trattandosi di una chiave sotto il ramo HKCU (HKEY_CURRENT_USER), la verifica riguarda l’utente con il quale si esegue il comando.

Per ottenere un controllo meno fragile si può usare:

$p = 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties'
if (Test-Path $p) { $v = Get-ItemProperty $p -Name LID -ErrorAction SilentlyContinue; if ($v.LID) { "GDID: g:$([Convert]::ToUInt64($v.LID,16))" } else { 'LID non presente' } } else { 'Chiave IdentityCRL non presente' }

Perché cancellare il valore nel registro non rappresenta una soluzione

La rimozione del valore LID dal registro di sistema di Windows elimina soltanto la copia locale disponibile nel momento dell’intervento.

L’identificatore risulta già associato al dispositivo sui server Microsoft e Windows può richiederlo nuovamente alla prima occasione utile. Dopo il riavvio, la riconnessione o l’avvio di uno dei componenti interessati, la voce può quindi ricomparire nel registro.

Tale comportamento è osservabile, ad esempio, esportando la chiave, eliminando il valore e monitorando il registro con Process Monitor. L’aggiunta di un filtro sul percorso contenente IdentityCRL\ExtendedProperties permette di individuare il processo che lo riscrive: ovviamente l’esperimento ha mero valore diagnostico.

Assegnare autorizzazioni restrittive alla chiave del registro rappresenta un’altra soluzione apparente. Windows potrebbe non riuscire a salvare nuovamente il dato in quel punto, ma ciò non cancella l’associazione lato server e può causare anomalie nei componenti di autenticazione.

Due livelli di blocco del GDID con conseguenze molto diverse

La misura più radicale consiste nel bloccare login.live.com prima che una nuova installazione di Windows acceda a Internet. Il dominio partecipa alla registrazione presso i servizi di identità Microsoft e, nei test pubblicati, la sua mancata risoluzione impedisce la comparsa del GDID.

Il prezzo da pagare è elevato: login.live.com non serve soltanto al GDID poiché gestisce l’autenticazione degli account Microsoft e interviene nell’accesso a OneDrive, Microsoft Store, Microsoft 365, Xbox e applicazioni che usano l’identità Microsoft. Un blocco permanente può produrre finestre di login vuote, errori di autenticazione, installazioni dallo Store non riuscite e richieste ripetute di credenziali.

La seconda strada lascia attivo il servizio di identità e tenta invece di interrompere la registrazione del dispositivo e alcuni canali di comunicazione successivi.

I domini sui quali intervenire comprendono dds.microsoft.com, cdpcs.access.microsoft.com, activity.windows.com e la famiglia do.dsp.mp.microsoft.com. In questo scenario il GDID può continuare a esistere localmente e lato server; l’obiettivo più realistico consiste nel ridurre i servizi che lo usano e le occasioni nelle quali Windows lo trasmette.

Non si può quindi parlare di anonimizzazione garantita. Microsoft gestisce più servizi, endpoint e identificatori; inoltre gli indirizzi e i flussi possono cambiare con gli aggiornamenti. Il blocco va interpretato come una misura di contenimento verificabile, non come la certezza che nessun componente comunichi mai un identificatore del dispositivo.

Bloccare gli endpoint con AdGuard Home, Pi-hole o Technitium

Un resolver DNS sotto il controllo dell’utente offre il metodo più pratico per filtrare intere famiglie di nomi. AdGuard Home, Pi-hole e Technitium DNS Server possono applicare regole a tutti i PC della rete e registrare ogni richiesta, caratteristica essenziale per capire quali servizi Windows tenti di raggiungere.

Con la sintassi di AdGuard Home, un blocco completo può includere:

||login.live.com^$dnsrewrite=0.0.0.0
||dds.microsoft.com^$dnsrewrite=0.0.0.0
||cdpcs.access.microsoft.com^$dnsrewrite=0.0.0.0
||do.dsp.mp.microsoft.com^$dnsrewrite=0.0.0.0
||activity.windows.com^$dnsrewrite=0.0.0.0

Chi vuole conservare l’accesso all’account Microsoft deve escludere la prima regola e limitarsi agli endpoint collegati alla registrazione dei dispositivi, alle attività condivise e a Delivery Optimization. La regola relativa a do.dsp.mp.microsoft.com copre anche nomi regionali come geo.prod.do.dsp.mp.microsoft.com e altri sottodomini generati dall’infrastruttura.

Dopo aver applicato le regole conviene svuotare la cache DNS con il comando ipconfig /flushdns, riavviare il computer e consultare il registro delle query del resolver.

Il comando Resolve-DnsName login.live.com consente inoltre di verificare la risposta ricevuta dal PC, mentre Get-DnsClientServerAddress mostra quali server DNS risultano configurati sulle interfacce di rete.

Un punto importante riguarda l’uso del protocollo DNS over HTTPS (DoH): se Windows, il browser, un agente VPN o un programma di sicurezza usa un resolver cifrato esterno, le richieste possono aggirare il server DNS locale. In una rete amministrata è opportuno impedire DNS diretti verso Internet, consentire la porta 53 soltanto verso il resolver interno e controllare le configurazioni DoH distribuite ai client.

Perché il file hosts è utile solo per prove limitate

Il file HOSTS di Windows, posto nel percorso C:\Windows\System32\drivers\etc\hosts, può deviare la risoluzione di singoli nomi di dominio verso 0.0.0.0 o 127.0.0.1. Per esempio:

0.0.0.0 login.live.com
0.0.0.0 dds.microsoft.com
0.0.0.0 cdpcs.access.microsoft.com
0.0.0.0 activity.windows.com

Il limite principale è l’assenza dei caratteri jolly. Una riga riferita a do.dsp.mp.microsoft.com non intercetta automaticamente geo.prod.do.dsp.mp.microsoft.com, kv601.prod.do.dsp.mp.microsoft.com o altri sottodomini. Bisogna conoscere e aggiungere ogni nome in modo esplicito.

Il file HOSTS, inoltre, non offre inoltre un registro centralizzato, si modifica facilmente con privilegi amministrativi e non governa necessariamente applicazioni dotate di un proprio resolver. Il blocco delle comunicazioni relative al GDID tramite file HOSTS va quindi bene per una verifica rapida; su più sistemi, un filtro DNS centrale risulta più affidabile e più semplice da gestire.

Disattivare Connected Devices Platform

La piattaforma Connected Devices comprende il servizio di sistema CDPSvc e servizi per utente con nomi simili a CDPUserSvc_3f2ab. Il suffisso varia tra installazioni e sessioni perché Windows crea istanze specifiche per utente.

Per esaminare la situazione corrente si possono eseguire, da una finestra PowerShell aperta con i diritti di amministratore:

Get-Service CDPSvc,DoSvc -ErrorAction SilentlyContinue
Get-Service | Where-Object Name -Like 'CDPUserSvc*' | Select-Object Name,Status,StartType

La disattivazione di CDPSvc si effettua con:

Stop-Service CDPSvc -Force -ErrorAction SilentlyContinue
Set-Service CDPSvc -StartupType Disabled

Per il modello del servizio per utente si può impostare il valore Start a 4 nella chiave seguente:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\CDPUserSvc" /v Start /t REG_DWORD /d 4 /f

Il riavvio resta necessario perché le istanze già create possono rimanere attive fino alla chiusura della sessione. Modificare soltanto CDPUserSvc_xxxxx rischia invece di agire su un’istanza temporanea e non sul modello dal quale Windows genera quelle successive.

La conseguenza non riguarda però soltanto l’identificatore GDID. Possono infatti smettere di funzionare o comportarsi in modo irregolare applicazioni di sistema come Collegamento al telefono, le esperienze tra dispositivi, la condivisione nelle vicinanze, alcune funzioni del selettore dispositivi e la sincronizzazione delle attività. Microsoft classifica CDPUserSvc tra i servizi per utente e ne documenta il coinvolgimento nelle esperienze di connessione e individuazione dei dispositivi.

La configurazione più equilibrata per un normale PC

Su un sistema che usa Microsoft Store, OneDrive o Microsoft 365, bloccare login.live.com risulta difficilmente sostenibile.

Una configurazione meno “invasiva” mantiene attivo il servizio di identità, filtra gli endpoint DDS e CDP, valuta la disattivazione delle esperienze tra dispositivi mediante Connected Devices Platform.

Chi desidera impedire fin dall’inizio l’assegnazione del GDID deve invece preparare una nuova installazione offline, usare un account locale e applicare il filtro su login.live.com prima del primo accesso alla rete. Dovrà poi rinunciare, almeno su quella macchina, alle principali funzioni che dipendono dall’account Microsoft.

In ogni caso, va tenuto presente che non esiste un “interruttore generale” e ufficiale per il GDID predisposto da Microsoft.

GDID e privacy: Microsoft dovrebbe offrire maggiore trasparenza?

L’assenza di un comando ufficiale per disattivare il GDID apre una questione che va oltre la configurazione tecnica di Windows. Il GDPR considera dati personali anche gli identificatori online quando permettono di distinguere una persona direttamente o indirettamente; un codice persistente associato a un dispositivo può quindi rientrare in tale definizione se Microsoft riesce a collegarlo a un account, agli indirizzi IP utilizzati, alle attività dei servizi o ad altre informazioni riconducibili all’utente.

La pseudonimizzazione non cambia la natura del dato: sostituire il nome con un identificatore numerico riduce l’immediatezza dell’identificazione, ma non rende anonime le informazioni finché il titolare conserva i mezzi per ricostruire il collegamento.

Microsoft dichiara nelle proprie informative di raccogliere dati sul dispositivo, sulla configurazione, sulla connettività e vari “device identifiers“; non risulta però disponibile, nella documentazione pubblica destinata agli utenti comuni, una spiegazione altrettanto esplicita del GDID, delle circostanze nelle quali nasce, dei componenti che lo trasmettono, della sua durata e delle modalità con cui chiederne la cancellazione o opporsi a determinati utilizzi.

Il GDPR non impone necessariamente un pulsante di disattivazione

Il GDPR non impone necessariamente un pulsante denominato “Disattiva GDID“, ma obbliga il titolare del trattamento a rispettare i principi di liceità, correttezza, trasparenza, minimizzazione e limitazione delle finalità. L’informativa dovrebbe consentire all’utente di capire quali categorie di dati sono raccolte, perché servono, su quale base giuridica avviene il trattamento, per quanto tempo restano conservate e quali soggetti possono riceverle. Una formula generica come “identificatori del dispositivo” potrebbe non risultare sufficiente qualora il GDID consentisse di correlare stabilmente una stessa installazione di Windows a connessioni, indirizzi IP (definiti “dato personale“) e attività differenti. La valutazione dipenderebbe comunque dagli usi effettivi del codice e dalle informazioni che Microsoft conserva insieme ad esso: un identificatore impiegato soltanto per distribuire aggiornamenti presenta implicazioni diverse rispetto a uno utilizzato anche per sicurezza, analisi comportamentale, prevenzione delle frodi o correlazione tra servizi.

Consenso, legittimo interesse e diritto di opposizione

Anche la possibilità di disattivazione dipende dalla base giuridica. Se un impiego del GDID si fondasse sul consenso, Microsoft dovrebbe permetterne la revoca con la stessa facilità con cui lo ha raccolto. Se si basasse sul legittimo interesse, l’utente potrebbe esercitare il diritto di opposizione previsto dall’articolo 21 del GDPR; il trattamento potrebbe proseguire soltanto in presenza di motivi legittimi cogenti prevalenti o per esigenze giudiziarie.

Gli utilizzi necessari devono restare distinti da quelli facoltativi

Per gli utilizzi realmente necessari alla sicurezza, all’erogazione di un servizio richiesto o all’adempimento di obblighi legali, invece, la società potrebbe non essere tenuta a offrire una disattivazione completa lasciando inalterate tutte le funzioni. Rimane però necessario separare gli scopi indispensabili da quelli facoltativi: non sarebbe coerente con il principio di protezione dei dati per impostazione predefinita costringere l’utente a rinunciare all’autenticazione Microsoft, allo Store o agli aggiornamenti soltanto per impedire impieghi ulteriori dell’identificatore.

Perché il GDID potrebbe interessare il Garante Privacy

Proprio tali aspetti potrebbero giustificare un approfondimento da parte del Garante per la protezione dei dati personali o dell’Autorità europea competente. Un’istruttoria potrebbe chiarire se il GDID costituisca un dato personale nei trattamenti concretamente svolti, quali informazioni vi siano associate, quanto a lungo rimanga conservato lato server e se l’utente possa esercitare in modo effettivo i diritti di accesso, cancellazione, limitazione e opposizione.

Il fatto che, allo stato attuale, il blocco richieda filtri DNS, modifiche ai servizi di Windows o la rinuncia a funzionalità importanti non dimostra automaticamente una violazione del GDPR. Mostra però l’assenza di un controllo semplice e granulare, oltre a una documentazione pubblica che non sembra descrivere il GDID con la precisione che un identificatore persistente meriterebbe.

Maggiori informazioni tecniche su GDID sono reperibili nel repository GitHub no-gdid.