La verifica europea dell'età è open source: nove mesi di silenzio su GitHub

L'Unione Europea pubblica la specifica tecnica della verifica dell'età online su un archivio pubblico. I problemi di privacy emersi ad aprile 2026 erano stati documentati per iscritto, con nome e firma, nell'estate del 2025. Le risposte pubbliche, su quell'archivio, non sono mai arrivate.

Dove si scrivono le regole della verifica dell'età europea

C'è un luogo dove le decisioni di design sulla verifica europea dell'età vengono prese o non prese. È un archivio pubblico ospitato su GitHub, la piattaforma su cui sviluppatori e istituzioni pubblicano e discutono apertamente i loro progetti. Chiunque può leggere il documento, segnalare problemi, proporre modifiche. Tutte le interazioni restano pubbliche e datate.

Il documento si chiama specifica tecnica: è il manuale ufficiale che fissa nei dettagli come dovrà funzionare un'app europea di verifica dell'età. Non è una legge in senso classico, ma vincola le 27 app nazionali che ne deriveranno. Serve ad attuare l'articolo 28 del DSA, che obbliga le piattaforme online a misure di protezione dei minori ed è pensata come soluzione-ponte fino all'avvio del portafoglio digitale europeo (EUDI Wallet, l'identità digitale che sostituirà SPID e CIE) previsto per fine 2026.

Conviene tenere separati tre piani che il dibattito pubblico tende a fondere. Il documento normativo decide cosa un'app conforme può e non può fare. Le 27 implementazioni nazionali sono le app che ogni Stato membro produrrà a partire da quel documento. L'app di riferimento pubblicata dalla Commissione è una semplice dimostrazione, vive in un archivio separato e non è la stessa cosa della specifica. Questo articolo guarda solo al primo piano: il documento normativo. Le scelte fatte lì sono quelle che si propagano a valle.

Ho passato del tempo sul documento normativo per studiarlo ed ho trovato due interventi tecnici aperti da mesi, supportati dalla comunità, mai discussi pubblicamente dal gruppo di lavoro della Commissione.

La proposta numero 23: la dipendenza da Google Play Integrity

Il 1 agosto 2025 un utente con il soprannome lietu apre la proposta di modifica numero 23 (in inglese pull request, abbreviata PR), titolo italiano: Ripristiniamo privacy e libertà. Una proposta di modifica, su GitHub, è una proposta concreta di intervento sul testo: chi gestisce il progetto può accettarla, rifiutarla o lasciarla in sospeso. Tra le proposte di lietu, due sono il cuore del problema: rimuovere la dipendenza da Google Play Integrity ed eliminare la possibilità, per chi emette la prova di età, di sapere a quale sito l'utente la sta presentando.

Google Play Integrity è un servizio di Google che attesta se un dispositivo Android è "autentico": sistema operativo originale, non manomesso. Se il dispositivo non passa il controllo, l'app non funziona. La critica non è che la scelta sia irrazionale: oggi le alternative anti-manomissione su Android sono limitate e il rischio di dispositivi modificati per imbrogliare il sistema è reale. Il problema è l'altro: una specifica che non vieta esplicitamente la dipendenza la rende lo standard di fatto e il default delle 27 app nazionali sarà il servizio più diffuso. Una soluzione di identità europea che dipende da Google diventa un'infrastruttura europea che transita dai server americani dell'azienda di Mountain View ogni volta che un cittadino dimostra di essere maggiorenne. È lock-in infrastrutturale, mascherato da scelta tecnica.

Il secondo problema è il tracciamento incrociato tra siti. Se chi emette la prova di età sa anche quale sito la sta richiedendo, può ricostruire le abitudini di navigazione di chi la usa su ogni piattaforma che richiede la verifica.

La proposta raccoglie 89 pollici in su, 3 cuori, un solo voto contrario: sono le reazioni che chiunque, leggendo, può lasciare per dire se condivide o no la modifica. Riceve anche un'approvazione tecnica e diciassette commenti di revisione. Il tono dell'autore è polemico: chiude dichiarando che non accettare la proposta equivale a essere willingly complicit in the destruction of the privacy of EU citizens («consapevolmente complici nella distruzione della privacy dei cittadini europei»). Il tono è un problema tattico, perché offre al gruppo di lavoro una scusa procedurale per ignorare la sostanza. Ma nei commenti di revisione la sostanza c'è.

Maevii, che approva la proposta il 2 agosto 2025, scrive: «come Unione Europea non dobbiamo e non possiamo affidarci completamente ad aziende o governi stranieri per sistemi così critici» (we as the EU must not and cannot rely completely on foreign companies and/or governments for systems as critical as this). E aggiunge l'argomento decisivo: il problema va risolto alla radice, nella specifica, non delegato a valle.

A nove mesi dall'apertura, la proposta è ancora ferma: nessuno l'ha accolta, modificata o respinta nel merito.

La segnalazione numero 26: i tre divieti che René Mayrhofer ha chiesto invano

Un mese dopo la proposta di lietu, il 1 settembre 2025, René Mayrhofer apre la segnalazione numero 26 (in inglese issue, una segnalazione di problema senza una proposta di soluzione già scritta). Mayrhofer è professore e direttore dell'Institute of Networks and Security all'università Johannes Kepler di Linz ed è anche responsabile della sicurezza della piattaforma Android in Google. Chi conosce il dossier non dovrebbe ignorarlo.

La sua proposta è precisa. Tre modifiche al testo della specifica:

• Vietare attributi che rompano l'unlinkability. La specifica elenca gli attributi ammessi in una prova di età, ma non dichiara che l'elenco è chiuso. Un fornitore può aggiungere campi propri che diventano vettori di tracciamento. L'unlinkability è il principio per cui due usi diversi della stessa prova non devono poter essere collegati allo stesso utente.
• Vietare la conservazione del legame tra utente e prova dopo che la prova è stata emessa.
• Vietare al sito che richiede la verifica di conservare la prova oltre la sessione.

Mayrhofer lo dice esplicitamente: queste tre proposte sono pezze procedurali. Il fix strutturale sarebbe rendere obbligatoria una prova a conoscenza zero (ZKP), una crittografia che permette di dimostrare un fatto senza rivelare nient'altro: provare di avere più di 18 anni senza mostrare data di nascita, nome o documento. La differenza con un divieto contrattuale è netta: «non conservo i tuoi dati» si applica solo se qualcuno lo fa rispettare. Una prova a conoscenza zero rende l'informazione sensibile crittograficamente non trasmessa: non c'è bisogno di fidarsi, perché il dato non è mai stato condiviso.

Va detto che imporre ZKP oggi non è gratis. Le costruzioni più mature hanno ancora costi di calcolo e di interoperabilità non banali, l'esperienza d'uso su larga scala è un cantiere aperto e rendere obbligatoria una crittografia avanzata in una specifica con scadenze politiche stringenti è una scelta forte. Mayrhofer lo sa e propone i tre divieti minori proprio come compromesso pragmatico.

A otto mesi dall'apertura, la segnalazione ha tre commenti, tutti da contributori esterni: uno cita l'articolo 7 della Carta dei diritti fondamentali dell'Unione Europea, un altro aggiunge sostanza tecnica. Nessun commento dal gruppo di lavoro. Nessun responsabile assegnato, nessuna etichetta, nessuna data di rilascio prevista.

L'app bucata ad aprile e cosa dimostra davvero

Il 15 aprile 2026 Ursula von der Leyen annuncia l'app: «la nostra app rispetta tutti i requisiti. I più alti standard di privacy al mondo» (Our app ticks all the boxes. Highest privacy standards in the world). Il giorno dopo, il consulente di sicurezza britannico Paul Moore dimostra in meno di due minuti come aggirare l'app di riferimento: modificando un file di configurazione interno all'app. Il crittografo francese Olivier Blazy conferma. Thomas Regnier, portavoce della Commissione, risponde che «quando diciamo versione finale, è ancora una versione dimostrativa» (when we say it's a final version, it's still a demo version); il 17 aprile la Commissione pubblica una correzione.

Precisione: l'app "bucata" è la dimostrativa, non la specifica. I difetti del file di configurazione modificabile sono problemi dell'app di riferimento, non del documento normativo. Trattarli come la stessa cosa indebolisce l'argomento.

Ma il filo c'è ed è questo: una specifica che non impone vincoli forti consegna alle implementazioni la responsabilità di non sbagliare e le implementazioni hanno sbagliato al primo colpo. Lo standard di fatto vince. Se la specifica non vieta Google Play Integrity, le 27 app nazionali useranno Google Play Integrity. Se non impone una prova a conoscenza zero, nessuna delle 27 app la implementerà. Se non vieta la conservazione, qualcuna conserverà.

Il 2 marzo 2026, prima dell'aggiramento, una lettera aperta firmata da 438 ricercatori di sicurezza e privacy da 32 Paesi aveva già chiesto alla Commissione una moratoria fino a un consenso scientifico sui benefici e i rischi di queste tecnologie.

Il gruppo di lavoro potrebbe lavorare in silenzio. L'archivio pubblico no.

L'obiezione ovvia la conosco: il processo normativo europeo ha canali interni, tavoli tecnici, tempi che non coincidono con quelli di una proposta su GitHub. Il gruppo di lavoro potrebbe aver letto tutto, valutato tutto e star preparando una risposta strutturata altrove. Non lo escludo.

Però se l'archivio è presentato come luogo di partecipazione pubblica, il feedback pubblico va processato pubblicamente. Un «grazie, stiamo valutando internamente» richiede trenta secondi. Otto o nove mesi senza nemmeno quello e senza un piano pubblico su questi specifici problemi nelle altre sedi consultabili (l'Age Verification Manual, comunicati ufficiali, mailing list di settore), trasformano l'archivio da canale di partecipazione in registro di reclami archiviati. Chi ha competenza tecnica per contribuire lo capisce al primo colpo d'occhio.

Privacy promessa contro privacy garantita: il prezzo della specifica

Proteggere i minori online è un obiettivo legittimo. L'articolo 28 del DSA risponde a un problema reale. Costruire una soluzione-ponte mentre il portafoglio digitale europeo non è pronto è pragmatismo ragionevole.

Ma il pragmatismo ha un prezzo quando le scorciatoie diventano architettura. Senza obblighi crittografici forti, la privacy dei cittadini europei dipende da promesse contrattuali. E le promesse contrattuali fanno acqua nei due scenari operativi che contano. Il primo: uno Stato membro autoritario che usi i registri delle verifiche per mappare chi accede a stampa di opposizione, forum LGBTQ+, servizi di salute riproduttiva. Il secondo: un broker pubblicitario che incroci l'orario di una verifica con la sessione pubblicitaria sul sito di destinazione e ricostruisca il profilo. Nessuno dei due richiede una violazione: bastano i registri che la specifica non vieta di tenere.

La violazione dell'app si corregge con una correzione mirata. Il precedente normativo no. Un documento europeo scritto su un archivio pubblico, in cui le proposte tecniche di privacy, firmate e documentate, restano senza risposta sostanziale per mesi mentre il calendario politico avanza, fissa un metodo. L'archivio è pubblico. Le proposte sono firmate. Il silenzio deliberato, su una piattaforma in cui ogni azione è registrata con data e ora, è il dato più visibile del dossier.

Fonti

• Archivio della specifica age verification europea
• Proposta numero 23 — Restoring privacy and freedom (lietu, 1 agosto 2025)
• Segnalazione numero 26 — Proposed security/privacy improvements in spec (René Mayrhofer, 1 settembre 2025)
• Articolo 28 del Digital Services Act (regolamento UE 2022/2065)
• Comunicato Ursula von der Leyen e Henna Virkkunen (15 aprile 2026)
• Lettera aperta dei ricercatori sull'age assurance (438 firmatari, 2 marzo 2026)
• Proton, EU age verification app hacked in 2 minutes (aprile 2026)
• The Age Verification Manual, Commissione Europea