Uma boa maneira de reduzir o risco para os usuários é não armazenar dados sensíveis sobre eles que você não precisa e que afetam a privacidade deles. Há diversas maneiras de fazer isso e, ao mesmo tempo, atingir suas metas de negócios, e vale a pena considerar cada uma delas. Você pode:
- Explique para que você precisa dos dados.
- Coletar dados com menor granularidade.
- Remova os dados depois de usados.
- Não coletá-los.
Cada uma dessas abordagens pode ajudar seus usuários a se sentirem mais à vontade com o que você está fazendo e por quê, e isso contribui muito ao seu relacionamento com eles. A transparência gera confiança, e isso pode ser um diferencial para você. Muitas pessoas assumem que os usuários e clientes confiam nelas por padrão, mas os consumidores estão constantemente avaliando produtos e serviços, e isso pode não ser o caso. Se você criar um relacionamento com seus usuários em que eles confiem em você para processar os dados e suas interações com respeito, isso poderá oferecer uma vantagem competitiva para você como um projeto ou uma empresa: é algo que seus rivais não podem igualar, um verdadeiro diferencial.
Vamos analisar as abordagens acima na ordem da mais eficaz (mas também de maior impacto para sua empresa) para a menos eficaz. mas menos disruptivo para a implementação.
Não colete
A maneira mais óbvia de evitar comprometer os dados dos usuários é não coletá-los. Alguns dados são necessários para fornecer serviços, mas há mais lugares em que você pode evitar a coleta de dados do que você imagina. Considere, por exemplo, a opção "Comprar sem login". Quando os usuários vêm para comprar algo usando seu aplicativo da web, você pode exigir que eles se inscrevam em uma conta, porque depois você coletou dados pessoais para processamento posterior: eles podem ser adicionados à lista de e-mails, já estão pré-qualificados. como um cliente interessado e assim por diante. No entanto, os clientes reconhecem isso e não gostam disso: em 2021, um estudo descobriu que uma em cada quatro vendas abandonadas foi porque o site exigia que o usuário criasse uma conta. Se você não exigir uma conta, é mais provável que esses clientes continuem comprando. Possibilitar a conclusão de uma compra sem a inscrição oferece aos usuários opções melhores e também significa que você não tem tantos dados para proteger.
"Fuzz" seus dados
É claro que evitar a coleta de dados pode não ser uma opção. É importante coletar dados para fornecer serviços e fazer e tomar decisões de negócios sensatas. Também pode ser útil criar comunicações de marketing no contexto de uma relação de confiança. No entanto, também é importante saber que as decisões tomadas em conjunto (ou seja, que afetam muitos usuários de uma vez) são tomadas sobre dados em conjunto (ou seja, sobre propriedades coletivas dos dados).
Por exemplo, às vezes é útil ter uma noção das informações demográficas de seu público-alvo: em quais faixas etárias ele se encaixa, localização e assim por diante. Isso pode mudar sua mensagem ou sua abordagem. Mas isso não significa que você precisa coletar a idade exata de todos os usuários do seu serviço. Muitas vezes, você procura tendências e propriedades gerais. Se a decisão que você quer O alcance é afetado pelo fato de a maior parte de seu público estar no "grupo demográfico principal de 18 a 34 anos", então a única pergunta de que você realmente precisa se os usuários fazem parte desse grupo demográfico. Isso as coleta em dois "grupos": no grupo e fora dele. Em alguns casos, você precisará de dados mais detalhados, mas é razoável usar a lista de informações demográficas que você usa para tomar decisões e pedir aos usuários que se classifiquem com essa lista.
Exemplo
Portanto, se for útil saber como sua base de usuários se divide entre as categorias de idade "18 a 34", "35 a 49", "49 a 64" e "65 ou mais", é possível pedir aos usuários que escolham em qual categoria eles se enquadram. É tentador pedir dados extremamente granulares, dados pessoais e personalizados e, em seguida, classifique seus usuários por conta própria, evitando a necessidade de fazer a mesma pergunta novamente mais detalhes depois; por exemplo, para pedir uma idade e data de nascimento exatas e depois use essas informações para criar listas muitos usuários estão na faixa "35 a 49" categoria. Mas é importante entender como isso funciona, como já abordamos no curso e vai abordar novamente, pedir níveis detalhados de dados pode deixar as pessoas desconfortáveis e reduzir a confiança dos usuários na organização, ao mesmo tempo que aumenta o risco.
Também é importante considerar suas necessidades de dados. Às vezes, a "necessidade" de dados mais detalhados é especulativa, um requisito "por precaução". Talvez, no momento, só precisemos classificar os usuários nessas quatro faixas etárias, mas, no futuro, talvez queiramos restringir isso. Portanto, precisamos coletar dados muito detalhados agora para manter essa opção aberta para mais tarde. Pode valer a pena considerando a frequência com que os dados mais granulares foram realmente usados no passado para orientar as decisões. Solicitar dados que sejam percebidos como invasivos em relação ao serviço oferecido, necessariamente resulta na diminuição da confiança dos usuários organização. Se esses dados estiverem sendo coletados por motivos “por precaução”, talvez você não esteja apenas trocando a confiança do usuário por melhores decisões de negócios, mas deixando de lado apenas pela possibilidade de alguma decisão teórica futura que possa nem existe, além de assumir requisitos de segurança referentes a essas informações.
Também há formas algorítmicas mais detalhadas de reduzir a granularidade dos dados coletados. Os métodos de resposta aleatória significam que os dados são coletados com um grau configurável de imprecisão e são usados há décadas nas ciências sociais para coletar dados potencialmente invasivos ou sensíveis, mantendo a confidencialidade do respondente. O método acima de coleta de dados envolve ampliar as respostas do usuário. Por exemplo, "Qual é a sua idade?" se torna "Em qual das seguintes faixas etárias você se encaixa?", em que a resposta aleatória envolve uma certa proporção de usuários que mentem sobre as respostas. Se a proporção de usuários que respondem incorretamente for conhecida, ainda será possível tirar conclusões significativas com base nos dados coletados, mas a privacidade do usuário individual não será comprometida, porque os dados coletados podem estar incorretos. Nesse caso, se 80% do seu público ainda afirmarem que se enquadram na faixa etária de 18 a 34 anos, você pode ter relativa certeza de que essa é a maior parcela, mesmo que 10% delas estejam deliberadamente dando respostas incorretas. O grau de incorreção também pode ser alterado programaticamente, em que as respostas corretas são sempre solicitadas, mas o software altera uma determinada porcentagem de respostas antes da transmissão. Esse processo e as consequências dele também podem ser explicados aos usuários quando os dados são coletados. Isso significa que os usuários não precisam confiar que você não vai abusar dos dados coletados, porque os dados individuais não são confiáveis.
Um processo semelhante, mas mais complexo do ponto de vista técnico, é a privacidade diferencial. Isso usa técnicas matemáticas para alterar o armazenamento de dados de modo que as propriedades agregadas dos dados ainda estejam presentes, mas não é possível nem mesmo dizer se um indivíduo em particular forneceu dados ou quais dados ele forneceu. Assim como na resposta aleatória, isso protege dados até mesmo de você e demonstra clara intenção da sua parte: não será possível usar se você não tiver esses dados.
Essas e abordagens semelhantes também aumentam a segurança contra violações e vazamentos de dados, porque os dados coletados reduz os comprometimentos da privacidade do usuário, mesmo para você, e também reduz o nível de comprometimento em caso de vazamento de dados. Lembre-se, porém, que se você aplicar técnicas de privacidade diferencial no servidor (para que seus usuários enviem dados não agregados e depois usar as técnicas para agregá-los), ainda é necessário proteger esses dados brutos e e excluir após o processamento, além de ter e seguir políticas claras para confirmar que não está sendo usado antes agregação (ou deixe claro para que você a usa).
Retenção: colete dados e remova-os depois de usados
É útil lembrar que os dados coletados têm um ciclo de vida: eles são coletados, usados para ajudar você a tomar decisões de negócios e, em algum momento, precisam ser removidos. Mais uma vez, as desvantagens são: fazer perguntas aos usuários ou armazenar informações sobre outros sites visitados, ou você acompanha quais coisas elas acessaram e por quanto tempo para fazer previsões sobre suas preferências, esses são os dados que estão sendo concedidos a você para um propósito específico, não como uma concessão aberta para o desenvolvedor usar como achar adequado. Quando esses dados não forem mais necessários para essa finalidade, às vezes após um minuto, às vezes após muitos anos, eles precisarão ser excluídos.
Sempre que você coletar informações sobre seus usuários, saiba para que vai usar esses dados (veja abaixo) e também quando e por que vai deixar de armazenar esses dados. Isso pode acontecer quando o usuário decide excluir ou sair, após um período específico ou após um evento específico. Uma ótima maneira de criar confiança na relação é deixar claro para os usuários como eles podem controlar os dados sobre eles, incluindo, sempre que possível, uma opção de desativação unilateral. Como eles excluem os dados? Como ele pode excluir a conta? Além de ajudar a construir esse relacionamento, é melhor de armazenar dados pelo tempo que for necessário processá-los, e não por mais tempo, e que deve haver uma maneira de os usuários ver e remover os dados que você coletar deles ou em nome deles. Pode haver leis até mesmo sobre esse ponto em territórios que você opera.
nessa área, é possível definir metas técnicas claras, o que ajuda os usuários no autoatendimento. caso seus usuários possam desativar seu data warehouse sem ter que pedir permissão, eles podem se sentir muito mais à vontade para fazer a ativação, e isso não é e precisar de qualquer recurso de suporte para isso.
É importante reconhecer a importância de recusas fáceis e padrão: "Para criar confiança e reconhecimento, as empresas podem comece firmando um contrato social em que se comprometa a respeitar o público-alvo em todos os pontos de contato, ouvindo as necessidades deles e respondendo de acordo", afirma IAPP. O Nielsen Norman Group afirma que os usuários "precisam de uma 'saída de emergência' claramente marcada para sair da ação indesejada sem ter que passar por um processo prolongado". Todos sabem que é mais fácil se inscrever do que cancelar a inscrição. No entanto, como diz a Nielsen Norman, permitir que os usuários saiam sem precisar fazer malabarismos "estimule um senso de liberdade e confiança". Estudos acadêmicos confirmam isso e o chamam de "princípio de revocabilidade", afirmando: "A interface precisa permitir que o usuário revogue facilmente as autoridades que ele concedeu sempre que a revogação for possível. Os usuários precisam poder revogar esse consentimento e, portanto, reduzir o acesso de autoridades aos recursos, se possível." Consulte Yee e Iacono para ver exemplos.
Por quanto tempo e quais dados reter é um assunto que difere muito entre organizações e entre projetos, mas há algumas diretrizes comuns a serem consideradas.
O que fazer
É útil permitir que os usuários excluam contas (e quaisquer dados associados, quando possível) e façam isso regularmente (por exemplo, ao sair) limpar os dados temporários e armazenados localmente ao sair com o cabeçalho Clear-Site-Data.
Forneça um cabeçalho Clear-Site-Data para remover alguns ou todos os dados do usuário armazenados no lado do cliente (seja em cookies,
localStorage ou IndexedDB, ou no cache do navegador), quando for razoável. O caso de uso óbvio para o Clear-Site-Data é quando um usuário
faz logout, mas ele também pode ser usado após incidentes de segurança para garantir que uma conta potencialmente comprometida não tenha rastros
de dados comprometidos armazenados no cliente.
Adicionar suporte a Clear-Site-Data envolve o envio de um cabeçalho HTTP, Clear-Site-Data, quando o usuário sai (ou em outros
momentos em que você quer limpar o armazenamento do lado do cliente) na página que confirma o status de desconectado (https://your-site/logout
ou semelhante). Esse cabeçalho pode ter alguns ou todos os valores a seguir ou "*" para todos:
Clear-Site-Data: "cache", "cookies", "storage"
Esses valores limpam, respectivamente, páginas em cache (e outros recursos em cache HTTP), cookies armazenados, localStorage, IndexedDB e similares.
Você pode encontrar uma referência a outra opção, executionContexts, mas ela não é compatível com muitos navegadores.
Usar o cabeçalho Clear-Site-Data provavelmente será mais fácil do que excluir todos os recursos criados individualmente, porque ele não exige que o código JavaScript seja
executado no cliente (e é a única forma oficial de limpar o cache do navegador), mas não é compatível com todos os navegadores.
Observação de uso: se você estiver limpando o cache (enviando Clear-Site-Data: cache), o cabeçalho Clear-Site-Data não será
enviado na página de desativação, mas em algum outro recurso que a página carrega. Isso ocorre porque em um computador mais lento
com um cache grande, a página é bloqueada enquanto o cache é limpo, o que impede a navegação. Isso pode levar alguns minutos,
o que vai frustrar o usuário. É improvável que isso aconteça, mas é difícil de testar. Portanto, é uma prática recomendada ter isso em mente.
Explique para que você precisa dos dados
A importância da confiança nos usuários relação com seu serviço foi estabelecida repetidamente, porque isso aumenta a longevidade do usuário. Além disso, oferece vantagem competitiva. Uma maneira de aumentar esse nível de confiança é com a transparência nos seus processos. Uma boa maneira de ser transparente é explicar para que você quer os dados. Você aprendeu anteriormente que, para cada coisa coletada, você deve saber quando ele será excluído. Para saber isso, você precisa saber por que quer esses dados, quais perguntas específicas precisam deles para encontrar respostas e quais decisões serão guiadas pela coleta. Depois que você souber por que precisa desses dados, que o usuário desistir, isso ajudará a criar confiança explicando isso a esses usuários. Na sua política de privacidade ou ao fazer perguntas sobre a conta a criação, descreva por que você precisa de uma resposta para essa pergunta específica, o que você fará com esses dados e quando e como eles podem ser removidos.
Essas explicações ficam muito mais visíveis quando apresentadas inline. Ocultar explicações em um documento de política denso em outro lugar do site pode parecer uma tentativa de ocultá-las. Um formulário de inscrição, finalização de compra ou solicitação pode apresentar os motivos para coletar dados junto com a coleta por conta própria. Muitas vezes, um campo de formulário pode ter um asterisco (*) para indicar que um campo é obrigatório. Formulários complicados geralmente têm um link de informação (i) para explicar o que o campo significa. Considere adicionar a essas explicações uma descrição do motivo da coleta dos dados. Uma frase frequentemente usada para isso é "Por que precisamos disso?" ao lado de um campo de formulário, que, quando clicado, mostra uma explicação pop-up.
Um exemplo de HTML pode ser parecido com o seguinte, e o CSS e o JavaScript se encarregam de ocultar o <aside> e mostrá-lo como um pop-up quando
o link for clicado. Confirme a acessibilidade do formulário que você criou para o site.
A forma exata de fazer isso depende dos seus estilos e abordagens, mas o ponto principal é associar diretamente a coleta de dados a
uma explicação de por que esses dados estão sendo coletados. Isso não é necessário para todos os campos. Ninguém precisa de uma explicação sobre por que você precisa que eles
escolha uma senha ao se inscrever. Mas decorar cada solicitação de informações pessoais e de contato com a forma como você planeja usá-las e mantê-las pode ajudar
deixe claro para os usuários que você investe na proteção dos dados deles.
<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>
Passar por esse processo com tudo o que você coleta sobre um usuário também pode ajudar em processos e discussões internas. Anteriormente, você viu como pode haver a tentação de coletar dados "por precaução". Quando você é transparente sobre seus motivos para coletar, pode ser bastante óbvio que isso está acontecendo. Se você estiver relutante em escrever publicamente o que deseja a ver com os dados do usuário porque eles não gostam da explicação, isso pode ser um sinal de que vale a pena repensar a coleta reimplantá-lo. Isso se aplica se a explicação desagradável for muito invasiva ("vamos usar isso para rastrear os locais que você visita a cada hora"), muito amplo ("não sabemos para que vamos usar isso ainda, mas o queremos caso pensemos em algo para isso") ou muito evasivo ("usaremos essas informações para fins internos não divulgados"). Essa não é apenas uma questão de moralidade. As pessoas são espertas o suficiente para reconhecer isso, como já foi descrito, e há uma expectativa do usuário de que experimentar algo não é o início de um compromisso de longo prazo. Tornar a inscrição o mais simples e fácil possível é comum no design de experiência do usuário, porque, nos estágios iniciais, o usuário não está, por definição, muito envolvido no serviço. Por isso, é importante permitir a investir mais facilmente quando ainda têm pouca inclinação para isso. Se for tão fácil sair novamente, testar o serviço se torna exatamente um experimento, e não o início não disposto de um compromisso de longo prazo forçado. Como antes, é paradoxal, mas é verdade que a melhor maneira de construir confiança é não exigir que os usuários confiem em você se fizerem isso que você não quer.
As pessoas têm bons motivos para não compartilhar dados ou compartilhar dados mínimos. No início do seu relacionamento com eles, pode não ter um motivo para confiar em você e não deveria confiar. Seu objetivo é demonstrar por que eles deveriam fazer isso.
O que fazer
- Para todos os dados que você planeja coletar, decida por que você quer e por quanto tempo os armazenará.
- Ao solicitar esses dados, explique aos usuários por que você os está coletando.
- Exclua-o dos bancos de dados do servidor depois de usá-lo.
- Permita que os usuários excluam contas criadas por eles e limpem os dados armazenados com o cabeçalho
Clear-Site-Data.
Por quê?
Criar um relacionamento com os usuários é uma questão de confiança, e a confiança é uma questão de abertura. Se você puder demonstrar que não é coletar o máximo de dados possível sobre os usuários e ocultar o uso deles, o que ajuda a criar confiança, pode ser uma vantagem competitiva para você sobre rivais menos criteriosos.