Non saro’ breve.

L’emendamento D’Alia al pacchetto sicurezza ha riacceso il dibattito sulla censura, sulla neutralita’  della rete, sugli strumenti di controllo dell’informazione e sulla responsabilita’ dei provider.

C’e’ chi dice che l’emendamento non introduce sostanziali novita’ rispetto agli Art. 14, 15 e 16 del D.Lgs. 70/2003, ma c’e’ anche chi osserva che le novita’  ci sono e che sono importanti: e’ l’esecutivo a disporre gli interventi con decreti del Ministro degli interni, i casi di istigazione e apologia di reato a cui gli interventi possono essere applicati sono molto ampi, non e’ chiaro se si parli anche di provvedimenti preventivi, si fa esplicito riferimento all’applicazione di filtri da parte dei fornitori di accesso. Le mie riflessioni si concentrano solo su quest’ultimo punto. Quindi non discuto chi, quando e perche’ debba disporre interventi, ma solo la fattibilita’ tecnica e le possibili conseguenze di tali interventi.

Il testo

I punti 3 e 4 del testo approvato dell’Art. 50-bis recitano:

3. Entro 60 giorni dalla pubblicazione della presente legge il Ministro dello sviluppo economico, con proprio decreto, di concerto con il Ministro dell’interno e con quello della pubblica amministrazione e innovazione, individua e definisce, ai fini dell’attuazione del presente articolo, i requisiti tecnici degli strumenti di filtraggio di cui al comma 1, con le relative soluzioni tecnologiche.

4. I fornitori dei servizi di connettivita’ alla rete internet, per l’effetto del decreto di cui al comma 1, devono provvedere ad eseguire l’attivita’ di filtraggio imposta entro il termine di 24 ore. La violazione di tale obbligo comporta una sanzione amministrativa pecuniaria da euro 50.000 a euro 250.000, alla cui irrogazione provvede il Ministero dello sviluppo economico.

Il comma 3 rimanda ad un successivo decreto che dovra’ definire i requisiti tecnici degli strumenti di filtraggio, e quindi non e’ escluso che verra’ fatta chiarezza, ma il comma 4 contiene gia’ due elementi che meritano di essere discussi: il ricorso a filtri (comunque definiti da futuri decreti) e l’individuazione dei fornitori di connettivita’ (internet service providers, ISP) come soggetti incaricati di applicarli.

Gli attori

Per semplicita’  immaginiamo che l’attivita’  di istigazione o apologia sia compiuta attraverso un testo pubblicato in web. Si tratta del caso piu’ semplice che mi viene in mente, ma vedremo che e’ gia’ sufficientemente complesso, e poi diremo cosa c’e’ di piu’ complicato.

Per pubblicare una pagina (o un commento) su un sito web l’autore (1) si avvale di un fornitore di connettivita’ (2) e di un fornitore di servizi di hosting (3). Per leggere la pagina gli utenti (4) si avvalgono a loro volta di un fornitore di connettivita’ (5) ed accedono al sito del fornitore di servizi (3). Sia l’autore (1) che gli utenti (4) usufruiscono di Internet (6) per stabilire un collegamento tra la rete del proprio fornitore di connettivita’ (2 o 5) e il server su cui risiede il sito web (3). Abbiamo quindi almeno 6 protagonisti e due flussi principali di informazioni, tra l’autore e il server e tra il server e gli utenti.

I punti in cui le reti dei fornitori di connettivita’ si raccordano ad Internet sono detti gateway. Tutti i nodi coinvolti nella comunicazione sono identificati univocamente da un indirizzo IP.

Il funzionamento

Tutte le informazioni sono scambiate in pacchetti con un indirizzo sorgente, un indirizzo destinazione e un contenuto. I pacchetti passano di nodo in nodo tra la sorgente e la destinazione, seguendo percorsi decisi di volta in volta in base al traffico. Tutti i nodi della rete attraversati da un pacchetto lo memorizzano temporaneamente per gestirlo, cioe’ per leggerne l’indirizzo e inoltrarlo verso la destinazione. Tecnicamente i nodi della rete non hanno necessita’ di aprire il pacchetto e guardare il contenuto, ma avendone una copia locale potrebbero farlo. Per ragioni pratiche i protocolli di rete sono fatti a strati che rendono le applicazioni (al livello piu’ alto) indipendenti dalle caratteristiche fisiche della rete e dei canali di comunicazione (ai livelli piu’ bassi). Per garantire efficienza e neutralita’ alla rete, i nodi di Internet che hanno la funzione di smistare il traffico implementano solo i protocolli di livello piu’ basso e ignorano il contenuto dei pacchetti.

I filtri

I filtri sono strumenti informatici (programmi, componenti hardware, o un mix dei due) il cui funzionamento dipende da due scelte principali: la collocazione e i criteri di filtraggio.

La collocazione deve essere scelta in modo da intercettare tutto il traffico a cui devono essere applicati, mentre i criteri di filtraggio devono essere concepiti in modo da evitare errori. Gli errori possono essere di due tipi: falsi positivi (pacchetti che vengono bloccati ingiustamente) e falsi negativi (pacchetti maliziosi che non vengono riconosciuti come tali).

In ogni caso i filtri hanno bisogno di tempo e risorse di calcolo per funzionare, e rallentano il traffico a cui vengono applicati. Le risorse e il tempo di elaborazione aumentano all’aumentare della quantita’ di traffico e della complessita’ dei criteri di filtraggio.

I criteri di filtraggio

Se si sapesse da dove provengono i dati da bloccare, la cosa piu’ semplice sarebbe bloccare i pacchetti in base all’IP sorgente. Ma questo bloccherebbe tutti i dati provenienti da quell’indirizzo, dando luogo a molti falsi positivi. Si pensi al caso in cui la sorgente sia un server popolare come Google, Facebook, o Youtube.

I casi in cui ci sia interesse a bloccare un pacchetto in base all’IP destinazione sono simmetrici a quelli basati sull’IP sorgente, e non meritano ulteriori considerazioni.

Resta il caso del filtraggio in base al contenuto o, peggio, al suo significato. In linea di principio questo sembra l’approccio piu’ sensato, ma pone enormi problemi concettuali e tecnici, oltre che etici.

Per avere un’idea della complessita’ dei filtri bisogna pensare che i programmi non sono altro che sequenze di istruzioni non ambigue. Non serve essere dei programmatori per provare a descrivere in modo non ambiguo dei criteri di filtraggio utili a discriminare contenuti leciti da contenuti riconducibili a reati di apologia o istigazione a delinquere. Se provandoci non doveste riuscirci sappiate che il problema non sta nel linguaggio, ma nella difficolta’ intrinseca del problema. Se invece doveste riuscirci fatemelo sapere…

La posizione dei filtri

I filtri devono essere applicati dove passa il traffico, cioe’ su uno qualunque dei nodi coinvolti e con il supporto di chi lo gestisce. Ovviamente applicare i filtri piu’ di una volta allo stesso flusso di dati e’ sconveniente. Immaginando che non sia possibile chiedere la collaborazione dell’autore del contenuto di cui si vuole impedire la diffusione, i filtri possono essere applicati: sui server che ospitano le pagine e i servizi web, sui nodi di Internet, sui gateway degli ISP, o sui computer degli utenti.

Applicare filtri ai nodi di Internet e’ impensabile per mille ragioni, tra le quali l’inadeguatezza tecnologica dei nodi stessi, la drammatica perdita di efficienza della rete che ne conseguirebbe, la reiterazione dei filtraggi, …

Applicarli sui computer degli utenti e’ impensabile perche’ comporterebbe un controllo sugli utenti. Esistono filtri spontaneamente applicati dagli utenti sui propri computer ma sono concepiti per tutt’altre finalita’ (parental control) e non fanno al caso.

Restano quindi i server web e i gateway dei fornitori di accesso. Il Decreto sembra affidare a questi ultimi il compito, ma dal punto di vista logistico sarebbe piu’ pratico applicare i filtri alla fonte, soprattutto se questa e’ stata identificata.

Chiedere ai fornitori di accesso (ISP) di applicare filtri sui propri gateway sarebbe come chiedere ai giornalai di leggere tutti i giornali che vendono per sbianchettare i contenuti da filtrare.

Ulteriori difficolta’

Come avevo premesso, il caso che abbiamo preso in esame fin qui e’ il piu’ semplice possibile. Ci sono numerosi e frequenti elementi che nella pratica aggiungono complessita’ al problema del filtraggio:

• canali cifrati (ogni volta che accedendo ad un sito vediamo che l’indirizzo inizia con https, la s finale sta ad indicare che il canale e’ cifrato per garantire la riservatezza dei dati scambiati tra il nostro computer e il server. I flussi criptati non possono essere filtrati lungo il tragitto)
• contenuti multimediali (se filtrare un testo in base al contenuto non e’ di per se’ banale, lo e’ ancora meno capire cosa si nasconde in un’immagine o in un file video)
• trasmissione in tempo reale (se i contenuti non risiedono su un server, ma vengono scambiati in Internet in tempo reale, non e’ concettualmente possibile filtrarli prima che il destinatario li riceva, a meno di non introdurre ritardi tali da compromettere il funzionamento delle applicazioni in tempo reale)
• server distribuiti (i servizi piu’ popolari non risiedono su un solo server, ma su decine di migliaia di server distribuiti in tutto il mondo, ciascuno con il proprio indirizzo IP)
• propagazione (esistono meccanismi automatici di propagazione e aggregazione di contenuti in web che di fatto creano copie dei dati difficili da censire. L’eventuale oscuramento della fonte delle informazioni non comporterebbe automaticamente l’oscuramento o l’eliminazione delle copie)
• globalita’ (la rete e’ globale e i servizi in rete sono indipendenti dalla localizzazione dei server e degli utenti. Impedire unilateralmente la fruizione di un servizio senza compromettere il funzionamento di Internet e’ praticamente impossibile o inutile)

Collaborazione ex ante o ex post?

I problemi tecnici di cui stiamo parlando cambiano drasticamente proporzione a seconda che agli operatori della rete venga chiesto di collaborare dopo l’identificazione di un reato per bloccarne gli effetti e identificarne il responsabile (collaborazione ex post), o di svolgere una funzione di garanzia per impedire che un reato venga commesso o che produca effetti (garanzia ex ante).

Nel primo caso il problema principale sta nell’attribuire le responsabilita’ del reato e nell’identificarne gli autori, ma la collaborazione tra autorita’ gudiziaria e operatori per porre fine al reato e’ gia’  disciplinata dagli articoli 14 comma 3, 15 comma 2 e 16 comma 3 del D.Lgs. 70/2003, che distinguono correttamente i ruoli e le responsabilita’  dei fornitori di accesso e dei fornitori i servizi. Gli accorgimenti tecnici da adottare per porre fine ad una violazione non sono necessariamente dei filtri, ma possiamo accettare che il termine “filtro” venga usato in senso lato nell’emendamento D’Alia per indicare un generico provvedimento che blocchi in modo selettivo un servizio. Inoltre i soggetti chiamati a collaborare non sono necessariamente i “fornitori di accesso”, ma anche in questo caso sono portato a pensare che il termine sia usato genericamente nell’emendamento D’Alia per indicare operatori di rete, siano essi fornitori di accesso o di servizi.

Nel secondo caso, cioe’ in assenza di un reato e di un colpevole, non potrebbero essere intraprese azioni mirate e quindi i filtri dovrebbero assumere un significato piu’ stretto ed essere adottati su larga scala a scopi preventivi. Alla luce delle considerazioni tecniche fatte fin qui non ritengo pero’ che questo sia tecnicamente possibile senza compromettere drasticamente il funzionamento della rete, e pertanto sono portato a pensare che non sia questo il senso dell’emendamento D’Alia.

Riferimenti

• Testo approvato dal Senato dell’Emendamento D’Alia al Pacchetto Sicurezza, Art. 50-bis del Disegno di Legge S. 733
• Decreto Legislativo n. 70 del 9 aprile 2003

L’editoriale di Fred Schneider sul numero di agosto di Security & Privacy, magazine dell’IEEE, lamenta l’assenza di un adeguato dibattito sul tema della sicurezza e dell’affidabilità di Internet nel contesto delle proposte regolamentari finalizzate a tutelarne la neutralità. L’editoriale è molto breve e si limita ad introdurre il tema e ad anticipare un articolo che apparirà sul Federal Communication Law Journal, ma offre spunti ampi e interessanti. La domanda è:

fino a che punto è giusto ammettere eccezioni al principio di neutralità (che impedisce ai provider di discriminare in base all’applicazione, al contenuto e alla provenienza dei pacchetti) per tutelare la sicurezza degli utenti e l’affidabilità delle reti?

In pratica si tratta di trovare il giusto compromesso tra due proprietà delle reti: la neutralità da una parte e la “dignità di fiducia” (per tradurre alla lettera il termine inglese “trustworthiness“) dall’altra. Poichè il dibattito sulla neutralità è ormai centrale, e numerose proposte regolamentari sono già state elaborate, il compromesso sembra dover essere cercato nelle eccezioni alla neutralità tollerate in nome della trustworthiness.

Come al solito ci sono due estremi: regole troppo rigide che rischiano di impedire il raggiungimento di livelli adeguati di sicurezza e affidabilità, regole troppo lasche che rischiano di compromettere la neutralità.

Esempi di regole troppo strette sono quelli delle proposte normative del North Dakota e del Maine, che consentirebbero ai provider di offrire servizi legati alla sicurezza in deroga al principio di neutralità, solo se i singoli utenti hanno la possibilità di rinunciare a tali servizi in nome della neutralità. Norme troppo lasche sono invece quelle che ammettono qualsiasi discriminazione che possa dirsi motivata da ragioni di sicurezza. La questione si fa ulteriormente complessa se le tecniche di tutela della sicurezza richiedono accordi trasparenti tra gli operatori.

In conclusione, Schneider sollecita l’apertura di un dibattito piu’ ampio sull’argomento e suggerisce un procedimento per affrontare il tema della sicurezza sui tavoli della network neutrality:

1. cominciare con l’enumerazione della proprietà di sicurezza e affidabilità che gli utenti della rete potrebbero desiderare,

2. evidenziare quelle per le quali allo stato dell’arte non esistono implementazioni end-to-end,

3. chiedere che le proposte normative sulla network neutrality “non impediscano” lo sviluppo di tecniche atte a garantire le proprietà di sicurezza non altrimenti implementabili.

Riferimenti:

• Fred B. Schneider, “Network Neutrality versus Internet Trustworthiness?”, IEEE Security & Privacy, Vol. 6, No. 4, pp. 3-4, 2008. (pdf)