Uma boa maneira de reduzir os riscos para os usuários é não guardar dados sensíveis sobre eles que não sejam necessários e que afetem 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 usá-los.
- 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, acima de tudo, a confiança pode ser um ponto de venda exclusivo para você. Muitas pessoas pressupõem que os usuários e clientes confiam neles por padrão, mas os consumidores estão sempre avaliando produtos e serviços, e isso pode mas esse não é o caso. Se você criar um relacionamento com seus usuários em que eles confiam em você para lidar com os dados e interações deles com respeito, ela pode oferecer uma vantagem competitiva para você como projeto ou negócio: é algo que seus concorrentes podem e não correspondem, 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 coletá-los
A maneira mais óbvia de evitar o comprometimento dados é 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: em 2021, um estudo descobriu que uma em cada quatro vendas abandonadas ocorreu porque o site exigiu que o usuário criasse uma conta. Se você não precisar de uma conta, a probabilidade de manter esses clientes será maior. 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.
"Fzz" 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 perceber que as decisões tomadas de forma agregada (ou seja, que afetam muitos usuários de uma só vez) são tomadas sobre dados agregados (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 abordagem. Mas isso não significa que você precisa coletar as informações idade de cada usuário do seu serviço. O que você procura com frequência são tendências e propriedades em geral. 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 os coleta em dois "buckets": nesse grupo e não nele. Pode haver situações em que você precise de dados mais granulares, mas é perfeitamente razoável levar 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 é útil saber como sua base de usuários se divide entre as categorias de idade "18-34", "35-49", "49-64" e "65+", você pode pedir aos usuários para escolher em qual dessas categorias 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” para dados mais granulares é o especulativo, "apenas para garantir" requisito fundamental. Talvez a gente só precise classificar os usuários de acordo com essas quatro faixas etárias no momento, mas no futuro poderemos restringir isso e, portanto, devemos 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 são 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. Métodos de resposta aleatórios significa que os dados são coletados com um grau ajustável de imprecisão e que têm sido usados há décadas na rede social ciências ao coletar dados potencialmente invasivos ou sensíveis, mantendo a confidencialidade do responsável pela resposta. A método acima de coleta de dados envolve ampliar as respostas do usuário (assim "quantos anos você tem" se torna "em qual das seguintes faixas etárias você se enquadra"), onde a resposta aleatória envolve ter uma certa proporção dos usuários mentem sobre suas respostas. Se a proporção de usuários que responderem incorretamente for conhecida, então conclusões significativas serão ainda podem ser extraídos dos dados coletados, mas a privacidade do usuário individual não é comprometida porque os dados coletados podem estar errada. Nesse caso, se 80% do seu público ainda afirmar que se enquadram no grupo demográfico de 18 a 34 anos, você pode ser relativamente confiante de que essa ainda é a maior parcela, mesmo que 10% deles estejam deliberadamente a dar respostas incorretas. O grau de incorreção também pode ser alterado programaticamente, em que as respostas corretas são sempre solicitadas, mas o o software altera uma certa porcentagem de respostas antes de transmiti-las. Esse processo e as consequências dele também podem ser explicado aos usuários quando os dados forem coletados: isso significa que os usuários não precisam confiar que você não abusará de seus coletados, porque os dados individuais não são confiáveis.
Um processo semelhante, mas mais tecnicamente envolvido, é 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: coletar dados e removê-los depois de usados
É útil lembrar que os dados coletados têm um ciclo de vida; são coletados e usados para ajudar você a tomar decisões de negócios, e, em algum momento, deve ser removido. 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 os dados não são mais necessários para essa finalidade, às vezes, depois de um minuto, às vezes depois de muitos anos, ela deve ser excluída.
Sempre que coletar informações sobre seus usuários, você deve saber para que usará esses dados (veja abaixo) e deve você também saberá quando e por que deixará de reter esses dados. Isso pode acontecer quando o usuário opta por excluí-lo ou quando assina depois de um período específico ou de um evento específico. Uma excelente forma de criar confiança nas relações é deixar claro para os usuários como eles podem controlar os dados sobre eles, incluindo, sempre que possível, uma recusa 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. Segundo o Nielsen Norman Group, os usuários "precisam de uma tag "saída de emergência" a sair da ação indesejada sem precisar passar por um processo prolongado". Todos sabem que é mais fácil se inscrever do que cancelar a inscrição. Mas, como diz Nielsen Norman, oferecer aos usuários a possibilidade de ir embora sem ter que passar por aros, "promove uma sensação de liberdade e confiança". Estudos acadêmicos reforçam isso e o nomeiam como "princípio do revogabilidade", com a seguinte mensagem: "A interface deve permitir que o usuário revogue facilmente as autoridades concedidas pelo usuário sempre que pode ser revogada. Os usuários precisam conseguir revogar esse consentimento e, assim, reduzir o acesso das 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 "Clear-Site-Data" é quando um usuário
sai da conta, mas também pode ser usada após incidentes de segurança para garantir que uma conta potencialmente comprometida não tenha rastros restantes
de dados comprometidos armazenados no cliente.
A adição de suporte a Clear-Site-Data envolve o envio de um cabeçalho HTTP, Clear-Site-Data, quando o usuário sai (ou em outro
horários em que você quer limpar o armazenamento do lado do cliente) na página que confirma o status de logout (https://your-site/logout)
ou similares). 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.
Talvez você veja referência a outra opção, executionContexts, mas ela não é aceita por 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 sobre o uso: se você estiver limpando o cache (enviando Clear-Site-Data: cache), o cabeçalho Clear-Site-Data não deverá ser
enviado na página de logout, mas em algum outro recurso a página é carregada. Isso ocorre porque, em um computador mais lento,
com um cache grande, a página será bloqueada enquanto limpa o cache, 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. Ele também oferece vantagem competitiva. Uma maneira de aumentar esse nível de confiança é com transparência em seus processos e uma boa maneira de ser transparente é explicar para que você quer dados. Você aprendeu anteriormente que, para cada coisa coletada, você deve saber quando ele será excluído. Para saber isso, é preciso saber por que você quer esses dados, em quais perguntas específicas eles precisam para encontrar respostas e quais decisões serão orientadas 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 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. Explicações ocultas em um documento de política denso em outro lugar do site pode parecer uma tentativa de ocultá-los. 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 ele é obrigatório. formulários complicados geralmente têm um link de informação (i) explicar o que o campo significa. Considere adicionar a essas explicações uma descrição do motivo da coleta dos dados. Frequentemente frase 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 semelhante ao mostrado a seguir. Em seguida, CSS e JavaScript ocultam a <aside> e a mostram como um pop-up.
o link é clicado. Confirme a acessibilidade do formulário criado para seu site.
A maneira exata de dispor tudo depende dos seus estilos e abordagens, mas o ponto principal aqui é associar diretamente a coleta de dados à
uma explicação sobre 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 com 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"). Não é simplesmente uma questão de moralidade; as pessoas são espertas o suficiente para reconhecem isso, como já descrito, e há uma expectativa do usuário de que testar algo não é o começo 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ê?
Construir um relacionamento com seus usuários é questão de confiança, e confiança tem a ver com 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.