La verifica dell’età UE affronta le critiche di Hacker News sulla fiducia nell’hardware

Il progetto UE per la verifica dell’età ha attirato l’attenzione di Hacker News dopo che la sua specifica ha inserito l’hardware crittografico nativo nel percorso di conformità. Il requisito protegge le credenziali d’età dall’estrazione o dalla duplicazione. Solleva però anche una questione più difficile: chi controlla l’accesso quando un wallet open source dipende da app approvate, hardware affidabile e sistemi operativi riconosciuti?

La controversia è più specifica delle affermazioni secondo cui l’Unione Europea avrebbe vietato Linux o imposto ovunque Google Play Integrity. Nessuna delle due conclusioni deriva direttamente dalla specifica pubblicata. Gli utenti desktop possono completare un flusso tra dispositivi con un wallet mobile, mentre gli implementatori nazionali mantengono la facoltà di scegliere ulteriori controlli di integrità.

Tuttavia, la preoccupazione non è immaginaria. L’architettura attuale è incentrata sui dispositivi mobili e i fornitori di credenziali devono rifiutare le app esterne a un elenco di conformità gestito dalla Commissione. Questa combinazione fa sì che la disponibilità del codice sorgente sia solo una parte dell’apertura pratica.

Il risultato è un autentico compromesso di politica pubblica. Il vincolo hardware può impedire che credenziali copiate e client modificati indeboliscano un controllo dell’età. Lo stesso modello di fiducia può escludere build della comunità, sistemi Android alternativi, dispositivi meno recenti e persone prive di smartphone compatibili.

Cosa richiede realmente la specifica UE per la verifica dell’età

La regola vincolante riguarda l’hardware crittografico, ma l’accesso in produzione dipende anche dall’approvazione dell’app e dalla politica del fornitore di credenziali.

La Commissione europea ha pubblicato la prima versione del suo progetto white-label per la verifica dell’età il 14 luglio 2025. È stato concepito come base riutilizzabile che gli Stati membri potevano adattare in applicazioni nazionali.

Il progetto supporta l’Articolo 28 del Digital Services Act, che richiede alle piattaforme interessate di proteggere i minori attraverso misure appropriate e proporzionate. La Commissione presenta il sistema come un ponte temporaneo verso gli European Digital Identity Wallets previsti entro la fine del 2026.

Il suo flusso di base separa la prova dell’età dalla divulgazione dell’identità. Un fornitore autorizzato verifica l’età di una persona e rilascia un’attestazione digitale. Un sito web richiede successivamente una condizione legata all’età, ad esempio se il visitatore abbia più di 18 anni.

Il sito web che fa affidamento sulla prova riceve il risultato relativo all’età richiesto, anziché un dossier completo sull’identità. Questo approccio mira a evitare l’invio ripetuto a singoli servizi di passaporti, dettagli di pagamento, immagini del volto o date di nascita.

In base alla specifica tecnica pubblicata, un’app di verifica dell’età “DEVE” usare hardware crittografico nativo quando questa capacità è disponibile. Gli esempi includono Secure Enclave di Apple e Trusted Execution Environment o StrongBox di Android.

Questi componenti isolano le operazioni crittografiche dal sistema operativo principale. Una chiave privata associata a una credenziale può rimanere inaccessibile anche quando il normale spazio di archiviazione dell’applicazione viene copiato o ispezionato.

Il requisito non afferma esplicitamente che ogni implementazione debba usare Google Play Integrity o Apple App Attest. L’archiviazione delle chiavi supportata dall’hardware e l’attestazione remota della piattaforma sono controlli correlati, ma rispondono a domande diverse.

L’archiviazione sicura chiede se una chiave sia protetta dal dispositivo. L’attestazione remota può chiedere se un server riconosca l’app, il sistema operativo, lo stato di avvio, l’hardware o il canale di distribuzione.

Questa distinzione è diventata centrale dopo che un report originale ha descritto le implicazioni per Linux e i sistemi mobili alternativi. Il report ha osservato che servizi più rigorosi non erano imposti universalmente dall’implementazione di riferimento.

La specifica stabilisce comunque altri controlli obbligatori. Ogni prova dell’età è monouso e viene rimossa dal lotto emesso dopo la presentazione. I fornitori di attestazioni devono verificare l’età a un livello di garanzia “sostanziale” o “elevato” prima di rilasciare le credenziali.

I fornitori devono inoltre rifiutare di rilasciare attestazioni ad app esterne all’elenco della Commissione delle applicazioni conformi. Un fornitore di app deve notificare la Commissione prima di pubblicare un wallet conforme e la Commissione gestisce il relativo elenco.

Questo livello di governance conta quanto la clausola sull’hardware. Chiunque potrebbe essere in grado di ispezionare o fare fork del codice, ma un fork non può necessariamente ottenere credenziali autentiche dagli emittenti in produzione.

Il progetto rimane un’implementazione di riferimento, non un servizio universale già completo. Il suo repository Android afferma che la demo è in sviluppo attivo e richiede ulteriore lavoro prima della distribuzione in produzione.

Gli Stati membri o altri implementatori devono gestire il rafforzamento dell’app, la configurazione degli emittenti, l’archiviazione sicura, la gestione delle chiavi, la sicurezza dell’iscrizione, la localizzazione e la conformità legale. Le loro scelte determineranno se i sistemi finali useranno un vincolo hardware di base o valutazioni del dispositivo molto più rigide.

Perché Hacker News si è concentrato sull’open source senza accesso aperto

Il dibattito su Hacker News riguarda in ultima analisi se il codice verificabile sia sufficiente quando le istituzioni controllano ancora le credenziali e l’elenco di fiducia.

Il progetto pubblica il codice sorgente sotto European Union Public Licence. Gli sviluppatori possono ispezionare le app di riferimento, compilarle localmente, segnalare problemi e proporre modifiche.

Ciò offre una trasparenza significativa. Consente ai ricercatori di esaminare flussi di iscrizione, archiviazione delle credenziali, protocolli di presentazione e dipendenze prima che le implementazioni nazionali raggiungano milioni di utenti.

Tuttavia, una licenza open source non obbliga un emittente a fidarsi di ogni binario modificato. Ciò entrerebbe in conflitto con l’obiettivo di sicurezza del sistema, perché un client alterato potrebbe rimuovere i controlli di autenticazione o automatizzare la presentazione delle credenziali.

La Commissione necessita quindi di un modo per distinguere le applicazioni accettate da software arbitrario. La sua specifica lo fa tramite l’elenco delle app conformi e le regole imposte ai fornitori di attestazioni.

Questo produce due diverse definizioni di apertura.

La prima è l’apertura del codice. Uno sviluppatore può studiare, compilare e modificare l’applicazione senza ottenere l’autorizzazione di un fornitore proprietario.

La seconda è l’apertura operativa. Un’applicazione modificata può partecipare alla rete reale delle credenziali senza l’approvazione di un’autorità centrale o di un gatekeeper della piattaforma.

Il progetto UE supporta chiaramente la prima definizione. Il suo supporto alla seconda è limitato per progettazione, perché agli emittenti viene richiesto di riconoscere solo le applicazioni elencate.

I partecipanti alla discussione collegata hanno evidenziato questo divario. Alcuni hanno considerato i requisiti hardware una difesa necessaria contro la copia delle credenziali. Altri hanno visto nell’architettura una strada verso l’esclusione del software controllato dagli utenti.

Entrambe le argomentazioni individuano proprietà reali del progetto. Un emittente non può considerare affidabile ogni client, ma un processo di approvazione può diventare una barriera se le sue regole sono opache o difficili da soddisfare per gli sviluppatori indipendenti.

L’architettura separa inoltre l’accesso desktop dall’esecuzione del wallet. La sua documentazione descrive flussi di presentazione sullo stesso dispositivo e tra dispositivi.

In un flusso sullo stesso dispositivo, il wallet e il sito web operano su un unico dispositivo. In un flusso tra dispositivi, un sito web su desktop mostra una richiesta che un wallet mobile nelle vicinanze completa, comunemente tramite un codice QR.

Ciò significa che Linux non è espressamente vietato. Un utente Linux può visitare un sito web con restrizioni e presentare la prova tramite un telefono supportato.

Tuttavia, questo non equivale al supporto nativo di un wallet su Linux. Le attuali implementazioni di riferimento si concentrano su Android e iOS, mentre la specifica definisce l’app mobile white-label come canale di distribuzione principale.

Chi possiede un laptop Linux ma non uno smartphone compatibile si trova comunque di fronte a un problema di accesso. Lo stesso vale per un utente il cui telefono non disponga dell’hardware sicuro richiesto o non riesca a soddisfare la politica di integrità di un’implementazione nazionale.

L’applicazione di riferimento Android richiede il livello API 29, che corrisponde ad Android 10. Questa soglia esclude già i dispositivi più vecchi prima che intervenga qualsiasi ulteriore rafforzamento per la produzione.

L’accessibilità coinvolge inoltre più dei soli sistemi operativi. L’iscrizione può basarsi sull’identificazione elettronica nazionale, su documenti d’identità supportati, fornitori affidabili o altre fonti specifiche per paese.

Le persone prive di documenti supportati possono incontrare una barriera prima ancora che la fiducia nell’hardware diventi rilevante. Rifugiati, migranti, visitatori e residenti i cui dati non si collegano in modo chiaro a un emittente necessitano di alternative praticabili.

Questi problemi non dimostrano che il sistema sia concepito come un meccanismo di sorveglianza. Mostrano però perché “open source” non possa risolvere da solo il dibattito sull’accesso.

Un repository aperto rende possibile la revisione. Non garantisce una partecipazione equa tra dispositivi, sistemi operativi, stato della documentazione o implementazioni nazionali.

Il vincolo hardware protegge le credenziali ma sposta il controllo

Il compromesso centrale consiste in una maggiore resistenza al furto delle credenziali in cambio di una più ampia dipendenza dai fornitori hardware, dai distributori di app e dalle decisioni istituzionali sulla fiducia.

Una prova dell’età riutilizzabile acquisisce valore quando i siti web la accettano. Gli aggressori hanno quindi incentivi a copiare credenziali, generare attestazioni false, automatizzare le presentazioni o modificare un wallet per aggirare l’autenticazione locale.

Le chiavi supportate dall’hardware riducono questi rischi. Il wallet può richiedere firme senza esporre la chiave privata alla normale memoria o allo spazio di archiviazione dell’applicazione.

Questo protegge dall’estrazione più diretta. Copiare i file del wallet su un altro dispositivo non dovrebbe copiare l’autorità crittografica necessaria per presentare la credenziale.

La specifica aggiunge attestazioni monouso per limitare la riproduzione e il tracciamento tra servizi. I fornitori rilasciano le credenziali in lotti e il wallet rimuove ogni attestazione dopo averla presentata.

Un periodo massimo di validità raccomandato di tre mesi limita per quanto tempo un lotto emesso rimane utile. Il documento evita la revoca obbligatoria perché un servizio di revoca aggiungerebbe complessità e potrebbe aumentare la collegabilità.

Queste scelte illustrano l’ingegneria della privacy del progetto. Un servizio centrale non deve approvare ogni visita a un sito web, mentre le parti che fanno affidamento sulla prova ricevono un attributo d’età strettamente circoscritto.

Anche l’European Data Protection Board ha pubblicato dieci principi di privacy per la verifica dell’età. Essi enfatizzano necessità, proporzionalità, minimizzazione dei dati, equità, accuratezza, sicurezza e alternative efficaci.

La protezione hardware supporta la sicurezza, ma non soddisfa automaticamente gli altri principi. Un sistema tecnicamente sicuro può comunque escludere utenti o rivelare più informazioni di quante ne richieda un particolare servizio.

La controversia cresce quando gli implementatori aggiungono servizi di integrità remota. Google descrive Play Integrity come un modo per valutare se le richieste provengano da un’app riconosciuta in esecuzione su un ambiente Android autentico e certificato.

I suoi livelli di integrità possono includere segnali supportati dall’hardware, stato del bootloader, certificazione del sistema operativo, aggiornamenti di sicurezza recenti, riconoscimento dell’app e origine dell’installazione.

Queste capacità aiutano a rilevare client manomessi e dispositivi sottoposti a root. Possono anche rifiutare sistemi operativi alternativi che offrono una forte sicurezza ma non sono accettati dal modello di certificazione di Google.

Google stessa raccomanda un'applicazione a livelli, perché un numero minore di dispositivi soddisfa il verdetto più rigoroso. Questo consiglio riconosce il problema della copertura: la risposta di sicurezza più severa non è disponibile per tutti gli utenti legittimi.

App Attest di Apple segue un modello simile, verificato dal server. Crea una chiave basata sull'hardware e consente ad Apple di certificare che la chiave appartiene a un'istanza valida dell'applicazione.

Anche le linee guida di attestazione di Apple invitano gli sviluppatori a verificare la disponibilità e a gestire correttamente i dispositivi non supportati. Non presumono che ogni dispositivo o tipo di applicazione possa fornire il servizio.

La specifica UE non riconduce attualmente tutta la protezione hardware a questi due servizi commerciali. Indica ambienti crittografici nativi e lascia ulteriori decisioni di rafforzamento agli implementatori.

Questa flessibilità è importante, ma rinvia anche la questione politica decisiva. Le implementazioni nazionali possono scegliere controlli con conseguenze diverse per app store alternativi, sistemi operativi aftermarket e wallet compilati in modo indipendente.

Un'implementazione limitata potrebbe associare le credenziali a una chiave sicura senza chiedere a un operatore di piattaforma di approvare l'intero ambiente software. Un'implementazione più rigorosa potrebbe richiedere una firma dell'app riconosciuta, bootloader bloccato, sistema operativo certificato e canale di distribuzione ufficiale.

Entrambe le implementazioni potrebbero definirsi supportate dall'hardware. I loro effetti sulla concorrenza e sulla libertà degli utenti sarebbero però nettamente diversi.

Gli sviluppatori dovrebbero quindi evitare di considerare l'“attestazione hardware” come un'unica tecnologia indivisibile. La politica di fiducia effettiva dipende dalle attestazioni richieste da un verificatore e dalle autorità che accetta.

Un dispositivo può dimostrare che una chiave risiede in hardware sicuro senza dimostrare che Google ha approvato il suo sistema operativo. Al contrario, Play Integrity può combinare prove hardware con le classificazioni di Google relative ad app e dispositivi.

La domanda significativa non è se sia coinvolto l'hardware. È chi definisce un dispositivo accettabile, quali prove siano richieste e se agli utenti respinti venga offerto un altro percorso sicuro.

La promessa di privacy presenta ancora debolezze pratiche

L'architettura può ridurre al minimo la divulgazione di dati ai siti web, ma non può dimostrare che la persona che possiede una credenziale per adulti sia quella che visualizza il contenuto.

Il progetto UE affronta uno dei principali fallimenti della tradizionale verifica dell'età. Un sito web con accesso limitato non deve raccogliere un documento d'identità né mantenere un database che colleghi le identità legali alle attività di navigazione.

Il progetto white-label della Commissione descrive un metodo rispettoso della privacy che gli Stati membri possono personalizzare. La credenziale è pensata per rivelare una condizione legata all'età anziché informazioni personali non pertinenti.

Questa separazione ha valore. Grandi raccolte di passaporti, selfie, date di nascita e dati di pagamento creano obiettivi appetibili per gli aggressori e aumentano le conseguenze di una violazione.

Tuttavia, la tutela della privacy non risolve il problema del prestito delle credenziali. Un minore può usare il telefono di un adulto, mentre un adulto può approvare una richiesta per qualcun altro.

La specifica riconosce che i dispositivi possono essere condivisi tra utenti. Richiede un'autenticazione locale affidabile, come un PIN, una password, una sequenza o un controllo biometrico, prima di presentare un'attestazione.

Questo verifica l'accesso al wallet. Non stabilisce chi stia guardando lo schermo di destinazione dopo l'accettazione della prova.

Controlli locali più forti possono rendere meno comoda la condivisione occasionale, ma il sistema non può associare continuamente il consumo di contenuti alla persona la cui età è stata verificata. Farlo richiederebbe un monitoraggio più invasivo.

Questo è il limite fondamentale di molti sistemi di verifica dell'età. Aumentare il livello di garanzia richiede spesso ulteriori prove di identità, controlli biometrici, analisi comportamentali o autenticazioni ripetute.

Ogni misura aggiuntiva può ridurre le possibilità di aggiramento. Ognuna può anche creare nuovi rischi di raccolta dati, esclusione, accessibilità e sicurezza.

L'associazione all'hardware protegge la credenziale dall'estrazione, ma non può impedire la consegna volontaria di un dispositivo sbloccato. L'attestazione dell'app può rilevare software modificato, ma non può determinare chi si trovi dietro lo schermo.

Anche il meccanismo a conoscenza zero del progetto merita un trattamento preciso. Il linguaggio normativo afferma che le applicazioni dovrebbero implementare il meccanismo di prova a conoscenza zero specificato, mentre le parti che fanno affidamento sul sistema dovrebbero implementarne la verifica.

Nei linguaggi normativi, “dovrebbe” è significativo ma meno vincolante di “deve”. Le implementazioni possono quindi differire nel modo in cui forniscono non collegabilità e divulgazione selettiva.

Una prova a conoscenza zero consente a una parte di dimostrare un fatto senza rivelare il segreto sottostante. In questo contesto, l'obiettivo è dimostrare una condizione relativa all'età senza divulgare l'identità o una data di nascita esatta.

Anche un sistema di prove ben progettato opera all'interno di una rete più ampia. Emittenti, app, elenchi affidabili, siti web, dispositivi e servizi di piattaforma producono comunque dati operativi.

La privacy dipende dalla possibilità che questi componenti correlino gli eventi di emissione e presentazione. Dipende anche dalle politiche di registrazione, dalla precisione dei timestamp, dagli identificatori di rete, dall'analisi dei dati e dalle scelte di implementazione nazionali.

La specifica tenta di ridurre il collegamento usando attestazioni monouso e limitando la precisione dei timestamp. Queste misure meritano riconoscimento, ma i test indipendenti devono confermare come si comportano le implementazioni complete.

L'attuale applicazione Android è esplicitamente una demo in fase di sviluppo attivo. Il suo repository avverte che le implementazioni in produzione richiedono archiviazione sicura, gestione delle chiavi, rafforzamento dell'app, convalida dell'iscrizione e attività di governance.

Un difetto in una build dimostrativa non invaliderebbe necessariamente il protocollo. Allo stesso modo, un protocollo solido non garantirebbe che ogni applicazione nazionale lo implementi in modo sicuro.

Questa distinzione dovrebbe guidare la copertura dei futuri rapporti di sicurezza. I ricercatori devono identificare se una debolezza riguarda la demo, una scelta di implementazione, il protocollo delle credenziali o l'intero modello di garanzia.

La reazione su Hacker News riflette la sfiducia verso sistemi che iniziano con uno scopo limitato e in seguito acquisiscono usi più ampi. L'attuale specifica si concentra sull'accesso ai servizi online e considera vari scenari del mondo fisico al di fuori del suo ambito prioritario.

Questo ambito può cambiare attraverso successive decisioni politiche. I componenti tecnici realizzati per la prova dell'età potrebbero in futuro supportare altri attributi nel più ampio quadro dell'Identità Digitale Europea.

Tale espansione non è stabilita dall'attuale documento sulla verifica dell'età. Tuttavia, la governance dovrebbe affrontare la limitazione delle finalità prima dell'implementazione, perché la compatibilità tecnica rende più semplice il riutilizzo successivo.

La promessa di privacy è quindi condizionata, non vuota. Il progetto può divulgare meno dati rispetto ai controlli diretti dei documenti, ma il suo successo dipende da implementazione, supervisione, alternative e resistenza all'espansione dell'ambito.

Cosa dovrebbero osservare sviluppatori e utenti

Le prove decisive arriveranno dalle politiche nazionali di fiducia, dai test di sicurezza indipendenti e dal trattamento dei dispositivi legittimi che non superano i controlli di integrità preferiti.

Il primo segnale è la politica di conformità per le applicazioni in produzione. L'elenco della Commissione dei wallet accettati determinerà se i fornitori indipendenti dispongano di un percorso realistico per entrare nell'ecosistema.

Gli sviluppatori hanno bisogno di criteri pubblicati, tempistiche di revisione, procedure di ricorso e regole per build riproducibili open source. Senza questi elementi, l'elenco può funzionare come una barriera opaca anche quando il codice sorgente resta pubblico.

Un processo credibile dovrebbe spiegare se le applicazioni mantenute dalla comunità possano qualificarsi. Dovrebbe inoltre identificare chi si assume la responsabilità degli aggiornamenti di sicurezza, della risposta agli incidenti e della revoca delle credenziali dopo l'accettazione di un wallet.

Il secondo segnale è il modo in cui gli Stati membri implementano la fiducia nel dispositivo. La sola archiviazione di chiavi supportata dall'hardware produce conseguenze di accesso diverse rispetto ai verdetti obbligatori di Play Integrity o App Attest.

Le applicazioni nazionali dovrebbero documentare quali segnali richiedono e come rispondono ai fallimenti. Un risultato di integrità vuoto non dovrebbe essere automaticamente trattato come prova di frode quando hardware non supportato o un sistema operativo alternativo possono produrre lo stesso esito.

Le soluzioni alternative contano. Una persona che non dispone di un telefono compatibile necessita di un altro modo proporzionato per dimostrare l'età, soprattutto quando l'accesso riguarda informazioni lecite anziché una funzionalità commerciale opzionale.

Queste alternative potrebbero includere credenziali multi-dispositivo provenienti da un altro wallet affidabile, iscrizione assistita, canali fisici supportati o hardware sicuro indipendente dalla piattaforma. Ogni opzione richiede una propria analisi delle minacce.

Il terzo segnale è la valutazione indipendente del sistema completo. I repository di riferimento menzionano aggiornamenti continui, rafforzamento per la produzione e test della comunità, ma la revisione pubblica del codice non sostituisce una valutazione strutturata.

I ricercatori dovrebbero testare l'estrazione delle credenziali, la resistenza ai replay, la clonazione del wallet, gli abusi degli emittenti, la collusione dei verificatori, gli scenari di dispositivi condivisi, la correlazione dei metadati, il diniego di servizio e i fallimenti di accessibilità.

Dovrebbero inoltre pubblicare se una scoperta riguarda il protocollo o una sua implementazione. Questa chiarezza evita che un bug applicativo correggibile venga presentato come un fallimento crittografico totale.

Al contrario, una demo sicura non dovrebbe essere usata per affermare che il modello politico abbia risolto la garanzia dell'età. Il prestito delle credenziali, l'accesso ai documenti, l'esclusione digitale e l'espansione delle finalità non sono normali difetti software.

Anche le piattaforme affrontano decisioni operative. Un sito web deve convalidare che un'attestazione provenga da un fornitore autorizzato e contenga l'attributo richiesto.

Dovrebbe richiedere solo la condizione minima relativa all'età prevista dalla legge o dalla politica. Raccogliere attributi aggiuntivi comprometterebbe il vantaggio dichiarato del sistema rispetto ai fornitori di verifica ad alta intensità d'identità.

Gli sviluppatori che integrano il protocollo dovranno monitorare le specifiche in evoluzione, poiché il progetto è allineato all'European Digital Identity Architecture and Reference Framework in continuo sviluppo. Le affermazioni di interoperabilità dipendono da questi standard in movimento.

Dovrebbero inoltre evitare di presumere che l'implementazione di un Paese predica quella di un altro. Il progetto consente adattamenti nazionali in materia di iscrizione, soglie di età, controlli di sicurezza, conservazione e configurazione dei fornitori.

Per gli utenti, le domande più chiare sono pratiche. Il wallet nazionale può funzionare sul loro dispositivo, possono ottenere una credenziale e possono contestare un rifiuto errato?

Agli utenti dovrebbe inoltre essere spiegato cosa riceve il sito web che fa affidamento sul sistema, per quanto tempo il wallet conserva le attestazioni e se l'emissione possa essere collegata a presentazioni successive. Queste spiegazioni devono essere comprensibili senza leggere una specifica di protocollo.

L'argomento più forte a favore dell'approccio UE è che può sostituire la divulgazione ripetuta dell'identità con prove dell'età monouso e circoscritte. Le chiavi associate all'hardware rendono tali prove più difficili da copiare o fabbricare.

L'obiezione più forte è che la sicurezza può trasformarsi in permesso. Se le credenziali di produzione funzionano solo tramite software approvato su dispositivi riconosciuti dai fornitori, gli utenti perdono un controllo significativo pur ricevendo il codice sorgente.

Per questo la controversia su Hacker News non può essere risolta etichettando il progetto come rispettoso della privacy o escludente. L'architettura contiene meccanismi che supportano entrambi gli esiti.

Osservate prima l'elenco di conformità, poi i requisiti nazionali di integrità e infine i risultati indipendenti dei flussi completi in produzione. Insieme, questi segnali mostreranno se la fiducia nell'hardware protegge una credenziale privata o diventa una barriera attorno all'accesso legittimo a Internet.

Sviluppatori, decisori politici e utenti dovrebbero esigere una risposta concreta prima di accettare un’implementazione nazionale: quale percorso sicuro rimane quando una persona legittima non riesce a soddisfare il controllo preferito del dispositivo? La risposta rivelerà se questo sistema considera i problemi di compatibilità eccezioni gestibili o motivi di esclusione. Questa scelta, più dell’esistenza di un Secure Enclave o di StrongBox, determinerà se il progetto europeo di verifica dell’età saprà conquistare fiducia oltre le notizie per hacker.