Omnia in Mensura et Numero et Pondere (Sapienza 11,20)

Transcript

Omnia in Mensura
et Numero
et Pondere
(Sapienza 11,20)
Indice
Introduzione
1
1 La Privacy e il Web
7
1.1
1.2
La privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.1.1
Definizione di privacy . . . . . . . . . . . . . . . . . . .
7
1.1.2
La legislazione italiana . . . . . . . . . . . . . . . . . .
8
1.1.3
Tecnologia dell’informazione e sorveglianza elettronica .
9
1.1.4
Consumatori, la privacy e il marketing . . . . . . . . . 12
Il Web e la privacy . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.1
Web 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.2
La privacy dei servizi basati su Web . . . . . . . . . . . 17
1.2.3
Le internet privacy policy . . . . . . . . . . . . . . . . 19
1.2.4
Social network privacy . . . . . . . . . . . . . . . . . . 23
2 Una soluzione al problema: Secure Google Documents
2.1
2.2
2.3
29
Analisi del problema . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1
Proteggere i dati personali nel browser . . . . . . . . . 29
2.1.2
Privacy e controllo dei contenuti . . . . . . . . . . . . . 32
Google Documents . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.1
Dal desktop al browser, il software online . . . . . . . . 36
2.2.2
Google Documents Access Control List . . . . . . . . . 39
2.2.3
Google Documents, termini di utilizzo e privacy . . . . 40
Una soluzione: SecureGDocs . . . . . . . . . . . . . . . . . . . 42
2.3.1
La soluzione implementata . . . . . . . . . . . . . . . . 42
3
4
INDICE
2.3.2
Caratteristiche di SecureGdocs
2.3.3
Utilizzo di SecureGdocs . . . . . . . . . . . . . . . . . 45
2.3.4
Sicurezza in SecureGDocs . . . . . . . . . . . . . . . . 48
3 Architettura di SecureGDocs
3.1
3.2
3.3
. . . . . . . . . . . . . 43
53
Struttura delle directory e dei file . . . . . . . . . . . . . . . . 53
3.1.1
Estensioni per Firefox . . . . . . . . . . . . . . . . . . 53
3.1.2
Struttura delle directory . . . . . . . . . . . . . . . . . 54
3.1.3
La directory chrome . . . . . . . . . . . . . . . . . . . 57
I file XUL: l’interfaccia utente . . . . . . . . . . . . . . . . . . 58
3.2.1
I file XUL e l’interfaccia . . . . . . . . . . . . . . . . . 58
3.2.2
Il file XUL principale: secugdocs.xul . . . . . . . . . . 60
I file Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.3.1
I file Javascript e la logica . . . . . . . . . . . . . . . . 61
3.3.2
Modulo CORE . . . . . . . . . . . . . . . . . . . . . . 62
3.3.3
Modulo HTTP . . . . . . . . . . . . . . . . . . . . . . 66
3.3.4
Modulo CHIPER . . . . . . . . . . . . . . . . . . . . . 70
3.3.5
Modulo UTILS . . . . . . . . . . . . . . . . . . . . . . 72
3.3.6
Intercettazione e crittografia dei contenuti . . . . . . . 73
Conclusioni
77
A Google Docs Privacy Policy
79
A.1 Personal Information . . . . . . . . . . . . . . . . . . . . . . . 79
A.2 Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.3 Your choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.4 More information . . . . . . . . . . . . . . . . . . . . . . . . . 81
B Librerie esterne
83
Bibliografia
87
Elenco delle figure
2.1
Schermata di login al servizio . . . . . . . . . . . . . . . . . . 43
2.2
Visualizzazione di un file non decifrato . . . . . . . . . . . . . 45
3.1
Struttura directory . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2
Sottodirectory chrome . . . . . . . . . . . . . . . . . . . . . . 58
3.3
Rappresentazione di un file . . . . . . . . . . . . . . . . . . . . 61
3.4
Interfaccia utente principale . . . . . . . . . . . . . . . . . . . 62
5
Introduzione
La privacy e il Web 2.0
In questa tesi si è analizzato il problema della protezione della privacy nelle applicazioni Web 2.0, in particolare nell’applicazione Google Documents.
Mantenere la privacy personale delle informazioni in rete è diventato sempre
più difficile con l’avvento delle nuove tecnologie.
La riservatezza delle informazioni viene messa a rischio non soltanto dalle
applicazioni di social networking che permettono di condividere pagine personali specificando dati demografici uniti a preferenze di consumo, ma anche
dalle applicazioni Web, che stanno sostituendo le applicazioni installate localmente consentendo di salvare contenuti e dati direttamente sui server [Adl05].
Il solo transitare in rete espone dati ed informazioni a molteplici rischi; spesso
non basta la protezione garantita dall’account per evitare la lettura da parte
di terzi.
Scrivere contenuti su Google Documents non ne implica la pubblicazione: i
documenti inseriti sono disponibili solo dall’account del creatore e sono condivisi con altri utenti solo se inseriti volontariamente nella lista di condivisione
dal proprietario stesso.
Nonostante questo, i documenti privati non condivisi, non rispettano la proprietà di riservatezza: i contenuti sono accessibili da Google che ne possiede
la copia originale.
Questa mancanza di riservatezza con le aziende che offrono il servizio può
essere di ostacolo alla sua diffusione: i documenti creati con software di tipo
‘Office‘ sono riservati e personali, e questo implica la necessità di una prote1
2
INTRODUZIONE
zione da qualsiasi intromissione, sia essa da parte di utenti terzi o da parte
del gestore.
La soluzione proposta in questa tesi è la creazione di uno strumento che risolva il problema introducendo un livello aggiuntivo di sicurezza che si occupi
di cifrare i contenuti dei documenti creati con Google Documents.
Nascondendo tramite cifratura questi contenuti se ne conserverebbe la totale
riservatezza: Google ne custodirebbe soltanto una versione criptata.
La soluzione implementata come risultato di questa ricerca è un’estensione
per il popolare browser Mozilla Firefox chiamata ‘Secure Google Documents‘
o ‘SecureGdocs‘.
Questo software cifra in automatico i contenuti dei documenti di testo creati
tramite l’interfaccia di Google Documents.
L’estensione SecureGdocs si frappone tra l’utente e i server di Google in maniera del tutto trasparente; l’applicazione Web non subisce alcuna modifica
nel suo aspetto e la cifratura dei file viene gestita dalla ‘sidebar‘ tramite una
password per ogni documento.
Gli utenti che vogliono assicurarsi la riservatezza totale dei propri documenti
mantengono i pregi dell’utilizzo di un’applicazione Web come suite da ufficio
senza incorrere nei rischi precedentemente esposti.
Un’ulteriore applicazione pratica è la condivisione protetta dei documenti:
si possono utilizzare le funzionalità di condivisione che Google Documents
offre in aggiunta alla protezione garantita da SecureGdocs. L’utente inserito
nella lista di condivisione deve anche possedere la password specifica per il
documento per accedervi e per modificarlo in maniera collaborativa.
Gli sviluppi futuri potrebbero essere l’estensione dell’applicazione agli altri
software che compongono Google Documents, cioè Spreadsheets e Presentations ed anche la configurabilità da parte dell’utente di alcuni aspetti che la
rendano compatibile con altre tipologie di applicazioni Web 2.0.
Oltre questo SicureGdocs potrebbe implementare in futuro algoritmi asimmetrici in modo da fornire direttamente nell’applicazione un canale sicuro
per lo scambio delle password: l’algoritmo utilizzato potrebbe essere un ibri-
Introduzione
do, cioè potrebbe utilizzare la velocità di AES per cifrare simmetricamente
i contenuti, mentre potrebbe utilizzare un più lento algoritmo asimmetrico
come RSA, per condividere il segreto (la password di AES) tramite un canale
non sicuro.
Il primo problema affrontato in questo lavoro è la privacy delle informazioni personali collezionate indirettamente o direttamente dai siti Web.
Fin dagli anni novanta il problema della privacy costituiva un ostacolo alla
diffusione dell’e-commerce. Gli utenti sono stati spesso derubati delle loro
informazioni personali mediante tecnologie invasive come i cookie e lo spam.
Queste tecnologie hanno generato un atteggiamento di diffidenza verso tutto
quello che è presente nel Web [Cla99].
I governi hanno regolato il settore cercando di arginare questi problemi e
parallelamente si sono sviluppate svariate soluzioni per proteggere la privacy
degli utenti come anonimizzatori e proxy [HWW98].
Oltre alle amministrazioni pubbliche, che producono legislazione in materia
di protezione dei dati, lo sforzo per il rispetto della privacy degli utenti deve
partire anche dalle aziende che operano sul Web; esse devono pubblicare le
loro politiche sulla privacy (privacy policy) in documenti facilmente accessibili.
Questi documenti devono essere chiari e completi, cioè devono toccare tutti
i punti principali della tutela delle informazioni e soprattutto devono essere
rispettati dalle aziende che li pubblicano [AE01].
La soluzione dalla parte degli utenti, lato client, è invece quella di utilizzare
strumenti come proxy e anonimizzatori che blocchino la divulgazione delle
informazioni sensibili durante la navigazione.
Le soluzioni analizzate sono solo una piccola parte di quelle esistenti, ed ancora molti sforzi dovranno essere fatti dall’industria per garantire il rispetto
e il controllo della privacy personale da parte degli utenti.
Il secondo problema è derivato direttamente dal primo ed è quello della
perdita dei contenuti sottoscritti nelle applicazioni Web 2.0.
Le applicazioni Web 2.0 sono l’evoluzione dei siti internet in applicazioni
3
4
INTRODUZIONE
complete e fruibili dal Web browser, che utilizzano tecnologie nuove (AJAX,
openAPI) e svolgono funzioni particolari (social network, blogging) [GV07].
La nascita delle applicazioni Web 2.0 ha messo in relazione diretta la crescita
delle informazioni sottoscritte nel Web con la perdita del controllo su di esse:
il problema della perdita della custodia delle informazioni avviene sia nelle
applicazioni che servono a pubblicare i contenuti come i blog e i wiki, sia
nelle applicazioni di social network, ma anche nelle applicazioni Web sostitutive delle versioni installate, ad esempio Google Documents. Questi rischi
potrebbero rappresentare delle barriere d’entrata per la diffusione del Web
2.0.
La perdita dei contenuti nei blog si verifica perché spesso l’autore inserisce
direttamente nell’interfaccia Web l’articolo che vuole pubblicare, senza salvarne una copia in locale. In questo modo l’esistenza dell’articolo dipende
solo dall’affidabilità dell’applicazione di blogging e da quella dei server che
la ospitano.
Nei social network invece gli utenti inseriscono dati personali associati ad abitudini e preferenze, generando dei rischi per la privacy poiché la moltitudine
di dati pubblicati è aggregata in un’unica applicazione; le aziende possono
usare queste applicazioni come sorgenti da dove attingere per le ricerche di
mercato, lo studio di preferenze e le altre tecniche di profilazione degli utenti/consumatori.
Nel capitolo 1 si analizzano alcuni aspetti riguardanti la privacy in Facebook,
l’applicazione social network più diffusa ad oggi [HJ05].
Per le applicazioni sostitutive di quelle Desktop come Google Documents vi
sono altri problemi legati alla pubblicazione dei documenti online: anche se
restano privati, qualcuno sicuramente può accedervi, per lo meno Google,
violando il diritto alla riservatezza dei contenuti. Il prossimo problema si
riferisce direttamente a questo.
Il problema della divulgazione di informazioni sensibili e personali è dunque
più grave nel panorama 2.0 e sono necessarie soluzioni provenienti sia dai
fornitori dei servizi, sia dagli utenti.
Introduzione
Gli utenti possono utilizzare strumenti sviluppati ad-hoc per la protezione delle informazioni su varie applicazioni Web, come ad esempio quella
sviluppata come risultato di questa tesi.
Il terzo problema è un caso particolare del secondo e riguarda la perdita
del controllo e della riservatezza delle informazioni personali contenute nei
documenti gestiti e modificati tramite Google Documents.
Google, fornendo gratuitamente l’applicazione, memorizza tutti i documenti
e i relativi contenuti nei server sotto forma di testo in chiaro.
Il problema dei documenti di tipo ‘Office‘ è che per natura essi contengono
testi privati e personali, che non si devono e non si vogliono condividere con
nessuno, tanto meno con Google.
Il problema nasce dal momento in cui i file di questo tipo, storicamente salvati nel computer locale e accessibili solo dal proprietario, vengono salvati su
server Web, potenzialmente accessibili in qualsiasi momento.
Come risultato di questo studio e come soluzione a questo problema si è implementata una soluzione chiamata SecureGdocs.
SecureGdocs è una estensione (extension) al browser Mozilla Firefox.
SecureGdocs si apre come ‘sidebar‘ nel browser: l’utente utilizza Google Documents con la sua interfaccia originale. La sidebar si occupa di creare e
gestire i documenti cifrati ponendosi tra l’applicazione Web e il browser.
Dal lato del server i file sono semplici file di testo composti tramite il modulo
’Writer’ di Google Documents ma dal contenuto cifrato; dal lato utente i
documenti vengono visualizzati in chiaro a patto di avere aperta la sidebar
SecureGdocs e di possedere la giusta password per il documento.
Quando le modifiche partono dal browser per il server vengono cifrate, quando un documento deve viaggiare nel senso opposto per essere visualizzato dal
creatore esso viene decifrato.
In questo modo si può garantire la proprietà fondamentale della crittografia, cioè la riservatezza delle informazioni, garantendo l’esclusione persino di
Google dalla lettura dei documenti.
La sicurezza delle crittografia è garantita dall’algoritmo AES, l’Advandced
5
6
INTRODUZIONE
Encryption Standard, riconosciuto dal governo americano come algoritmo
standard e sicuro [SCO03].
La licenza con cui è sviluppato SecureGdocs è GNU/GPL 2.0, per consentire ad altri sviluppatori di migliorare il supporto ed aggiungere nuove
funzionalità.
Gli sviluppi futuri di questa applicazione possono essere molteplici.
Uno di questi può essere l’adattamento dell’applicazione ad altre tipologie di
siti Web 2.0, del tipo Office come ad esempio ‘zoho.com‘. Si possono inoltre
estendere le funzionalità dell’applicazione per essere adattate ad applicazioni
di social network, per condividere testi solo con particolari individui di un
gruppo possessori di una password. Si potrebbe anche adattare SecureGdocs
ai blog per consentire la pubblicazione di un articolo cifrato e distribuire la
password per decifrarlo solo ad alcuni utenti.
Il futuro remoto dell’applicazione è la totale configurabilità, per essere adattata secondo le esigenze direttamente dagli utenti.
L’aspetto più importante di questo approccio è che esso è totalmente userbased: la crittografia è gestita dall’utente, nessuna informazioni in chiaro sui
contenuti viaggia in rete. Gestendo direttamente questo aspetto l’utente ha il
pieno controllo delle informazioni pubblicate, raggiungendo lo scopo prefisso
di mantenere la riservatezza totale dei contenuti.
Capitolo 1
La Privacy e il Web
1.1
1.1.1
La privacy
Definizione di privacy
La privacy è il diritto alla riservatezza delle informazioni personali e della
propria vita privata: ’the right to be let alone’, secondo la formulazione del
giurista statunitense Louis Brandeis che fu probabilmente il primo al mondo
a formulare una legge sulla riservatezza, insieme a Samuel Warren (si veda
il loro articolo The Right to Privacy, in ‘Harvard Law Review‘, 1890).
Brandeis fu ispirato dalla lettura dell’opera di Ralph Waldo Emerson, il grande filosofo americano, che proponeva la solitudine come criterio e fonte di
libertà.
La privacy si traduce spesso (nella sua originaria accezione difensiva) nella
capacità di una persona (o di un gruppo di persone) di impedire che le informazioni che la riguardano diventino note ad altri, incluse organizzazioni ed
enti, qualora il soggetto non abbia volontariamente scelto di fornirle.
Il termine ‘privacy‘, concetto inizialmente riferito alla sfera della vita privata,
negli ultimi decenni ha subito un’evoluzione estensiva, arrivando a indicare
il diritto al controllo sui propri dati personali.
La recente diffusione delle nuove tecnologie ha contribuito ad un assottiglia7
8
1. La Privacy e il Web
mento della barriera della privacy, ad esempio la tracciabilità dei cellulari o
la relativa facilità a reperire gli indirizzi di posta elettronica delle persone.
Oggi la privacy è dunque un indiscutibile strumento di salvaguardia della
libera e piena autodeterminazione dell’individuo.
Privacy non è infatti soltanto il sacrosanto diritto a che nessuno invada il
‘nostro mondo precostituito‘ bensı̀ è anche l’altrettanto sacrosanto diritto a
che ciascuno possa liberamente esprimere le proprie aspirazioni più profonde
e realizzarle, attingendo liberamente e pienamente ad ogni propria potenzialità.
Il termine privacy assume diversi significati in differenti contesti.
La privacy può essere di vari tipi: la privacy fisica, delle informazioni e anche
organizzativa.
La privacy fisica rappresenta la protezione da intrusioni nello spazio personale o fisico.
La privacy delle informazioni invece è riferita all’evoluzione delle relazioni tra
tecnologia e diritti legali: le informazioni raccolte in maniera digitale sono
facilmente collezionabili e devono essere protette.
Le informazioni elettroniche lasciate al passaggio degli utenti spesso riescono
a ricostruire le informazioni personali, rappresentando una violazione della
privacy se condivise o utilizzate senza il consenso personale.
La privacy organizzativa infine rappresenta il diritto delle agenzie governative o delle corporazioni a tenere le loro attività segrete senza rivelarle ad altre
organizzazioni o persone fisiche.
1.1.2
La legislazione italiana
Per quanto attiene alla legislazione italiana, i fondamenti costituzionali
sono ravvisabili negli art. 14, 15 e 21 della Costituzione Italiana, rispettivamente riguardanti il domicilio, la libertà e segretezza della corrispondenza,
e la libertà di manifestazione del pensiero; ma si può fare anche riferimento
all’art. 2 della Costituzione, incorporando la riservatezza nei diritti inviolabili dell’uomo.
1.1 La privacy
Un ulteriore passo avanti nella formazione di una normativa adeguata viene
fatto per rispetto di obblighi internazionali: con la legge n. 98 del 21 febbraio
1989, è infatti ratificata la Convenzione di Strasburgo (adottata nel 1981),
sulla protezione delle persone rispetto al trattamento automatizzato di dati
di carattere personale.
In Italia è attualmente in vigore il Decreto Legislativo 30 giugno 2003, n.
196, ‘Codice in materia di protezione dei dati personali‘, che ha abrogato la
legge sulla privacy del 1996.
Oggi il termine ‘privacy‘ non è più utilizzato soltanto per sancire il diritto
di ogni individuo a proteggere la propria sfera del privato ma si estende a
definire il diritto alla riservatezza della propria identità e dei propri dati personali.
In questo senso si parla di privacy come ‘autodeterminazione e sovranità su
di sé‘ (Stefano Rodotà) e ‘diritto a essere io‘ (Giuseppe Fortunato), riconoscersi parte attiva e non passiva di un sistema in evoluzione, che deve portare
necessariamente ad un diverso rapporto con le istituzioni, declinato attraverso una presenza reale, un bisogno dell’esserci, l’imperativo del dover contare,
nel rispetto reciproco delle proprie libertà.
1.1.3
Tecnologia dell’informazione e sorveglianza elettronica
La privacy delle informazioni personali è argomento di discussione già
negli anni ottanta.
Roger Clarke infatti, in un articolo del 1988 [Cla88], si trova ad analizzare le
tecniche di sorveglianza digitale che stanno soppiantando le tecniche classiche
ed introduce l’argomento della necessità di una regolamentazione specifica.
La sorveglianza è l’investigazione sistematica e il monitoraggio delle azioni o
delle comunicazioni di una o più persone col fine primario di collezionare informazioni sui loro orientamenti socio-culturali e sulle attività da loro svolte.
Ci può essere anche una secondaria intenzione di utilizzare la sorveglianza
come deterrente per evitare alcuni tipi di attività.
9
10
La forma base di sorveglianza è quella fisica (visiva e uditiva): il monitoraggio di un individuo può avvenire tramite l’utilizzo di immagini satellitari,
telecamere, amplificatori di suono e microfoni, sia in maniera locale che remota.
Nuovi metodi hanno facilitato ed aumentato la sorveglianza personale e di
massa, richiedendo contromisure più efficaci, introducendo il termine ‘sorveglianza elettronica‘ che si riferisce all’incremento sia della sorveglianza fisica
che a quella delle comunicazioni.
Clarke introduce in letteratura il termine ’dataveillance’ che definisce come
l’utilizzo sistematico dei sistemi tecnologici per l’investigazione e il monitoraggio delle azioni e delle comunicazioni di una o più persone. Fa anche uso
dei termini ‘sorveglianza personale‘ e ‘sorveglianza di massa‘.
Il primo termine indica la sorveglianza di un determinato individuo per una
ragione specifica (ad esempio la prevenzione di reati).
La sorveglianza di massa è relativa invece al monitoraggio di un gruppo di
persone, spesso di notevole entità, al fine di identificare e classificare individui appartenenti ad una determinata classe interessante per l’organizzazione
che mette in atto la sorveglianza.
La sorveglianza personale è un’arma importante nella lotta al terrorismo e al
crimine organizzato e può essere utilizzata per collezionare prove per i processi legali, nonché d’altro canto per screditare un personaggio di rilievo nella
società rendendo pubblici particolari imbarazzanti della sua vita privata.
La sorveglianza di massa invece è più comunemente collegata alle realtà aziendali in cui le organizzazioni mantengono dei registri sugli individui con i quali
hanno relazioni, ad esempio i clienti. Le relazioni possono essere dirette o
indirette.
Con l’avvento del digitale la sorveglianza elettronica ha notevolmente sviluppato i seguenti aspetti:
• La capacità di memorizzazione dei dati che ha subito un’evoluzione
immensa nella dimensione e nei materiali, anche in termini economici;
• Un ricco assortimento di tecnologie per catturare, visualizzare e disse-
1.1 La privacy
minare i dati;
• Dati testuali e strutturati sono stati sostituiti da database relazionali
DBMS, che facilitano ancora la collezione e la ricerca sui dati stessi
organizzandoli in maniera più efficiente;
• La tecnologia informatica ha subito una grande evoluzione computazionale, risolvendo problemi deterministici e evolvendo le tecniche dei
modelli probabilistici;
• Continua l’evoluzione delle telecomunicazioni in particolare in velocità,
costi, robustezza, sicurezza;
Oltre alla sorveglianza personale la rivoluzione informatica ha incrementato il problema della sorveglianza di massa: tramite nuovi strumenti è diventato più facile controllare un gruppo di individui piuttosto che uno solo.
La sorveglianza di massa utilizza le stesse tecniche utilizzate per la sorveglianza individuale in maniera sistematica, cioè per ogni transazione, creando di
fatto un database delle stesse che identifica i clienti e i soggetti che vi sono
coinvolti.
Roger Clarke fa distinzione tra quelli che sono i benefici e i pericoli che la
sorveglianza digitale introduce.
Tra i benefici annovera la sicurezza fisica e delle proprietà private nonché
la prevenzione da frodi, furti, abusi; essi si rilevano nell’attività governativa
(tasse e welfare) e nel settore privato (finanza e assicurazioni).
Tra i pericoli della sorveglianza di massa vi è il rischio che la moralità delle
organizzazioni che utilizzano queste tecniche di sorveglianza sia da mettere
in dubbio, poiché la sorveglianza personale è per natura intrusiva ed espone
le persone a dei rischi: è ragionevole dunque che le organizzazioni siano obbligate a giustificarne l’utilizzo.
I pericoli invece della sorveglianza personale sono dati dagli schemi di identificazione che classificano gli individui, schemi che sono però soggetti ad
errori.
11
12
L’esempio concreto e recente può essere dato dalla lista americana denominata ’no-fly list’.
In questa lista sono elencati centinaia di migliaia di passeggeri che non possono volare per rischi riguardanti il terrorismo: i cittadini non possono controllare la loro presenza o meno all’interno della lista, e la TSA (l’organizzazione
che gestisce la sicurezza degli aeroporti americani) si riserva il diritto di vietare i voli ai passeggeri che compaiono nell’elenco.
Esistono però dei casi di omonimia o di semplici errori al momento della redazione di questa lista che vietano il volo a passeggeri che ne hanno diritto.
Questo è un caso di errore nella classificazione delle persone attraverso la
sorveglianza di massa [Sch04].
L’utilizzo delle informazioni collezionate dalla sorveglianza sono definite in
convenzioni internazionali che regolamentano e vietano la diffusione e l’utilizzo improprio dei dati.
Questi problemi sollevati da Clarke mettono in evidenza la necessità di occuparsi delle serie implicazioni generate dai benefici introdotti, creando misure
di sicurezza in merito e adattando la legislazione alla regolamentazione di
questi aspetti.
1.1.4
Consumatori, la privacy e il marketing
Undici anni dopo Roger Clarke in un altro articolo si trova a considerare
‘la fiducia nella società dell’informazione‘, cioè la sensibilità degli utenti in
materia di privacy nei confronti delle organizzazioni che operano su internet.
Nella diffusione dell’e-commerce, ad esempio, Clarke mette in evidenza un
problema di fiducia degli utenti nei confronti delle aziende che operano nel
settore. Questo problema di fiducia sarebbe la causa della scarsa diffusione
dell’e-commerce [Cla99].
La fiducia dei consumatori verso il commercio elettronico dipende da complessi fattori che includono i diritti del consumatore, la libertà di espressione
e l’equità sociale.
L’invasione da parte del cyberspazio della sfera privata individuale con tec-
1.1 La privacy
niche invasive come i cookie e lo spam è alla fonte di questi problemi: troppo
spesso gli utenti si sono sentiti derubati dei propri dati personali come gli
indirizzi e-mail o le preferenze di navigazione.
La privacy infatti è comunemente definita come diritto morale o legale, ma
è importante considerarla anche come interesse individuale a mantenere uno
spazio personale, libero da interferenze da parte di altre persone o organizzazioni.
Il termine ‘spazio personale‘ è multidimensionale e fa riferimento contemporaneamente alla privacy della persona, alla privacy del comportamento
individuale, alla privacy delle comunicazioni e alla privacy dei dati personali.
La privacy è violata dalle organizzazioni pubbliche e private che collezionano grandi quantità di dati individuali; i profili individuali collezionano
informazioni su ogni individuo influenzando il suo comportamento e riducendo la sua libertà.
Il marketing e le tecnologie hanno generato la tendenza a convertire le azioni anonime collezionate su internet in transazioni identificate e collezionate
per scopi di ricerca. Questa ricerca spesso è orientata al marketing ed alla
pubblicità e serve a presentare spot personalizzati, offerte specifiche, ed altro
ancora [Kob07].
Contro l’avvento dell’invasione della privacy comandata dalle tecnologie, le
difese naturali di protezione non sembrano avere effetto.
La considerazione della privacy e della fiducia degli utenti può essere migliorata anche creando un meccanismo regolatorio che vigili sulle aziende e sul
Web.
L’auto-regolamentazione di questo aspetto da parte delle aziende non ha
avuto esito positivo nonostante ci siano stati vari tentativi negli anni, la migliore soluzione è quella di produrre delle regole legislative per garantire e
migliorare la fiducia nelle organizzazioni che operano online.
Negli ultimi anni abbiamo assistito a un crescente numero di casi che riguardano l’invasione della privacy personale correlate alla crescita di internet
e alle attività di marketing svolte su internet:
13
14
• L’invio di mail non desiderate da parte di compagnie che vogliono
pubblicità;
• L’attività degli annunci su Web che tracciano i percorsi e le azioni degli
utenti tramite varie tecniche;
• Il codice maligno introdotto nei siti Web che memorizzano le informazioni personali degli utenti;
• L’uso ed il trasferimento di informazioni personali in protocolli come
‘MSN Portal‘, utilizzate da Microsoft per effettuare ricerche di mercato.
L’utilizzo improprio delle informazioni personali è schematizzato in un
articolo da Wang [HWW98] in questo modo:
Accesso improprio l’infiltrazione nel computer dell’utente per accedere
alle informazioni personali;
Collezionamento improprio collezionare informazioni private dell’utente
senza comunicarlo nella giusta maniera;
Monitoraggio improprio sorvegliare l’utilizzo di internet da parte di un
utente senza il consenso;
Analisi impropria analizzare le informazioni collezionate senza il consenso;
Trasferimento improprio il trasferimento delle informazioni ad altre organizzazioni o industrie;
Salvataggio improprio in formato elettronico mantenere le copie dei
dati personali in maniera non sicura generando il rischio di intrusioni
e accessi non autorizzati;
Sollecitazioni non desiderate trasmettere informazioni a un utente senza
il suo consenso.
1.2 Il Web e la privacy
Dato il fallimento dell’auto-regolamentazione, le amministrazioni hanno
regolato il settore approvando leggi per la tutela della privacy. Anche le
le organizzazioni hanno cercato di fornire un livello di protezione adeguata
specificando chiaramente la maniera in cui saranno trattati i dati personali
e come saranno rispettate le leggi specifiche; queste soluzioni dovrebbero
perlomeno aumentare la fiducia degli utenti verso il Web.
Esistono tecnologie e tecniche che gli utenti possono adottare per migliorare la
privacy individuale minacciata dai nuovi fattori tecnologici e economici, l’idea
comune è quella di migliorare la fiducia degli utenti verso il Web attraverso
leggi, strumenti software e definendo delle politiche (policy) comuni e chiare.
Dall’articolo di Hoffmann [DLHP99] si analizzano gli ostacoli esistenti per
la diffusione dell’e-commerce nei primi anni del 2000. L’ostacolo principale
alla diffusione del commercio elettronico è la scarsa percezione di privacy e
fiducia da parte degli utenti.
Le responsabilità di questa percezione negativa da parte degli utenti è tutta
dell’industria che ha ‘maltrattato‘ i consumatori digitali, utilizzando tecniche
senza scrupoli di profilazione e pubblicità. Per questo il 95% degli utenti
del Web è restio a rilasciare informazioni personali, generando una sorta di
resistenza a diffonderle. Il primo passo dunque è guadagnare la fiducia degli
utenti tramite le tecniche elencate: anonimizzazione, legislazione, rispetto
della privacy degli utenti.
1.2
1.2.1
Il Web e la privacy
Web 2.0
Prima dell’analisi dei temi riguardanti il Web 2.0 e la privacy, si introduce
il concetto di Web.
Il World Wide Web è un sistema interconnesso di documenti ipertestuali accessibili da internet.
Tramite un Web-browser, cioè un software per navigare tra gli ipertesti disponibili su internet, si possono visitare e leggere pagine Web che contengono
15
16
testo, video, audio e immagini.
Il Web è uno dei maggiori veicoli di diffusione di informazioni personali; il
numero di utenti del Web è molto esteso, ognuno di questi diffonde dati personali durante la navigazione internet.
Il Web è sempre più orientato al servizio, cioè i siti si sono evoluti verso vere
e proprie applicazioni che offrono un servizio: questi servizi rappresentano
un rischio per la privacy individuale, ma questo aspetto sarà approfondito in
seguito in questa tesi.
Il termine ‘Web 2.0‘ venne coniato da Dale Dougherty (O’Reilly Media, Inc.)
e Craig Cline (Media Live International) durante la preparazione di una conferenza che avrebbero dovuto tenere congiuntamente, nel 2001.
Negli anni il Web 2.0 non ha assunto una definizione precisa: è un insieme
di aspetti comuni che le applicazioni hanno implementato.
In definitiva, è possibile individuare nel concetto di ‘Web 2.0‘ un insieme di
approcci, più o meno nuovi, per usare la rete in modo innovativo.
La definizione ufficiale di Dale Dougherty è:
’il Web 2.0 è la rete intesa come piattaforma, che abbraccia e si estende su
tutti i sistemi ad essa connessi; le applicazioni Web 2.0 sono quelle che riescono a sfruttare i vantaggi di una tale piattaforma: offrendo software come
un servizio sempre aggiornato che migliora all’aumentare del numero di persone che lo usano’.
Da queste parole si intuisce che le applicazioni Web ‘moderne‘ sono vere e
proprie piattaforme tramite le quali gli utenti leggono e creano i contenuti,
gli sviluppatori integrano nelle applicazioni le funzionalità in tempo reale e
sfruttano quelle offerte da altre per mezzo di API pubbliche (openAPI).
Le applicazioni online moderne arricchiscono l’esperienza del visitatore coinvolgendolo e mutando di giorno in giorno.
Le caratteristiche comuni del Web 2.0 sono:
• il design minimale e pulito;
• l’offerta di un servizio che consente di effettuare direttamente online
operazioni per le quali sarebbe normalmente necessario installare dei
software appositi sul proprio computer;
• la gratuità del servizio base (con l’eventuale previsione di servizi avanzati
• la creazione di comunità di utenti in grado di interagire, collaborare,
• l’utilizzo di tecniche di ultima generazione quali XML, CSS e AJAX;
• la disponibilità (per favorire la distribuzione dei contenuti, per consentire la loro pubblicazione su altri siti e per facilitare la realizzazione di
nuovi siti ed applicazioni che sfruttino quel servizio) di RSS, Widget e
API;
• la fase beta che spesso è accostata al nome dell’applicazione, poiché è
in continua evoluzione.
Le funzioni presenti nei servizi Web 2.0 sono: ‘Blog‘, ‘Wiki‘, ‘Tagging‘, ‘Social
Bookmarking‘, ‘Multimedia sharing‘, ‘Audio podcasting‘, ‘RSS syndication‘
e nuove applicazioni e servizi Web 2.0 come ‘Google Documents‘ o ‘Google
Calendar‘ [And07].
1.2.2
La privacy dei servizi basati su Web
In questo paragrafo si illustrano gli aspetti riguardanti la privacy nelle
applicazioni e nei servizi Web 2.0.
La diffusione delle informazioni da sorgenti come i personal computer o i
database pubblici ha subito una crescita notevole negli anni a causa della
massiccia informatizzazione.
Parallelamente alla diffusione delle informazioni sono stati sviluppati strumenti per collezionare e integrare queste informazioni personali. Ad esempio
sono stati sviluppati gli strumenti usati dai motori di ricerca per cercare all’interno di queste informazioni in maniera efficiente.
La collezione e l’analisi dei dati distribuiti sono utili e non rappresentano un
17
18
pericolo se le fonti delle informazioni collezionate, analizzate e ricercate sono
pubbliche.
Ci sono però delle applicazioni che trattano informazioni sensibili e necessitano di dati personali per effettuare ricerca, ma questi dati non sono pubblici
ma strettamente privati: si pensi alla ricerca medica [Boy04].
La ricerca medica tratta informazioni sanitarie sui pazienti considerate altamente riservate, queste informazioni devono essere analizzate dai ricercatori:
• quali sono i rischi per la privacy dei pazienti?
• è il caso di rendere anonimi i dati per preservare la riservatezza degli
individui?
• quali informazioni sensibili i ricercatori possono condividere e con chi?
Queste domande hanno senso sia nel panorama delle applicazioni Web sanitarie, utilizzate nelle strutture sanitari e nelle organizzazioni di ricerca, sia
nel panorama meno critico delle applicazioni Web in generale.
La privacy delle informazioni nei servizi basati su Web coinvolge due attori
principali: il provider dell’applicazione che colleziona i dati e l’utente che li
fornisce direttamente (rispondendo a delle domande o compilando dei moduli) oppure indirettamente (collezionamento implicito delle informazioni).
L’esempio più semplice è quello di un utente che fornisce dati all’applicazione, l’applicazione effettua una computazione e ritorna il risultato all’utente.
I dati sono condivisi tra l’applicazione e l’utente. Questo caso è chiamato
‘2-party‘ cioè sono coinvolti solamente due attori nelle operazioni che riguardano le informazioni sensibili: l’applicazione e l’utente. In questo caso
l’utilizzatore dei dati è anche il fruitore del servizio [Boy04].
Più complesso è lo scenario in cui dati devono essere condivisi con un’altra
entità autorizzata. Questo caso è chiamato ‘3-party‘ e differisce dal caso
precedente perché è presente la terza parte autorizzata ad avere i dati, diversa
dal fornitore del servizio.
Questo caso è il più delicato per la protezione della privacy personale perché
la terza parte può essere non fidata, può cioè essere un’azienda esterna che
utilizza i dati per scopi di marketing.
Dunque lo scenario cambia, e molto, se la fiducia è completa in entrambe
le due parti coinvolte. Se dalla parte dell’utente c’è fiducia sia nel fornitore
dell’applicazione, sia nella terza parte, non c’è un problema di violazione di
privacy.
Se la terza parte è fidata, l’utente deve stare prestare attenzione solo all’uso
improprio dei dati da parte dell’applicazione, ad esempio l’accesso da parte
di altri utenti alle informazioni. Il problema sussiste solo nel caso in cui le
informazioni inserite diventano pubbliche e visualizzabili da chiunque.
La situazione diventa più complessa nel caso di terza parte non fidata, oppure quando non si ha coscienza dell’esistenza di una terza parte: in questo
modo si perde totalmente il controllo dei dati personali.
L’ultimo caso di questo scenario è quello in cui non si ha fiducia nell’applicazione né tanto meno nella terza parte, in questo caso non è possibile utilizzare
l’applicazione e mantenere la privacy personale.
La maggioranza delle applicazioni Web generiche garantisce il rispetto della
privacy delle informazioni personali tramite dei documenti che definiscono
gli attori coinvolti nel trattamento dei dati personali, i dati analizzati e gli
scopi delle analisi dei dati, le ‘privacy policy‘.
1.2.3
Le internet privacy policy
I siti Web, per garantire agli utenti il rispetto della privacy sulle informazioni collezionate, definiscono le loro politiche in materia privacy su documenti che specificano i dettagli del trattamento dei dati: le ‘privacy policy‘.
Le privacy policy sono descrizioni complete delle pratiche che i siti Web
compiono con le informazioni. Spesso sono in un posto visibile e accessibile
dell’applicazione.
Ogni organizzazione coinvolta nelle transazioni online ha la responsabilità di
adottare e implementare una policy per proteggere la privacy delle informazioni personali identificabili chiamate ‘Personally Identifiable Information‘
19
20
(PII). Le PII sono informazioni che possono identificare un individuo, sole o
in combinazione con altre informazioni [AIAS05].
Secondo Anton e Earp [AE01] nel 1999 l’87% degli utilizzatori di internet era
preoccupato dei pericoli che la propria privacy correva durante la navigazione
online.
Gli utenti erano più inclini a fidarsi di un sito che pubblicasse chiaramente
le linee guida sulla privacy, rendendo questo aspetto molto importante. Dagli anni della ricerca di Anton-Earp ad oggi le privacy policy sono diventate
obbligatorie per legge e devono rispondere a ben determinati requisiti.
Nonostante questo gli utenti interessati alla lettura delle policy sono sicuramente una minoranza più sensibile al problema privacy.
La maggioranza di utenti accetta le policy senza un’accurata lettura, ignorando totalmente le tematiche esposte in questa tesi.
Per valutare la bontà di una privacy policy si analizza il raggiungimento degli
obiettivi di tutela e le possibili vulnerabilità della policy, cioè le carenze che
possono generare dei problemi.
Gli obiettivi da raggiungere per esaminare ed approvare una privacy policy
sono:
Notice/Awareness l’obiettivo è informare gli utenti del trattamento dei
dati personali da parte delle organizzazioni prima che le informazioni
siano collezionate;
Choice/Consent l’obiettivo è assicurare ai consumatori l’opzione di decidere quali informazioni personali raccolte su di loro sono usate dall’applicazione e quali sono usate per scopi secondari;
Access/Partecipation obiettivi che permettono o negano l’accesso a un
particolare sito o funzionalità basato sulla volontà di rilasciare alcune
informazioni da parte dell’utente.
Gli obiettivi di questa categoria includono anche la disponibilità delle
informazioni personali per la lettura e la modifica da parte dell’utente
in modo da garantire il controllo totale;
Integrity/Security obiettivi che garantiscono che i dati siano accurati e
sicuri. Gli obiettivi di questa categoria vanno dal semplice dichiarare superficialmente che le informazioni sono collezionate in un modo
sicuro fino al dichiarare specificatamente i protocolli utilizzati per il
trasferimento sicuro;
Enforcement/Redress gli obiettivi sono di definire il meccanismo adottato
per garantire la privacy, le linee guida che l’azienda segue e il modo di
lavorare per garantire la protezione della privacy.
Per individuare le aree carenti nella policy si possono analizzare i punti
che la compongono cercando di evitare vulnerabilità, ponendosi le seguenti
domande:
Information Monitoring (monitoraggio delle informazioni) quali organizzazioni possono tracciare il consumatore con tecniche ad esempio dei
cookie?
Information Aggregation (aggregazione delle informazioni) Chi può aggregare altre informazioni personali con quelle raccolte su questo sito?
Information Storag (salvataggio delle informazioni) quali e quanti dati
sono salvati nei database e in che modo?
Information Transfer (trasferimento delle informazioni) come vengono trasferite le informazioni, perché non possono essere intercettate da altri?
Information Collection (collezionamento delle informazioni) quali e quante informazioni sono collezionate in modo diretto richiedendole all’utente e quali in modo indiretto?
Information Personalization (personalizzazione/profilazione) Quali informazioni sono utilizzate per personalizzazioni? Cosa cambia nell’applicazione, quale aspetto è personalizzato con queste informazioni?
21
22
Contact (contatti) Perché e come le organizzazioni possono contattare gli
utenti utilizzando le loro informazioni personali?
La valutazione delle privacy policy serve a controllare la presenza di errori
o la mancanza di alcune informazioni importanti. Nel caso in cui tutte le
domande hanno risposte chiare la policy analizzata è valida e completa. Nonostante le modalità di controllo e valutazione esposte sopra, inevitabilmente
le privacy policy differiscono di sito in sito.
I siti Web di commercio elettronico hanno delle privacy policy più accurate,
perché necessitano della fiducia degli utenti maggiore, poiché questi devono
inserire dati personali critici come ad esempio i numeri di carta di credito.
Gli obiettivi elencati sopra servono a controllare le policy di tutte le applicazione e siti Web, lasciando un certo grado di personalizzabilità dei dettagli
per essere adattate alle varie realtà: alcune organizzazioni che trattano dati
personali più delicati, applicano gli obiettivi più rigidamente e utilizzano un
alto livello di sicurezza. Altre invece definiscono solo i dettagli necessari e
sufficienti.
Le privacy policy coinvolgono anche il design delle funzionalità dell’applicazione Web per questo esse devono essere definite durante la stesura dei
requisiti funzionali cioè durante la fase di progettazione.
Non presentare agli utenti una privacy policy adeguata rappresenta una violazione della legge che protegge i dati personali, oltre che generare il senso di
sfiducia negli utenti verso l’applicazione [AIAS05].
Una soluzione al problema della mancata lettura o comprensione delle
policy e della grande varietà di policy presenti su internet potrebbe essere
quella di standardizzare le policy [Lan02]. In questo modo si possono sviluppare strumenti che permettono all’utente di definire una volta per tutte
i comportamenti che si vogliono adottare, ad esempio nel browser, per poi
adottarli durante la navigazione Web senza la necessità di lettura e comprensione di ogni singola policy da parte dell’utente.
Uno sforzo comune in questo senso è stato fatto dal consorzio W3C che ha
definito delle specifiche per un protocollo, il P3P, per definire delle pratiche
comuni sia dal lato browser che dal lato server [GR00]. P3P specifica una
sintassi XML per le privacy policy, un protocollo per identificare questi policy sui siti Web e una sintassi compatta per specificare le policy negli header
dei messaggi HTTP.
Lo standard P3P è stato creato per incrementare la comprensione delle policy
dei siti da parte dell’utente, ma anche per automatizzare le scelte dell’utente
dall’interno del browser, senza il bisogno di effettuare un’analisi diretta.
I maggiori portali e browser utilizzato questo protocollo [ECC06].
1.2.4
Social network privacy
I social network sono una categoria di applicazioni Web 2.0 utilizzate per
intrattenere relazioni sociali. Queste applicazioni creano dei veri e propri
collegamenti tra le persone, che possono suddividersi in gruppi in base al
grado di conoscenza personale e all’appartenenza o meno ad alcune correnti
politiche, musicali, lavorative.
Gli utilizzatori di queste applicazioni condividono varie informazioni su se
stessi all’interno dei profili creati per trovare e farsi trovare dagli amici o dai
membri dello stesso gruppo.
Il concetto di ‘amico‘ (friend) è alla base e dei social network. Le persone
iscritte all’applicazione riempiono dei moduli con dei dati personali, da questi
dati è generata una pagina personale, dalla quale possono comunicare con gli
amici. La ricerca di amici, conoscenti e colleghi avviene per parole chiave o
sfogliando i profili e le liste di altri amici.
Gli amici possono essere aggiunti inviando una richiesta alla loro pagina personale.
In questo modo si instaurano le relazioni sociali: con gli amici si può parlare,
mandare messaggi privati e non, giocare, segnalare una foto inserita da altri
ma anche controllare se nelle liste degli amici esistono altri conoscenti da
aggiungere alla propria. Il meccanismo è virale cioè agiungere un amico al
proprio gruppo permette di sfogliare la sua lista di amici; questo permette di
trovare altre amicizie da aggiungere generando un meccanismo a catena.
23
24
Le informazioni nei profili possono essere inserite con una certa granularità
fine, cioè si possono fornire solo le informazioni necessarie all’iscrizione come
si possono indicare tutti i dettagli della propria vita privata inclusi gusti sessuali, musicali e le preferenze.
Le organizzazioni che gestiscono queste applicazioni non specificano chiaramente quali informazioni possono essere omesse senza compromettere il
funzionamento dell’applicazione e spesso gli utenti le ignorano, rispondonendo a tutte le domande presentate. Gli utenti spesso non capiscono che le
informazioni sono pubbliche come comportamento predefinito [TG08].
Questi comportamenti superficiali degli utenti con la complicità anche delle
applicazioni stesse rappresentano il tema principale in materia di internet e
privacy nell’attualità: c’è tutta una serie di problemi e implicazioni generate
dalla condivisione di tutti questi dati personali già aggregati da un’interfaccia comune, pronti a essere ‘rubati‘ e utilizzati per le già citate tecniche di
profilazione e ricerca.
Il caso di Facebook
Di seguito si analizza il caso di Facebook, la più diffusa applicazione social
network, e la privacy.
Facebook è uno dei più diffusi siti di social network, con circa 10 milioni di
utenti, di cui uno solo in Italia. Tutte le informazioni personali concentrate
in un unico sito generano non pochi rischi per la privacy personali degli utenti
che si iscrivono e utilizzano il servizio.
Gli utenti inseriscono informazioni senza avere coscienza della condivisone
pubblica, comprese le aziende che pubblicano annunci pubblicitari su Facebook stesso.
Compagnie di terze parti possono creare dei database basandosi sulle informazioni collezionate da Facebook e poi venderle al miglior offerente [HJ05].
Le informazioni che Facebook colleziona sono di vario tipo e si possono dividere in informazioni ‘in prima persona‘ (first-party) cioè inserite dall’utente
stesso e quelle di ‘terza persona‘ (third-party), cioè informazioni personali
inserite da un soggetto ma riguardanti un’altra persona.
First-party information
Tutti i campi di Facebook possono essere lasciati vuoti, tranne il nome,
email, indirizzo e stato dell’utente (lavoratore/studente/universitario).
Un profilo minimale di Facebook elenca il nome, la data di iscrizione al
servizio, scuola ed email. Ogni altra informazione oltre queste è inserita facoltativamente.
Le informazioni configurabili dall’utente sono divise in categorie e le più interessanti sono sicuramente le ‘privacy settings‘, configurabili dalla pagina
‘My Privacy‘.
Le privacy settings permettono di definire gli aspetti della privacy cioè il
grado di condivisione delle informazioni personali. L’utente deve avere familiarità con l’applicazione per capire a cosa si riferiscono queste opzioni perché
questi aspetti sono specifici e riferiti ad azioni particolari.
Il comportamento di default è quello di condividere tutto.
Facebook è ritenuta un’applicazione all’avanguardia perché permette di controllare la diffusione delle informazioni in maniera molto dettagliata. La
visibilità dei dati può essere abilitata selettivamente per amici, amici di amici, tutti.
Questa possibilità di personalizzazione delle preferenze sulla privacy da un
lato confonde gli utenti che la mole di informazioni controllabili. Troppo spesso questi lasciano i comportamenti predefiniti, che corrispondono al massimo
grado di condivisione, cioè rendere pubbliche tutte le informazioni.
Third-party information
Due funzioni permettono di condividere informazioni inserite da terzi e
sono il ’My Wall’, che permette di tenere un bollettino di messaggi nella pagina personale in cui gli altri utenti possono lasciare messaggi e segnalazioni
e le ’My Photo’ , che permette di segnalare il profilo degli utenti che compaiono nelle foto, senza il consenso di quest’ultimi.
25
26
Queste funzioni sono molto rischiose per la privacy personale perché permettono ad alcune informazioni personali di sfuggire totalmente dal controllo
degli utenti coinvolti: gli utenti sono informati da una notifica della segnalazione in una foto.
Nel caso delle informazioni inserite da terzi (third-party information) la perdita del controllo delle informazioni è totale da parte dell’utente [GAH05].
Gli utenti possono spedire e associare informazioni sulla pagine di altri utenti.
Ad esempio possono spedire foto e marcarle (taggarle) con il nome di chi
figura. Queste informazioni risiedono in una pagina non controllata dal soggetto ritratto nella foto.
Facebook permette all’utente associato nelle foto di dissociarsi: la foto resta
sui server ma l’associazione con il suo profilo viene cancellata.
La possibilità di associare da parte di terzi le informazioni personali su altri
utenti viola uno dei principi chiave della manipolazione delle informazioni
personali: l’idea che solo il proprietario dei dati li possa modificare.
Nonostante Facebook permetta di disassociare l’utente dalle fotografie inserite da altri, questo richiede un costante controllo da parte di quest’ultimo
che viene informato dell’avvenuta associazione con un messaggio, rendendo
necessario un controllo continuo da partedi chi che non vuole essere associato
a nessuna foto.
Una soluzione proposta da questi ricercatori [HJ05] è quella di offrire un’opzione aggiuntiva nella pagina ’My Privacy’ per decidere di disassociare direttamente l’utente dalle foto, senza la supervisione costante.
I ricercatori citati hanno sviluppato uno strumento automatico per la collezione dei dati di studenti di alcuni college americani disponibili pubblicamente
su Facebook.
Su questa collezione hanno compiuto delle ricerche che hanno dato come
risultato:
• il possesso di account personali di Facebook ha una percentuale del
91% per gli studenti
• una considerevole fetta degli utenti analizzati condividono informazioni
identificanti senza limitarne l’accesso agli amici;
• gli utenti più attivi rilasciano più informazioni personali. Le persone
con più di 300 amici hanno specificato circa l’80% delle informazioni
specificabili nel profilo di Facebook;
• una fetta considerevole di utenti (70%) rivelano informazioni demografiche combinate ai propri interessi: in questo modo si creano dei veri e
propri database di informazioni commercialmente valide per le ricerche;
• gli utenti non controllano chi ha la visibilità delle proprie informazioni: non conoscono la pagina ‘My Privacy‘ o lasciano le informazioni
predefinite;
• gli utenti ignorano le privacy policy di Facebook;
Le soluzioni implementabili direttamente da Facebook sono:
• privatizzazione dei profili ‘by default‘ cioè tutte le informazioni devono avere il comportamento predefinito di divulgare le informazioni
solamente agli amici diretti.
• sensibilizzazione degli utenti circa la privacy: Facebook dovrebbe evidenziare che la maggior parte delle informazioni possono essere omesse
o protette.
Nonostante abbia qualche problema in materia, Facebook sembra il leader
delle applicazioni Web 2.0 non solo per numero di iscritti ma anche per le
ampie possibilità di protezione delle informazioni. Solo il tempo deciderà
se l’implementazione delle funzioni ‘salva-privacy‘ saranno implementate nel
software.
27
Capitolo 2
Una soluzione al problema:
Secure Google Documents
2.1
2.1.1
Analisi del problema
Proteggere i dati personali nel browser
Le analisi effettuate in questo enunciato in materia di protezione di privacy hanno concentrato l’attenzione sul browser come veicolo principale di
diffusione delle informazioni sensibili.
Utilizzando un browser si disseminano informazioni in internet sia in modo
diretto, rispondendo a domande o compilando dei moduli, che in modo indiretto, tramite l’identificazione dell’utente.
Le nuove funzionalità introdotte nel Web 2.0 inoltre permettono all’utente
la collaborazione attiva nella stesura dei contenuti che compongono il Web
stesso, generando un nuovo e grave rischio per la privacy delle informazioni.
Esistono molte tecniche per migliorare la privacy degli utenti attraverso il
browser, le meno recenti si concentrano sulla protezione delle informazioni personali che il browser fornisce indirettamente ai server [DMMSB+ 01],
quelle più recenti invece si concentrano sulla privacy dei contenuti pubblicati
soprattutto nelle applicazioni Web 2.0 [ACR07].
29
30
2. Una soluzione al problema: Secure Google Documents
Le tecniche principali per quanto riguarda la protezione dal browser dalla
divulgazione di informazioni sensibili riguardano la modifica delle preferenze
di privacy interne e le estensioni al browser specializzate [JAK03].
Le problematiche principali dunque possono essere distinte tra:
• protezione delle informazioni sensibili sulla navigazione, clickstream,
preferenze indirettamente diffuse dall’utente;
• protezione dei contenuti pubblicati (pubblici e non) nel Web, direttamente sottoscritti dall’utente;
In questo paragrafo si illustrano brevemente le tecniche del primo tipo,
nel prossimo quelle del secondo.
I dati collezionati dalle organizzazioni in maniera indiretta analizzano i percorsi di navigazione e le preferenze, durante la visita dei siti Web; l’utente
non fornisce esplicitamente nessuna informazione ai server, ma i server stessi
con tecniche più o meno legittime effettuano questa raccolta.
Le informazioni private raccolte in questo modo sono ad esempio l’indirizzo
IP e le preferenze salvate nei cookie. Altre informazioni sono catturate da
piccoli script inviati all’utente da terze parti, ad esempio sotto forma di piccole immagini come i Web bugs.
I Web bugs sono immagini prive di contenuto che servono a tracciare l’utente
analizzando il percorso di caricamento delle stesse [KMW07].
I meccanismi di protezione devono aver ben chiara l’idea di cosa proteggere
e l’impatto che questa protezione può avere nell’utilizzo dell’applicazione.
Le tecniche di protezione basate sul browser sono efficaci perché agiscono
direttamente nel punto in cui si generano le richieste delle pagine, all’interno
del browser.
La tecnica più semplice è quella dunque di configurare il browser per non
accettare i cookie, non accettare le immagini e non abilitare l’esecuzione di
codice Javascript.
Questa tecnica spesso non permette l’utilizzo di alcune applicazioni Web poi-
2.1 Analisi del problema
ché esse dipendono fortemente dal Javascript o dalle informazioni salvate nei
cookie.
Le tecniche di protezione configurabili dall’interno dei browser includono:
disabilitazione dei cookie questa tecnica può disabilitare solo i cookie di
terze parti oppure tutti, in modo da limitare i danni nell’utilizzo delle
applicazioni Web;
disabilitazione dell’esecuzione di Javascript non è considerata una vera tecnica di protezione per la privacy ma lo è indirettamente;
Filtraggio degli annunci pubblicitari (ads) questa tecnica non è fornita direttamente ma alcune distribuzioni linux la includono come estensioni pre-installata (Firefox AdBlock Plus). Anche questa è una tecnica che protegge la privacy indirettamente vietando lo scaricamento di
immagini e annunci che tracciano la navigazione.
Disabilitazione del caricamento delle immagini questa tecnica, utilizzata per migliorare le performance di download della pagine Web, può
essere usata anche per evitare l’utilizzo delle tecniche di tracciamento
tramite immagini invisibili (Web-bugs). Alcuni browser permettono il
blocco delle immagini provenienti da terze parti.
Le tecniche appena esposte sono piuttosto estreme e spesso impediscono la
corretta visualizzazione delle pagine Web. Esistono tecniche più evolute e
meno invasive, basate sulla modifica dei dati che il client genera durante la
navigazione, che consistono nell’eliminazione del contenuto fornito alle terze
parti prima che sia divulgato ai server.
Queste tecniche sono simili a quelle esposte sopra ma agiscono in maniera
più silenziosa senza stravolgere le funzionalità e i comportamenti del browser
che le applicazioni si aspettano.
Le opzioni sono:
Filtrare tutti gli oggetti di terze parti permettere di caricare il conte-
31
32
nuto degli oggetti provenienti solo dal dominio in questione e bloccare
tutti gli altri.
Rimuovere il contenuto dei Javascript rimuovere semplicemente il contenuto degli oggetti Javascript.
Filtrare le richieste con URL identificanti alcuni URL sono usati per
passare dei parametri al server. Questi URL contengono caratteri come ’ ?’,’=’,’&’ che possono codificare dei dati pericolosi per la privacy.
Spesso questi dati contengono informazioni utili per la navigazione.
Filtrare gli oggetti dei server aggregatori di informazione questi server sono di proprietà di aziende finalizzate alla ricerca di informazioni personali. Gli oggetti che arrivano da questi server possono essere
direttamente bloccati.
Rimuovere le immagini invisibili (‘Web bugs‘) si possono rifiutare tutte le immagini grandi 1x1 o 2x2 pixel utilizzate per tracciare gli utenti.
Anonimizzare il contenuto dei cookie i cookie possono essere ’svuotati’
dal loro contenuto sensibile.
2.1.2
Privacy e controllo dei contenuti
Si è accennato alle problematiche introdotte dalle applicazioni Web 2.0,
cioè ai problemi di privacy e proprietà delle informazioni sensibili disseminate
nei server che forniscono queste applicazioni.
Il panorama della privacy è cambiato perché non soltanto le informazioni collezionate dai server in modo indiretto rappresentano una minaccia ma anche
documenti come articoli, foto e pagine personali sono salvate tramite applicazioni Web specializzate.
Gli utenti non sempre hanno coscienza della visibilità delle informazioni inserite; è difficile distinguere in questo panorama cioè che è considerato ‘privato‘
da ciò che è considerato ‘pubblico‘, quello che è considerato pubblico è ancora
suddiviso in ‘personale‘ e ’non personale’. [MH07]
Queste nuove possibilità di condividere le informazioni devono essere analizzate per cercare nuove modalità di controllo e limitazione della diffusione
delle informazioni. Le applicazioni Web 2.0 creano un conglomerato di dati
personali che necessitano di nuovi approcci per eseguire dei controlli sull’accesso di questi dati.
Per ‘informazioni private‘ si intendono quelle informazioni considerate tali
dalla legislazione, piuttosto che le informazioni considerate ‘private‘ dagli individui specifici, considerate ‘personali‘.
Ad esempio alcune informazioni generiche come gli indirizzi di residenza e i
numeri di telefono sono considerate informazioni personali identificanti ma
non sono controllate dalla legge come i dati finanziari e medici. Dunque i
primi potranno essere diffusi e utilizzati per scopi interni mentre per il secondo tipo di dati la legge vieta queste pratiche senza il consenso esplicito
dei soggetti.
Quindi le informazioni ‘personali‘, nel Web 2.0, sono quelle informazioni che
l’individuo vuole rivelare soltanto ad alcune persone, o gruppi, che rispondono a un determinato criterio di selezione. Le persone che vogliono controllare
questo tipo di informazioni vorrebbero avere un controllo sulla loro vita virtuale (digital life) simile al controllo che hanno della loro vita reale (analog
life) [MH07].
Dunque dovranno essere sviluppate soluzioni specifiche come ad esempio funzionalità per proteggere i contenuti delle pagine, selezionando accuratamente
da una lista i soggetti a cui dare il permesso di accedere in lettura a queste
informazioni. L’abilità di riuscire a controllare questa tipologia di controllo
di accesso non è essenziale solo nel mondo del Web 2.0 ma determinerà il
successo o il fallimento di molti domini di attività sociali, politici ed economici del Web [Gat07].
Questa nuova forma di controllo necessaria genera nuovi requisiti tecnici riguardanti i meccanismi di controllo di accesso (Access Control Service), che
si vanno ad analizzare.
33
34
Lo studio di un sistema che garantisca queste funzionionalità deve rispondere ai seguenti requisiti:
deve essere basato sulle relazioni l’utente deve controllare il rilascio delle informazioni personali come fa nella vita reale, basando cioè sulla
relazione che ha con il destinatario dell’informazione;
deve essere a grana fine (fine-grained) oltre all’essere basate sulle relazioni, i controlli sugli accessi devono essere configurabili fino a un livello
discreto di dettaglio;
deve garantire interoperabilità le applicazioni Web 2.0 sono diverse e
richiedono un account differente per ognuna di esse, il controllo all’applicazione che si sta utilizzando. Questo meccanismo può essere
implementato sia come un’entità di controllo di accesso i queste ‘access
control list‘ (ACL) per essere utilizzate dalle varie applicazioni o siti.
policy ‘incollate‘ al contenuto (sticky-policy) le policy create seguono
i dati per cui sono definite. Il concetto di sticky policy è introdotto da
Mont [Mon03] e consiste nell’associare le policy a dei dati particolari, in
modo che le policy restino ‘attaccate‘ ai dati per cui sono state definite.
Questa soluzione richiede un alto livello di sicurezza del software e
dell’dware sottostante utilizzando ad esempio un’architettura TCPA.
L’argomento delle ACL (access control list) per il Web 2.0 è trattato in
letteratura anche da un documento [MH07] introdotto con la frase: ‘more
content - less control‘. Questa frase racchiude un po’ il problema principale
con cui ci si è confrontati in questa tesi: il rapporto diretto che esiste tra la
crescita delle informazioni diffuse nel Web 2.0 e la diminuzione del controllo
su di esse da parte dell’autore. t e gli altri hanno esaminato 23 applicazioni
di blogging e social network per misurare il livello di controllo disponibile
delle informazioni.
I siti analizzati comprendono ‘Blogger‘, ‘Facebook‘, ‘Flickr‘, ‘YouTube‘ e
‘MySpace‘, le più diffuse e utilizzate applicazioni Web 2.0.
Da questa analisi è risultato che alcune applicazioni offrono solamente il livello di base di controllo del tipo informazione privata/pubblica; altre sono
basate sul modello di amicizia (friends model), per decidere quali soggetti hanno l’accesso alle informazioni in base all’appartenenza ad un gruppo
di amici, definito dall’utente. Tra le soluzioni disponibili questa soluzione
sembra la migliore perché mantiene un buon equilibrio tra facilità d’uso e
flessibilità.
La necessità del controllo delle informazioni, soprattutto nelle social network,
ha portato a una diffusione maggiore proprio delle applicazioni che hanno più
possibilità di controllo sui dati tramite opzioni configurabili dall’utente.
Nonostante la diffusione del modello basato sulla amicizia, che rappresenta il massimo grado di controllo di accesso alle informazioni già implementato,
esso ha qualche problema; ad esempio non c’è la possibilità di discriminare
all’interno di un gruppo nonostante esistano vari livelli di intimità tra le amicizie. La scelta del numero di ‘amici‘ presenti nella propria lista compiere
una scelta: essere popolare, cioè avere molti amici, o proteggere la propria
privacy, includendo nella lista solo gli amici più stretti [HJ05].
A causa della struttura dinamica e all’assenza di un amministratore, non si
può risolvere facilmente il problema con gli schemi tradizionali di controllo di
accesso, perché sarebbero necessarie una sorta di ’Role-Based Access Control
List’ cioè liste di accesso basate sul ruolo di una persona all’interno di un
gruppo [SCFY96]. Per definire una ‘Role-Based Access Control List‘ si dichiara esplicitamente per ogni utente un gruppo di appartenenza e un ruolo
all’interno del gruppo; l’accesso ad alcune informazioni può essere deciso in
base ai ruoli che le persone hanno nel gruppo.
Il problema principale di questa soluzione è la necessità di un amministratore
che gestisca le liste degli utenti e dei gruppi. Questo spesso non è possibile
nei social network, ad esempio, perché non hanno un amministratore principale che mantiene le liste.
Alcuni ricercatori hanno provato a risolvere questi problemi basandosi su
controlli di accesso basati su attributi e credenziali. Il progetto MaX im-
35
36
plementa questo meccanismo e permette agli autori di inserire un’etichetta
(label) al contenuto generato che il lettore dovrà possedere per avere accesso
al contenuto. Spesso questo attributo è una credenziale crittografica.
Nonostante questo sistema garantisca un buon livello decisionale sulla protezione, in un ambiente distribuito come il Web, questo richiede agli autori
di specificare manualmente le policy di accesso per ogni oggetto, dunque etichettare ogni contenuto e scegliere un segreto che lo protegga.
Una soluzione simile è stata utilizzata per il prototipo sviluppato in questa
ricerca, che protegge il contenuto dei documenti creati e modificati in ‘Google Documents‘ con tecniche crittografiche. Solo gli utenti che possiedono il
segreto accedono al suddetto contenuto.
Lo scopo della ricerca è di creare un sistema usabile dagli utenti ‘non tecnici‘ che supporti i contenuti dinamici dei blogs, social network e siti di
condivisione di informazioni e documenti.
In conclusione le policy di controllo di accesso non sono ancora abbastanza espressive soprattutto nelle applicazioni di tipo social network, le soluzioni
adottate andranno evolvendosi fino al raggiungimento dell’obiettivo di controllo totale dei contenuti ‘postati‘.
Nel prossimo paragrafo si analizzano Google Documents e le informazioni
contenute nei documenti di questa applicazione, la riservatezza di questi e la
soluzione proposta da questa tesi.
2.2
2.2.1
Google Documents
Dal desktop al browser, il software online
Come detto nel precedente paragrafo la soluzione implementata in questa
ricerca è un meccanismo di controllo delle informazioni inserite in Google
Documents.
Google Documents è il tipico esempio di applicazione Web 2.0. Grazie a
questo sito è possibile utilizzare un software di tipo ‘Office‘ direttamente dall’interno di un browser, senza la necessità di installare prodotti e occupare
2.2 Google Documents
spazio su disco [Sal08].
Raggiungibile dall’URL http://www.docs.google.com, l’applicazione si presenta come un repository di file documentali del tipo ’word processor’, fogli
di calcolo e presentazioni.
Dalla pagina principale si possono organizzare i file e ricercare all’interno
degli stessi, aggiungere file dal disco locale dell’utente, salvare file dall’applicazione al disco locale. Naturalmente si possono aprire i file presenti e
modificarli tramite un’interfaccia specializzata, a seconda del tipo di file.
Gli autori modificano i documenti salvati sui repository di Google usando
un editor sviluppato utilizzando la tecnologia AJAX (Asynchronous JavaScript and XML). Gli utenti registrati possono creare documenti e invitare
collaboratori che li possono leggere e modificare. C’è anche una categoria di
utilizzatori che possono solo leggere i documenti e non modificarli, chiamati
‘viewers‘.
Le modifiche al documento sono trasmesse in automatico ai server approssimativamente ogni minuto. Se il server trova un conflitto tra la modifica e lo
stato corrente del documento, ad esempio durante la modifica concorrente di
un documento, lo notifica all’utente.
Inoltre uno storico delle revisioni è mantenuto dal server ed è possibile riportare il documento ad uno stato precedente in qualsiasi momento.
I documenti possono essere esportati dagli autori nei noti formati PDF,
HTML, ODT, ‘Microsoft Word‘ ed altri.
Alcuni ricercatori usano Google Docs per collaborare attivamente alla stesura dei documenti scientifici e in particolare Dekeyser e Stijn [DW07] in
un articolo analizzano i vantaggi e gli svantaggi incontrati nello sviluppo di
documenti tecnici collaborativi tramite questa applicazione. Essi effettuano un confronto delle funzionalità offerte da Google con altre applicazioni
per l’editing collaborativo e definiscono alcuni accorgimenti utilizzati per la
collaborazione. Da questo studio emergono i seguenti piccoli accorgimenti:
• L’editor è basato su HTML, è facile e veloce da usare ma non costruisce
codice XHTML valido;
37
38
• Le funzioni di esportazioni non funzionano egregiamente quando si
esporta nel formato Word o PDF;
• La scrittura di formule e simboli nei documenti non è possibile in Google
Docs;
• La mancanza di un controllo forte sul layout delle pagine, necessario
per la stesura di documenti tecnici. Il layout è controllato tramite un
CSS associato alla pagina;
• e nel caso di esportazioni in PDF o Word è molto difficile controllarne
la resa finale;
Le funzionalità principali mancanti per rendere Google Docs un indispensabile strumento per la stesura di documenti tecnici in maniera collaborativa
sono il supporto per la modifica off-line dei documenti e il supporto a LATEX.
Spesso i ricercatori viaggiano e scrivono i loro documenti in luoghi in cui
non è presente un collegamento a internet, per questo necessitano di strumenti utilizzabili anche senza connessione: questo problema è stato risolto
da Google stesso rilasciando ‘Google Gears‘, uno strumento per utilizzare
le applicazioni di Google senza disporre di una connessione a internet. Al
momento della connessione l’applicazione allinea le versioni online con le versioni sviluppate offline.
L’altra funzionalità mancante è il supporto a LATEX: introducendo uno strumento che permetta di convertire i documenti in LATEXsi risolverebbero i
problemi di layout e si potrebbero adattare i documenti alle formattazioni
richieste dalle istituzioni varie.
Un aspetto negativo minore è dato dal fatto che i documenti risiedono sui
server di Google senza nessuna garanzia che l’accesso sia limitato solo agli
autori: Google li conserva in chiaro sui server, esponendoli ai rischi conosciuti, e con la possibilità che i server stessi effettuino ricerche e statistiche sui
contenuti.
Anche l’utilizzo del browser come editor può risultare limitato rispetto all’utilizzo di versioni più professionali e specializzate.
L’esistenza di API fornite da Google per comunicare con i server permetterà
in futuro lo sviluppo di editor esterni più avanzati che utilizzano Google Documents per tutte le funzioni di salvataggio e modifica collaborativa.
I risultati delle ricerca promuovono comunque Google Documents come strumento collaborativo per la stesura di documenti nonostante siano emersi
questi difetti nell’utilizzo accademico e professionale.
2.2.2
Google Documents Access Control List
I problemi esposti in questa tesi inerenti la privacy e le applicazioni Web
2.0 riguardano Google Docs in maniera evidente: esistono dei meccanismi per
creare delle lista di accesso (ACL), ma i contenuti dei documenti risiedono
sui server, in chiaro.
Nonostante la protezione rappresentata dall’account, i contenuti di documenti sono accessibili dall’interno dei server di Google, e spesso non sono salvati
in una copia locale nella macchina client che li genera, creando un problema
di perdita del controllo delle informazioni personali.
Gli utenti sono più sensibili alla privacy dei documenti personali tipicamente
creati con Google Docs sia perché questi file sono storicamente conservati
nei computer di proprietà dell’autore, sia perché contengono informazioni
riservate che non dovrebbero essere lette, né da amici, né dai server che le
conservano.
I documenti di questo tipo sono principalmente ‘personali‘: oltre a essere
privati, cioè visualizzabili ma di proprietà dell’autore, sono anche riservati,
cioè non visualizzabili da nessuno senza l’approvazione dell’autore.
Per garantire questo Google Documents considera tutti i nuovi file ’privati’,
cioè accessibili solo dall’account del creatore (e da Google stesso naturalmente).
I file privati possono essere resi pubblici trasformandoli in pagine Web HTML:
Google assegna una URL rendendoli disponibili pubblicamente. Questa funzione è utile quando si vuole pubblicare un articolo, senza effettuare altri
passaggi, è sufficiente condividerlo e comunicare agli interessati l’indirizzo
39
40
dove reperire il documento.
Per garantire l’accesso selettivo e la collaborazione, Google implementa un
meccanismo di ’Access Control List’ (ACL) di controllo di accesso tramite
liste. Ogni documento privato può essere condiviso con altri utenti inserendo
le loro email nella lista. L’utente può decidere se condividere il documento
solo in lettura, oppure condividerlo anche in scrittura, abilitando effettivamente l’editing collaborativo sul documento stesso.
Gli utenti con i quali si sono condivisi i documenti possono essere avvisati
tramite email che il documento condiviso si trova all’interno del loro account,
pronto per la modifica o per la lettura.
Il problema che resta in primo piano riguarda la modalità in cui sono
salvate le informazioni: esse viaggiano in chiaro sulla rete, vengono salvate
in chiaro nell’account dell’utente esponendole a rischi. L’account potrebbe
essere violato garantendo l’accesso ai contenuti da parte dell’attaccante e i
contenuti stessi possono essere letti dai server di Google per scopi commerciali o di servizio.
Nel prossimo paragrafo si analizza la soluzione sviluppata dall’autore di
questa tesi per risolvere i problemi sopra esposti.
2.2.3
Google Documents, termini di utilizzo e privacy
Prima di analizzare la soluzione sviluppata si analizzano brevemente i
termini di utilizzo e le pagine dedicate alla privacy in Google Documents.
Nella pagina in appendice [Goo06] Google introduce:
‘The Google Privacy Policy describes how we treat personal information when
you use Google’s services, including information provided to Google Docs. In
addition, the following describes our practices that are specific to Google Doc‘
In questa pagina si specificano brevemente le posizioni di Google per quanto riguarda le informazioni personali, l’utilizzo delle informazioni inserite, le
possibilità dell’utente di cancellazione dei documenti.
Le informazioni personali sono definite in due sotto-paragrafi:
Google Account; per l’utilizzo dei servizi è necessario un Google Account,
con tutte le implicazioni come la registrazione delle attività personali dell’account ‘Similar to other Web services, Google records information such as
account activity (e.g., storage usage, number of log-ins, actions taken), data
displayed or clicked on (e.g., UI elements, links), and other log information
(e.g., browser type, IP address, date and time of access, cookie ID, referrer
URL).‘
Dunque Google può analizzare le attività dell’account, indirizzi IP, dati visualizzati e scelte effettuate tramite click dall’utente.
Contenuti; Google salva, processa e mantiene i contenuti dei documenti
per fornire il servizio. L’utilizzo delle informazioni è definito al solo scopo
interno di garantire il massimo livello di servizio. Le informazioni presenti
in Google Docs possono essere copiate, analizzate e redistribuite da gente
conosciuta e da gente sconosciuta. Sta agli utenti prestare attenzione nel
disseminare informazioni personali.
Il paragrafo finale definisce i diritti dell’utente nell’uso del servizio:
l’utente può terminare in qualsiasi momento l’uso di Google Docs;
l’utente può cancellare permanentemente i file dai server anche se alcune
tracce dei file o delle azioni dell’account sono conservate per tre mesi.
L’appendice A di questo documento mostra la versione originale della Google
Docs privacy policy.
Al seguito dell’analisi di queste informazioni, i contenuti dei documenti
salvati da Google Docs non sembrano molto al sicuro in quanto a riservatezza
dei dati.
Certamente gli utenti non sono autorizzati a visualizzare i file di altri utenti,
ma Google sembra avere troppi poteri su quelle informazioni che dovrebbero
restare private e riservate. Per questo si è sviluppata la soluzione dedicata
per Google Docs, un prototipo che permette la ‘privatizzazione‘ dei file e la
41
42
scelta selettiva di chi è abilitato nella lettura dei contenuti, oltre che alla
visualizzazione, tramite delle semplici tecniche crittografiche.
2.3
2.3.1
Una soluzione: SecureGDocs
La soluzione implementata
I rischi per la privacy e la sicurezza delle informazioni possono impedire
l’utilizzo di uno strumento come Google Documents per i documenti che richiedono una certa confidenzialità.
Si è analizzato il rischio che comporta l’utilizzo di un’applicazione per la gestione, creazione e modifica di documenti del tipo ‘Office‘.
Questi file, classicamente salvati in locale sulla macchina che i software classici da ufficio, sono salvati sui server di Google, in chiaro, esponendoli alle
problematiche esposte nel capitolo precedente.
L’idea di base sulla quale è fondata la soluzione è quella di proteggere le informazioni nei documenti senza cambiare le abitudini di utilizzo della stessa
da parte degli utenti, fornendo appunto una componente aggiuntiva al browser che effettui il lavoro in maniera trasparente.
La privacy e la sicurezza di queste informazioni sono preservate utilizzando
tecniche di crittografia che implementano direttamente le tecniche di controllo di accesso.
La crittografia codifica i contenuti, prima di spedirli verso il server, e li decodifica, nel senso opposto per visualizzarli in maniera leggibile e modificabile
all’utente. Tutte le operazioni sono svolte dal lato client.
Le informazioni sono protette da un algoritmo crittografico simmetrico protetto da una password. L’idea è stata quella di sviluppare uno strumento leggero e integrato nel browser che garantisca confidenzialità dei dati e l’accesso
al contenuto dei documenti solo da utenti autorizzati tramite la condivisione
del segreto condiviso.
Le informazioni nascoste dalla crittografia subiscono un ulteriore livello di sicurezza: esse viaggiano su un canale cifrato (HTTPS), risolvendo i problemi
2.3 Una soluzione: SecureGDocs
di intercettazione dei dati nella rete.
Il nome dell’estensione sviluppata è SecureGdocs (Secure Google Documents).
2.3.2
Caratteristiche di SecureGdocs
SecureGdocs si presenta all’interno di Firefox come una sidebar aggiuntiva, cioè una barra laterale, apribile dal menù delle ‘Sidebar‘ sotto la voce
‘View‘. L’interfaccia principale è suddivisa in due pagine: la pagina relativa
al login nell’account Google e la pagina relativa alla gestione dei file.
Figura 2.1: Schermata di login al servizio
In seguito all’attivazione della sidebar, dal menù di Firefox o dal bottone inserito personalizzando la ‘toolbar‘ principale di Firefox, si visualizza la
pagina del login che richiede le credenziali di accesso e permette di memorizzarle ed accedere alle preferenze del programma.
In caso di login corretto, si visualizza l’interfaccia utente principale che permette la gestione dei file, cifrati e non.
Dal momento dell’accesso all’account di Google il modulo che analizza e cifra
i contenuti è attivato in maniera trasparente. L’utente può aprire i file presenti nell’account e procedere con la modifica tramite l’interfaccia di Google
Documents all’interno della finestra principale del browser.
La soluzione sviluppata crea un livello aggiuntivo che si frappone tra l’utente
43
44
(quindi il browser) e Google, questo livello garantisce le funzionalità crittografiche necessarie alla protezione dei contenuti dei documenti e facilita la
gestione dei file dall’interno dell’estensione utilizzando le API di Google per
effettuare operazioni sugli stessi.
Le funzionalità principale dell’estensione sono:
• login nel servizio di Google Documents;
• visualizzazione dei file contenuti nell’account;
• filtraggio dei file per directory di appartenenza/parole chiave;
• ricerca di testo all’interno dei documenti salvati;
• creazione di file ‘word processor‘, presentazioni, fogli di calcolo, e di file
cifrati da SecureGdocs;
• apertura e modifica dei file cifrati e non cifrati;
Documenti sicuri
La funzionalità principale introdotta da SecureGdocs e non presente nell’applicazione ufficiale di Google è la creazione di documenti sicuri, chiamati
‘Secure Documents‘.
Questo tipo di documenti estendono la tipologia ’Writer’: sono a tutti gli
effetti dei documenti creati e gestiti con il modulo ‘word processor‘ ma differiscono nel nome e nel contenuto dai normali file di testo presenti nell’account.
L’utente visualizza i file cifrati di tipo ‘Secure Documents‘ come normali documenti di testo. Al momento dell’apertura o della creazione di un file cifrato
una finestra richiede la password per poter sbloccare la cifratura dei documenti.
Gli utenti che non possiedono una password valida o che non possiedono lo
strumento SecureGdocs visualizzano i contenuti dei documenti in maniera
cifrata, dunque visualizzano un insieme di caratteri pseudo-casuali. Anche
Google è escluso dalla visualizzazione di queste informazioni perché conserva
nei suoi server la versione cifrata dei file, le modifiche incrementali non vengono salvate e le password di decifratura sono memorizzate solo nel browser
e solo per la durata della sessione.
Il modulo sottostante garantisce la sicurezza del documento tramite queste
funzionalità:
• Interfacciamento dell’applicazione con i server di Google per mezzo
delle Google API;
• Registrazione e modifica delle attività HTTP effettuate dal browser per
individuare le informazioni da cifrare e decifrare;
• Cifratura/decifratura dei file SecureGdocs in maniera trasparente;
Figura 2.2: Visualizzazione di un file non decifrato
2.3.3
Utilizzo di SecureGdocs
L’utilizzo di Secure Google Docs è semplice perché esso assiste l’utente
nelle fasi di creazione, gestione ed apertura dei file di Google Documents,
garantendo la privacy dei documenti sicuri per mezzo di cifratura, senza richiedere particolari interventi.
SecureGdocs introduce un livello aggiuntivo per la sicurezza delle informazioni conservate da Google Documents; permette all’utente di interagire con
i file presenti nell’account e in caso di apertura per la modifica, i file vengono
45
46
aperti nel browser. L’utente utilizza l’estensione per velocizzare la gestione
dei file e per creare quelli sicuri.
Al momento dell’apertura di un file cifrato l’estensione secureGdocs controlla
la presenza di una password, se questa non è stata inserita precedentemente
la richiede all’utente. Le password dei documenti sono salvate nel database
interno di Firefox soltanto per la durata della sessione corrente.
La password di protezione, diversa per ogni file, può essere scambiata tra gli
utenti che condividono un file in modo da garantire la riservatezza assoluta
del contenuto.
La password specifica di un documento può anche essere protetta tramite algoritmi asimmetrici in modo da poterla scambiare in canali non sicuri come
internet.
Questa funzionalità non è ancora integrata all’interno di SecureGdocs ma
rappresenta un sicuro sviluppo futuro dell’applicazione. Si può utilizzare per
adesso un’estensione che svolge questa funzione chiamata FireGPG.
Tramite questo gli utenti possono condividere il segreto per sbloccare un file
SecureGdocs, senza la necessità di scambiarsi le password su un canale non
sicuro, tralasciando questi particolari all’applicazione FireGPG.
Di seguito sono spiegate le funzionalità principali di SecureGdocs:
Login al servizio
Aprire la sidebar di SecureGdocs e inserire le credenziali per l’accesso al
Google Accounts.
Creazione di un file sicuro
La creazione di un file SecureGdocs può essere effettuata dal menu ‘Actions‘ oppure dalla voce situata sopra la lista dei file.
Prima di procedere alla creazione del file, SecureGdocs mostra una finestra
in cui si devono specificare le opzioni per lo stesso: nome del file, password e
bit utilizzati per la cifratura.
Alcune informazioni sono salvate all’interno del nome del file in modo da
garantire l’indipendenza dalla postazione di utilizzo. Le informazioni salvate
nel nome del file sono i bit di cifratura e la presenza di cifratura, rispettivamente concludendo il nome del file con ‘ bit‘ dove bit sono i bit di cifratura
e iniziandolo con ‘SD ‘.
Il nome di un file sicuro sarà del tipo: ‘SD prova 256‘ per indicare che il file
è cifrato, ed è cifrato con crittografia a 256 bit.
Modifica di un file
L’apertura di un file è effettuata selezionando la voce ‘open nella casella
che rappresenta il file, oppure è automatica in seguito alla creazione di un
nuovo file.
Prima di visualizzare il file, se questo è cifrato, si deve specificare la password utilizzata per la cifratura. Il file viene aperto nel browser nella pagina
di Google Documents dedicata alla modifica.
Da questo momento si può modificare e salvare i contenuti del file, che
verranno cifrati e spediti ai server che li immagazzinano.
Condivisione di un file cifrato
Un file cifrato può essere condiviso con gli strumenti messi a disposizione
da Google Documents. L’utente con il quale si condividono apre SecureGdocs nel suo browser e, se conosce la password per il file specifico, lo decifra
per la modifica e la lettura.
Lo scambio della password può essere effettuato di persona o tramite tool
esterni che implementano la crittografia asimmetrica come ad esempio FireGPG.
Visualizzazione dei file non cifrati
SecureGdocs può essere utilizzato anche per creare, modificare, cancellare
i file non cifrati all’interno dell’account, aumentando la versatilità di utilizzo
di Google Documents dal browser.
47
48
Aprendo la sidebar si possono effettuare ricerche rapide e filtrare i file presenti, si possono anche aprire i documenti tramite l’apposito tasto senza caricare
la pagina principale di Google Documents.
In conclusione il programma sviluppato in questa ricerca è indirizzato verso utenti sensibili ai problemi della privacy e interessati all’utilizzo di Google
Documents come strumento per la stesura di documenti importanti.
La soluzione implementata nella sua forma di base potrebbe essere ampliata
per integrare al suo interno molte altre funzionalità correlate di cui si accenna
nei capitoli successivi e nelle conclusioni di questa tesi.
In un contesto dove non è pensabile condividere i documenti interni o personali con un’entità esterna come Google, è necessario l’utilizzo di SecureGdocs per garantire l’accesso selettivo alle informazioni da parte degli utenti,
in modo ma mantenerne il totale controllo risolvendo il problemi introdotti
ad inizio capitolo.
2.3.4
Sicurezza in SecureGDocs
SecureGdocs ha lo scopo principale di garantire la sicurezza dei contenuti
dei file cifrati.
Dal punto di vista della sicurezza dei contenuti, i file vengono cifrati prima di
essere spediti dal browser al server, i testi in chiaro non lasciano la macchina
dell’utente che li ha generati, garantendone la sicurezza. Google Documents
è di fatto escluso dall’accesso dei contenuti in chiaro.
Oltre questo tutte le chiamate alle Google API, dunque tutte le interazioni
con i server sono protette utilizzando il protocollo HTTPS.
Anche le informazioni che SecureGdocs salva nel database interno di Firefox,
’SQLite’, sono trattate in modo da non lasciare tracce nelle macchina in cui
si utilizzano.
I dati memorizzati nel database successivamente al login riguardano i metadati dei file ma non i contenuti.
I meta-dati sono i titoli, la data dall’ultimo accesso, la URL per raggiungerli.
Anche questi e sono salvati nel database solamente fino altermine della ses-
sione o alla chiusura dell’applicazione.
I contenuti sono invece salvati solo nella versione cifrata nei server, e in nessun modo nei client, per evitare di disseminare informazioni in rete o nelle
macchine locali.
Le password per sbloccare la cifratura dei documenti vengono salvate nel
database di Firefox al momento dell’inserimento e cancellate al momento del
‘logout‘ o al momento della chiusura di SecureGdocs.
SecureGdocs garantisce le tre proprietà fondamentali di ogni sistema crittografico: confidenzialità, integrità, accessibilità.
Queste tre proprietà sono cosı̀ definite:
confidenzialità assicurare che l’informazione è accessibile solo dalle persone
autorizzate;
integrità la salvaguardia della accuratezza e della completezza delle informazioni e dei metodi di processo delle stesse;
disponibilità l’assicurazione che sono gli utenti autorizzati hanno accesso
alle informazioni e alle informazioni memorizzate quando richieste;
Quindi la confidenzialità è ‘la proprietà che i dati o le informazioni non
siano disponibili o rivelate a persone non autorizzate‘, l’integrità è ‘la proprietà che i dati e le informazioni non siano alterate o distrutte in maniera
non autorizzata‘ e la disponibilità è ‘la proprietà che i dati e le informazioni
siano accessibili e usabili dopo esplicita richiesta da parte di una persona
autorizzata‘ [RPW05].
Queste proprietà sono garantite per i contenuti dei documenti da un algoritmo simmetrico chiamato AES cioè Advanced Encryption Standard.
Gli algoritmi simmetrici sono quella famiglia di algoritmi crittografici in
cui si utilizza lo stesso segreto per la codifica e decodifica delle informazioni.
Questo segreto è una password che inizializza l’algoritmo di cifratura che
converte il testo in chiaro in testo cifrato e viceversa. Il messaggio uscente
dall’algoritmo di cifratura non è riconducibile al testo in chiaro.
Dunque SecureGdocs non fa altro che sostituire il contenuto del documento
49
50
testuale in contenuto cifrato, tramite una password specificata dall’utente.
La proprietà di confidenzialità è garantita dal fatto che solo gli utenti al
corrente della password specifica per quel documento riescono ad accedere e
leggere il contenuto del documento.
L’integrità del documento è garantita tramite dei delimitatori di inizio e fine
del contenuto cifrato.
Infine la proprietà di disponibilità delle informazioni è garantita dal fatto che
i file sono salvati sui server di Google, dunque sempre disponibili, naturalmente per avere l’accesso di contenuti cifrati si deve disporre dello strumento
SecureGdocs e delle password specifiche per i documenti.
Il problema degli algoritmi simmetrici è la necessità di un canale sicuro per
la comunicazione della password. Questa deve essere scambiata dagli utenti
coinvolti nella condivisione di un file e non sempre questi possono incontrarsi
di persona per assicurarsi che nessun altro intercetti.
Questo problema è stato risolto dalla scoperta degli algoritmi asimmetrici:
attraverso una coppia di chiavi per ogni utente, una pubblica e una privata,
si può cifrare con la chiave pubblica di un utente un’informazione decifrabile
solo dal possessore della chiave privata associata. In questo modo non è necessario l’incontro tra le parti.
L’estensione per Firefox chiamata FireGPG gestisce le chiavi e la cifratura e
decifratura implementando le funzionalità del GPG (GNU PGP).
Il meccanismo della crittografia a chiave asimmetrica può essere utilizzato in
SecureGdocs per scambiare le password dell’algoritmo simmetrico, per adesso attraverso degli strumenti esterni come FireGPG.
L’algoritmo utilizzato per la cifratura del contenuto dei file è del tipo simmetrico perché questi algoritmi sono più semplici e veloci, anche il noto SSL
(Secure Socket Layer) utilizza la velocità dei simmetrici uniti ai vantaggi degli asimmetrici [DW96].
Il prototipo sviluppato non implementa ancora internamente il meccanismo
della crittografia asimmetrica perché essa è piuttosto complessa computazionalmente, dunque si rimanda all’utilizzo di strumenti conosciuti e robusti,
sviluppati e testati per questi scopi.
Nel prossimo capitolo si illustra l’architettura e l’implementazione di SecureGdocs.
51
Capitolo 3
Architettura di SecureGDocs
3.1
3.1.1
Struttura delle directory e dei file
Estensioni per Firefox
In questo capitolo si illustrano le caratteristiche di SecureGdocs e le scelte
progettuali effettuate durante il suo sviluppo.
SecureGdocs è sviluppato come estensione per il browser Mozilla Firefox, in
particolare per la versione 3.0.4 e superiori.
Tutte le applicazioni rilasciate da Mozilla, compreso Firefox, consentono di
estendere le funzionalità di base tramite lo sviluppo di elementi aggiuntivi al
browser, veri e propri software che svolgono i più svariati compiti.
Le estensioni sono sviluppate in Javascript, C++ e XUL: la parte logica,
cioè il codice che implementa le funzionalità dell’applicazione, è sviluppata
in Javascript o C++, la parte riguardante le interfacce è sviluppata in XUL,
un linguaggio XML-based con cui è disegnata anche quella di Mozilla Firefox.
Le applicazioni Mozilla sono composte da componenti indipendenti, chiamati
XPCOM Components, riutilizzabili nel codice delle estensioni.
Le estensioni sono inoltre eseguite con gli stessi privilegi dell’utente che esegue
il browser. Si veda [BB06] e [Huf07] per una breve trattazione delle estensioni
per Firefox.
53
54
3. Architettura di SecureGDocs
La scelta progettuale di sviluppare un’estensione per Mozilla Firefox è
stata motivata dalla licenza open-source del software, dalla possibilità di riutilizzare componenti esistenti e dalla vasta raccolta di estensioni esistenti
complete di codice sorgente.
Le estensioni si presentano sotto forma di file .xpi (si pronuncia zippi) che
non sono altro che file compressi con l’algoritmo .zip.
Per installare un .xpi basta trascinarlo sulla finestra del browser o aprire una
URL che punta ad un file .xpi.
SecureGdocs è sviluppata come estensione di Firefox nella forma di una sidebar, cioè una barra aggiuntiva nel browser con orientamento verticale a
scomparsa.
Il codice con cui è stata sviluppata l’estensione è Javascript, uno dei linguaggi più diffusi visto che è utilizzato massicciamente nelle pagine web, e XUL
(si pronuncia zool), un linguaggio XML-based sviluppato da Mozilla per costruire velocemente le interfacce sul modello di pagine HTML/XML tramite
widget predefiniti.
Nei paragrafi successivi si analizza l’implementazione di SecureGdocs.
3.1.2
Struttura delle directory
La struttura delle directory segue gli standard di Mozilla per la creazione
di estensioni per Firefox. Nella figura si può vedere questa struttura. La
directory principale si chiama ‘segodoc‘ e contiene al suo interno le directory ’chrome’, ’components’ e ’defaults’ oltre ai file necessari all’installazione:
’install.rdf’ e ’chrome.manifest’.
La directory ‘chrome‘ contiene tutti i file disponibili all’estensione e visualizzati nel protocollo ’chrome://’ nel browser, inclusi i file XUL e la logica
dell’applicazione in Javascript.
La directory ‘components‘ contiene i componenti XPCOM utilizzati dall’applicazione.
Anche Firefox, come detto precedentemente, è un insieme sofisticato di componenti orientati al riutilizzo.
3.1 Struttura delle directory e dei file
Figura 3.1: Struttura directory
La directory ‘defaults‘ contiene alcuni file necessari per salvare le preferenze
dell’applicazione.
File d’installazione
I file install.rdf e chrome.manifest invece servono all’installazione e alla
creazione della struttura dei file nel chrome.
Il primo, install.rdf è un file xml dentro il quale si specificano le informazioni
di base. Di seguito si può vedere il codice.
1
< Description about = ‘ urn : mozilla : install - manifest ‘ >
2
 segdoc @gargan o 
4
 secureGdocs Extension 
 1.0 
6
 Secure Google Documents 
 Edoardo Gargano 
55
56
 http :// www . cs . unibo . it 
8
 chrome :// segodoc / skin / segodoc_small . png 
 chrome :// segodoc / content / about . xul 
10
12
<! - - Firefox -->

14
< Description >
16
{ ec8030f7 - c20a -464 f -9 b0e -13 a3a9e97384 } 
18
 3.* 
 3.0.4 
</ Description >

20
22

< Description about = ‘ urn : mozilla : extension : file : segodoc ‘ >
24
 content / 
26
 locale / en - US / 
 skin / classic / 
</ Description >

28
</ Description >
Tra le informazioni principali sull’estensione si notano nome, versione,
creatore, icona predefinita e URL dell’estensione (linea 1-10), ma anche l’id
dell’applicazione per cui è stata creata l’estensione (linea 14-20), in questo
caso Firefox nelle versioni dalla 3.0.4 in poi.
Per ultimo si specificano le directory di contenuto, di aspetto (skin) e di localizzazione (locale).
Il secondo file è ‘chrome.manifest‘. Esso specifica dove posizionare e quali
sono i file del chrome: il chrome è l’insieme di elementi dell’interfaccia utente
dell’applicazione che sono fuori dall’area del contenuto della finestra principale del browser.
Firefox utilizza questo protocollo per definire i percorsi assoluti di questi file.
1
content
2
locale segodoc en - US
4
segodoc chrome / segodoc / content /
chrome / segodoc / locale / en - US /
skin
segodoc classic /1.0 chrome / segodoc / skin / classic /
style
chrome :// global / content / c u s t o m iz e T o o l b a r . xul
chrome :// segodoc / skin / css / toolbar - button . css
overlay chrome :// browser / content / browser . xul
chrome :// segodoc / content / firefoxO verlay . xul
3.1 Struttura delle directory e dei file
Il contenuto (content) dell’applicazione è in chrome/segodoc/content/ (linea 3), i file locale per le localizzazioni in chrome/segodoc/locale/en-US/
(linea 4) e cosı̀ per le altre. Interessante di definizione le linee per definire la
posizione del file ‘overlay‘ (linea 5).
Lo scopo di questo file è la definizione della posizione e della forma che l’estensione prende all’interno della interfaccia utente principale di Firefox.
Nel prossimo paragrafo dedicato ai file XUL si spiega come Firefox aggrega
gli overlays e li integra nella sua interfaccia.
3.1.3
La directory chrome
All’interno della directory chrome c’è la directory ‘segodoc‘ che contiene
le directory ‘content‘, ‘locale‘ e ‘skin‘.
Nella directory content c’è il codice dell’applicazione, sia per quanto riguarda
l’interfaccia, quindi i file XUL necessari a definire la sidebar, sia il codice
Javascript che implementa la logica dell’applicazione.
Nella directory ’skin’ c’è la directory ‘css‘ che contiene i fogli di stile utilizzati
dall’estensione, la directory ‘images‘ che contiene le immagini.
All’interno della directory ‘locale‘ ci sono le localizzazioni dell’estensione, in
questo caso c’è la localizzazione inglese americana in ’locale/en-US’.
In quest’ultima sono definite le stringhe nella lingua inglese all’interno di file
.dtd (Document Type Definition), ereditati direttamente da XML.
La directory principale di tutta l’architettura è ‘content‘ perché contiene il
codice sorgente dell’applicazione.
La directory ‘content‘ contiene al primo livello i file XUL dell’interfaccia e le
directory ‘js‘, ‘templates‘ e ‘usertemplates‘.
La directory templates contiene dei file ‘template‘ (modelli) utilizzati da
una libreria Javascript per velocizzare la creazione di elementi nelle interfacce
XUL.
La directory ‘usertemplates‘ contiene i file ‘template‘ utilizzati per la creazione di nuovi file.
I file template sono stati introdotti da Microsoft Office e sono dei file base
57
58
Figura 3.2: Sottodirectory chrome
che definiscono la struttura di base dei nuovi file creati da SecureGdocs.
Nei prossimi paragrafi si spiega il funzionamento dei file più importanti sia
per quanto riguarda la logica del programma, con i file Javascript, che per
quanto riguarda l’interfaccia utente, definita nei file XUL.
3.2
I file XUL: l’interfaccia utente
3.2.1
I file XUL e l’interfaccia
I file XUL di secureGdocs all’interno della directory content e sono:
firefoxOverlay.xul serve ad aggiungere la sidebar all’overlays di Firefox
secureGdocs.xul è il file XUL principale e disegna il contenuto della sidebar
fileOptions.xul è la finestra pop-up che serve a cambiare le opzioni sui
singoli file
options.xul è la finestra delle preferenze generali
about.xul mostra le informazioni base su secureGdocs
3.2 I file XUL: l’interfaccia utente
Il file firefoxOverlay.xul definisce l’overlay per disegnare la sidebar.
Firefox utilizza la tecnica degli overlay per aggiungere del contenuto aggiuntivo alla sua interfaccia.
Gli ‘overlay‘ sono file XUL che specificano a quale elemento dell’interfaccia
principale aggiungerne il contenuto, ed anche specificano in che forma aggiungere il contenuto dell’estensione ad esempio tramite ‘toolbar‘, ‘sidebar‘
o ‘window‘.
Nel momento in cui Firefox disegna la sua interfaccia principale aggrega tutti
gli overlay in modo da non poter distinguere gli elementi originali da quelli
aggiunti dalle estensioni, permettendo un alto grado di personalizzazione del
browser.
L’elemento principale di questo file è il seguente:
1
2
< broadcas terset id = ‘ mainBroadcasterSet ‘ >
< broadcaster id = ‘ viewSeGoDoc ‘
label = ‘ Secure Google Documents ; ‘
4
autoCheck = ‘ false ‘
type = ‘ checkbox ‘
6
group = ‘ sidebar ‘
sidebarurl = ‘ chrome :// secugdocs / content / secugdocs . xul ‘
8
sidebarTitle = ‘ Secure Google Documents ‘
oncommand = ‘ secugdocs . toggleSidebar () ; ‘ / >
10
</ broadc asterset >
Nel file viene specificata la forma di sidebar che avrà l’estensione (linea 6) e
il percorso del file XUL principale che disegna l’interfaccia principale interna
alla sidebar (linea 7).
Questo URI è specificato come percorso assoluto nel protocollo chrome:
’chrome://secugdocs/content/secugdocs.xul’.
Il protocollo chrome è gestito da Firefox nello stesso modo di altri protocolli
come ’http://’ o ’file://’; inserendo l’URI nel browser si visualizza l’interfaccia dell’estensione all’interno della finestra principale del browser.
Il file ’secugdocs.xul’ è il file decisamente più importante e contiene l’interfaccia principale dell’estensione.
Gli altri file sono meno importanti perché disegnano la pagina delle opzioni
(options.xul), la pagina delle opzioni di cifratura per i file (fileOptions.xul) e
59
60
le informazioni riguardanti il software e l’autore (about.xul).
3.2.2
Il file XUL principale: secugdocs.xul
Secugdocs.xul contiene l’interfaccia utente dell’estensione SecuGdocs.
In questo file si importano i moduli Javascript necessari per eseguire la logica
del programma, cioè i file contenenti le funzioni che saranno collegate alle
azioni dell’interfaccia.
L’importazione è nello stile HTML/XML:
<script type=’application/x-javascript’ src=’js/core/secugdocs.js’>
In questo modo si importa il file principale ’secugdocs.js’ che contiene le funzioni principali.
Dopo aver importato tutti i file Javascript necessari si definiscono due elementi ‘page‘ che disegnano le due schermate principali: il primo disegna
la schermata di login (loginPage), il secondo disegna la schermata di SecureGdocs successiva al login (searchPage), dunque l’interfaccia per gestire i
documenti.
La ’loginPage’ è semplice e rispecchia la classica pagina di login ai servizi di
Google: contiene le aree testuali per l’inserimento di username, password, il
tasto login, il tasto per accedere alle preferenze e l’opzione ‘remember me‘
per salvare le credenziali nel Password Manager.
Dal punto di vista dell’interfaccia questa pagine è molto semplice e si occupa
solo di fornire alla funzione login le credenziali da spedire a Google.
Le azioni sono collegate agli elementi XUL tramite eventi DOM, utilizzati
classicamente nella pagine Web.
Ad esempio il tasto login è collegato al metodo login presente nel file secureGdocs.js in questo modo:
1
< button label = ‘ login ‘ oncommand = ‘ segodoc . login () ; ‘[...]
La searchPage invece definisce l’interfaccia utente principale di secureGdocs con la quale l’utente interagisce con i documenti cifrati e non.
3.3 I file Javascript
Questa interfaccia è piuttosto complessa ed è organizzata nello spazio per
mezzo di box, simili ai tag ’div’ utilizzati da HTML/CSS per definire i layout delle pagine.
I box definiscono le aree in cui è suddivisa l’interfaccia: la parte superiore
contiene i menu a comparsa e il tasto ‘logout‘, la parte centrale contiene le
aree di testo per la ricerca dei file, la parte inferiore contiene la lista dei file
disegnata all’interno di un’area contenente il titolo, la data dell’ultima modifica, il proprietario del file e i vari tasti di azione che si possono effettuare
su questi file.
Figura 3.3: Rappresentazione di un file
Una scelta progettuale è stata quella di non sovraccaricare i file XUL di
codice Javascript: la lista dei file è disegnata dal codice Javascript per mezzo
di una libreria chiamata ’JsTemplateBuilder’; Questa libreria permette di
specificare un file template per disegnare elementi ripetitivi partendo da un
elemento vuoto XUL e un array di oggetti Javascript. Per una trattazione di
questo argomento si rimanda all’appendice B di questo documento.
Tramite questa tecnica viene disegnata la lista file ed il menù per selezionare
delle directory.
3.3
3.3.1
I file Javascript
I file Javascript e la logica
I file Javascript contengono la logica del programma e sono contenuti nella
directory ‘content/js‘.
Il codice Javascript è diviso in moduli logici, cioè in quattro cartelle che
separano i file a seconda del loro ruolo nel software:
61
62
Figura 3.4: Interfaccia utente principale
CORE contiene i file ‘init.js‘, ‘overlay.js‘ e ‘secureGdocs.js‘;
HTTP contiene i file ‘http.js‘, ‘parChanger.js‘ e ‘requestResponse.js‘;
CIPHER contiene il file ‘AESChiper.js‘;
UTILS contiene le librerie esterne ed il file ‘secureGdocsUtils.js‘;
I file Javascript ‘init.js‘ e ‘overlay.js‘ del modulo CORE contengono le funzioni per l’inizializzazione del programma. Il file principale è secureGdocs.js
e contiene tutte le azioni associate all’interfaccia.
I file Javascript del modulo HTTP servono a implementare il meccanismo
che cattura i dati spediti e ricevuti dal browser.
Il file ‘AESChiper.js‘ dentro il modulo cipher contiene l’implementazione dell’algoritmo AES (Advanced Ecnryption Standard) utilizzato per la cifratura.
Nei paragrafi seguenti si analizzano i moduli Javascript.
3.3.2
Modulo CORE
Il modulo CORE è il modulo principale del programma e contiene i file
Javascript ‘init.js‘, ‘overlay.js‘, ‘secureGdocs.js‘.
I primi due file sono utilizzati per inizializzare l’estensione.
Il terzo file, ‘secureGdocs.js‘ , è il file principale del modulo core poiché contiene al suo interno le funzioni ‘init()‘, ‘login()‘ e ‘logout()‘.
La funzione init gestisce le azioni preliminari dell’applicazione: inizializza la
sessione utente, controlla se sono già presenti le credenziali di accesso nello
strumento Password Manager di Firefox ed inizializza gli oggetti principali
utilizzati nel codice.
In caso di pressione del tasto ‘Login‘ nell’interfaccia viene direttamente chiamata la funzione omonima ‘login()‘ che rappresenta il punto di entrata del
flusso di esecuzione.
La funzione ‘logout()‘ invece viene chiamata alla pressione del tasto ‘Logout‘
e rappresenta l’uscita dall’account di Google, invalidando la sessione e visualizzando di nuovo la schermatainiziale.
Il flusso di controllo passa da una funzione all’altra in caso di accesso all’account seguendo questo schema:
-> init -> login
-> loginSuccess
-> startTamper e getFeed
-> savetoDB
-> addFolderMenu
La funzione ‘login()‘ si occupa di spedire al server le credenziali inserite dall’utente; le credenziali sono spedite per mezzo di una chiamata AJAX asincrona
alle API per l’autenticazione di Google, chiamate ‘Authentication API‘, utilizzando il protocollo HTTPS.
SecureGdocs genera le chiamate AJAX tramite la libreria YUI fornita da
Yahoo!, la richiesta è asincrona ed è effettuata al seguente URL:
’https://www.google.com/accounts/ClientLogin’. Il codice che segue specifica il tipo, l’URL e il metodo della richiesta HTTP (linea 2).
Subito dopo si specificano le funzioni da chiamare in caso di successo o fallimento (linea 4-5) e infine si definisce la stringa da inserire come quarto
parametro che deve specificare le credenziali raccolte dalla form di login, il
63
64
nome dell’applicazione per la quale eseguire l’accesso e il tipo di account
(linea 12).
1
YAHOO . util . Connect . asyncRequest ( ‘ POST ‘ , ‘ https : // www . google . com / a c c o u n t s / ClientLogin ‘ ,
{
success : this . loginSuccess ,
2
failure : this . loginFail ,
customevents : {
4
onStart : this . startLoad ,
onComplete : this . completeLoad
6
},
scope : this
8
},
10
‘ Email = ‘ + username + ‘& Passwd = ‘ + password +
‘& service = writely & source = segodoc & accountType = HOSTED \ _OR \ _GOOGLE ‘) ;
Il flusso di controllo del programma in caso di successo nel login passa alla
funzione ‘loginSuccess()‘.
In caso di login corretto Google ritorna una stringa (token) utilizzata per
effettuare le successive chiamate alle API di Google senza compiere di nuovo
il login. Il token di risposta di Google è rappresentato dalla stringa ‘AUTH‘ e
viene utilizzato in ogni successiva chiamata alle API diversa dal login/logout.
La funzione ‘loginSuccess()‘ chiama la funzione ‘getFeed()‘ e la funzione
‘startTamper()‘.
La funzione ‘startTamper()‘ attiva il modulo HTTP che analizza il traffico
Web del browser.
La funzione ‘getFeed()‘ si occupa di scaricare il file ‘feed‘ dall’account Google
Docs. Il file XML dei feed contiene elementi che rappresentano i file, con tutti
i relativi meta-dati. In questo file non è presente il contenuto dei documenti
elencati.
In caso di esito positivo nella richiesta dei feed il controllo passa alla funzione
‘savetoDB()‘.
La funzione ‘savetoDB()‘ effettua il passaggio dei dati dalla forma di file di
feed alla forma di oggetti Javascript, tramite la libreria ObjTree. Inoltre il
contenuto del file feed viene analizzato per estrarre i singoli file con tutti i
meta-dati associati.
Le informazioni contenute in questo file vengono salvate in una tabella del
database interno a Firefox chiamata ‘gdocs‘. Questa tabella è utilizzata per
i successivi accessi alla lista dei file.
Il flusso passa alla funzione ‘createDocs()‘ che si occupa di creare la lista dei
file nell’interfaccia grafica, utilizzando la libreria JsTempalteBuilder.
Questa libreria effettua una conversione da oggetto Javascript ad elementi
XUL, tramite un file template in cui si possono utilizzare costrutti del tipo
‘foreach‘ e ‘if/else‘. In questo modo si velocizza la creazione della lista file
da un array mantenendo pulito il codice Javascript.
Infine il controllo passa alla funzione ‘addFolderMenu()‘ per la generazione
dei menù. La funzione ‘addFolderMenu()‘ aggiunge i due menù a comparsa,
posizionati in alto a destra e in alto a sinistra.
Il primo menù server per selezionare una directory e filtrare i file visualizzando solo quelli presenti nella directory.
Il secondo menù è quello delle Actions tramite il quale si possono creare nuovi
file, aprire la pagina principale di Google Documents nel browser e gestire le
preferenze di secureGdocs.
Queste sono le funzioni principali coinvolte nell’avvio del programma secureGdocs, seguendo questo flusso il programma è pronto ad interagire con
l’utente per la creazione, modifica, cancellazione dei file cifrati e non cifrati.
Nel file secureGdocs.js quindi sono anche presenti tutte le funzioni associate
ad azioni dell’interfaccia grafica come ad esempio ‘open()‘, ‘delete()‘, ‘options()‘.
Nell’esempio successivo si mostra la funzione ‘getFeed()‘.
1
2
getFeed : function () {
......
YAHOO . util . Connect . r e s e t D e f a u l t H e a d e r s () ;
4
YAHOO . util . Connect . initHeader ( ‘ Authorization ‘ , ‘ GoogleLogin auth = ‘ +
this .\ _AUTH ) ;
YAHOO . util . Connect . initHeader ( ‘ Cookie ‘ , ‘‘, false ) ;
6
this .\ _f e ed Co nn e ct io n = YAHOO . util . Connect . asyncRequest ( ‘ GET ‘ ,
‘ https : // docs . google . com / feeds / d o c u m e n t s / private / full ‘ , {
success : this . savetoDB ,
8
failure : this . getFeedFail ,
customevents : {
10
onStart : this . startLoad ,
onComplete : this . completeLoad
65
66
},
12
scope : this
})
14
},
La funzione ‘getFeed()‘ configura l’header delle richieste con il token ‘AUTH‘
di riconoscimento (linea 4). La richiesta è asincrona ed è effettuata tramite
il metodo GET all’URL:
https://docs.google.com/feeds/documents/private/full.
In caso di successo viene chiamata la funzione ‘savetoDB()‘ (linea 7), in caso
di fallimento viene chiamata la funzione ‘getFeedFail()‘ (linea 8).
3.3.3
Modulo HTTP
Il modulo HTTP è formato da tre file: ‘http.js‘, ‘requestResponse.js‘ e
‘parChanger.js‘.
Lo scopo di questo modulo è leggere e modificare i messaggi HTTP generati e ricevuti dal browser, consentendo a secureGdocs di cifrare e decifrare i
messaggi di modifiche dei file verso Google Documents.
Il file ‘http.js‘ è il file principale in cui è definito il metodo ‘startTamper()‘,
chiamato dalla funzione ‘loginSuccess()‘ (si veda paragrafo precedente).
Il metodo ‘startTamper()‘ crea un oggetto ‘Tamper‘ che registra degli osservatori chiamati observer.
Gli observer sono osservatori di eventi che si attivano quando un messaggio
HTTP transita nel browser.
Gli eventi possono essere di modifica della richiesta (modify request) e di
analisi delle risposte HTTP (examine response).
L’analisi e la modifica dei messaggi HTTP è attivata successivamente al login
e disattivata alla chiusura dell’estensione o del browser.
La tecnica per implementare l’analisi dell’HTTP consiste nell’utilizzo delle
interfacce esposte da Firefox, in particolare le interfacce nsIHttpChannel e
nsITraceableChannel.
La gestione delle richieste (request) HTTP è effettuata tramite l’interfaccia
67
‘nsIHttpChannel‘ che rappresenta un ‘canale‘ HTTP.
Le gestione delle risposte (response) HTTP è effettuata tramite l’interfaccia
’nsITraceableChannel’.
Per utilizzare le interfacce HTTP si devono compiere i seguenti passi:
• definire un metodo ‘observe()‘ che ‘osserva‘ e segnala ogni attività
HTTP;
• aggiungere gli observer al servizio ‘observerService‘ tramite il metodo
‘addObserver()‘ specificando per quale tipo di evento si deve avere una
notifica.
Gli eventi per i quali ricevere notifica sono molto numerosi e divisi tipologie.
La tipologia di eventi utilizzata da SecureGdocs è chiamata ‘HTTP requests
observer notifications‘ e riguarda appunto le comunicazioni HTTP.
Le ‘HTTP requests observer notifications‘ sono due:
• http-on-modify-request viene attivata quando una HTTP request viene
generata, il canale è disponibile per modificare la richiesta;
• http-on-examine-response viene attivata quando una HTTP response è
stata ricevuta, gli header della risposta sono disponibili sul canale;
Entrambe le notifiche sono passate al metodo ‘observe()‘ come parametro.
Il metodo ‘startTamper()‘ inizializza alcune variabili e aggiunge il metodo
‘observe()‘ al servizio ‘observerService‘ nel seguente modo:
1
2
var o bs er v er Se rv i ce =
Components . classes [ ‘ @mozilla . org / observer - service ;1 ‘]
. getService ( Components . interfaces . n s I O b s e r v e r S e r v i c e ) ;
4
o bs er ve r Se rv ic e . addObserver ( this , ‘ http - on - modify - request ‘ ,
false ) ;
o bs er ve r Se rv ic e . addObserver ( this , ‘ http - on - examine - response ‘ , false ) ;
All’interno del metodo ‘observe()‘ si definisce il comportamento che il software deve effettuare a seconda del tipo di evento.
Nel codice sottostante si distingue il caso della modifica delle risposte da
quello delle richieste.
68
Nel caso di modifica delle richieste si chiama il metodo ‘onModifyRequest()‘.
Nel caso di modifica delle risposte si crea un oggetto ‘TracingListener‘ e si
aggiunge al listener originale.
1
observe : function ( aSubject , aTopic , aData ) {
aSubject . QueryIn terface ( Components . interfaces . nsIHttp Channel ) ;
2
if ( aTopic == ’ http - on - modify - request ’) {
this . on Mo d if yR eq u es t ( aSubject ) ;
4
} else if ( aTopic == ’ http - on - examine - response ’) {
var newListener = new Tr a ci ng Li s te ne r () ; // n s I T r a c e a b l e C h a n n e l
6
try {
8
aSubject . QueryIn terface ( Components . interfaces . n s I T r a c e a b l e C h a n n e l ) ;
newListener . o r i g i n a l L i s t e n e r =
aSubject . setNewL istener ( newListener ) ;
} catch ( e ) {}
10
}
}
12
}
La compatibilità dell’estensione sviluppata con le versioni uguali o superiori alla 3.0.4 è proprio causata da questa interfaccia: un bug esistente in
questa interfaccia ne ha impedito l’utilizzo fino all’uscita di questa versione
[Odv08].
L’evento http-on-modify-request
Se l’evento è di tipo ‘http-on-modify-request‘ è chiamato il metodo ‘onModifyRequest()‘.
Questo metodo implementa il codice necessario per analizzare i messaggi di
richiesta HTTP generati dal browser.
Lo scopo dell’analisi è quella di estrarre i parametri presenti nei messaggi per
identificare quelli utilizzati da Google Documents per salvare le modifiche al
documento.
L’‘onModifyRequest()‘ istanzia l’oggetto ‘requestResponse‘, che si trova nell’omonimo file sorgente requestResponse.js, che analizza la richiesta HTTP,
leggendone il contenuto, compresi i parametri presenti nell’header della richiesta.
Configurato l’oggetto ‘requestResponse‘ con i dettagli delle richiesta si chiama il metodo ‘startCrypt()‘ contenuto all’interno di ‘parChanger.js‘.
Quest’ultimo file analizza i parametri del messaggio, compresi i dati contenuti nel campo POST della richiesta. Proprio in questo parametro Google
spedisce le modifiche ai file verso i server.
Se vengono riconosciuti i parametri utilizzati da Google Documents per aggiornare il contenuto e provenienti da URL di Google Documents questi parametri vengono estratti e passati alle funzioni di cifratura.
Alla fine di questo capitolo si analizza il funzionamento della codifica/decodifica dei parametri che Google Documents utilizza per comunicare le modifiche
ai documenti.
Il codice seguente mostra il metodo che analizza i parametri e individua il
parametro ‘docContents‘, utilizzato per il salvataggio di tutto il documento.
Questo parametro una volta individuato viene passato alla funzione di cifratura che ritorna il contenuto sotto forma di testo cifrato.
1
2
modifyRequest : function () {
......
if ( dataObj . name == ‘ docContents ‘) {
4
.....
dataObj . value = segodoc . crypt ( dataObj . value , this . uri ) ;
L’evento http-on-examine-response
Se l’evento invece è del secondo tipo, ovvero ‘http-on-examine-response‘,
il comportamento differisce leggermente da quello precedente.
Si crea un oggetto ‘TracingListener‘ tramite le seguenti righe:
1
var newListener = new Tr a ci ng Li s te ne r () ;
2
newListener . o r i g i n a l L i s t e n e r = aSubject . setN ewListen er ( newListener ) ;
Nell’implementazione dell’oggetto ‘TracingListener‘ si definiscono i tre metodi specificati nell’interfaccia:
onDataAvailable che si attiva al passaggio dei dati sul canale;
onStartRequest che si attiva all’inizio della risposta;
69
70
onStopRequest che si attiva al termine della risposta;
Il metodo ‘onDataAvailable()‘ legge i dati disponibili nel canale HTTP e
permette di modificarli prima che essi siano passati al motore di rendering
Gecko di Firefox: è cosı̀ che SecureGdocs gestisce la decifrazione prima di
visualizzare il contenuto dei documenti nella pagina di Google Docs.
Il contenuto cifrato è racchiuso tra 2 identificatori per assicurarsi che sia
interamente passato alla funzione di decifrazione. Il codice sottostante mostra
come nel metodo ‘onDataAvailable()‘ si implementa uno ‘stream‘ in entrata,
da cui si leggono di dati.
I dati sono cifrati nella seconda linea tramite la funzione ‘decrypt()‘ presente
nel file ‘secureGdocs.js‘.
Il risultato della funzione di decifrazione è salvato nella stessa variabile ‘data‘.
In seguito la variabile ‘data‘ viene scritta in uno stream di uscita che passa i
contenuti decifrati al creatore del canale HTTP, in questo caso Firefox stesso,
che li integra e li visualizza nella finestra delbrowser.
1
var data = b i n a r y I n p u t S t r e a m . readBytes ( count ) ;
2
data = segodoc . decrypt ( data , request . URI . asciiSpec ) ;
4
inputStream = storageStream . ne wInputSt ream (0) ;
b i n a r y O u t p u t S t r e a m . writeBytes ( data , data . length ) ;
this . o r i g i n a l L i s t e n e r . o nD a ta Av ai l ab le ( request , context , inputStream , offset ,
count ) ;
3.3.4
Modulo CHIPER
Il modulo CIPHER è formato dal solo file ‘AESChiper.js‘ che implementa
l’Advanced Encryption Standard. Si veda [Dwo01] e [SCO03] per i dettagli
sull’implementazione di AES.
In crittografia, l’Advanced Encryption Standard (AES), conosciuto anche
come Rijndael [Sch95] (benché, più propriamente, AES sia una particolare
implementazione dell’algoritmo Rijndael), è un algoritmo di cifratura a blocchi utilizzato come standard dal governo degli Stati Uniti d’America.
Data la sua sicurezza e le sue specifiche pubbliche è AES prenderà il posto
del suo predecessore, il Data Encryption Standard (DES).
71
AES è stato adottato dalla National Institute of Standards and Technology
(NIST) e dalla US FIPS PUB nel novembre del 2001 dopo 5 anni di studi e
standardizzazioni.
L’algoritmo è stato sviluppato da due crittografi Belgi, Joan Daemen e Vincent Rijmen, che lo hanno presentato al processo di selezione per l’AES con il
nome di ‘Rijndael‘, derivato dai nomi degli inventori. Rijndael, in fiammingo,
si pronuncia approssimativamente ‘rèin-daal‘.
Le funzioni di cifratura e decifratura nell’implementazione utilizzata sono
‘AESEncryptCtr()‘ e ‘AESDecryptCtr()‘.
Esse prendono in input tre parametri:
• il testo da cifrare nel primo caso (plaintext), da decifrare nel secondo
(ciphertext);
• la password per impostare l’algoritmo (password);
• il numero di bit da utilizzare nell’algoritmo (nBits);
1
function AESEncryptCtr ( plaintext , password , nBits ) {}
2
function AESDecryptCtr ( ciphertext , password , nBits ) {}
Queste funzioni effettuano le operazioni necessarie per la suddivisone in blocchi del testo in chiaro e per l’inizializzazione delle chiavi di cifratura.
Entrambe chiamano la funzione Cipher che si occupa delle cifratura dei blocchi di bit.
Le altre funzioni importanti dell’algoritmo sono ‘SubBytes()‘, ‘ShiftRows()‘,
‘MixColumns()‘ e ‘AddRoundKey()‘ che sono utilizzate all’interno di ‘Chiper‘ per le permutazioni dei bit.
L’algoritmo scompone in blocchi i dati in input e vi applica le operazioni sui
bit che permettono alla funzione di essere reversibile.
1
2
function Cipher ( input , w ) {
var Nb = 4;
// main Cipher f u n c t i o n
// block size ( in words ) : no of columns in state ( fixed
at 4 for AES )
var Nr = w . length / Nb - 1; // no of rounds : 1 0 / 1 2 / 1 4 for 128/192/256 - bit
keys
4
72
var state = [[] ,[] ,[] ,[]];
// i n i t i a l i s e 4 xNb byte - array ’ state ’ with
input
6
for ( var i =0; i <4* Nb ; i ++) state [ i %4][ Math . floor ( i /4) ] = input [ i ];
8
state = AddRoundKey ( state , w , 0 , Nb ) ;
for ( var round =1; round < Nr ; round ++) {
10
state = SubBytes ( state , Nb ) ;
12
state = ShiftRows ( state , Nb ) ;
14
state = AddRoundKey ( state , w , round , Nb ) ;
state = MixColumns ( state , Nb ) ;
}
16
state = SubBytes ( state , Nb ) ;
state = ShiftRows ( state , Nb ) ;
18
state = AddRoundKey ( state , w , Nr , Nb ) ;
20
var output = new Array (4* Nb ) ;
// convert state to 1 - d array before
returning
for ( var i =0; i <4* Nb ; i ++) output [ i ] = state [ i %4][ Math . floor ( i /4) ];
22
return output ;
24
}
3.3.5
Modulo UTILS
Il modulo UTILS contiene il file secureGdocsUtils.js, in cui ci sono le
funzioni di utilità come ad esempio la funzione di logging, la funzione di controllo della robustezza delle password, la funzione di generazione di password
casuali. Oltre a questo file il modulo contiene tutte le librerie esterne.
Le librerie esterne sono:
YUI (Yahoo! User Interface) utilizzata per creare le richieste AJAX.
JsTemplateBuilder utilizzata per generare elementi XUL dell’interfaccia
dal codice Javascript;
Behaviour utilizzata per aggiungere eventi Javascript all’interno di dei file
XUL definendo delle regole e assegnandole agli elementi;
ObjTree utilizzata per trasformare file XML in oggetti Javascript di più
facile manipolazione;
Per una più dettagliata descrizione di queste librerie si rimanda all’appendice
B di questo documento.
3.3.6
Intercettazione e crittografia dei contenuti
Per capire come funziona il meccanismo di cifratura e decifratura dei
documenti testuali creati con secureGdocs bisogna spiegare brevemente il
funzionamento di Google Documents.
Google Documents è implementato in parte con codice Javascript eseguito
dal lato client, nel browser, e in parte con codice lato server.
Il codice dal lato client interessante è quello riguardante la modifica dei documenti creati con il modulo ‘Writer‘. Questo codice è nel file ’215317294EditPage.js’.
Le interfacce specifiche per gestire i fogli di calcolo e le presentazioni scaricano
altri file Javascript rispettivamente é ’858654377-trix core.js’ e ’749477615PresentationEditor.js’.
L’applicazione comunica tutte le azioni effettuate nelle interfacce per mezzo
di chiamate AJAX verso i server.
I server interpretano le azioni ricevute ed effettuano le operazioni lato server
come il salvataggio delle modifiche o la creazione di un nuovo file.
Riassumendo il concetto, il lato client implementa l’applicazione nelle sue
funzionalità che riguardano la creazione e le azioni dell’interfaccia, il lato
server si occupa di salvare tutto quello che avviene nel lato client.
SecureGdocs si posiziona su un livello intermedio tra il lato client e il lato
server.
Posizionandosi in quel punto secureGdocs riesce a intercettare i dati salvati
dal lato client prima che siano spediti ai server.
Nel verso opposto secureGdocs riesce a intercettare i contenuti dei documenti
appena sono ricevuti dal browser, ma prima che essi siano visualizzati dallo
stesso. Ricevendo i dati prima della visualizzazione il sfotware riesce a decodificarli in tempo reale.
73
74
In questo modo si riesce a ottenere la crittografia del documento in entrata
e in uscita.
Il salvataggio delle modifiche è effettuato da Google Documents per mezzo di
chiamate AJAX all’URL dell’applicazione in cui le modifiche sono codificate
nel parametro POST. Il campo POST dell’header HTTP contiene una lista
di parametri-valori codificata nella maniera degli URL.
I parametri utilizzati per i salvataggi sono ‘docContents‘, dentro il quale è
codificato tutto il contenuto testuale del documento in forma ‘URL-encoded‘
e ‘delta‘, utilizzato per salvare le modifiche incrementali nei file.
L’applicazione secureGdocs intercetta questi due parametri per mezzo del
modulo HTTP.
Il parametro ‘docContents‘ è cifrato completamente nel suo contenuto testuale.
Il parametro ‘delta‘ specifica il numero del carattere da cui partire con la
modifica, la modifica testuale e un numero di controllo.
//composizione del parametro delta
delta=‘=25 +testo =4‘
//parametro URL-encoded
delta=%3D25%20+testo%20%3D4
Visto che la posizione della modifica non è più quella indicata dal primo
numero del parametro ‘delta‘, poiché dal lato server il documento è salvato in
forma cifrata, questo parametro non può essere più utilizzato per la modifica
dei file.
Per risolvere questo problema si è analizzata la cronologia dei salvataggi
effettuati da Google Documents:
-> creazione file
-> primo salvataggio,
contenuto del file in docContents
-> successivi salvataggi,
modifiche incrementali nel parametro delta
In caso di errore nel salvataggio di una modifica ‘delta‘, tutto il contenuto
del documento viene rispedito dal server al client all’interno di un parametro
docContents, esattamente come se fosse un primo salvataggio.
Si è deciso di sfruttare questa funzionalità annullando il delta, per evitare
che Google riceva le modifiche incrementali, rimuovendo il contenuto testuale
e modificando il codice finale di controllo in modo da forzare l’errore e il
successivo salvataggio tramite il parametro ‘docContents‘.
Creazione del file
-> primo salvataggio (docContents)
-> successivi salvataggi (delta)
-> annullamento del delta
-> errore interno di Google Docs lato server
-> richiesta del contenuto totale (docContents)
-> salvataggio tramite docContents}.
Nessun contenuto testuale in questo modo arriva a Google in forma di testo in
chiaro, garantendo la confidenzialità dei contenuti e introducendo finalmente
un livello accettabile di privacy durante l’utilizzo dell’applicazione Google
Documents.
Gli altri dati spediti verso l’applicazione sono cifrati dal protocollo HTTPS,
evitando attacchi di intercettazione delle credenziali o delle azioni effettuate
sui file.
Per adesso l’applicazione SecureGdocs funziona per Google Documents,
uno dei possibili sviluppi futuri potrebbe essere la gestione interna della crittografia asimmetrica, in modo da riuscire a condividere dei file cifrati senza
bisogno di comunicarsi il segreto, ma anche l’adattamento di questo schema
di cifratura a qualsiasi altra applicazione Web 2.0 che salva contenuti generati dagli utenti tramite parametri nel campo POST.
Gli utenti potrebbero condividere una password comune e cifrare gli articoli
di un blog tramite questo strumento adattato al caso specifico, in modo da
assicurarsi che gli articoli siano letti solo dagli utenti autorizzati (possessori
della password).
Inoltre si potrebbe definire lo schema di cifratura/decifratura in file di configurazione, in modo da rendere l’estensione adattabile per altre applicazioni
Web.
75
Conclusioni
In questo lavoro di tesi sono stati analizzati i problemi di privacy delle
informazioni personali nel mondo del Web.
Negli anni novanta la questione era limitata alla navigazione del Web ed al
controllo degli utenti finalizzato a collezionare dati personali e abitudini di
consumo.
Le tecnologie invasive e la mancanza di un adeguato rispetto della privacy
hanno fatto si che la fiducia degli utenti nei confronti di internet iniziasse a
venire meno.
Con l’avvento del Web 2.0 e delle applicazioni che ne fanno parte, caratterizzate dal fatto che gli utenti possono partecipare attivamente alla stesura
dei contenuti, ai problemi si è aggiunto quello della perdita delle proprietà.
Questo problema assume diversi aspetti e dipende dal tipo di applicazione
Web 2.0 e dal tipo di informazioni che vi si sottoscrive.
Si è proposta in questa tesi una soluzione al problema specifico della mancanza di riservatezza nei documenti creati e gestiti con Google Documents.
Questi documenti sono mantenuti da Google, che può accedere al loro contenuto.
Al fine di risolvere questo problema della riservatezza si è sviluppato uno
strumento apposito, come risultato di questa tesi.
SecureGdocs, lo strumento sviluppato come estensione al browser Firefox,
utilizza la crittografia per mantenere la riservatezza dei contenuti dei documenti scritti e conservati su Google Documents. L’applicazione si occupa di
gestire i file del modulo ‘Writer‘ dell’applicazione di Google utilizzando la
77
78
CONCLUSIONI
crittografia simmetrica per gestire tramite password la crittografia nei documenti.
Il concetto di SecureGdocs potrebbe essere esteso agli altri software componenti di Google Documents ma anche ad applicazioni simili che svolgono le
stesse funzionalità.
La carenza attuale di SecureGdocs è la gestione dello scambio sicuro delle
password di cifratura. Le password possono essere scambiate utilizzando delle applicazioni esterne che permettono lo scambio sicuro, tipicamente tramite
un algoritmo di cifratura asimmetrico. Ad esempio l’estensione per Firefox
FireGPG implementa tutto il necessario per fare questo.
In futuro si potrebbero implementare internamente le funzionalità di condivisione dei documenti, tramite le API di Google, all’interno di SecureGdocs, si
potrebbe implementare anche la gestione degli algoritmi asimmetrici per utilizzare le chiavi pubbliche e private per cifrare i documenti. Una interessante
funzionalità potrebbe essere inoltre la possibilità di firmare digitalmente i
documenti.
Un altro sviluppo futuro dell’applicazione può essere la configurabilità totale
della stessa per permettere agli utenti di adattare il meccanismo di protezione
della privacy anche per altre applicazioni Web 2.0: ad esempio un autore può
cifrare ad esempio un articolo del suo blog e distribuire la password solo ad
alcuni utenti, oppure un utente potrebbe cifrare delle informazioni sensibili
inserite nei social network e distribuire la password solo ad alcuni membri
del suo gruppo di amici.
Le idee sono interessanti e gli argomenti sono attuali ed ancora in fase di
studio, in futuro probabilmente si assisterà alla nascita di varie applicazioni
simili a questa per imporre, dal lato utente, la protezione della riservatezza
delle informazioni personali e dei contenuti.
Appendice A
Google Docs Privacy Policy
http://www.google.com/google-d-s/privacy.html
October 11, 2006
The Google Privacy Policy describes how we treat personal information
when you use Google’s services, including information provided to Google
Docs. In addition, the following describes our practices that are specific to
Google Docs.
A.1
Personal Information
1. Account activity. You need a Google Account to use Google Docs.
Google asks for some personal information when you create a Google
Account, including your email address and a password, which is used
to protect your account from unauthorized access. Google’s servers automatically record certain information about your use of Google Docs.
Similar to other web services, Google records information such as account activity (e.g., storage usage, number of log-ins, actions taken),
data displayed or clicked on (e.g., UI elements, links), and other log
79
80
A. Google Docs Privacy Policy
information (e.g., browser type, IP address, date and time of access,
cookie ID, referrer URL).
2. Content. Google Docs stores, processes and maintains your documents
and previous versions of those documents in order to provide the service
to you.
A.2
Uses
1. We use this information internally to deliver the best possible service to
you, such as improving the Google Docs user interface and maintaining
a consistent and reliable user experience.
2. Files you create with Google Docs may, if you choose, be read, copied,
used and redistributed by people you know or, again if you choose,
by people you do not know. Information you disclose using the chat
function of Google Docs may be read, copied, used and redistributed
by people participating in the chat. Use care when including sensitive
personal information in documents you share or in chat sessions, such as
social security numbers, financial account information, home addresses
or phone numbers.
A.3
Your choices
1. You may terminate your use of Google Docs at any time.
2. You may permanently delete any files you create in Google Docs. Because of the way we maintain this service, residual copies of your files
and other information associated with your account may remain on our
servers for three weeks.
A.4 More information
A.4
More information
Google adheres to the U.S. Safe Harbor privacy principles. For more
information about the Safe Harbor framework or our registration, see the
Department of Commerce’s web site.
Further information about Google Docs is available here.
For more information about our privacy practices, go to the full privacy
policy. For questions concerning the product or your account, please check
out the Google Help page.
R
2008
Google
81
82
A. Google Docs Privacy Policy
Appendice B
Librerie esterne
YUI Le librerie YUI (Yahoo! User Interface) sono un insieme di utility Javascript per creare applicazioni web interattive usando tecniche come
lo scripting DOM, DHTML e le chiamate AJAX. Tutte le componenti
di YUI sono coperte da licenza BSD e sono naturalmente fornite da Yahoo!. SecureGdocs utilizza queste librerie per creare, inviare e ricevere
le risposte dalle chiamate AJAX che comunicano con le Google API.
JsTemplateBuilder Questa libreria, creata da Disruptive Innovations, è
utilizzata per creare alcuni elementi dell’interfaccia XUL. Il metodo
tradizionale per creari nuovi elementi DOM da aggiungere all’interfaccia è quello di utilizzare i metodi ’document.createElement’ e ’setAttribute’. Se si hanno molti dati a disposizione e il codice diventa molto
complesso JSTemplateBuilder semplica il lavoro del programmatore:
la libreria prende un oggetto Javascript, un elemento DOM e un file
template. I vantaggi sono nei file template, che supportano gli elementi
XUL ma anche costrutti come il foreach. secureGdocs utilizza questa
libreria per riempire la lista dei file e delle directory. Si specifica il file
template tramite il metodo ’loadTemplate’,
this._jstpl = new jsTemplateBuilder();
Si assegna l’array dal quale creare gli elementi XUL
83
84
B. Librerie esterne
this._jstpl.assign("results", []);
E infine si costruisce l’interfaccia, specificando come secondo parametro
l’elemento XUL dentro al quale creare gli elementi:
this._jstpl.build("list.tpl", "searchResultsBox", true);
Il metodo build effettua le operazioni finali di inserimento:
this._jstpl.loadTemplate("templates/list.tpl");
Behaviour Behavoiur è una libreria Javascript creata da Ben Nolan. Essa
permette di semplificare il codice HTML inserendo i comportamenti del
DOM (behaviour) in regole esterne ai file HTML/XML/XUL, in modo
da tenerne pulito il codice. Piuttosto che inserire i comportamenti degli
elementi dentro agli stessi, in questo modo:
<a href="#" onclick="alert(’This alert box has been badly
generated by an inline event handler.’)">
This link element opens
up an alert box</a>
Si creano delle regole interne al codice Javascript che in seguito si
assegnano agli elementi legittimi tramite DOM:
var rulelink={
’a’ : function(element){
element.onclick = function(){
alert(’This event handler has been assigned via the
Behaviour library.’);
}
}
};
Behaviour.register(rulelink);
85
Infine la regola va registrata tramite in metodo ‘register‘ secureGdocs utilizza questa libreria per inserire alcuni ‘comportamenti‘ dell’interfaccia che altrimenti andrebbero a pesare direttamente nel codice
XUL.
Objtree ObjTree è un parser che trasforma il codice XML in oggetto Javascript di più facile manipolazione. É utilizzato da secureGdocs per
analizzare il file XML dei feeds e renderlo un oggetto Javascript dal
quale poi estrarre tutte le informazioni sui file.
Bibliografia
[ACR07] Corin Pitcher Andrew Cirillo, Radha Jagadeesan and James
Riely. Formal methods for web 2.0 security protocols - position paper. Technical report, IEEE Technical Committee on
Security and Privacy, 2007.
[Adl05] Steven Adler. Webos: say goodbye to desktop applications.
netWorker, 9(4):18–26, December 2005.
[AE01] Annie I. Anton and Julia B. Earp. A taxonomy for web site
privacy requirements. Technical report, North Carolina State
University at Raleigh, 2001.
[AIAS05] Lynda Aiman-Smith Annie I. Anton, Julia B. Earp and William H. Stufflebeam. Examining internet privacy policies within the context of user privacy values. IEEE transaction on
engineering management, Vol. 52, No. 2, 2005.
[And07] Paul Anderson. What is web 2.0? ideas, technologies and
implications for education. Technical Report JISC Technology and Standards Watch, Feb. 2007, JISC Technology and
Standards Watch, 2007.
[BB06] Annette Bailey and Godmar Back. Libx - a firefox extension
for enhanced library access. Library Hi Tech, 24(2):290–304,
2006.
87
88
BIBLIOGRAFIA
[Boy04] Claus Boyens.
Privacy trade-offs in web-based services.
Dissertation, Humboldt-Universitat zu Berlin, 2004.
[Cla88] Roger A. Clarke. Informatione tecnology and dataveillance.
Communications of the ACM Volume 31, No. 5, 1988.
[Cla99] Roger A. Clarke. Internet privacy concerns confirm the case
for intervention. Communications of the ACM Vol. 42, No.
2, 1999.
[DLHP99] Thomas P. Novak Donna L. Hoffman and Marcos Peralta.
Building consumer trust online. Communications of the ACM
Vol. 42, No. 4, 1999.
[DMMSB+ 01] Jr. David M. Martin, Richard M. Smith, Michael Brittain,
Ivan Fetch, and Hailin Wu. The privacy practices of web
browser extensions. Commun. ACM, 44(2):45–50, 2001.
[DW96] Bruce Schneider David Wagner. Analysis of the ssl 3.0 protocol. Technical report, Proceedings of the Second USENIX
Workshop on electionic commerce, 1996.
[DW07] Stijn Dekeyser and Richard Watson. Extending google docs
to collaborate on research papers.
Technical report, The
University of Southern Queensland, Australia, Australia,
2007.
[Dwo01] Morris Dworkin. Recommendation for block cipher modes of
operation. Technical report, NIST Special Publication 80038A 2001 Edition, 2001.
[ECC06] Serge Egelman, Lorrie Faith Cranor, and Abdur Chowdhury. An analysis of p3p-enabled web sites among top-20 search results. In ICEC ’06: Proceedings of the 8th international conference on Electronic commerce, pages 197–207. ACM,
2006.
BIBLIOGRAFIA
89
[GAH05] Ralph Gross, Alessandro Acquisti, and John H. Heinz. Information revelation and privacy in online social networks.
In WPES ’05: Proceedings of the 2005 ACM workshop on
Privacy in the electronic society, pages 71–80. ACM Press,
2005.
[Gat07] Dr. Carrie E. Gates. Access control requirements for web
2.0 security and privacy. Technical report, IEEE Technical
Committee on Security and Privacy, 2007.
[Goo06] Google. Google docs privacy policy. Google Website, 2006.
http://www.google.com/google-d-s/privacy.html.
[GR00] Rudiger Grimm and Alexander Rossnagel. Can p3p help to
protect privacy worldwide?
In MULTIMEDIA ’00: Pro-
ceedings of the 2000 ACM workshops on Multimedia, pages
157–160. ACM, 2000.
[GV07] Stephan Hagemann Gottfried Vossen. From version 1.0 to
version 2.0: A brief history of the web. ERCIS Working Paper
No. 4, 2007.
[HJ05] Jos Hiram Soltren Harvey Jones.
privacy.
Facebook: Threats to
Project MAC: MIT Project on Mathematics and
Computing, 2005.
[Huf07] Justin Huff. Building firefox extensions. Linux J., 2007(160):8,
2007.
[HWW98] Matthew K.O. Lee Huaiqing Wang and Chen Wang.
Consumer privacy concerns about internet marketing.
Communications of the ACM Vol. 41, No. 3, 1998.
[JAK03] Stefanos Gritzalis John Argyrakis and Chris Kioulafas. Privacy enhancing technologies:
A review.
Government, pages 281–288. Springer, 2003.
In Electronic
90
BIBLIOGRAFIA
[KMW07] Balachander Krishnamurthy,
Delfina Malandrino,
and
Craig E. Wills. Measuring privacy loss and the impact of
privacy protection in web browsing. In SOUPS ’07: Proceedings of the 3rd symposium on Usable privacy and security,
pages 52–63. ACM, 2007.
[Kob07] Alfred Kobsa. Privacy-enhanced web personalization. In Lecture Notes in Computer Science, pages 628–670. Springer,
2007.
[Lan02] Marc Langheinrich. A privacy awareness system for ubiquitous computing environments. In UbiComp 2002: Ubiquitous
Computing, pages 315–320. Springer, 2002.
[MH07] Amanda Stent Michael Hart, Rob Johnson. More content less control: Access control in the web 2.0. Technical report,
IEEE Technical Committee on Security and Privacy, 2007.
[Mon03] S. Bramhall Mont, M.C. Pearson. Towards accountable management of identity and privacy: sticky policies and enforceable
tracing services. In Database and Expert Systems Applications, 2003. Proceedings. 14th International Workshop, pages
377–382. ACM, 2003.
[Odv08] Jan Odvarko.
nsitraceablechannel, intercept http traffic.
Software is hard, 2008.
[RPW05] Randall C. Reid, Richard G. Platt, and June Wei. A teaching
module to introduce encryption for web users. In InfoSecCD
’05: Proceedings of the 2nd annual conference on Information
security curriculum development, pages 60–65, New York, NY,
USA, 2005. ACM.
[Sal08] Mika Salminen. From desktop to browser platform: Office ap-
BIBLIOGRAFIA
91
plication suite with ajax. Technical report, Helsinki University
of Technology, 2008.
[SCFY96] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman.
Role-based access control models. Computer, 29(2):38–47,
1996.
[Sch95] Bruce Schneier. Applied Cryptography: Protocols, Algorithms,
and Source Code in C, Second Edition. Wiley, 1995.
[Sch04] Bruce Schneier.
Secrets and Lies : Digital Security in a
Networked World. Wiley, 2004.
[SCO03] Harold Johnson Stanley Chow, Philip Eisen and Paul C. Van
Oorschot. White-box cryptography and an aes implementation. In Selected Areas in Cryptography, pages 250–270.
Springer Berlin / Heidelberg, 2003.
[TG08] E. Michael Maximilien Tyrone Grandison. Towards privacy
propagation in the social web. Technical report, IBM Almaden
Research Center, San Jose, CA 95120, USA, 2008.

Omnia in Mensura et Numero et Pondere (Sapienza 11,20)

Transcript

Documenti analoghi

Associazione KI NO KENKYUKAI Italia

Lampkin con Gas Gas trionfano alla SSDT

Recensione - Consumatori Diritti Mercato

5E programma svolto 2014-15 - progetti

Opzioni della Schermata di scelta del browser

Programma Corso SEO

Privacy Policy. - Gigliola Sfreddo

Goggle Cloud Print

diritto all`oblio

Google Books, o di Alessandria d`Egitto ai tempi della