Se il concetto della privacy by design è semplice, la sua applicazione non lo è. Molto spesso, parlando con chi si occupa dello sviluppo di sistemi e di prodotti software, le domande sono semplici quanto complesse: “Quali sono i dati che devo considerare personali?” Come li devo gestire? Come posso stabilire le politiche di cancellazione e conservazione? Chi dovrebbe poter accedere a questi dati?”.
In effetti parte delle difficoltà derivano dal fatto che viene spesso trascurata, perché non interpretata come un reale valore di business, la definizione, all’interno del proprio sistema, di quali siano i dati personali e il loro scopo. Fare questo, consentirebbe di applicare criteri specifici ed automatizzati per la gestione di quei dati che richiedono protezioni aggiuntive.
Un approccio abbastanza generalizzato nell’applicazione della Privacy by Design nello sviluppo del software è quello di procedere ad analizzare la situazione corrente (Quali sono i dati personali nella soluzione? Esistono criteri per la cancellazione? Quali le misure di sicurezza applicate? Quali le misure organizzative?), raccogliere e catalogare queste informazioni e valutarne i relativi rischi. Questa analisi, già di per se complessa, può essere ulteriormente ostacolata dall’impiego delle metodologie Agili, che si contrappongono al tradizionale modello a cascata di sviluppo del software proponendo un approccio meno strutturato e focalizzato sull’obiettivo di consegnare il prodotto/servizio al cliente frequentemente e in tempi brevi.
Aziende tecnologiche e privacy, in arrivo un possibile tsunami normativo: ecco perché
Il punto di forza di queste metodologie è quello di concentrare le fasi di sviluppo in finestre di tempo limitate, chiamate iterazioni, solitamente di breve durata (qualche settimana) in cui sono previste tutte le fasi di tipiche dello sviluppo del software (pianificazione, analisi dei requisiti, sviluppo, testing, documentazione, rilascio). Ogni iterazione richiede lo sviluppo di nuovi requisiti, e pertanto di fatto richiederebbe una nuova analisi di Privacy by Design, che potrebbe anche andare ad inficiare le analisi già effettuate.
Indice degli argomenti
Come bilanciare i vari aspetti
Una possibile soluzione è quella di far uso di tassonomie (dal greco άξις, tàxis, ordinamento e νόμος, nòmos, norma o regola), ovvero di strumenti dedicati alla classificazione di concetti. Un pioniere, nell’ambito della privacy, è stato Daniel Solove, professore alla George Washington University Law School, che nel suo libro “A Taxonomy of Privacy”, analizza e classifica i diversi tipi di danno che possono derivare da violazioni della privacy. La tassonomia che ne deriva è organizzata in quattro categorie: Information collection, Information processing, Information dissemination e Invasion. Per ognuna di queste categorie, la tassonomia identifica le relative pratiche che potrebbero portare a violazioni. Per esempio, nel caso di Information collection, essa identifica la videosorveglianza o l’acquisizione di informazioni sotto coercizione (Interrogation).
Sempre nell’ambito delle tassonomie, ma totalmente differente rispetto a quella del Prof. Solove, è invece l’approccio seguito dal progetto “Fides” (dal latino, “fede” o “fiducia), indicato anche come “Privacy as Code”, e sviluppato da Ethyca. Fides utilizza il linguaggio open-source “fideslang, basato su YAML. YAML fu inizialmente detto “Yet Another Markup Language” (“Ancora un altro linguaggio di markup”) e successivamente “YAML Ain’t Markup Language” (“YAML non è un linguaggio di markup”) e rappresenta uno standard di serializzazione dei dati disponibile per tutti i linguaggi di programmazione, la cui caratteristica principale e punto di forza, è la leggibilità. Esso infatti fa uso di elementi usati da vari linguaggi di programmazione ben conosciuti, come Perl, C e Python per proporre una sintassi facile alla lettura.
L’idea alla base del progetto sviluppato da Ethyca è quella di utilizzare il linguaggio fideslang per “etichettare” e “classificare” i dati, per capire, con un semplice colpo d’occhio, quali sono e le loro caratteristiche e applicare in maniera quanto più possibile automatizzata le policy che formalizzano le decisioni aziendali e che rappresentano i requisiti di conformità normativa. Fideslang distingue quattro livelli di gerarchia con i quali descrivere i dati (personali) e il trattamento a loro associato. Ciascuno di questi livelli gerarchici può essere suddiviso in una varietà di sottoclassi che consentono di raggiungere la granularità richiesta.
Data Categories
Le Data Categories descrivono le diverse tipologie di dati. Esistono tre entità principali, Account, System e User Data, da cui derivare ulteriori categorie più specifiche.
Data Use Categories
Queste categorie descrivono come o per quali scopi un componente del sistema utilizza i dati.
Esempi di tale categorie sono: provide (fornito dall’entità), improve, collect, third-party sharing, etc.
Data Subject Categories
Queste categorie descrivono i proprietari dei dati personali.
Esempi di queste categorie sono: anonymous_user, employee, customer, etc.
Data Identification Qualifiers
Queste categorie codificano il grado di identificazione di un certo dato.
Esempi sono: anonymized, pseudoanonymized, identified
Come si utilizza il linguaggio Fides
Supponiamo ad esempio, di voler descrivere il fatto che un utente del sistema abbia fornito un dato in grado di identificarlo direttamente, e in particolare un dato di contatto, come una email. In questo caso potremmo scrivere:
user.provided.identifiable.contact.email
Se volessimo invece descrivere, in maniera più generica, tutti i dati condivisi con le terze parti per fini di marketing, potremmo scrivere
third_party_sharing.personalized_advertising
Una volta definite le caratteristiche dei dati, queste informazioni vengono salvate come metadati all’interno del progetto software. A questo punto Fides Control (fidesctl) può essere incorporato nel proprio progetto ed utilizzato per scrivere e applicare specifiche privacy policy sulla base delle caratteristiche di privacy dei dati definite attraverso il linguaggio fideslang e delle normative.
(da Github)
Si veda ad esempio la definizione della seguente policy che impedisce la raccolta di dati sensibili o di quelli che non derivano da attività di sistema. Gli impieghi con questo tipo di approccio possono essere molteplici. Si pensi, ed esempio, a complessi requisiti normativi che possono essere sintetizzati in policy predefinite. L’idea di Ethyca è quella di fornire un’interfaccia utente dedicata per scrivere facilmente tali policy. Oppure, si consideri la possibilità di evidenziare, in maniera automatizzata, eventuali incongruenze tra caratteristiche di privacy definite sui dati e le policy applicate. Ciò consentirebbe non solo di identificare e gestire i rischi per la privacy nella fase di sviluppo del codice ancor prima della produzione, ma diventerebbe anche un modo per documentare la conformità stessa del codice sulla base di tali requisiti.
