Omnia in Mensura et Numero et Pondere - Tesi < Fabio's...

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.


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.


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:


• 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


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


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


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


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‘


(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;


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?


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


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.


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


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.


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


• 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-


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


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.


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.


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-


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;


• 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.


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


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:


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


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


(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


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


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


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.


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-


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


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,


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 >

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



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


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


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:


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‘.


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


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


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


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


‘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.


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.


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;


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).


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


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;


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.


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


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.

Omnia in Mensura et Numero et Pondere - Tesi < Fabio's...

Documents

Transcript of Omnia in Mensura et Numero et Pondere - Tesi < Fabio's...