Azioni

Differenze tra le versioni di "Scheletro - Progettazione e realizzazione di un servizio web per il trattamento dei dati personali contenuti in documenti OOXML complessi"

Da Wikis.

m (Lorenzo.amorosa ha spostato la pagina Progettazione e realizzazione di un servizio web per il trattamento dei dati personali contenuti in documenti OOXML complessi a [[Scheletro - Progettazione e realizzazione di un servizio web per il trattamento...)
 
(14 versioni intermedie di uno stesso utente non sono mostrate)
Riga 3: Riga 3:
 
==La problematica del trattamento dei dati personali==  
 
==La problematica del trattamento dei dati personali==  
  
1) Introduzione all'argomento, con riferimenti alle normative sulla privacy vigenti (GDPR)
+
#Introduzione all'argomento, con riferimenti alle vigenti normative sulla privacy (GDPR).
2) Esemplificazione degli enti coinvolti (aziende, scuole, studi legali ect.) e dei documenti che necessitano di anonimizzazione o pseudonimizzazione
+
#Esempi di organizzazioni coinvolte (pubbliche amministrazioni, scuole, studi legali, aziende, etc.) e dei documenti che necessitano di anonimizzazione o pseudonimizzazione.
  
 
==Scenario di lavoro==   
 
==Scenario di lavoro==   
  
1)Breve accenno al confronto e alla collaborazione con AFA Systems
+
#Breve cenno al confronto e alla collaborazione con l'azienda.
2)Descrizione di ciò che AFA Systems vorrebbe: web tool, destinato all'uso degli enti prima citati, tramite il quale anonimizzare o pseudonimizzare documenti. In particolare, verra' posta attenzione sul trattamento di nomi e cognomi, i quali saranno anonimizzati
+
#La specifica di massima come espressa in fase iniziale: web tool, destinato all'uso delle organizzazioni prima citate, tramite il quale anonimizzare o pseudonimizzare documenti. L'oggetto del trattamento saranno i nominativi (nome e cognome) che compaiono nei documenti e che devono essere anonimizzati o pseudononimizzati. Si osserva che la definizione con maggiore precisione delle specifiche costituisce oggetto della tesi.
  
 
=Definizione delle specifiche=
 
=Definizione delle specifiche=
  
==Analisi dell'usabilita'==
+
==Analisi dell'usabilità==
  
===Nominativi forniti in input===
+
===Elenco dei nominativi da trattare come dati espressi in input===
  
1)vantaggi e svantaggi se l'input viene dato dall'utente
+
#Vantaggi e svantaggi nel caso in cui i nominativi siano forniti in input dall'utente.
  
===Impiego di dizionari===
+
===Elenco dei nominativi da trattare dedotti automaticamente da un dizionario===
  
1)vantaggi e svantaggi se il documento viene trattato da un dizionario (valutazioni sulle possibile struttura del dizionari: se contiene nomi, cognomi o entrambi, se contiene nomi/cognomi stranieri ect.; valutazione su criteri di ricerca (conviene ricercare i termini del documento nel dizionario o viceversa?) ect. )
+
#Vantaggi e svantaggi nel caso in cui il documento venga trattato con l'ausilio di un dizionario
 +
##Valutazione sulla possibile struttura del dizionario: se contenente nomi, cognomi o entrambi, se contenente nomi e cognomi stranieri etc.
 +
##Valutazione sui criteri di ricerca: conviene ricercare i termini del documento nel dizionario o viceversa? etc.
 +
##In particolare si argomenterà la scelta di usare un singolo dizionario contente soltanto nomi (anche stranieri).
  
 
===Soluzione ibrida adottata===
 
===Soluzione ibrida adottata===
  
1)illustrazione di una soluzione ibrida che applica entrambe le strategie
+
#Illustrazione di una soluzione ibrida che applica entrambe le strategie: vengono individuati i nominativi contenuti nel documento fornito in input con il dizionario, in seguito viene chiesto all'utente quali nominativi tra quelli individuati desidera trattare e se eventualmente vuole indicarne degli altri, infine il documento viene elaborato e i nominativi indicati anonimizzati o pseudonimizzati.
  
==Analisi linguistica e della struttura dei documenti==
+
==Analisi linguistica e strutturale dei documenti==
  
===Ambiguita' linguistiche===
+
===Ambiguità linguistiche===
  
1) esemplificazione delle ambiguita' linguistiche (omonimia totale o parziale dei nominativi, nomi/cognomi identificabili anche come lessico quotidiano, range di variabilita' con il quale un nominativo puo' comparire ect.), commenti sul come sia difficile trattare con un automa queste ambiguita' (antinomie)
+
#Esemplificazione delle ambiguità linguistiche (omonimia totale o parziale dei nominativi, nomi/cognomi identificabili anche come lessico comune, range di variabilità con il quale un nominativo può comparire etc.), commenti sul come sia difficile trattare con un automa queste ambiguità (caso limite: antinomie).
2)definizione dei pattern dei nominativi: (differenze tra quelli che sono inseriti dall'utente e presi dal dizionario)
+
#Motivazione dell'adozione di un approccio ''pattern-based'' per il riconoscimento dei nominativi, con cenni ad una possibile alternativa basata su tecniche di Text Analysis e relativi vantaggi e svantaggi.
 +
#Definizione del rapporto fra i pattern corrispondenti ai nominativi inseriti dall'utente e quelli dedotti dal dizionario, con valutazioni per il trattamento delle ambiguità.
  
===Formattazione===
+
===Formattazione dei documenti===
  
1) esemplificazioni di formattazioni possibili: grassetto, corsivo, tabelle, elenchi, titoli, note a pie' pagina (ect.)
+
#Esempi di formattazioni possibili: grassetto, corsivo, tabelle, elenchi, titoli, note a piè pagina, etc.
2) definizione dei pattern dei nominativi sulla base degli elementi di formattazione del documento
+
#Definizione del rapporto fra i pattern corrispondenti ai nominativi e gli elementi di formattazione del documento.
  
 
==Scelta dei formati da trattare==
 
==Scelta dei formati da trattare==
  
1)Introduzione: è buona prassi che il documento sia pseudonimizzato il prima possibile, per evitare che i dati in chiaro circolino in rete, quindi le persone alle quali e' rivolto il servizio sono le stesse che si occupano di redigere il documento: esse possono quindi decidere il formato del documento. E' ragionevole quindi lavorare su un unico formato
+
#Introduzione: è buona prassi che il documento sia pseudonimizzato il prima possibile, per evitare che i dati in chiaro ''sfuggano'' in rete; quindi le persone alle quali è rivolto il servizio sono gli stessi autori (creatori) che redigono il documento: esse possono quindi scegliere il formato del documento. Risulta ragionevole quindi lavorare su un solo formato.
2)Confronto formati di testo con approfondita argomentazione e scelta del formato OOXML Document (DOCX)
+
#Confronto formati di testo con approfondita argomentazione e scelta del formato OOXML Document (DOCX).
  
 
==Privacy by design==
 
==Privacy by design==
  
1)Illustrazione di come il principio influenzi l'architettura dell'applicazione, con commenti su scenari critici (interruzione della comunicazione, blackout ect.)
+
#Illustrazione di come il principio influenzi l'architettura dell'applicazione, con commenti su scenari critici (interruzione della comunicazione, blackout etc.), gestione dei file temporanei e delle schermate di interazione con l'utente (ad esempio, per iniziare una nuova anonimizzazione viene aperta una nuova scheda del browser, nel momento in cui l'utente chiude la scheda il file da lui caricato e ogni dato connesso vengono rimossi. In questo modo, informando l'utente di tale procedura, esso potrà avere pieno controllo sui propri documenti e piena ''fiducia'' (trust) nel servizio).
  
==Architettura web application== [A COME SOTTOCAPITOLO]
+
=Architettura del servizio=  
 +
 
 +
==I componenti software nell'architettura LAMP==
 +
 
 +
#Linux, Apache, MySql, Php e possibili varianti (ad es. Python, Perl etc.), confronti con tecnologie java per web.
 +
 
 +
==Single responsibility principle==
 +
 
 +
#Suddivisione delle responsabilità: il programma java dovrà occuparsi della logica applicativa (''logica di business'') e della gestione dei dati, lo script php dovrà curare l'interazione web con l'utente.
 +
#Vantaggio: libera realizzazione di nuove interfacce indipendenti dalla logica di business, la quale costituisce anche la base per estendere il servizio attraverso API.
 +
#Problematiche di rilievo: invocazioni concorrenti del servizio da parte di più utenti (...nomi dei file), execution environment, etc.
  
 
=Approfondimenti tecnologici=
 
=Approfondimenti tecnologici=
Riga 54: Riga 68:
 
==Analisi della struttura dei formati W3C OOXML==
 
==Analisi della struttura dei formati W3C OOXML==
  
1) descrizione preliminare dei punti salienti del formato
+
#Descrizione preliminare dei punti salienti del formato.
2) ideazione di una navigazione ed elaborazione bottom-up del file xml principale del docx, valutazione e analisi della complessita' introdotta dai vari nodi xml e traduzione dell'analisi svolta in nuove specifiche
+
#Ideazione di una navigazione ed elaborazione bottom-up del file xml principale del docx, valutazione e analisi della complessità introdotta dai vari nodi xml e traduzione dell'analisi svolta in nuove specifiche.
  
 
==La libreria in ambiente java open source Docx4j==
 
==La libreria in ambiente java open source Docx4j==
  
1)Potenzialita' e astrazione della libreria
+
#Potenzialità e astrazione della libreria.
2)Riferimenti allo standard W3C XPath e alcune altre osservazioni rilevanti su Docx4j
+
#Riferimenti allo standard W3C XPath e alcune altre osservazioni rilevanti su Docx4j.
 +
 
 +
==Ottimizzazione del dizionario==
 +
 
 +
#Studio di un semplice algoritmo di machine learning per ottimizzazioni sulla base di criteri di frequenza e ultima apparizione rilevata dei nominativi.
 +
#Valutazione sulla scelta di implementazione del dizionario (ad es. tramite database (MySql, soluzione adottata), file .xlsx, file .txt).
 +
#Valutazione sulle implicazioni relative agli accessi concorrenti in scrittura al dizionario e contromisure necessarie.
 +
#Valutazione sulle contromisure possibili a fronte di malevoli inserimenti di nominativi (gestione delle frequenze).
 +
 
 +
==Curiosità==
  
=Architettura web application= [B COME CAPITOLO]
+
#Illustrazione di alcuni accorgimenti interessanti fatti durante lo sviluppo della tesi: mediawiki come piattaforma di redazione e revisione della documentazione, funzionalità meno note di Github, semplici tool accessori a riga di comando in ambiente linux per la velocizzazione dello sviluppo realizzati.
  
 
=Sviluppi futuri=
 
=Sviluppi futuri=
  
==Ottimizzazione dei dizionari==
+
==Ulteriore ottimizzazione dei dizionari==
  
1) Valutazione sulla necessita' di ottimizzazione del dizionario sulla base di caratteristiche dei documenti trattati (es. lunghezza, se contengono solo tabelle o solo testo o entrambe ect.) o sulla loro tipologia (elenchi di studenti, atti di tribunale ect.)
+
#Apprendimento di nuovi nominativi, alla luce del fatto che è impossibile indivuare un pattern standard per i nomi e considerando possibili utenti malevoli. Possibili alternative (si osserva che in ogni caso è opportuno considerare validi nuovi nominativi se e solo se l'utente effettua il download finale del file anonimizzato):
2)Studio di un semplice algoritmo di machine learning per ottimizzazioni sulla base di criteri di frequenza e ultima apparizione rilevata dei nominativi e per l'apprendimento di nuovi nominativi.
+
##introdurre un meccanismo di autenticazione in modo tale che vengano accettati nuovi nominativi solo se l'elaborazione del documento è stata richiesta da un utente autenticato. Se poi, ad esempio, risulta che è stata richiesta l'aggiunta di un certo nominativo per almeno 3 volte in 3 giorni diversi da 3 utenti diversi allora esso viene aggiunto al dizionario. Vantaggio: procedura automatica; Svantaggi: necessità di tenere traccia dell'utente che ha inserito un nuovo nominativo (un utente può essere malevolo anche se registrato, e in tal caso va bannato) e conseguente perdita di privacy, impossibile identificare errori di battituta (anche se la richiesta di molteplici utenti per un nome apparentemente errato può significare che quel nome è in realtà esistente), riduzione dell'usabilità: l'utente è portato ad anonimizzare i documenti direttamente senza perdere tempo con procedure di login (si osserva che il login non è obbligatorio).
 +
##Introduzione di un meccanismo ''captcha'', che avrebbe circa gli stessi vantaggi/svantaggi della soluzione prima indicata, senza fare ricorso al concetto di utente e salvaguardando la privacy (anche se la scarsa usabilità rimarrebbe, anzi peggiorerebbe).
 +
##Ogni nominativo sconosciuto al programma che viene inserito dall'utente viene aggiunto su un file, sul quale inoltre è indicato, per ogni nominativo, il numero di volte che esso è stato richiesto in giorni diversi. Un amministratore saltuariamente potrà valutare il contenuto di questo file e lanciando un semplice comando potrà aggiungere alcuni o tutti i nuovi nominativi al dizionario. Vantaggi: elevata usabilità per l'utente, completo rispetto della privacy, maggiore controllo possibile; svantaggio: procedura non automatica.
 +
#Valutazione sulla necessità di ottimizzazione del dizionario sulla base di caratteristiche dei documenti trattati (es. lunghezza, se contengono solo tabelle o solo testo o entrambe etc.) o sulla loro tipologia (elenchi di studenti, atti di tribunale etc.).
  
==Valuazione di altri pattern==
+
==Valutazione di altri pattern==
  
1)Il rischio della re-identificazione, con valutazione di risultati scentifici sperimentali
+
#Il rischio della re-identificazione, con valutazione di risultati scentifici sperimentali, ulteriore argomentazione a supporto di un dizionario di soli nomi (maggiore privacy).
2)Altri dati personali trattabili: date e luoghi di nascita, indirizzi, email, numeri di telefono, sesso ect.
+
#Altri dati personali trattabili: date e luoghi di nascita, indirizzi, email, numeri di telefono, sesso etc.
3)introdurre funzionalita' per la pseudonimizzazione dei documenti (es. Amorosa Lorenzo -> Amorosa L.)
 

Versione attuale delle 16:21, 10 set 2019

Introduzione

La problematica del trattamento dei dati personali

  1. Introduzione all'argomento, con riferimenti alle vigenti normative sulla privacy (GDPR).
  2. Esempi di organizzazioni coinvolte (pubbliche amministrazioni, scuole, studi legali, aziende, etc.) e dei documenti che necessitano di anonimizzazione o pseudonimizzazione.

Scenario di lavoro

  1. Breve cenno al confronto e alla collaborazione con l'azienda.
  2. La specifica di massima come espressa in fase iniziale: web tool, destinato all'uso delle organizzazioni prima citate, tramite il quale anonimizzare o pseudonimizzare documenti. L'oggetto del trattamento saranno i nominativi (nome e cognome) che compaiono nei documenti e che devono essere anonimizzati o pseudononimizzati. Si osserva che la definizione con maggiore precisione delle specifiche costituisce oggetto della tesi.

Definizione delle specifiche

Analisi dell'usabilità

Elenco dei nominativi da trattare come dati espressi in input

  1. Vantaggi e svantaggi nel caso in cui i nominativi siano forniti in input dall'utente.

Elenco dei nominativi da trattare dedotti automaticamente da un dizionario

  1. Vantaggi e svantaggi nel caso in cui il documento venga trattato con l'ausilio di un dizionario
    1. Valutazione sulla possibile struttura del dizionario: se contenente nomi, cognomi o entrambi, se contenente nomi e cognomi stranieri etc.
    2. Valutazione sui criteri di ricerca: conviene ricercare i termini del documento nel dizionario o viceversa? etc.
    3. In particolare si argomenterà la scelta di usare un singolo dizionario contente soltanto nomi (anche stranieri).

Soluzione ibrida adottata

  1. Illustrazione di una soluzione ibrida che applica entrambe le strategie: vengono individuati i nominativi contenuti nel documento fornito in input con il dizionario, in seguito viene chiesto all'utente quali nominativi tra quelli individuati desidera trattare e se eventualmente vuole indicarne degli altri, infine il documento viene elaborato e i nominativi indicati anonimizzati o pseudonimizzati.

Analisi linguistica e strutturale dei documenti

Ambiguità linguistiche

  1. Esemplificazione delle ambiguità linguistiche (omonimia totale o parziale dei nominativi, nomi/cognomi identificabili anche come lessico comune, range di variabilità con il quale un nominativo può comparire etc.), commenti sul come sia difficile trattare con un automa queste ambiguità (caso limite: antinomie).
  2. Motivazione dell'adozione di un approccio pattern-based per il riconoscimento dei nominativi, con cenni ad una possibile alternativa basata su tecniche di Text Analysis e relativi vantaggi e svantaggi.
  3. Definizione del rapporto fra i pattern corrispondenti ai nominativi inseriti dall'utente e quelli dedotti dal dizionario, con valutazioni per il trattamento delle ambiguità.

Formattazione dei documenti

  1. Esempi di formattazioni possibili: grassetto, corsivo, tabelle, elenchi, titoli, note a piè pagina, etc.
  2. Definizione del rapporto fra i pattern corrispondenti ai nominativi e gli elementi di formattazione del documento.

Scelta dei formati da trattare

  1. Introduzione: è buona prassi che il documento sia pseudonimizzato il prima possibile, per evitare che i dati in chiaro sfuggano in rete; quindi le persone alle quali è rivolto il servizio sono gli stessi autori (creatori) che redigono il documento: esse possono quindi scegliere il formato del documento. Risulta ragionevole quindi lavorare su un solo formato.
  2. Confronto formati di testo con approfondita argomentazione e scelta del formato OOXML Document (DOCX).

Privacy by design

  1. Illustrazione di come il principio influenzi l'architettura dell'applicazione, con commenti su scenari critici (interruzione della comunicazione, blackout etc.), gestione dei file temporanei e delle schermate di interazione con l'utente (ad esempio, per iniziare una nuova anonimizzazione viene aperta una nuova scheda del browser, nel momento in cui l'utente chiude la scheda il file da lui caricato e ogni dato connesso vengono rimossi. In questo modo, informando l'utente di tale procedura, esso potrà avere pieno controllo sui propri documenti e piena fiducia (trust) nel servizio).

Architettura del servizio

I componenti software nell'architettura LAMP

  1. Linux, Apache, MySql, Php e possibili varianti (ad es. Python, Perl etc.), confronti con tecnologie java per web.

Single responsibility principle

  1. Suddivisione delle responsabilità: il programma java dovrà occuparsi della logica applicativa (logica di business) e della gestione dei dati, lo script php dovrà curare l'interazione web con l'utente.
  2. Vantaggio: libera realizzazione di nuove interfacce indipendenti dalla logica di business, la quale costituisce anche la base per estendere il servizio attraverso API.
  3. Problematiche di rilievo: invocazioni concorrenti del servizio da parte di più utenti (...nomi dei file), execution environment, etc.

Approfondimenti tecnologici

Analisi della struttura dei formati W3C OOXML

  1. Descrizione preliminare dei punti salienti del formato.
  2. Ideazione di una navigazione ed elaborazione bottom-up del file xml principale del docx, valutazione e analisi della complessità introdotta dai vari nodi xml e traduzione dell'analisi svolta in nuove specifiche.

La libreria in ambiente java open source Docx4j

  1. Potenzialità e astrazione della libreria.
  2. Riferimenti allo standard W3C XPath e alcune altre osservazioni rilevanti su Docx4j.

Ottimizzazione del dizionario

  1. Studio di un semplice algoritmo di machine learning per ottimizzazioni sulla base di criteri di frequenza e ultima apparizione rilevata dei nominativi.
  2. Valutazione sulla scelta di implementazione del dizionario (ad es. tramite database (MySql, soluzione adottata), file .xlsx, file .txt).
  3. Valutazione sulle implicazioni relative agli accessi concorrenti in scrittura al dizionario e contromisure necessarie.
  4. Valutazione sulle contromisure possibili a fronte di malevoli inserimenti di nominativi (gestione delle frequenze).

Curiosità

  1. Illustrazione di alcuni accorgimenti interessanti fatti durante lo sviluppo della tesi: mediawiki come piattaforma di redazione e revisione della documentazione, funzionalità meno note di Github, semplici tool accessori a riga di comando in ambiente linux per la velocizzazione dello sviluppo realizzati.

Sviluppi futuri

Ulteriore ottimizzazione dei dizionari

  1. Apprendimento di nuovi nominativi, alla luce del fatto che è impossibile indivuare un pattern standard per i nomi e considerando possibili utenti malevoli. Possibili alternative (si osserva che in ogni caso è opportuno considerare validi nuovi nominativi se e solo se l'utente effettua il download finale del file anonimizzato):
    1. introdurre un meccanismo di autenticazione in modo tale che vengano accettati nuovi nominativi solo se l'elaborazione del documento è stata richiesta da un utente autenticato. Se poi, ad esempio, risulta che è stata richiesta l'aggiunta di un certo nominativo per almeno 3 volte in 3 giorni diversi da 3 utenti diversi allora esso viene aggiunto al dizionario. Vantaggio: procedura automatica; Svantaggi: necessità di tenere traccia dell'utente che ha inserito un nuovo nominativo (un utente può essere malevolo anche se registrato, e in tal caso va bannato) e conseguente perdita di privacy, impossibile identificare errori di battituta (anche se la richiesta di molteplici utenti per un nome apparentemente errato può significare che quel nome è in realtà esistente), riduzione dell'usabilità: l'utente è portato ad anonimizzare i documenti direttamente senza perdere tempo con procedure di login (si osserva che il login non è obbligatorio).
    2. Introduzione di un meccanismo captcha, che avrebbe circa gli stessi vantaggi/svantaggi della soluzione prima indicata, senza fare ricorso al concetto di utente e salvaguardando la privacy (anche se la scarsa usabilità rimarrebbe, anzi peggiorerebbe).
    3. Ogni nominativo sconosciuto al programma che viene inserito dall'utente viene aggiunto su un file, sul quale inoltre è indicato, per ogni nominativo, il numero di volte che esso è stato richiesto in giorni diversi. Un amministratore saltuariamente potrà valutare il contenuto di questo file e lanciando un semplice comando potrà aggiungere alcuni o tutti i nuovi nominativi al dizionario. Vantaggi: elevata usabilità per l'utente, completo rispetto della privacy, maggiore controllo possibile; svantaggio: procedura non automatica.
  2. Valutazione sulla necessità di ottimizzazione del dizionario sulla base di caratteristiche dei documenti trattati (es. lunghezza, se contengono solo tabelle o solo testo o entrambe etc.) o sulla loro tipologia (elenchi di studenti, atti di tribunale etc.).

Valutazione di altri pattern

  1. Il rischio della re-identificazione, con valutazione di risultati scentifici sperimentali, ulteriore argomentazione a supporto di un dizionario di soli nomi (maggiore privacy).
  2. Altri dati personali trattabili: date e luoghi di nascita, indirizzi, email, numeri di telefono, sesso etc.