Tesi di Laurea in

RETI DI CALCOLATORI

 
PROGETTO E REALIZZAZIONE DI UNA
INFRASTRUTTURA PER LA REGISTRAZIONE DEGLI
EVENTI SU INTERFACCE WEB REMOTE

Laureando: Relatore:
Tarlao Fabiano Prof. Alberto Bartoli

Correlatori:
Prof. Eric Medvet
Ing. Giorgio Davanzo
 Premessa
La navigazione sui siti web è una pratica frequente e necessaria
per larga fetta della popolazione

Utenti interagiscono con le pagine in modo differente

Possibili ricerche sull’interazione utente-interfaccia web:

• Identificazione dell’utente
• Creazione di nuovi CAPTCHA (distinguere uomo-macchina)
• Usabilità dei siti

Tutte queste ricerche presuppongono la capacità di registrare

l’ interazione tra utente e interfaccia web.
 Obiettivo
Progetto e realizzazione infrastruttura per:
• Registrazione eventi di interfaccia utente
• Durante la navigazione web
(traiettoria-velocità mouse, pressione tasti,…)

….
….
….
….
Mouse x,y Mouse
Mousex,y
x,y
 Requisiti
• Nessuna interferenza con applicativi web esistenti
• Nessuna modifica ai contenuti web (logica, dati)
• Nessuna installazione sw/plugin lato utente

• Impatto minimo sulle prestazioni percepite dall’utente

(cpu, banda)
 Tecnologie utilizzate
Tecnologie utilizzate per lo sviluppo dell'applicativo:

• Linguaggio di programmazione Java

• Google Widget Toolkit
• JavaScript e AJAX
 Descrizione infrastruttura
L’infrastruttura realizzata è stata denominata GWT-Observer

GWT-Observer è composto da due componenti:

• Applicativo client
o JavaScript eseguito nel browser dell’utente

o rileva gli eventi nel browser e li trasmette al server

• Applicativo server
o Web application Java in esecuzione su un AS

o Riceve eventi dal client e li registra su file

 Principio di funzionamento
1
OBSERVER
OBSERVER

2 3 4
Client Backend
GWT-Observer GWT-Observer

1. Il browser richiede la pagina (contiene client GWT-Observer)

2. Il client GWT-Observer viene eseguito dal browser
3. Il client trasmette la descrizione degli eventi al backend
4. Il backend salva la registrazione su file
 Modi di utilizzo
E’ prevista la registrazione in due modalità con finalità differenti:

• Direct
Il gestore di un sito registra l’interazione utente sulle pagine
(selezionate) del proprio sito.

• Proxy
L’amministratore di rete registra le azioni degli utenti durante
la navigazione su qualunque sito internet.
(anche di terze parti: facebook, amazon, google maps …)
 Direct
• Si registra l’interazione di utenti con sito e pagine specifiche
• Il gestore del sito inserisce manualmente il codice nelle pagine

Esempio codice HTML da inserire nella pagina:

<script language=“javascript” src=

“/it.univ.trieste.observer/it.univ.trieste.observer
.nocache.js”>
</script>
 Proxy 1/6
Schema di principio

• Gli utenti sono connessi attraverso un proxy http

• Il proxy dovrà iniettare il client GWT-Observer nelle pagine http
 Proxy 2/6
Problematiche relative alla Same Origin Policy (SOP)
• Misura di sicurezza implementata nei browser
• Applicativi JavaScript non possono accedere a risorse su
domini differenti da quelli della pagina

Come si aggira la SOP?

1. Un intermediario (proxy) deve inoltrare le richieste
dell’applicativo per la risorsa su un dominio diverso
2. Caricamento dinamico JSON, non attuabile con le GWT-
RPC
 Proxy 3/6
Struttura del Proxy

componenti del Proxy (azzurro):

• Proxy HTTP Squid
• Server ICAP GreasySpoon
• Redirector Squirm
• AS GlassFish
 Proxy 4/6
Richiesta di una risorsa HTML
HTML

2 2
HTML
HTML
3
3
1 1

1. Richiesta http di una risorsa a www.facebook.com

2. Risposta del sito, invio del contenuto al server ICAP
3. Iniezione di GWT-Observer, contenuto inviato al client
 Proxy 5/6
Invio dati al backend
Problemi legati alla SOP
3
Per FACEBOOK:
Mouse x,y
Client 3
Tasto K
GWT-Observer
1 2

1
1. Obiettivo: Richiesta per invio registrazioni al backend
2. Una richiesta diretta è impedita dalla SOP del browser
3. L’applicativo può inviare le richieste solo a facebook.com
 Proxy 6/6
Invio dati al backend
Proxy inoltra richieste

Per FACEBOOK: Per BACKEND:

Mouse x,y Mouse x,y
Client
Tasto K Tasto K
GWT-Observer
1 2
3

1. Richiesta con registrazioni (per backend) a facebook

2. Squirm modifica URL destinazione da facebook a backend
3. Invio della richiesta all’host corretto (insaputa browser)
 Dati rilevati
Si separano in due categorie:
• Dati generali sulla interazione
o ID, SID
o URL pagina, Referrer URL
o IP utente
o User agent dell’utente
• Azioni dell’ utente
o Movimenti mouse (coordinate del mouse)
o Click e rotella mouse
o Pressione tasti
o Scroll
o Ridimensionamento finestra
o Descrizione elementi HTML (posizione, tipo..)
 Convenzioni dati salvati
Formato registrazioni vengono salvate sul server in due formati:

• Binario
o Serializzazione delle registrazioni si file binario
o Nome file TapeDB
o Compatto

• XML
o Serializzazione XML delle registrazioni con XStream
o Nome file: IP-ID_interazione.xml , 192.168.2.2-
1264457427969003.xml
o Formato leggibile, ispezionabile con un editor
 Prestazioni client
Si sono rilevate sperimentalmente le prestazioni:
• Dimensione applicativo poche decine di Kbytes

• Ritardo nel rendering pagina 100 ms, impercettibile

• Aumento nel carico del processore pari al 12% del valore

massimo CPU
• La banda di picco in upload:
o senza compressione 2,5 Kbytes/sec
o con compressione gzip (si stima) 0,75 Kbytes/sec

Rispetto dei requisiti

Prospettiva sui risultati
 Esperimenti – Direct 1/2
Scopo: verificare il funzionamento nella modalità Direct

Invitati più utenti ad accedere a pagine monitorate

Si è realizzato un applicativo web per esperimenti, TestPages:

• Pagina di Login per l’esperimento
• Descrizione pagine di test
• Visualizza pagine di test iniettate con GWT-Obsever

TestPages sarà riutilizzabile nelle future ricerche

 Esperimenti – Direct 2/2
Pagine di test presentate da TestPages:
• registrazione nuovo utente Google;
• registrazione nuovo utente Amazon;
• login sul sito Bing;
• registrazione nuovo utente Bing;
• registrazione nuovo utente Ebay;
• login sul sito Facebook;
• registrazione nuovo utente sul forum Html.it;
• login sul sito Skype.

Risultati:
• Nessun malfunzionamento o disagio per l’utente
• Registrazioni avvenute con successo
 Esperimenti - Proxy
Scopo: verificare il funzionamento della modalità Proxy.

E' stato chiesto agli utenti di effettuare le seguenti operazioni:

• una navigazione su alcuni siti appartenenti ad una lista;
• una navigazione libera sui siti di loro preferenza;
• annotare le impressioni soggettive sull'uso o gli eventuali
problemi riscontrati.

Risultati:
• Nessun malfunzionamento o disagio per l’utente
• Registrazioni avvenute con successo
 Stato dell’arte
A livello accademico:
• CSIP, Emory University, Atlanta
• USAPROXY, Università di Monaco
Non soddisfano i requisiti

Prodotti commerciali, numerosi; ClickTale:

• Rispetta i requisiti
• Non è utilizzabile con siti di terzi (no proxy)
• Software proprietario (Web Analytics)
Non è possibile estrarre i dati desiderati
 Software utilizzati
Software utilizzati per lo sviluppo
• IDE, NetBeans ver. 6.8
• Piattaforma JDK 1.6
• Google Widget Toolkit, GWT SDK ver. 2.0.0
• Libreria: Xstream ver.1.3.1
Software server/servizi
• AS, GlassFish ver.3
• Proxy, Squid ver.3.0
• Server ICAP: GreaseSpoon ver. 1.02
• URL redirector(rewriter): Squirm ver.1.26
 Conclusioni
Realizzata l’infrastruttura per la registrazione remota

Rispetto dei requisiti prestazionali:

• Dimensione applicativo (tempo download basso)
• Carico CPU
• Banda

Superati i test di registrazione dell’interazione:

• Direct
• Proxy

L’infrastruttura realizzata è pronta per l’impiego nella ricerca

Domande?