Questo articolo non nasce per difendere Cloudflare, né per attaccare AGCOM per principio. Nasce per un motivo molto più semplice e meno ideologico: il cosiddetto Piracy Shield è un sistema tecnicamente fragile e giuridicamente incompatibile con l’ordinamento italiano, europeo e internazionale. Il provvedimento contro Cloudflare e il blocco preteso sul DNS 1.1.1.1 non sono un errore di esecuzione, ma l’esito logico di un impianto sbagliato alla radice.

Chiunque lavori seriamente con infrastrutture di rete, cloud o diritto delle tecnologie lo sa: quando un sistema fallisce sempre nello stesso modo, il problema non è l’operatore che “non collabora”, ma il modello.

Questo articolo è un estratto della trattazione completa che è pubblicata sulla pagina LinkedIn di Antonio Ieranò, dove troverete le argomentazioni relative ai limiti giurisdizionali e amministrativi del provvedimento contro CloudFlare, in riferimento alla Costituzione italiana, al diritto dell'Unione Europea, al GDPR e al diritto internazionale.

Le falle tecniche del Privacy Shield

Il Piracy Shield nasce da un presupposto tecnologico errato: l’idea che Internet sia una rete centralizzata, controllabile per punti discreti, come una rete televisiva o una dorsale telefonica. Questo presupposto era già superato vent’anni fa. Oggi è semplicemente incompatibile con il funzionamento reale della rete. Internet è una rete distribuita, stratificata per livelli, progettata per essere resiliente, ridondante e adattiva.

Gli standard fondamentali su cui si basa, a partire dall’architettura TCP/IP e dal Domain Name System, non associano mai in modo diretto un contenuto a un indirizzo IP.

Gli RFC che definiscono il DNS, in particolare RFC 1034 e RFC 1035, descrivono un sistema di risoluzione dei nomi distribuito, gerarchico e basato su cache. Un resolver DNS non “ospita” contenuti, non li seleziona e non li controlla. Traduce nomi in indirizzi. Punto.

Il Piracy Shield, invece, tratta indirizzi IP e risoluzioni DNS come se fossero identificatori univoci di contenuto. Non lo sono. Non lo sono mai stati.

Questo porta direttamente al secondo problema tecnico: l’overblocking strutturale.

Nel mondo cloud e CDN, un singolo indirizzo IP può servire centinaia o migliaia di domini diversi, spesso appartenenti a soggetti completamente estranei tra loro. È una conseguenza diretta del modello multi-tenant adottato da CDN, cloud provider e servizi di sicurezza. Bloccare un IP significa bloccare tutto ciò che passa da quell’IP, indipendentemente dalla liceità dei contenuti.

Non è un errore occasionale. È un effetto previsto. È come sequestrare un intero condominio perché un inquilino guarda un film pirata.

Dal punto di vista architetturale, il Piracy Shield opera prevalentemente a livello di rete (Layer 3 e 4 del modello OSI), mentre i contenuti risiedono a livello applicativo (Layer 7). Questa “cecità applicativa” rende il sistema tecnicamente primitivo. Non analizza il contesto, non distingue i servizi, non valuta l’uso effettivo di un dominio o di un’infrastruttura.

In un’Internet moderna, questo approccio non è solo inefficace: è dannoso.

Un ulteriore elemento critico è l’assenza totale di auditabilità tecnica indipendente. Non esistono specifiche tecniche pubbliche complete del funzionamento del Piracy Shield, non esistono audit terzi, non esistono metriche verificabili sui falsi positivi. Un sistema che incide sull’accesso alla rete, sulla continuità dei servizi e sull’attività economica senza audit indipendente non è uno strumento di enforcement. È un atto di fede tecnologica.

Paradossalmente, il Piracy Shield indebolisce anche la sicurezza complessiva della rete. Incentiva l’uso di DNS alternativi non controllati, spinge verso VPN opache, rompe meccanismi di protezione come CDN, WAF e sistemi anti-DDoS. Non a caso, gli standard più recenti del DNS, come DNS over HTTPS (RFC 8484) e DNS over TLS (RFC 7858), nascono proprio per ridurre interferenze arbitrarie sulla risoluzione dei nomi.

Un sistema che pretende di “proteggere” internet rompendo i suoi meccanismi di sicurezza di base produce più superficie d’attacco di quanta ne riduca.

Caso esemplare – CloudFlare e il DNS 1.1.1.1

Il caso Cloudflare rende evidente, in modo quasi didattico, l’inadeguatezza del modello Piracy Shield.

AGCOM ha preteso che Cloudflare intervenisse sul proprio servizio DNS pubblico 1.1.1.1 per impedire la risoluzione di domini segnalati dal Piracy Shield. Questa richiesta presenta problemi tecnici e giuridici enormi.

1.1.1.1 è un resolver DNS globale, non nazionale. Il servizio è identico per utenti italiani, europei o extra-UE. Il DNS non ospita contenuti, non li distribuisce e non li seleziona. Risolve nomi secondo standard IETF.

Per applicare un blocco selettivo su base nazionale, Cloudflare avrebbe dovuto segmentare geograficamente il servizio, identificare gli utenti, introdurre logging e trattamenti di dati aggiuntivi. Tutto ciò sarebbe entrato in conflitto diretto con i principi di minimizzazione e limitazione delle finalità previsti dal GDPR, oltre a creare incoerenze con altri ordinamenti giuridici.

In altre parole: la richiesta non era solo contestabile. Era strutturalmente impossibile senza violare altre norme.

Leggi l'articolo completo sulla pagina LinkedIn di Antonio Ieranò