Omnia in Mensura
et Numero
et Pondere
(Sapienza 11,20)
Indice
Introduzione 1
1 La Privacy e il Web 7
1.1 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
1.2 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 29
2.1 Analisi del problema . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1 Proteggere i dati personali nel browser . . . . . . . . . 29
2.1.2 Privacy e controllo dei contenuti . . . . . . . . . . . . . 32
2.2 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
2.3 Una soluzione: SecureGDocs . . . . . . . . . . . . . . . . . . . 42
2.3.1 La soluzione implementata . . . . . . . . . . . . . . . . 42
3
4 INDICE
2.3.2 Caratteristiche di SecureGdocs . . . . . . . . . . . . . 43
2.3.3 Utilizzo di SecureGdocs . . . . . . . . . . . . . . . . . 45
2.3.4 Sicurezza in SecureGDocs . . . . . . . . . . . . . . . . 48
3 Architettura di SecureGDocs 53
3.1 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
3.2 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
3.3 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 nel-
le 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 per-
sonali specificando dati demografici uniti a preferenze di consumo, ma anche
dalle applicazioni Web, che stanno sostituendo le applicazioni installate local-
mente 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 condi-
visi con altri utenti solo se inseriti volontariamente nella lista di condivisione
dal proprietario stesso.
Nonostante questo, i documenti privati non condivisi, non rispettano la pro-
prieta 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 prote-
1
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 risol-
va 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 ma-
niera 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 Presenta-
tions 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 asim-
metrici in modo da fornire direttamente nell’applicazione un canale sicuro
per lo scambio delle password: l’algoritmo utilizzato potrebbe essere un ibri-
Introduzione 3
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 informa-
zioni 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 accessi-
bili.
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 an-
cora 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
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 sosti-
tutive 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 sal-
varne 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 abi-
tudini 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 uten-
ti/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 5
Gli utenti possono utilizzare strumenti sviluppati ad-hoc per la protezio-
ne 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 sal-
vati 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 im-
plementata una soluzione chiamata SecureGdocs.
SecureGdocs e una estensione (extension) al browser Mozilla Firefox.
SecureGdocs si apre come ‘sidebar‘ nel browser: l’utente utilizza Google Do-
cuments 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, quan-
do 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 crittogra-
fia, 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
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 con-
sentire 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 adat-
tata secondo le esigenze direttamente dagli utenti.
L’aspetto piu importante di questo approccio e che esso e totalmente user-
based: 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 La privacy
1.1.1 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 gran-
de 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 infor-
mazioni 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 assottiglia-
7
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 potenzia-
lita.
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 perso-
nale 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 governati-
ve 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, rispettiva-
mente 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 inviola-
bili dell’uomo.
1.1 La privacy 9
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 per-
sonali.
In questo senso si parla di privacy come ‘autodeterminazione e sovranita su
di se‘ (Stefano Rodota) e ‘diritto a essere io‘ (Giuseppe Fortunato), ricono-
scersi parte attiva e non passiva di un sistema in evoluzione, che deve portare
necessariamente ad un diverso rapporto con le istituzioni, declinato attraver-
so 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 elet-
tronica
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 in-
formazioni 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.
10 1. La Privacy e il Web
La forma base di sorveglianza e quella fisica (visiva e uditiva): il monito-
raggio di un individuo puo avvenire tramite l’utilizzo di immagini satellitari,
telecamere, amplificatori di suono e microfoni, sia in maniera locale che re-
mota.
Nuovi metodi hanno facilitato ed aumentato la sorveglianza personale e di
massa, richiedendo contromisure piu efficaci, introducendo il termine ‘sorve-
glianza 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 monito-
raggio 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 indivi-
dui 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 pro-
cessi 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 azien-
dali 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 svilup-
pato 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 11
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 computa-
zionale, 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 incremen-
tato il problema della sorveglianza di massa: tramite nuovi strumenti e di-
ventato piu facile controllare un gruppo di individui piuttosto che uno solo.
La sorveglianza di massa utilizza le stesse tecniche utilizzate per la sorveglian-
za 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 ob-
bligate a giustificarne l’utilizzo.
I pericoli invece della sorveglianza personale sono dati dagli schemi di iden-
tificazione che classificano gli individui, schemi che sono pero soggetti ad
errori.
12 1. La Privacy e il Web
L’esempio concreto e recente puo essere dato dalla lista americana denomi-
nata ’no-fly list’.
In questa lista sono elencati centinaia di migliaia di passeggeri che non posso-
no volare per rischi riguardanti il terrorismo: i cittadini non possono control-
lare 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 vie-
tare i voli ai passeggeri che compaiono nell’elenco.
Esistono pero dei casi di omonimia o di semplici errori al momento della re-
dazione 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’uti-
lizzo improprio dei dati.
Questi problemi sollevati da Clarke mettono in evidenza la necessita di occu-
parsi 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 com-
plessi 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 13
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 organiz-
zazioni.
Il termine ‘spazio personale‘ e multidimensionale e fa riferimento contem-
poraneamente 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 colle-
zionano grandi quantita di dati individuali; i profili individuali collezionano
informazioni su ogni individuo influenzando il suo comportamento e riducen-
do la sua liberta.
Il marketing e le tecnologie hanno generato la tendenza a convertire le azio-
ni 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 miglio-
rata 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 mi-
gliore 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 ri-
guardano l’invasione della privacy personale correlate alla crescita di internet
e alle attivita di marketing svolte su internet:
14 1. La Privacy e il Web
• 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 informa-
zioni 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 or-
ganizzazioni 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 15
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 Il Web e la privacy
1.2.1 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 ac-
cessibili da internet.
Tramite un Web-browser, cioe un software per navigare tra gli ipertesti di-
sponibili su internet, si possono visitare e leggere pagine Web che contengono
16 1. La Privacy e il Web
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 per-
sonali 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 con-
ferenza 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 rie-
scono a sfruttare i vantaggi di una tale piattaforma: offrendo software come
un servizio sempre aggiornato che migliora all’aumentare del numero di per-
sone 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 coin-
volgendolo 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
1.2 Il Web e la privacy 17
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 avan-
zati
• 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 consen-
tire 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 stru-
menti per collezionare e integrare queste informazioni personali. Ad esempio
sono stati sviluppati gli strumenti usati dai motori di ricerca per cercare al-
l’interno di queste informazioni in maniera efficiente.
La collezione e l’analisi dei dati distribuiti sono utili e non rappresentano un
18 1. La Privacy e il Web
pericolo se le fonti delle informazioni collezionate, analizzate e ricercate sono
pubbliche.
Ci sono pero delle applicazioni che trattano informazioni sensibili e necessi-
tano 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 alta-
mente 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 sani-
tarie, 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 modu-
li) oppure indirettamente (collezionamento implicito delle informazioni).
L’esempio piu semplice e quello di un utente che fornisce dati all’appli-
cazione, l’applicazione effettua una computazione e ritorna il risultato all’u-
tente.
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 ri-
guardano 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
1.2 Il Web e la privacy 19
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, op-
pure 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’applica-
zione 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 infor-
mazioni collezionate, definiscono le loro politiche in materia privacy su docu-
menti 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 informa-
zioni personali identificabili chiamate ‘Personally Identifiable Information‘
20 1. La Privacy e il Web
(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. Da-
gli 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 sicura-
mente una minoranza piu sensibile al problema privacy.
La maggioranza di utenti accetta le policy senza un’accurata lettura, igno-
rando 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 deci-
dere quali informazioni personali raccolte su di loro sono usate dall’ap-
plicazione 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;
1.2 Il Web e la privacy 21
Integrity/Security obiettivi che garantiscono che i dati siano accurati e
sicuri. Gli obiettivi di questa categoria vanno dal semplice dichiara-
re 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 organiz-
zazioni possono tracciare il consumatore con tecniche ad esempio dei
cookie?
Information Aggregation (aggregazione delle informazioni) Chi puo ag-
gregare 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 tra-
sferite le informazioni, perche non possono essere intercettate da altri?
Information Collection (collezionamento delle informazioni) quali e quan-
te informazioni sono collezionate in modo diretto richiedendole all’u-
tente e quali in modo indiretto?
Information Personalization (personalizzazione/profilazione) Quali infor-
mazioni sono utilizzate per personalizzazioni? Cosa cambia nell’appli-
cazione, quale aspetto e personalizzato con queste informazioni?
22 1. La Privacy e il Web
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. No-
nostante 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 applica-
zione 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’appli-
cazione 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 vio-
lazione 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 svi-
luppare 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 compren-
sione 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
1.2 Il Web e la privacy 23
comuni sia dal lato browser che dal lato server [GR00]. P3P specifica una
sintassi XML per le privacy policy, un protocollo per identificare questi poli-
cy 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 per-
sonale.
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.
24 1. La Privacy e il Web
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 ses-
suali, musicali e le preferenze.
Le organizzazioni che gestiscono queste applicazioni non specificano chia-
ramente quali informazioni possono essere omesse senza compromettere il
funzionamento dell’applicazione e spesso gli utenti le ignorano, rispondonen-
do 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’interfac-
cia 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 Face-
book stesso.
Compagnie di terze parti possono creare dei database basandosi sulle infor-
mazioni collezionate da Facebook e poi venderle al miglior offerente [HJ05].
Le informazioni che Facebook colleziona sono di vario tipo e si possono divi-
dere in informazioni ‘in prima persona‘ (first-party) cioe inserite dall’utente
stesso e quelle di ‘terza persona‘ (third-party), cioe informazioni personali
1.2 Il Web e la privacy 25
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 fa-
coltativamente.
Le informazioni configurabili dall’utente sono divise in categorie e le piu in-
teressanti 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 fami-
liarita 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 con-
trollare la diffusione delle informazioni in maniera molto dettagliata. La
visibilita dei dati puo essere abilitata selettivamente per amici, amici di ami-
ci, tutti.
Questa possibilita di personalizzazione delle preferenze sulla privacy da un
lato confonde gli utenti che la mole di informazioni controllabili. Troppo spes-
so 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 pa-
gina personale in cui gli altri utenti possono lasciare messaggi e segnalazioni
e le ’My Photo’ , che permette di segnalare il profilo degli utenti che compa-
iono nelle foto, senza il consenso di quest’ultimi.
26 1. La Privacy e il Web
Queste funzioni sono molto rischiose per la privacy personale perche permet-
tono ad alcune informazioni personali di sfuggire totalmente dal controllo
degli utenti coinvolti: gli utenti sono informati da una notifica della segnala-
zione in una foto.
Nel caso delle informazioni inserite da terzi (third-party information) la per-
dita del controllo delle informazioni e totale da parte dell’utente [GAH05].
Gli utenti possono spedire e associare informazioni sulla pagine di altri uten-
ti.
Ad esempio possono spedire foto e marcarle (taggarle) con il nome di chi
figura. Queste informazioni risiedono in una pagina non controllata dal sog-
getto 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 inse-
rite 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’op-
zione aggiuntiva nella pagina ’My Privacy’ per decidere di disassociare diret-
tamente l’utente dalle foto, senza la supervisione costante.
I ricercatori citati hanno sviluppato uno strumento automatico per la collezio-
ne 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
1.2 Il Web e la privacy 27
• 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 demogra-
fiche 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 informazio-
ni: 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 de-
vono avere il comportamento predefinito di divulgare le informazioni
solamente agli amici diretti.
• sensibilizzazione degli utenti circa la privacy: Facebook dovrebbe evi-
denziare 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.
Capitolo 2
Una soluzione al problema:
Secure Google Documents
2.1 Analisi del problema
2.1.1 Proteggere i dati personali nel browser
Le analisi effettuate in questo enunciato in materia di protezione di pri-
vacy 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 indi-
retto, 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 informazio-
ni 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, diretta-
mente 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 per-
corsi 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 pic-
cole 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 31
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 ve-
ra tecnica di protezione per la privacy ma lo e indirettamente;
Filtraggio degli annunci pubblicitari (ads) questa tecnica non e forni-
ta direttamente ma alcune distribuzioni linux la includono come esten-
sioni pre-installata (Firefox AdBlock Plus). Anche questa e una tecni-
ca che protegge la privacy indirettamente vietando lo scaricamento di
immagini e annunci che tracciano la navigazione.
Disabilitazione del caricamento delle immagini questa tecnica, utiliz-
zata 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-
32 2. Una soluzione al problema: Secure Google Documents
nuto degli oggetti provenienti solo dal dominio in questione e bloccare
tutti gli altri.
Rimuovere il contenuto dei Javascript rimuovere semplicemente il con-
tenuto degli oggetti Javascript.
Filtrare le richieste con URL identificanti alcuni URL sono usati per
passare dei parametri al server. Questi URL contengono caratteri co-
me ’?’,’=’,’&’ 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 ser-
ver sono di proprieta di aziende finalizzate alla ricerca di informazio-
ni personali. Gli oggetti che arrivano da questi server possono essere
direttamente bloccati.
Rimuovere le immagini invisibili (‘Web bugs‘) si possono rifiutare tut-
te 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 col-
lezionate dai server in modo indiretto rappresentano una minaccia ma anche
documenti come articoli, foto e pagine personali sono salvate tramite appli-
cazioni Web specializzate.
Gli utenti non sempre hanno coscienza della visibilita delle informazioni inse-
rite; e difficile distinguere in questo panorama cioe che e considerato ‘privato‘
da cio che e considerato ‘pubblico‘, quello che e considerato pubblico e ancora
2.1 Analisi del problema 33
suddiviso in ‘personale‘ e ’non personale’. [MH07]
Queste nuove possibilita di condividere le informazioni devono essere ana-
lizzate 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’ac-
cesso di questi dati.
Per ‘informazioni private‘ si intendono quelle informazioni considerate tali
dalla legislazione, piuttosto che le informazioni considerate ‘private‘ dagli in-
dividui 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 se-
condo 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 rispondo-
no a un determinato criterio di selezione. Le persone che vogliono controllare
questo tipo di informazioni vorrebbero avere un controllo sulla loro vita vir-
tuale (digital life) simile al controllo che hanno della loro vita reale (analog
life) [MH07].
Dunque dovranno essere sviluppate soluzioni specifiche come ad esempio fun-
zionalita 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 econo-
mici del Web [Gat07].
Questa nuova forma di controllo necessaria genera nuovi requisiti tecnici ri-
guardanti i meccanismi di controllo di accesso (Access Control Service), che
si vanno ad analizzare.
34 2. Una soluzione al problema: Secure Google Documents
Lo studio di un sistema che garantisca queste funzionionalita deve rispon-
dere ai seguenti requisiti:
deve essere basato sulle relazioni l’utente deve controllare il rilascio del-
le 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 rela-
zioni, 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 al-
l’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.
2.1 Analisi del problema 35
Da questa analisi e risultato che alcune applicazioni offrono solamente il li-
vello di base di controllo del tipo informazione privata/pubblica; altre sono
basate sul modello di amicizia (friends model), per decidere quali sogget-
ti 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 rappresen-
ta 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 ami-
cizie. 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 di-
chiara 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 princi-
pale 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-
36 2. Una soluzione al problema: Secure Google Documents
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 pro-
tezione, in un ambiente distribuito come il Web, questo richiede agli autori
di specificare manualmente le policy di accesso per ogni oggetto, dunque eti-
chettare 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 ‘Goo-
gle 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 tec-
nici‘ 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 abbastan-
za espressive soprattutto nelle applicazioni di tipo social network, le soluzioni
adottate andranno evolvendosi fino al raggiungimento dell’obiettivo di con-
trollo 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 Google Documents
2.2.1 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 dal-
l’interno di un browser, senza la necessita di installare prodotti e occupare
2.2 Google Documents 37
spazio su disco [Sal08].
Raggiungibile dall’URL http://www.docs.google.com, l’applicazione si pre-
senta 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’ap-
plicazione 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 Java-
Script 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 approssi-
mativamente 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 ripor-
tare 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 ste-
sura 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 effettua-
no 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;
38 2. Una soluzione al problema: Secure Google Documents
• 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 indispen-
sabile 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 stru-
menti 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 ver-
sioni sviluppate offline.
L’altra funzionalita mancante e il supporto a LATEX: introducendo uno stru-
mento 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 conosciu-
ti, 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’u-
tilizzo di versioni piu professionali e specializzate.
2.2 Google Documents 39
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 Do-
cuments per tutte le funzioni di salvataggio e modifica collaborativa.
I risultati delle ricerca promuovono comunque Google Documents come stru-
mento 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 documen-
ti 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 naturalmen-
te).
I file privati possono essere resi pubblici trasformandoli in pagine Web HTML:
Google assegna una URL rendendoli disponibili pubblicamente. Questa fun-
zione e utile quando si vuole pubblicare un articolo, senza effettuare altri
passaggi, e sufficiente condividerlo e comunicare agli interessati l’indirizzo
40 2. Una soluzione al problema: Secure Google Documents
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 effettiva-
mente 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 commer-
ciali 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 quan-
to 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:
2.2 Google Documents 41
Google Account; per l’utilizzo dei servizi e necessario un Google Account,
con tutte le implicazioni come la registrazione delle attivita personali del-
l’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 vi-
sualizzati 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
42 2. Una soluzione al problema: Secure Google Documents
scelta selettiva di chi e abilitato nella lettura dei contenuti, oltre che alla
visualizzazione, tramite delle semplici tecniche crittografiche.
2.3 Una soluzione: SecureGDocs
2.3.1 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 ri-
chiedono una certa confidenzialita.
Si e analizzato il rischio che comporta l’utilizzo di un’applicazione per la ge-
stione, creazione e modifica di documenti del tipo ‘Office‘.
Questi file, classicamente salvati in locale sulla macchina che i software clas-
sici 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 in-
formazioni nei documenti senza cambiare le abitudini di utilizzo della stessa
da parte degli utenti, fornendo appunto una componente aggiuntiva al bro-
wser 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 control-
lo di accesso.
La crittografia codifica i contenuti, prima di spedirli verso il server, e li deco-
difica, 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 pro-
tetto da una password. L’idea e stata quella di sviluppare uno strumento leg-
gero 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 si-
curezza: esse viaggiano su un canale cifrato (HTTPS), risolvendo i problemi
2.3 Una soluzione: SecureGDocs 43
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 aggiun-
tiva, 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 botto-
ne inserito personalizzando la ‘toolbar‘ principale di Firefox, si visualizza la
pagina del login che richiede le credenziali di accesso e permette di memoriz-
zarle ed accedere alle preferenze del programma.
In caso di login corretto, si visualizza l’interfaccia utente principale che per-
mette 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 pre-
senti 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
44 2. Una soluzione al problema: Secure Google Documents
(quindi il browser) e Google, questo livello garantisce le funzionalita critto-
grafiche 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 nel-
l’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 diffe-
riscono 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 do-
cumenti di testo. Al momento dell’apertura o della creazione di un file cifrato
una finestra richiede la password per poter sbloccare la cifratura dei docu-
menti.
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
2.3 Una soluzione: SecureGDocs 45
nei suoi server la versione cifrata dei file, le modifiche incrementali non ven-
gono 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 ri-
chiedere particolari interventi.
SecureGdocs introduce un livello aggiuntivo per la sicurezza delle informa-
zioni 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
46 2. Una soluzione al problema: Secure Google Documents
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 al-
goritmi 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 ‘Ac-
tions‘ 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
2.3 Una soluzione: SecureGDocs 47
garantire l’indipendenza dalla postazione di utilizzo. Le informazioni salvate
nel nome del file sono i bit di cifratura e la presenza di cifratura, rispettiva-
mente 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 pas-
sword 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 SecureG-
docs 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 Fi-
reGPG.
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.
48 2. Una soluzione al problema: Secure Google Documents
Aprendo la sidebar si possono effettuare ricerche rapide e filtrare i file presen-
ti, 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 ver-
so 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 per-
sonali con un’entita esterna come Google, e necessario l’utilizzo di SecureG-
docs 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 meta-
dati 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-
2.3 Una soluzione: SecureGDocs 49
sione o alla chiusura dell’applicazione.
I contenuti sono invece salvati solo nella versione cifrata nei server, e in nes-
sun 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 crit-
tografico: 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 infor-
mazioni 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 pro-
prieta 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 algorit-
mo 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
50 2. Una soluzione al problema: Secure Google Documents
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, natural-
mente 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 ne-
cessario 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 ades-
so attraverso degli strumenti esterni come FireGPG.
L’algoritmo utilizzato per la cifratura del contenuto dei file e del tipo sim-
metrico perche questi algoritmi sono piu semplici e veloci, anche il noto SSL
(Secure Socket Layer) utilizza la velocita dei simmetrici uniti ai vantaggi de-
gli asimmetrici [DW96].
Il prototipo sviluppato non implementa ancora internamente il meccanismo
della crittografia asimmetrica perche essa e piuttosto complessa computazio-
nalmente, dunque si rimanda all’utilizzo di strumenti conosciuti e robusti,
2.3 Una soluzione: SecureGDocs 51
sviluppati e testati per questi scopi.
Nel prossimo capitolo si illustra l’architettura e l’implementazione di Secu-
reGdocs.
Capitolo 3
Architettura di SecureGDocs
3.1 Struttura delle directory e dei file
3.1.1 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 riu-
tilizzare 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 si-
debar, cioe una barra aggiuntiva nel browser con orientamento verticale a
scomparsa.
Il codice con cui e stata sviluppata l’estensione e Javascript, uno dei linguag-
gi piu diffusi visto che e utilizzato massicciamente nelle pagine web, e XUL
(si pronuncia zool), un linguaggio XML-based sviluppato da Mozilla per co-
struire 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 directo-
ry ’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 visua-
lizzati 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’ap-
plicazione.
Anche Firefox, come detto precedentemente, e un insieme sofisticato di com-
ponenti orientati al riutilizzo.
3.1 Struttura delle directory e dei file 55
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
<em:id>segdoc@gargano </em:id>
4 <em:name>secureGdocs Extension </em:name>
<em:version >1.0</em:version >
6 <em:description >Secure Google Documents </em:description >
<em:creator >Edoardo Gargano </em:creator >
56 3. Architettura di SecureGDocs
8 <em:homepageURL >http :// www.cs.unibo.it</em:homepageURL >
<em:iconURL >chrome :// segodoc/skin/segodoc_small.png</em:iconURL >
10 <em:aboutURL >chrome :// segodoc/content/about.xul</em:aboutURL >
12
<!-- Firefox -->
14 <em:targetApplication >
<Description >
16 <em:id>{ec8030f7 -c20a -464f-9b0e -13 a3a9e97384}</em:id>
<em:minVersion >3.0.4</em:minVersion >
18 <em:maxVersion >3.*</em:maxVersion >
</Description >
20 </em:targetApplication >
22 <em:file>
<Description about=‘urn:mozilla:extension:file:segodoc ‘>
24 <em:package >content/</em:package >
<em:skin>skin/classic/</em:skin>
26 <em:locale >locale/en -US/</em:locale >
</Description >
28 </em:file>
</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 lo-
calizzazione (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 princi-
pale del browser.
Firefox utilizza questo protocollo per definire i percorsi assoluti di questi file.
1 content segodoc chrome/segodoc/content/
2 locale segodoc en-US chrome/segodoc/locale/en -US/
skin segodoc classic /1.0 chrome/segodoc/skin/classic/
4 style chrome :// global/content/customizeToolbar.xul
chrome :// segodoc/skin/css/toolbar -button.css
overlay chrome :// browser/content/browser.xul
chrome :// segodoc/content/firefoxOverlay.xul
3.1 Struttura delle directory e dei file 57
Il contenuto (content) dell’applicazione e in chrome/segodoc/content/ (li-
nea 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’e-
stensione 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 crea-
zione di nuovi file.
I file template sono stati introdotti da Microsoft Office e sono dei file base
58 3. Architettura di SecureGDocs
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 side-
bar
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 59
Il file firefoxOverlay.xul definisce l’overlay per disegnare la sidebar.
Firefox utilizza la tecnica degli overlay per aggiungere del contenuto aggiun-
tivo 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 ag-
giungere 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 <broadcasterset id=‘mainBroadcasterSet ‘>
2 <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 </broadcasterset >
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’inter-
faccia dell’estensione all’interno della finestra principale del browser.
Il file ’secugdocs.xul’ e il file decisamente piu importante e contiene l’inter-
faccia 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
60 3. Architettura di SecureGDocs
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 fun-
zioni principali.
Dopo aver importato tutti i file Javascript necessari si definiscono due ele-
menti ‘page‘ che disegnano le due schermate principali: il primo disegna
la schermata di login (loginPage), il secondo disegna la schermata di Secu-
reGdocs 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 secu-
reGdocs.js in questo modo:
1 <button label=‘login ‘ oncommand=‘segodoc.login(); ‘[...]
La searchPage invece definisce l’interfaccia utente principale di secureG-
docs con la quale l’utente interagisce con i documenti cifrati e non.
3.3 I file Javascript 61
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 lay-
out 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 mo-
difica, 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 I file Javascript
3.3.1 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:
62 3. Architettura di SecureGDocs
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 fun-
zioni 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 del-
l’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‘.
3.3 I file Javascript 63
I primi due file sono utilizzati per inizializzare l’estensione.
Il terzo file, ‘secureGdocs.js‘ , e il file principale del modulo core poiche con-
tiene 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 chia-
mata 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 visua-
lizzando di nuovo la schermatainiziale.
Il flusso di controllo passa da una funzione all’altra in caso di accesso all’ac-
count seguendo questo schema:
-> init -> login
-> loginSuccess
-> startTamper e getFeed
-> savetoDB
-> addFolderMenu
La funzione ‘login()‘ si occupa di spedire al server le credenziali inserite dall’u-
tente; le credenziali sono spedite per mezzo di una chiamata AJAX asincrona
alle API per l’autenticazione di Google, chiamate ‘Authentication API‘, uti-
lizzando 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 speci-
fica 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 fal-
limento (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
64 3. Architettura di SecureGDocs
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/accounts/ClientLogin ‘,
{
2 success: this.loginSuccess ,
failure: this.loginFail ,
4 customevents: {
onStart: this.startLoad ,
6 onComplete: this.completeLoad
},
8 scope: this
},
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
3.3 I file Javascript 65
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 visualizzan-
do 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 secu-
reGdocs, 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()‘, ‘op-
tions()‘.
Nell’esempio successivo si mostra la funzione ‘getFeed()‘.
1 getFeed: function () {
2 ......
YAHOO.util.Connect.resetDefaultHeaders ();
4 YAHOO.util.Connect.initHeader(‘Authorization ‘, ‘GoogleLogin auth=‘ +
this.\ _AUTH);
YAHOO.util.Connect.initHeader(‘Cookie ‘, ‘‘, false);
6 this.\ _feedConnection = YAHOO.util.Connect.asyncRequest(‘GET ‘,
‘https:// docs.google.com/feeds/ documents/private/full ‘, {
success: this.savetoDB ,
8 failure: this.getFeedFail ,
customevents: {
10 onStart: this.startLoad ,
onComplete: this.completeLoad
66 3. Architettura di SecureGDocs
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 genera-
ti 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 osser-
vatori 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
3.3 I file Javascript 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 var observerService =
2 Components.classes[‘@mozilla.org/observer -service ;1‘]
.getService(Components.interfaces.nsIObserverService);
4 observerService.addObserver(this , ‘http -on-modify -request ‘, false);
observerService.addObserver(this , ‘http -on-examine -response ‘, false);
All’interno del metodo ‘observe()‘ si definisce il comportamento che il soft-
ware deve effettuare a seconda del tipo di evento.
Nel codice sottostante si distingue il caso della modifica delle risposte da
quello delle richieste.
68 3. Architettura di SecureGDocs
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) {
2 aSubject.QueryInterface(Components.interfaces.nsIHttpChannel);
if (aTopic == ’http -on-modify -request ’) {
4 this.onModifyRequest(aSubject);
} else if (aTopic == ’http -on -examine -response ’) {
6 var newListener = new TracingListener (); // nsITraceableChannel
try {
8
aSubject.QueryInterface(Components.interfaces.nsITraceableChannel);
newListener.originalListener =
aSubject.setNewListener(newListener);
10 } catch(e) {}
}
12 }
}
La compatibilita dell’estensione sviluppata con le versioni uguali o supe-
riori 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 ‘on-
ModifyRequest()‘.
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 nel-
l’omonimo file sorgente requestResponse.js, che analizza la richiesta HTTP,
leggendone il contenuto, compresi i parametri presenti nell’header della ri-
chiesta.
3.3 I file Javascript 69
Configurato l’oggetto ‘requestResponse‘ con i dettagli delle richiesta si chia-
ma il metodo ‘startCrypt()‘ contenuto all’interno di ‘parChanger.js‘.
Quest’ultimo file analizza i parametri del messaggio, compresi i dati conte-
nuti 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 ag-
giornare il contenuto e provenienti da URL di Google Documents questi pa-
rametri vengono estratti e passati alle funzioni di cifratura.
Alla fine di questo capitolo si analizza il funzionamento della codifica/decodi-
fica 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 cifra-
tura che ritorna il contenuto sotto forma di testo cifrato.
1 modifyRequest : function () {
2 ......
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 TracingListener ();
2 newListener.originalListener = aSubject.setNewListener(newListener);
Nell’implementazione dell’oggetto ‘TracingListener‘ si definiscono i tre me-
todi specificati nell’interfaccia:
onDataAvailable che si attiva al passaggio dei dati sul canale;
onStartRequest che si attiva all’inizio della risposta;
70 3. Architettura di SecureGDocs
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 = binaryInputStream.readBytes(count);
2 data = segodoc.decrypt(data ,request.URI.asciiSpec);
binaryOutputStream.writeBytes(data , data.length);
4 inputStream = storageStream.newInputStream (0);
this.originalListener.onDataAvailable(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 bloc-
chi 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).
3.3 I file Javascript 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 Vin-
cent 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 ‘rein-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 bloc-
chi del testo in chiaro e per l’inizializzazione delle chiavi di cifratura.
Entrambe chiamano la funzione Cipher che si occupa delle cifratura dei bloc-
chi di bit.
Le altre funzioni importanti dell’algoritmo sono ‘SubBytes()‘, ‘ShiftRows()‘,
‘MixColumns()‘ e ‘AddRoundKey()‘ che sono utilizzate all’interno di ‘Chi-
per‘ 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 function Cipher(input , w) { // main Cipher function
2 var Nb = 4; // block size (in words): no of columns in state (fixed
at 4 for AES)
var Nr = w.length/Nb - 1; // no of rounds: 10/12/14 for 128/192/256 - bit
keys
4
72 3. Architettura di SecureGDocs
var state = [[] ,[] ,[] ,[]]; // initialise 4xNb 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);
10 for (var round =1; round <Nr; round ++) {
state = SubBytes(state , Nb);
12 state = ShiftRows(state , Nb);
state = MixColumns(state , Nb);
14 state = AddRoundKey(state , w, round , Nb);
}
16
state = SubBytes(state , Nb);
18 state = ShiftRows(state , Nb);
state = AddRoundKey(state , w, Nr , Nb);
20
var output = new Array (4*Nb); // convert state to 1-d array before
returning
22 for (var i=0; i<4*Nb; i++) output[i] = state[i%4][ Math.floor(i/4)];
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 con-
trollo 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;
3.3 I file Javascript 73
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 do-
cumenti creati con il modulo ‘Writer‘. Questo codice e nel file ’215317294-
EditPage.js’.
Le interfacce specifiche per gestire i fogli di calcolo e le presentazioni scaricano
altri file Javascript rispettivamente e ’858654377-trix core.js’ e ’749477615-
PresentationEditor.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 deco-
dificarli in tempo reale.
74 3. Architettura di SecureGDocs
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 te-
stuale.
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
3.3 I file Javascript 75
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 crit-
tografia 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 gene-
rati 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 confi-
gurazione, in modo da rendere l’estensione adattabile per altre applicazioni
Web.
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, caratte-
rizzate 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 man-
canza di riservatezza nei documenti creati e gestiti con Google Documents.
Questi documenti sono mantenuti da Google, che puo accedere al loro con-
tenuto.
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 docu-
menti 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 docu-
menti.
Il concetto di SecureGdocs potrebbe essere esteso agli altri software compo-
nenti 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 del-
le 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 condivi-
sione dei documenti, tramite le API di Google, all’interno di SecureGdocs, si
potrebbe implementare anche la gestione degli algoritmi asimmetrici per uti-
lizzare 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 au-
tomatically record certain information about your use of Google Docs.
Similar to other web services, Google records information such as ac-
count 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. Be-
cause 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 81
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
82 A. Google Docs Privacy Policy
Appendice B
Librerie esterne
YUI Le librerie YUI (Yahoo! User Interface) sono un insieme di utility Ja-
vascript 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 Ya-
hoo!. 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’interfac-
cia e quello di utilizzare i metodi ’document.createElement’ e ’setAt-
tribute’. 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‘ secureG-
docs utilizza questa libreria per inserire alcuni ‘comportamenti‘ dell’in-
terfaccia che altrimenti andrebbero a pesare direttamente nel codice
XUL.
Objtree ObjTree e un parser che trasforma il codice XML in oggetto Ja-
vascript 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 - posi-
tion 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 Wil-
liam H. Stufflebeam. Examining internet privacy policies wi-
thin 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 Techno-
logy 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 pro-
tocol. 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 800-
38A 2001 Edition, 2001.
[ECC06] Serge Egelman, Lorrie Faith Cranor, and Abdur Chowdhu-
ry. An analysis of p3p-enabled web sites among top-20 sear-
ch results. In ICEC ’06: Proceedings of the 8th internatio-
nal conference on Electronic commerce, pages 197–207. ACM,
2006.
BIBLIOGRAFIA 89
[GAH05] Ralph Gross, Alessandro Acquisti, and John H. Heinz. In-
formation 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. Facebook: Threats to
privacy. 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. Pri-
vacy enhancing technologies: A review. In Electronic
Government, pages 281–288. Springer, 2003.
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: Procee-
dings of the 3rd symposium on Usable privacy and security,
pages 52–63. ACM, 2007.
[Kob07] Alfred Kobsa. Privacy-enhanced web personalization. In Lec-
ture Notes in Computer Science, pages 628–670. Springer,
2007.
[Lan02] Marc Langheinrich. A privacy awareness system for ubiqui-
tous 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 mana-
gement of identity and privacy: sticky policies and enforceable
tracing services. In Database and Expert Systems Applica-
tions, 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 implemen-
tation. 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.