Niente telefono, niente account: il muro QR di Google e il GDPR
Google ora blocca la creazione di un nuovo account dietro una verifica QR basata sul telefono. Niente smartphone, niente account. Ecco perché questo si scontra con la minimizzazione dei dati del GDPR.

Prova a creare un account Google oggi e potresti trovarti davanti a un muro prima ancora di digitare un solo carattere del tuo nome. La schermata dice "Verify some info before creating an account", mostra un QR code e ti chiede di scansionarlo con la fotocamera del telefono. Non c'è alcun link da cliccare, nessun ripiego via email, nessun percorso "salta". Niente smartphone con una fotocamera funzionante significa niente account. È tutta qui l'interazione, e vale la pena fermarsi a guardarla, perché trasforma silenziosamente il telefono in una precondizione per usare il web.
Vivo nei Paesi Bassi, all'interno dell'UE, e l'impostazione di quella schermata ("Google needs to verify some info about your device or phone number") si legge meno come una funzione di sicurezza e più come una raccolta obbligatoria di identità travestita da anti-abuso. Questo articolo parla del perché questa distinzione conta e di dove si scontra con il GDPR.
Cosa pretende davvero quella schermata
Leggi il messaggio alla lettera. Per creare un account ti viene chiesto di:
- Possedere uno smartphone con una fotocamera in grado di scansionare un QR code.
- Passare il flusso a quel telefono, abbandonare il dispositivo da cui hai iniziato e completare passaggi che Google non ti mostra in anticipo.
- Legare il nuovo account a un numero di telefono, che in gran parte dell'UE è a sua volta collegato a un'identità governativa verificata a livello di SIM.
- Più avanti nello stesso percorso, fornire una data di nascita e altri dati personali.
Niente di tutto questo è un requisito tecnico per il funzionamento di un account email. Una casella di posta non ha bisogno di conoscere il tuo compleanno, il modello del tuo telefono o il tuo operatore. Sono decisioni di raccolta dati, non vincoli ingegneristici, e meritano di essere giudicate come decisioni di raccolta dati.
L'"anti-abuso" sta facendo un gran lavoro qui
La giustificazione è la prevenzione dei bot: "preventing abuse from computer programs or bots." È un problema reale, e limitare il ritmo di creazione degli account è legittimo. Ma osserva la forma del controllo. Non ti chiede di risolvere un problema che un umano può risolvere e uno script no. Ti chiede di presentare un telefono. La cosa che viene verificata non è "sei umano", è "puoi fornire un dispositivo e un numero che possiamo profilare e correlare."
Sono obiettivi diversi. Il primo è proporzionato alla lotta agli abusi. Il secondo è collegamento di identità, e una volta che un numero di telefono è agganciato alla registrazione, raramente resta confinato allo scopo per cui è stato raccolto. I numeri aggiunti "per sicurezza" hanno una lunga storia di scivolamento verso il targeting pubblicitario, i grafi sociali per il recupero dell'account e la correlazione tra servizi. I team di sicurezza chiamano questo function creep. Il GDPR lo chiama un problema di limitazione delle finalità.
Dove si scontra con il GDPR
Non sto sostenendo che un tribunale abbia dichiarato illecito questo specifico flusso. Sto indicando i principi che un'autorità per la protezione dei dati peserebbe davvero, perché collimano male con "scansiona questo o vattene."
Minimizzazione dei dati, Articolo 5(1)(c)
I dati personali devono essere "adeguati, pertinenti e limitati a quanto necessario" rispetto alla finalità. La finalità qui è creare un account email. Un numero di telefono e una data di nascita non sono necessari per far funzionare una casella di posta, il che significa che l'onere ricade sul titolare del trattamento, che deve dimostrare perché vengono raccolti, e non sull'utente, che dovrebbe giustificare il proprio rifiuto.
Consenso liberamente prestato, Articoli 4(11) e 7(4)
Il consenso è valido solo se è liberamente prestato, e il regolamento dice esplicitamente che bisogna valutare se un servizio sia reso condizionato al consenso a un trattamento non necessario per quel servizio. "Niente numero di telefono, niente account" è la definizione da manuale di condizionato. Quando l'unica alternativa al condividere i dati è essere esclusi del tutto dal servizio, la "scelta" sta facendo ben poco.
Proporzionalità e necessità
Anche su una base di legittimo interesse anziché di consenso, il trattamento deve superare un test di necessità e bilanciamento. Costringere ogni potenziale utente a passare attraverso un hardware che potrebbe non possedere, per sconfiggere bot che rappresentano una frazione delle registrazioni, è difficile da definire l'opzione meno invasiva quando CAPTCHA, conferma via email e segnali comportamentali esistono già e non richiedono una fotocamera.
L'esclusione che nessuno progetta
Sotto al problema di privacy ce n'è uno più silenzioso. Un controllo basato su QR e fotocamera presuppone un utente specifico: qualcuno che possiede uno smartphone recente, può vedere e scansionare fisicamente un codice, ed è a suo agio nello spostare un flusso di creazione account su un telefono. Quel presupposto esclude le persone che usano solo un desktop, le persone con disabilità visive, le persone con feature phone, le persone che mantengono deliberatamente una dotazione minima di dispositivi, e chiunque semplicemente non voglia un telefono personale collegato a ogni login.
"Usa e basta un telefono" non è un'impostazione predefinita neutra. È una decisione di progettazione che scarica il costo del problema di abusi di Google sugli utenti, inclusi gli utenti per cui uno smartphone non è scontato. Accessibilità e protezione dei dati puntano qui nella stessa direzione: un servizio così centrale dovrebbe avere un percorso che non richieda di possedere un hardware particolare.
Cosa potrebbe davvero fare l'UE al riguardo
Il meccanismo del GDPR per contestare tutto questo esiste già. Non serve una nuova legge, serve far applicare i principi sopra:
- Trattare il numero di telefono e la data di nascita alla registrazione come non necessari per impostazione predefinita, e imporre al titolare del trattamento di provare la necessità anziché affermarla.
- Imporre un percorso alternativo reale alla creazione dell'account che non richieda uno smartphone o un numero, sulla logica di condizionalità dell'Articolo 7(4).
- Esaminare la finalità: se un numero raccolto per l'anti-abuso viene poi usato per la pubblicità o la correlazione, si tratta di una violazione della limitazione delle finalità, indipendentemente da come fosse formulata la schermata di registrazione.
Una posizione coordinata dell'EDPB, o un singolo Garante determinato, è sufficiente a forzare una riprogettazione. Abbiamo visto esattamente questo schema con i cookie wall, dove le autorità hanno alla fine stabilito che "consenso o vattene" non è un consenso reale. Un muro hardware è lo stesso argomento con una fotocamera attaccata.
Cosa puoi fare oggi
Nulla di quanto sopra ti aiuta nei cinque minuti in cui hai davvero bisogno di un account, quindi in pratica:
- Usa un provider che non pretende un telefono per gli account che controlli. Diversi provider di posta con sede nell'UE trattano un numero come opzionale anziché obbligatorio.
- Tieni separate identità e comodità. Se devi proprio agganciare un numero da qualche parte, non riutilizzare quello che àncora la tua identità bancaria e governativa.
- Esercita i tuoi diritti. Una Subject Access Request e, dove appropriato, un reclamo al tuo Garante nazionale non sono simbolici. Sono il meccanismo che trasforma i principi sopra in pressione.
In sintesi
Un muro QR e telefono alla creazione dell'account viene venduto come sicurezza, ma i dati che effettivamente protegge sono i tuoi, consegnati come prezzo d'ingresso. Nell'UE quel prezzo ha una cornice giuridica: i dati devono essere minimizzati, il consenso deve essere libero, e un servizio non può silenziosamente rendersi condizionato alla cessione di informazioni di cui non ha bisogno per funzionare. "Scansiona questo o non puoi avere un account" fallisce tutti e tre i criteri a prima vista. Che un'autorità lo dica ad alta voce è, a questo punto, una questione di volontà più che di legge.
Leggi anche questo
- AWS Multi-party Approval for Organizations, per capire come appaiono i controlli di identità e approvazione quando sono progettati per limitare il potere anziché raccoglierlo.
- Why Your SSH Is Yelling About Quantum Computers, su come prendere alla lettera gli avvisi di sicurezza rispetto al leggere cosa proteggono davvero.
Ti stai chiedendo come gli assistenti AI gestiscono i dati di identità e consenso che vengono loro affidati? Le note sul campo su ercan.ai trattano proprio questo. Per consulenza su cloud, sicurezza e lavoro di piattaforma orientato alla compliance, parti da ercanermis.com.
Altro da Ercan
Altri due siti, stesso autore, terreno diverso.
IA, LLMs, agenti, ML applicato.
Note sul campo su workload IA. Analisi dei costi Bedrock, pattern di agenti, trade-off di storage vettoriale, failure mode in produzione.
Visita ercan.ai →L'hub. Chi sono, consulenza, contatti.
Hub personale per entrambe le tracce di scrittura. Chi sono, come funziona la consulenza, come contattarmi.
Visita ercanermis.com →