Un buon modo per ridurre i rischi per gli utenti è non conservare dati sensibili che non ti servono e che incidono sulla loro privacy. Ci sono molti modi sorprendenti per raggiungere questo obiettivo senza perdere gli obiettivi commerciali e vale la pena prendere in considerazione ciascuno di questi. Potresti:
- Spiega per cosa ti servono i dati.
- Raccogli i dati con una granularità inferiore.
- Rimuovi i dati una volta utilizzati.
- Non raccoglierli in primo luogo.
Ognuno di questi approcci consente agli utenti di sentirsi più a proprio agio con quello che stai facendo e perché, e questo contribuisce enormemente al tuo rapporto con loro. La trasparenza crea fiducia e, soprattutto, la fiducia può essere un punto di forza unico per te. Molte persone presumere che utenti e clienti si fidino di loro per impostazione predefinita, ma i consumatori valutano costantemente prodotti e servizi e questo può non è questo il caso. Se instauri un rapporto con i tuoi utenti in cui si fidano di te per gestire i loro dati e le tue interazioni rispetto, può offrirti un vantaggio competitivo come progetto o azienda: è qualcosa che i tuoi rivali potrebbero non corrispondono, un vero elemento di differenziazione.
Vediamo gli approcci sopra descritti, da quelli più efficaci (ma anche più efficaci per la tua attività) a quelli meno efficaci. ma meno invasivi da implementare.
Non raccoglierli in primo luogo
Il modo più ovvio per evitare di compromettere la tua privacy dati non è raccoglierli. Una parte della raccolta di dati è necessaria per fornire servizi, ma ci sono più posti in cui è possibile evitare la raccolta dei dati di quanto si possa pensare. Prendi in considerazione, ad esempio, il pagamento senza registrazione. Quando gli utenti vengono per effettuare un acquisto utilizzando la tua applicazione web, potresti richiedere loro di creare un account, perché hai acquisito i dettagli personali per l'evasione in seguito: possono essere aggiunti alla mailing list, sono già pre-qualificati come cliente interessato e così via. Tuttavia, i clienti lo riconoscono e non apprezzano questo aspetto: nel 2021, uno studio ha rilevato che una vendita abbandonata su quattro è dovuta al il sito ha richiesto all'utente di creare un account. Se non hai bisogno di un account, avrai maggiori probabilità di mantenere questi clienti. Se è possibile completare un acquisto senza effettuare la registrazione, per gli utenti, ma anche perché non hai molti dati da proteggere.
"Fuzz" i tuoi dati
Naturalmente, evitare del tutto la raccolta dei dati potrebbe non essere possibile. È importante raccogliere dati per fornire servizi e decisioni aziendali sensate. Può anche essere utile creare comunicazioni di marketing nel contesto di un rapporto di fiducia. Tuttavia, è anche importante rendersi conto che le decisioni prese in forma aggregata (ovvero che interessano più utenti contemporaneamente) vengono prese sui dati in forma aggregata (ovvero sulle proprietà collettive dei dati).
Ad esempio, a volte può essere utile avere un'idea dei dati demografici del pubblico: le fasce d'età a cui appartengono, posizione e così via. Ciò potrebbe cambiare i tuoi messaggi o il tuo approccio. Ma questo non significa che è necessario raccogliere le informazioni esatte età per ogni utente del servizio. Quello che cerchi spesso sono le tendenze e le proprietà generali. Se la decisione che vuoi è influenzata dal fatto che la maggior parte del pubblico faccia parte del "gruppo demografico chiave 18-34", allora l'unica domanda di cui hai effettivamente bisogno è se i tuoi utenti rientrano in quel gruppo demografico. Questa operazione li raccoglie in due "bucket": in quel gruppo e non in quel gruppo. Potrebbero verificarsi delle situazioni in cui hai bisogno di dati più granulari, ma è assolutamente ragionevole prendere l'elenco dei dati demografici che utilizzi per prendere decisioni e chiedere agli utenti di classificarsi con quell'elenco.
Esempio
Pertanto, se è utile sapere in che modo la tua base utenti si divide tra le categorie "18-34", "35-49", "49-64" e "65+", puoi chiedere agli utenti di scegliere a quale categoria appartengono. Chiedere dati estremamente granulari dati personali e personalizzati e di classificare gli utenti autonomamente, in questo modo non sarà necessario porre nuovamente la stessa domanda più avanti; ad esempio per chiedere l'età e la data di nascita esatte e poi utilizzare queste informazioni per creare elenchi personalizzati nella fascia "35-49" categoria. Ma è importante capire che aspetto ha: come il corso ha già trattato e torneremo su questo argomento: chiedere livelli dettagliati di dati può causare disagio alle persone e quindi ridurre la fiducia degli utenti nella tua organizzazione, e aggiungere rischi.
Inoltre, è importante considerare le tue esigenze in termini di dati. A volte, la "necessità" per ottenere dati più granulari è speculativo, una "giusto nel caso" requisito. Forse al momento dobbiamo solo classificare gli utenti in queste quattro fasce d'età, ma in futuro potremmo limitare questo aspetto, perciò dobbiamo raccogliere subito dati molto dettagliati per mantenere questa opzione aperta per un secondo momento. Potrebbe valere la pena considerando la frequenza con cui in passato i dati più granulari sono stati effettivamente utilizzati per orientare le decisioni. Chiedere dati percepiti come invasivi rispetto al servizio offerto comporta necessariamente una diminuzione del livello di fiducia degli utenti nei tuoi dell'organizzazione. Se questi dati vengono raccolti per motivi "in caso di necessità", potresti non limitarti a rinunciare alla fiducia degli utenti migliori decisioni aziendali, ma scambiandole solo per la possibilità di una futura decisione teorica futura non esistono, ma si assumono requisiti di sicurezza per tali informazioni.
Esistono anche metodi algoritmici più dettagliati per ridurre la granularità dei dati raccolti. Metodi di risposta randomizzati significa che i dati vengono raccolti con un certo grado di imprecisione e che sono stati utilizzati per decenni nei settori scienze quando si raccolgono dati potenzialmente invasivi o sensibili senza compromettere la riservatezza dell'intervistato. La precedente metodo di raccolta dei dati comporta l'ampliamento delle risposte dell'utente (quindi "quanti anni hai" diventa "in quale delle seguenti fasce d'età rientri"), in cui la risposta randomizzata prevede una determinata proporzione degli utenti mentono riguardo alle proprie risposte. Se è nota la percentuale di utenti che rispondono in modo errato, conclusioni significative possono comunque essere ricavati dai dati raccolti, ma la privacy dei singoli utenti non viene compromessa perché i dati raccolti potrebbero non sarà corretto. In questo caso, se l'80% del tuo pubblico dichiara ancora di rientrare nella fascia demografica 18-34 anni, puoi sono relativamente sicuri che si tratta ancora della quota maggiore, anche se il 10% di loro fornisce deliberatamente risposte errate. Il grado di errata può anche essere modificato in modo programmatico, in cui vengono sempre richieste le risposte corrette, ma software altera una certa percentuale di risposte prima di trasmetterle. Questo processo e le sue conseguenze possono anche Spiegare quando i dati vengono raccolti: significa che gli utenti non devono avere la certezza che non abuserai dei loro perché i singoli dati non sono affidabili.
Una procedura simile, ma più tecnicamente coinvolta, è la privacy differenziale. Questo utilizza tecniche matematiche per modificare l'archiviazione dei dati in modo che le proprietà aggregate dei dati siano ancora presenti, ma Non è nemmeno possibile dire se una determinata persona abbia fornito dei dati o quali dati ha fornito. Come la risposta randomizzata, questo protegge gli utenti dati anche da te e dimostra un chiaro intento da parte tua: non puoi usare la funzionalità dei tuoi utenti se non disponi di tali dati.
Questi e approcci simili forniscono inoltre maggiore sicurezza contro le violazioni e le fughe di dati, poiché i dati raccolti riduce le compromissioni della privacy dell'utente, anche a te, e riduce il livello di compromissione in caso di fuga di dati. Ricorda, però, che se applichi tecniche di privacy differenziale sul server (in modo che gli utenti ti indirizzino dati non aggregati e poi utilizzare le tecniche per aggregarli), è comunque necessario proteggere i dati utente non elaborati poi eliminarlo al termine dell'elaborazione. Inoltre, devi avere e seguire norme chiare per confermare che non lo usi prima l'aggregazione (o ti comunichi chiaramente per cosa lo usi).
Conservazione: raccogliere i dati e poi rimuoverli una volta utilizzati
È utile ricordare che i dati raccolti hanno un ciclo di vita; vengono raccolti, vengono utilizzati per aiutarti a prendere decisioni aziendali, e poi, prima o poi, essere rimosso. Anche in questo caso, ci sono dei compromessi: quando fai domande agli utenti o memorizzare informazioni su altri siti web visitati oppure monitorare quali contenuti hanno visualizzato e per quanto tempo in ordine per fare previsioni sulle loro preferenze, questi sono i dati che ti vengono concessi per uno scopo specifico, non come una concessione aperta che lo sviluppatore può usare in base alle esigenze. Quando i dati non sono più necessari per quello scopo, a volte può capitare dopo un minuto, a volte dopo molti anni.
Ogni volta che raccogli informazioni sui tuoi utenti, devi sapere per cosa utilizzerai questi dati (vedi di seguito) e devi sapere anche quando e perché smetti di conservare questi dati. Potrebbe verificarsi quando l'utente sceglie di eliminarla o quando firma dopo un determinato periodo di tempo o dopo che si è verificato un evento specifico. Un modo eccellente per instaurare un rapporto di fiducia è chiarire agli utenti in che modo possono controllare i dati che li riguardano, inclusa, se possibile, una disattivazione unilaterale. Come eliminano i propri dati? Come fa a eliminare il proprio account? Oltre a contribuire a costruire questo rapporto, è meglio Esercitarsi ad archiviare i dati per tutto il tempo necessario a elaborarli e non per più tempo, e che gli utenti abbiano un modo per vedere e rimuovere i dati che raccogli da loro o per loro conto. Potrebbe anche esistere una legislazione su questo argomento che gestisci.
Si tratta di un'area in cui è possibile definire obiettivi tecnici chiari, che aiutano gli utenti con il self-service; se gli utenti possono disattivare data warehouse senza dover chiedere l'autorizzazione, allora possono sentirsi più a proprio agio con l'attivazione e non di assistenza a questo scopo.
È importante riconoscere l'importanza di una disattivazione semplice e predefinita: "Per creare fiducia e riconoscimento, le aziende possono stipulano un contratto social in cui si impegnano a rispettare il proprio pubblico in ogni singolo punto di contatto, ascoltare le proprie esigenze e rispondere di conseguenza", afferma IAPP. Secondo Nielsen Norman Group gli utenti "hanno bisogno di una documentazione "uscita di emergenza" per abbandonare l'azione indesiderata senza dover eseguire un processo prolungato". Tutti sanno che è abbonarsi è più semplice che annullarli. Tuttavia, come afferma Nielsen Norman, offrire agli utenti la possibilità di ritirarsi senza dover che salta da un canestro all'altro, "promuove un senso di libertà e sicurezza". Gli studi accademici lo supportano e lo chiamano "principio della revocabilità", dichiarando: "L'interfaccia deve consentire all'utente di revocare facilmente le autorità concesse dall'utente, ovunque la revoca è possibile. Gli utenti devono essere in grado di revocare questo consenso e quindi ridurre le autorità per accedere alle loro risorse se possibile". (vedi Yee e Iacono per alcuni esempi).
La durata e quali dati conservare è un argomento che differisce molto tra le organizzazioni e tra i progetti, ma ci sono alcune linee guida comuni da prendere in considerazione.
Cosa fare
In questo caso, è utile per consentire agli utenti di eliminare gli account (e tutti i dati associati, se possibile) e regolarmente (ad esempio quando si disconnettono) cancellare i dati temporanei e memorizzati localmente all'uscita dall'account con l'intestazione Clear-Site-Data.
Fornisci un'intestazione Clear-Site-Data
per rimuovere alcuni o tutti i dati utente memorizzati sul lato client (nei cookie,
localStorage o IndexedDB o nella cache del browser), se ragionevole. Il caso d'uso più ovvio di Clear-Site-Data è quando un utente
si disconnette, ma può essere utilizzato anche dopo un incidente di sicurezza per garantire che non ci siano tracce persistenti di un account potenzialmente compromesso
dei dati compromessi archiviati sul client.
L'aggiunta del supporto per Clear-Site-Data
comporta l'invio di un'intestazione HTTP, Clear-Site-Data
, quando l'utente si disconnette (o in un altro
volte in cui vuoi cancellare lo spazio di archiviazione lato client), nella pagina che conferma lo stato di disconnessione (https://your-site/logout
o simili). Questa intestazione può avere alcuni o tutti i seguenti valori oppure "*"
per tutti:
Clear-Site-Data: "cache", "cookies", "storage"
Questi valori cancellano rispettivamente le pagine memorizzate nella cache (e altre risorse HTTP memorizzate nella cache), i cookie memorizzati, localStorage e IndexedDB e simili.
Potresti vedere un riferimento a un'altra opzione, executionContexts
, che però non è supportata da molti browser.
Tieni presente che utilizzare l'intestazione Clear-Site-Data
è probabilmente più semplice che eliminare singolarmente tutte le risorse create personalmente, poiché non è necessario disporre di codice JavaScript
vengono eseguiti sul client (ed è l'unico modo ufficiale per svuotare la cache del browser), ma non è supportato da tutti i browser.
Nota sull'utilizzo: se svuotare la cache (inviando Clear-Site-Data: cache
), l'intestazione Clear-Site-Data
non dovrebbe essere
inviato nella pagina di uscita effettiva, ma su qualche altra risorsa la pagina viene caricata. Questo perché su un computer più lento
con una cache di grandi dimensioni, la pagina si blocca mentre la svuota la cache, impedendo la navigazione. Questa operazione può richiedere alcuni minuti,
il che frustrarà l'utente. È improbabile che succeda, ma è difficile da testare ed è quindi consigliabile tenerlo a mente.
Spiega a cosa servono i dati
L'importanza della fiducia negli utenti con il tuo servizio è stato ripetuto più volte, perché aumenta la longevità dell'utente. Offre inoltre un vantaggio competitivo. Un modo per aumentare questo livello di fiducia è la trasparenza delle procedure e un un buon modo per essere trasparenti è spiegare per cosa vuoi ottenere i dati. In precedenza hai imparato che per ogni cosa raccolta devi sapere quando quell'elemento verrà eliminato. Per saperlo, devi sapere perché vuoi ricevere questi dati e per quali domande specifiche sono necessari. in modo da trovare risposte e quali decisioni saranno guidate dalla raccolta di queste informazioni. Dopo aver capito perché hai bisogno di questi dati, chiedi al tuo ad arrendersi, aiuterai a conquistare la loro fiducia spiegando loro ciò che li circonda. Nelle norme sulla privacy o quando poni domande relative al tuo account creazione, descrivi il motivo per cui hai bisogno di una risposta a questa specifica domanda, come userai i dati e quando e come potranno essere rimossi.
Queste spiegazioni sono molto più visibili se vengono presentate in linea. Seppellire le spiegazioni in un fitto documento di norme altrove sul sito web può sembrare un tentativo di nasconderli. Oltre alla raccolta dei dati, un modulo di registrazione, pagamento o richiesta può presentare i motivi della raccolta dei dati per trovare le regole. Spesso, un campo del modulo può contenere un asterisco (*) per indicare che un campo è obbligatorio. le forme complesse spesso hanno un link alle informazioni (i) spiegare il significato del campo. Valuta la possibilità di aggiungere a queste spiegazioni una descrizione del motivo per cui i dati vengono raccolti. Un modello come frase "Perché ne abbiamo bisogno?" accanto al campo del modulo che, se selezionato, mostra una spiegazione popup.
Alcuni esempi di codice HTML potrebbero avere il seguente aspetto, quindi CSS e JavaScript dovrebbero nascondere <aside>
e mostrarlo come popup quando
il clic sul link. Assicurati di confermare l'accessibilità del modulo che crei per il tuo sito.
Il modo esatto per definire il layout dipende dagli stili e dagli approcci, ma il punto principale qui è associare direttamente la raccolta dei dati
una spiegazione del motivo per cui questi dati vengono raccolti. Questa operazione non è necessaria per ogni campo. Nessuno ha bisogno di una spiegazione sul motivo per cui chiedi di farlo
scegliere una password al momento della registrazione. Tuttavia, integrare ogni richiesta di informazioni personali e di contatto in base a come intendi utilizzarle e conservarle può essere utile.
per capire chiaramente agli utenti che hai investito nella protezione dei loro dati.
<div>
<label for="email">Email address*</label>
<input id="email" type="email" name="email" required aria-describedby="whyemail">
<a href="#whyemail">Why do we need this?</a>
<aside id="whyemail">We need this information as a unique identifier for you, and if you forget your password we can send you a reminder. We will use your email address to send you regular updates on the service if you choose, and will delete your email address from any mailing lists if you delete your account.</aside>
</div>
Eseguire questa procedura con tutte le informazioni raccolte su un utente può essere utile anche per le discussioni e i processi interni. Prima hai visto come può esserci la tentazione di raccogliere dati "per ogni evenienza". Quando sei trasparente sulle tue ragioni per la raccolta, può essere abbastanza ovvio che sia così. Se non sei sicuro di voler scrivere pubblicamente ciò che vuoi che hanno a che fare con i dati degli utenti, perché a questi utenti la spiegazione non piacerà; questo potrebbe indicare che vale la pena ripensare alla raccolta li annotino. Questo vale nel caso in cui la spiegazione spiacevole sia troppo invasiva ("utilizzeremo questo dato per tenere traccia dei luoghi visitati su base oraria"). Troppo ampio ("non sappiamo per cosa lo useremo, ma lo vogliamo se pensiamo a qualcosa in proposito") o troppo evasivo ("utilizzeremo per scopi interni e non dichiarati"). Non è solo una questione di moralità, le persone sono abbastanza esperte riconoscilo, come già descritto, e gli utenti si aspettano che sperimentare con qualcosa non sia l'inizio di un impegno a lungo termine. È una prassi comune nella progettazione dell'esperienza utente rendere la registrazione il più semplice e fluida possibile. perché nelle fasi iniziali l'utente non è (per definizione) molto coinvolto nel servizio, pertanto è importante consentire a investirsi più facilmente quando hanno poca inclinazione a farlo. Se è così facile uscire di nuovo, sperimentare con il servizio diventa esattamente una sperimentazione e non l'inizio involontariamente di un impegno forzato a lungo termine. Come in precedenza, è paradossale, ma è vero che il modo migliore per instaurare un rapporto di fiducia è non richiedere agli utenti di fidarsi di te se ciò accade non voglio.
Le persone hanno buone ragioni per non condividere i dati o per condividere i dati in misura minima. All'inizio del rapporto con loro, potrebbero non avere un motivo per fidarsi e non dovrebbero esserlo. Il tuo obiettivo è dimostrare perché dovrebbero esserlo.
Cosa fare
- Decidi per quale motivo vuoi raccogliere tutti i dati che vuoi e per quanto tempo conserverai.
- Quando chiedi questi dati, spiega agli utenti il motivo per cui li stai raccogliendo.
- Eliminalo dai database del server dopo averlo utilizzato.
- Consenti agli utenti di eliminare gli account che hanno creato e cancella i dati memorizzati dal loro spazio di archiviazione con l'intestazione
Clear-Site-Data
.
Perché
Per instaurare un rapporto con gli utenti bisogna instaurare un rapporto di fiducia, mentre la fiducia comporta l'apertura. Se puoi dimostrare di non essere raccogliendo quanti più dati possibili sugli utenti e nascondendo i loro scopi, il che contribuisce a instaurare un rapporto di fiducia, un vantaggio competitivo per te rispetto a rivali meno scrupolosi.