Privacy dell'utente

Mary Kirtland

Microsoft Corporation

14 febbraio 2001

Nell'ultima colonna ho descritto la definizione della visione per il primo progetto di esempio del team di linee guida di Servizi Web, il servizio Preferiti. Mi scuso per il lungo ritardo tra le colonne; Sono stato fuori per la parte migliore di un mese con un brutto freddo. Spero che le cose siano tornate in pista ora per le colonne settimanali regolari per i prossimi due mesi.

Per riepilogare, l'obiettivo del servizio Preferiti consiste nel fornire alle applicazioni un modo per archiviare i collegamenti preferiti degli utenti finali ai siti Web in una posizione sicura, sicura, centrale, in modo che un utente possa accedere ai propri preferiti tramite queste applicazioni, indipendentemente dal computer che l'utente sta usando. Dal punto di vista tecnico, questo sembra un servizio piuttosto semplice da implementare. È fondamentalmente solo un archivio dati specializzato.

Nello stesso momento in cui abbiamo iniziato a esaminare il servizio Preferiti, c'è stata una vasta gamma di articoli di notizie sulla privacy degli utenti, in particolare sulle informazioni che terze parti potrebbero raccogliere tramite annunci pubblicitari nelle pagine Web. Questo ci ha pensato: l'intero modello di Servizi Web si basa su una pagina Web che usa servizi di terze parti, molto probabilmente senza la conoscenza dell'utente finale. C'erano problemi di privacy per preoccuparsi?

Anche senza una buona definizione di privacy degli utenti, siamo stati in grado di trovare alcuni scenari possibili che il servizio Preferiti proposto abilitava che sembrava discutibile. In base alla ricerca iniziale sui problemi, abbiamo deciso di implementare il servizio Preferiti in fasi, rinviando gli scenari interrogativi alle fasi successive. In questa colonna si parlerà di ciò che abbiamo scoperto durante la nostra ricerca iniziale, i problemi difficili che abbiamo posticipato, i problemi di privacy che rimangono nella fase uno del progetto e l'impatto di questi sulla progettazione e sull'implementazione.

Privacy definita

Iniziamo esaminando ciò che intendiamo in base alla privacy degli utenti. Ci concentreremo sulla privacy degli utenti e sul Web. Ogni volta che si usa il Web, sono disponibili tre tipi di informazioni che potrebbero essere scambiate tra l'applicazione usata (ad esempio un Web browser) e i siti Web a cui l'applicazione è connessa (ad esempio le pagine visualizzate nel browser):

Informazioni create usando una combinazione di applicazioni, ad esempio il messaggio di posta elettronica scritto, le foto di vacanza, i record finanziari e così via.
Informazioni sull'utente, ad esempio il nome, l'indirizzo, gli interessi personali e così via, raccolti da un'applicazione per fornire servizi all'utente.
Informazioni sulla connessione di computer e/o di rete in uso, ad esempio un indirizzo IP, raccolti da un'applicazione per fornire servizi all'utente.

Il problema relativo alla privacy degli utenti è il modo in cui queste informazioni vengono raccolte, usate e distribuite. Se acquisti un libro da un booktore online, naturalmente dovrai specificare il tuo nome, l'indirizzo e il numero di carta di credito per completare l'ordine. Ma cosa succede se il bookstore esegue il dump di queste informazioni in un database, insieme ai record dei libri specifici acquistati? Da un lato, può usare le informazioni per fornire servizi utili, ad esempio notificando quando vengono pubblicati nuovi libri dagli autori preferiti. D'altra parte, potrebbe vendere le tue informazioni personali, causando un'inondazione di posta indesiderata indesiderata. Qual è l'uso equo di queste informazioni da parte delle aziende che forniscono le applicazioni usate?

Sfortunatamente, non c'è una risposta adatta a tutte le dimensioni a questa domanda. La cosa giusta da fare è difficile determinare, soprattutto perché la percezione pubblica e le normative governative sono in flusso (e possono variare da una giurisdizione legale a un'altra). La procedura standard per i siti Web oggi consiste nel pubblicare un criterio sulla privacy che informa gli utenti di quali informazioni vengono raccolte e come può essere usato e distribuito. Tuttavia, non esiste uno standard relativo al fatto che l'utente debba leggere l'informativa sulla privacy prima che vengano raccolte informazioni o prima che l'utente possa accedere al sito Web.

La situazione diventa ancora più incerta con i servizi Web. L'utente finale probabilmente non sa nemmeno che vengono usati servizi Web. Se un servizio Web raccoglie informazioni che possono essere associate a un utente finale specifico (noto come informazioni personali), come il provider di servizi informa l'utente sulle informazioni raccolte e su come può essere usato o distribuito? Le applicazioni che distribuiscono le informazioni personali ai servizi Web devono divulgare questa operazione agli utenti finali? Tradizionalmente, le aziende non hanno divulgato che eseguono l'esternalizzare aspetti specifici dei loro processi aziendali. Ad esempio, un'azienda potrebbe non divulgare che l'evasione dell'ordine o il supporto tecnico dei clienti siano in uscita, anche se sia l'azienda di evasione degli ordini che l'organizzazione del supporto clienti hanno accesso alle informazioni personali sui clienti. Ma le regole potrebbero essere diverse online. Solo il tempo di indicare...

Procedure di informazioni corrette

Le procedure di informazione equa mantengono i clienti informati e controllano le loro informazioni personali. Queste informazioni sono protette dall'uso, dall'accesso o dalla distribuzione indesiderate, in modo che i clienti siano sicuri e soddisfatti quando si usano i prodotti di un'azienda. Il primo passo verso la comprensione della privacy dell'utente destinata al servizio Preferiti era leggere le procedure di informazioni corrette di Microsoft. Il gruppo di privacy aziendale di Microsoft definisce cinque elementi delle procedure di informazioni corrette:

Avviso. L'azienda deve definire criteri chiari relativi alla raccolta, all'uso e alla distribuzione di informazioni personali. Questo criterio deve includere l'uso primario e secondario dei dati, la distribuzione di dati tra le divisioni aziendali all'interno dell'azienda, la condivisione dei dati con le aziende affiliate e non affiliate e gli obblighi di contratto con i fornitori che supportano le transazioni aziendali. L'azienda deve stabilire linee guida per le modifiche dei criteri e l'impatto delle modifiche sui dati raccolti prima della modifica. Si vuole collaborare con i consulenti legali per assicurarsi che il criterio sia un elemento che è possibile applicare nei siti Web e nei servizi Web. Rendere i criteri disponibili per i clienti e gli utenti tramite più canali di distribuzione, tra cui online e offline.
Consenso. È consigliabile fornire meccanismi flessibili e accessibili per gli utenti per gestire le proprie preferenze per la raccolta dei dati, l'uso e la distribuzione. È necessario classificare le informazioni in raggruppamenti ragionevoli e significativi in modo che gli utenti possano capire quali sono i consenso e in modo da non richiedere troppo tempo per l'utente di configurare le preferenze. È importante considerare i valori predefiniti per le preferenze utente. L'utente deve abilitare in modo esplicito un uso specifico di informazioni personali (noto come consenso esplicito) o disabilitare esplicitamente l'uso (noto come opting out)?
Access. L'utente deve essere in grado di visualizzare e/o modificare le informazioni personali archiviate, per assicurarsi che venga mantenuto aggiornato e per gestire le preferenze di utilizzo. È necessario capire quali informazioni l'utente può modificare e quali informazioni possono essere visualizzate solo. Ad esempio, l'utente potrebbe non essere autorizzato a modificare un identificatore utente univoco, ma potrebbe essere consentito modificare una password. Idealmente gli strumenti per gestire le informazioni personali sarebbero disponibili sia per gli utenti online che per gli utenti offline.
Sicurezza. È necessario implementare misure di sicurezza appropriate per proteggere le informazioni personali degli utenti. Sono inclusi meccanismi di autenticazione e autorizzazione per proteggere l'accesso ai dati archiviati. Può anche includere meccanismi per proteggere i dati durante la trasmissione tra computer. Le misure di sicurezza devono essere proporzionali alla riservatezza delle informazioni. Ad esempio, si sarà molto più preoccupati della sicurezza se si lavora con un conto bancario o con i record medici di un utente rispetto a se si lavora con un elenco degli autori preferiti.
Applicazione. Non è utile avere un criterio di privacy se non lo segui. L'azienda deve definire (e seguire) procedure per il monitoraggio dei sistemi informativi per la conformità con i criteri di privacy. Definire i processi di risoluzione delle controversie per tutti i servizi informativi dei clienti e gestire relazioni di porto sicuro con organizzazioni di certificazione di terze parti. Anche se l'applicazione è in gran parte esterna al sito Web o al servizio Web stesso, è consigliabile considerare quali tipi di informazioni di controllo devono essere mantenute per supportare i processi di applicazione. Ad esempio, è possibile tenere traccia se e quando gli utenti hanno letto i criteri di privacy, quando e come un utente ha modificato le preferenze utente e così via.

Procedure e preferiti per le informazioni corrette

Tutto ciò sembra ragionevole in teoria, ma non era ancora completamente chiaro a noi come questo applicato al nostro servizio Web o come implementare tutti questi elementi per i servizi Web in generale. Quindi ho trascorso qualche ora a discutere i problemi con un membro del gruppo Criteri aziendali. È stato avviato un elenco di scenari che il servizio Preferiti potrebbe potenzialmente abilitare (in base all'istruzione di visione iniziale):

Un utente installa alcuni componenti aggiuntivi in Internet Explorer che fornisce un set di opzioni di menu come i preferiti di Internet Explorer, ad eccezione del fatto che i preferiti vengono effettivamente archiviati in coldrooster.com. Se si legge l'ultima colonna, si sa che è stato definito uno scenario aziendale intorno a una società di consulenza. Ora possiamo rivelare che il nome di questa società di consulenza fittizia è Cold Rooster Consulting, in onore del rooster che è stato appeso intorno al nostro edificio sul campus Microsoft. Di conseguenza coldrooster.com.
Coldrooster.com fornisce un'applicazione Web che consente agli utenti di gestire i preferiti.
Un sito Web, ad esempio msdn.microsoft.com, fornisce un pulsante su ogni pagina su cui un utente può fare clic per aggiungere tale pagina al preferito dell'utente archiviato in coldrooster.com.
Msdn.microsoft.com fornisce una pagina Web che visualizza i preferiti di un utente, archiviati originariamente da msdn.microsoft.com per conto dell'utente.
Msdn.microsoft.com fornisce un'applicazione Web che consente a un utente di gestire i preferiti archiviati originariamente da msdn.microsoft.com per conto dell'utente.
Cold Rooster Consulting accetta periodicamente tutti i preferiti archiviati, spogliati di tutte le informazioni che li collegano a un determinato utente e li scarica in un database separato per l'analisi.
Msdn.microsoft.com fornisce una pagina Web che visualizza tutti i preferiti archiviati da un utente, indipendentemente dal sito Web che originariamente ha archiviato il preferito per conto dell'utente.
Msdn.microsoft.com fornisce un'applicazione Web che consente agli utenti di gestire tutti i preferiti.
La consulenza del rooster freddo fornisce un servizio Web separato che msdn.microsoft.com può concedere una licenza. Questo servizio consente alle licenze di recuperare informazioni come "preferiti preferiti" o "persone che hanno salvato questa pagina anche salvate queste pagine", ma solo per il dominio msdn.microsoft.com.
La consulenza del rooster freddo fornisce il servizio Web descritto nello scenario 9, ad eccezione del fatto che le raccomandazioni restituite a msdn.microsoft.com possono includere preferiti da altri domini.

Poiché è necessario collegare i preferiti di un utente all'identificazione personale, ad esempio un indirizzo di posta elettronica o un identificatore di Microsoft Passport, per rendere disponibili tutti i preferiti dell'utente tramite qualsiasi applicazione e qualsiasi computer, i dati preferiti degli utenti rientrano sicuramente nella categoria delle informazioni personali identificabili. Se si è bloccati con questa definizione del servizio Preferiti, è necessario implementare procedure di informazioni corrette tramite una combinazione di criteri, procedure e codice.

Al momento della discussione, non c'erano leggi che richiederebbero di notificare all'utente prima di archiviare le informazioni per loro conto. È quindi possibile implementare l'elemento di avviso pubblicando una informativa sulla privacy su coldrooster.com. Come gli utenti sanno che hanno bisogno di leggere i criteri? Sono state presentate due opzioni: gli utenti devono iscriversi con coldrooster.com prima di poter archiviare i preferiti tramite il nostro servizio o le applicazioni client devono informare i loro utenti che il servizio Preferiti di consulenza del rooster freddo è stato usato, con un puntatore alla nostra informativa sulla privacy.

Dal punto di vista della sicurezza , i preferiti degli utenti non rientrano nella stessa categoria dei record medici, ma un utente vuole comunque avere un controllo su chi può accedervi. Ad esempio, guardando i preferiti che ho archiviato sul mio computer domestico, potresti scoprire quali squadre sportive io supporto, quali tipi di libri mi piace leggere, quali tipi di musica mi piace ascoltare e dove ho i miei conti bancari, non informazioni che voglio che tutti in tutto il mondo abbiano accesso. E se chiunque possa modificare i miei preferiti, potrebbe sostituire i collegamenti selezionati con altri siti (possibilmente per scopi nefari, ad esempio intercettare informazioni riservate) o aggiungere nuovi collegamenti ai miei preferiti. Quindi si vuole sicuramente proteggere l'accesso ai preferiti degli utenti. È probabile che si voglia consentire agli utenti di specificare quali applicazioni possono leggere o scrivere i preferiti. Ad esempio, potrei consentire a MSDN di modificare i preferiti per il dominio msdn.microsoft.com, ma non vorrei che MSDN visualizzi anche i collegamenti per le mie squadre sportive preferite. Perché MSDN dovrebbe preoccuparsi di questi?

Per consentire agli utenti di controllare quali applicazioni possono leggere o scrivere i preferiti, è necessario implementare il consenso e accedere agli elementi delle procedure di informazioni corrette. È anche probabile che si voglia implementare il codice di controllo per supportare l'elemento di imposizione .

Improvvisamente il nostro semplice servizio Web non suona così semplice! Quale livello di controllo è necessario assegnare agli utenti? È consigliabile specificare esattamente quali applicazioni possono leggere o scrivere preferiti da ogni dominio? Oppure è necessario raggruppare applicazioni e domini in zone per semplificare la configurazione? E quale degli scenari elencati sopra deve essere abilitato per impostazione predefinita?

L'esperto della privacy non ha avuto dubbi sugli scenari da 1 a 5. L'informativa sulla privacy tipica copre questi scenari. Tuttavia, per lo scenario 2, è necessario considerare se coldrooster.com dovrebbe essere in grado di gestire tutti i preferiti di un utente, indipendentemente dall'applicazione in cui sono archiviati i preferiti per l'utente o solo i preferiti aggiunti dalle applicazioni di Cold Rooster Consulting. È probabile che si esegua un errore sul lato della cautela e si dice che le applicazioni di Cold Rooster Consulting potrebbero gestire solo i preferiti degli utenti aggiunti tramite tali app, a meno che l'utente non abbia esplicitamente specificato che le app potrebbero essere usate per visualizzare o modificare tutti i preferiti archiviati per conto dell'utente.

Anche lo scenario 6 non è un problema eccessivo, purché l'informativa sulla privacy indichi che è possibile usare i preferiti degli utenti archiviati per un'ulteriore analisi. Anche in questo caso, è necessario valutare se i dati devono essere partizionati, in base al dominio o all'applicazione che ha originariamente fornito i dati, prima di analizzarli. Dal momento che molte persone fanno diffidenza nella profilatura dei dati, è possibile consentire agli utenti di rifiutare esplicitamente di includere i preferiti nei dati in pool usati per l'analisi.

Gli scenari rimanenti diventano sempre più dadi dal punto di vista della privacy. Questo non significa che non devono essere implementati, ma che sarebbe più difficile scrivere un'istruzione dei criteri accurata e comprensibile e gli utenti potrebbero non essere a proprio agio con gli scenari, quindi probabilmente dovrebbero essere disabilitati per impostazione predefinita (l'utente deve acconsentire esplicitamente).

Lo scenario 7 inizialmente sembra piuttosto innocuo, ma ciò che significa realmente dal punto di vista di un servizio Web è che un'applicazione può ottenere una copia di tutti i preferiti di un utente dal servizio Preferiti. Una volta che l'applicazione ha una copia dei dati, può eseguire le operazioni desiderate con esso. Se si fornisce un servizio Web che supporta questo scenario, è probabile che si voglia limitare l'accesso al servizio Web ai client noti con criteri di privacy che soddisfano alcuni criteri minimi.

Lo scenario 8 è ancora più problematico. Una volta che un'applicazione ha la possibilità di modificare i preferiti di un utente, cosa significa impedire all'applicazione di aggiungere pagine casuali all'elenco dell'utente o eliminare un preferito che punta al sito di un concorrente? In altre parole, in che modo il servizio Web può distinguere le richieste di servizio valide effettuate da un'applicazione per conto di un utente finale dalle richieste di servizio effettuate da un'applicazione di cui l'utente finale non è a conoscenza? I meccanismi di sicurezza disponibili che funzionano con HTTP e XML non supportano direttamente questo tipo di scenario client/server/servizio. È necessario implementare una soluzione di sicurezza personalizzata. Anche con il meccanismo di sicurezza personalizzato, è probabile che sia necessario un lavoro aggiuntivo per consentire agli utenti di specificare quali applicazioni possono modificare i preferiti.

Infine, gli scenari 9 e 10 vanno ancora più avanti nell'area di autenticazione della profilatura online rispetto allo scenario 6. I problemi tecnici in realtà non sono diversi da quelli già menzionati, ma il livello di disagio dell'utente sarebbe ancora più alto.

In base a questa analisi degli scenari, abbiamo deciso di tornare indietro e ripensare la visione per la distribuzione iniziale del servizio Preferiti. La nuova visione per la fase 1 è incentrata sugli scenari da 3 a 5 precedenti. Essenzialmente ogni applicazione ha un proprio archivio privato per i preferiti degli utenti. Se si passa a msdn.microsoft.com e si archivia un collegamento a questa colonna, è possibile visualizzare o modificare tale collegamento solo tramite l'interfaccia utente msdn.microsoft.com fornisce.

Questo approccio elimina diversi problemi difficili. In realtà, elimina l'intero problema di privacy dell'utente in quanto si riferisce ai preferiti degli utenti! Poiché ogni applicazione che usa il servizio Preferiti ha in modo efficace un archivio separato dei preferiti degli utenti, non è necessario uno schema di identificazione utente globale compreso dal servizio Preferiti. Ogni applicazione può usare qualsiasi tipo di identificatore desiderato. Il servizio Preferiti non può interpretare questi identificatori o correlare le informazioni archiviate da applicazioni diverse. Poiché i dati possono essere accessibili solo da una singola applicazione (o, più precisamente, da una singola licenza del servizio Preferiti), non è necessario preoccuparsi di fornire agli utenti un modo per acconsentire esplicitamente o rifiutare esplicitamente diversi scenari. È stato effettivamente delegato il problema della privacy dell'utente all'applicazione chiamante.

Questo non significa che non ci interessa risolvere le sfide tecniche sollevate nell'analisi degli scenari precedenti. Si vuole risolvere questi problemi in una fase futura del servizio Preferiti. Vogliamo solo dedicare un po' di più tempo a pensare alle cose e a trovare una soluzione che ci sentiamo a proprio agio nel consigliare alla community degli sviluppatori.

Quindi, cosa succede se avete bisogno di risolvere il problema oggi? Non è possibile vedere alcun modo per implementare un meccanismo di licenza per utenti e applicazioni. Gli utenti devono iscriversi per ottenere un account con il servizio. Ciò significa che si dispone di un sito Web in cui è possibile leggere l'informativa sulla privacy, iscriversi per l'account e gestire le proprie preferenze. Le aziende che sviluppano applicazioni devono anche iscriversi per ottenere una licenza per l'uso del servizio Web. Il contratto di licenza deve specificare il modo in cui le licenze notificano agli utenti l'uso del servizio Web. Sarà necessario determinare se è possibile considerare attendibili le licenze per usare solo il servizio Web in modo appropriato. In tal caso, è probabile che il sito Web possa raccogliere le credenziali utente e passarle al servizio Web. In caso contrario, è necessario fornire codice che le licenze possono usare per fornire un meccanismo sicuro per recuperare le credenziali utente e passarle al servizio Web. In entrambi i casi, ci sarà una notevole quantità di lavoro.

Problemi di privacy rimanenti

Anche se non è necessario preoccuparsi della privacy degli utenti rispetto ai preferiti degli utenti nella fase 1, esistono ancora alcuni problemi di privacy da considerare. Abbiamo deciso di concedere in licenza l'accesso al servizio Preferiti. Ciò significa che è necessario mantenere alcune informazioni di contatto sulle licenze. Tali informazioni rientrano nella categoria delle informazioni personali. Abbiamo quindi i problemi di privacy standard che qualsiasi applicazione che gestisce i visi delle informazioni sull'account.

Questi problemi sono stati risolti usando una combinazione di criteri e codice. Il diagramma seguente offre una panoramica generale dell'architettura di sistema:

Figura 1. Architettura del servizio Preferiti nella fase 1

Il servizio viene implementato con un'architettura a più livelli e viene distribuito su due livelli fisici, la Web farm e il cluster di dati. Le informazioni sull'account licenze vengono archiviate in un database nel cluster di dati. Il servizio Web e il sito Web tramite cui le licenze gestiscono le informazioni sull'account vengono distribuite nella Web farm. Esistono diversi livelli di protezione per le informazioni sulle licenze:

Il cluster di dati non è accessibile dai computer esterni a Cold Rooster Consulting.The data cluster is not accessible from machines outside Cold Rooster Consulting.
Il servizio Preferiti non deve accedere alle informazioni di contatto del licenziatario, quindi usa un componente Di accesso per autenticare le licenze. Il componente Accesso recupera solo le informazioni necessarie.
D'altra parte, il sito Web di gestione delle licenze deve accedere alle informazioni di contatto del licenziatario. In che modo può consentire al licenziatario di modificare i dati? Il sito Web esegue l'accesso a tutti i dati tramite il componente Licenze. I controlli di accesso nel componente Gestione licenze impediscono a qualsiasi altro sito Web di gestione delle licenze di chiamare il componente.
I controlli di accesso nel database licenze impediscono l'accesso al database da parte del componente Di accesso e del componente Licenze.
Le e-mail di conferma vengono inviate agli indirizzi specificati nelle informazioni di contatto ogni volta che vengono modificate le informazioni di contatto.

Effetto netto: deve essere molto difficile per gli utenti non autorizzati accedere o modificare le informazioni di contatto del licenziatario, a meno che l'identificatore e la password del licenziatario non vengano compromessi. Anche in tale situazione, se qualcuno ha tentato di modificare le informazioni di contatto, il contatto corrente verrebbe informato.

Verrà inoltre inserita un'informativa sulla privacy nel sito Web. È anche possibile fornire l'informativa sulla privacy insieme ad altre documentazioni fornite a nuove licenze, ad esempio la documentazione su come scrivere applicazioni che usano il servizio Preferiti.

Conclusione

La privacy degli utenti è un problema difficile per gli sviluppatori di servizi Web e le applicazioni che le usano. L'analisi del problema per il servizio Preferiti ci ha permesso di riconsiderare l'intero obiettivo per il servizio. Anche con l'ambito ridotto, è stato aggiunto un numero significativo di requisiti per garantire che le informazioni utente siano protette dall'uso inappropriato. Il requisito più importante era la necessità di limitare l'accesso alle applicazioni con licenza. La prossima settimana verranno esaminate in modo più dettagliato le licenze: i modelli aziendali considerati, il modello selezionato e l'impatto del modello sulla progettazione e sull'implementazione.

Se il servizio Web deve gestire le informazioni personali, è necessario eseguire molte operazioni oltre all'implementazione della funzionalità di base del servizio. È necessario affrontare tutti e cinque gli elementi delle procedure informative corrette: avviso, consenso, accesso, sicurezza e applicazione. È necessario determinare quando è necessario risolverli direttamente con gli utenti e quando è possibile rinviare i problemi di privacy alle applicazioni che usano il servizio Web. Ti consiglio vivamente di coinvolgere i tuoi consulenti legali nelle discussioni relative a questi problemi per assicurarti di essere aggiornato in merito alle leggi sulla privacy degli utenti ovunque si trovino gli utenti. Le risorse seguenti forniscono informazioni aggiuntive sulla privacy degli utenti:

Last updated on 2007-02-02

Condividi tramite