Privacidade desde a conceção – princípios

O RGPD estabelece, entre outros, o conceito de “privacy by design” como um dos princípios para o desenvolvimento de websites e aplicações. Em português, utilizamos o conceito de “privacidade desde a conceção”. Contudo, para além do obviamente disposto na lei, do que se trata?

O design, para muitos, pouco parece ter que ver com a privacidade. No entanto, alguns atributos e orientações já na conceção de projetos web podem orientar uma plataforma de modo a conceder maior ou menor privacidade, com base em 7 princípios fundamentais.

Privacidade desde a conceção – princípios

Em primeiro lugar, não se trata de um conceito novo – já leva quase 20 anos. A privacidade desde a conceção foi inicialmente concebida pela Dra. Ann Cavoukian, na ocasião comissária para informação e privacidade da província canadiana de Ontário. Em um podcast recente, a especialista fala mais sobre o conceito. De qualquer modo, essa abordagem é sustentada por 7 princípios:

  1. Proativo e não reativo; prevenir e não remediar
  2. Privacidade como configuração padrão
  3. Privacidade intrínseca ao design
  4. Funcionalidade plena
  5. Segurança de ponto a ponto
  6. Visibilidade e transparência
  7. Respeito pela privacidade do usuário

Embora alguns dos itens sejam de fácil compreensão, pairam dúvidas a respeito da interpretação de alguns dos princípios. É preciso pensar, a despeito da separação em tópicos, em alguns preceitos de forma universal – o facto é que o web design ou design com atributos de privacidade não pode, jamais, ser pensado em fragmentos. A privacidade desde a conceção exige que consideremos os fatores que são positivos ou negativos em relação à privacidade do usuário, como sugere em sua terminologia, ANTES da própria elaboração do projeto.

Em outros tópicos detalharemos cada um dos princípios, com exemplos práticos e referências de interpretação adotadas por especialistas na área.

 

Google Analytics – como anonimizar o IP dos usuários

Desde 25 de maio de 2010, o Google Analytics oferece o recurso _anonymizelp na biblioteca JavaScript ga.js e na biblioteca analytics.js para permitir que proprietários de websites solicitem que todos os endereços IP dos seus usuários sejam anonimizados no produto. Esse recurso foi desenvolvido para ajudar os proprietários de sites a manter a conformidade com suas próprias políticas de privacidade ou, em alguns países, com as recomendações de autoridades locais de proteção de dados, que podem proibir o armazenamento de informações de endereços IP completos. A anonimização/mascaramento de IP ocorre assim que os dados são recebidos pela rede de coleta do Google Analytics, antes de qualquer armazenamento ou processamento.

Considerando que o IP pode ser considerado um dado pessoal à luz do regulamentado pelo RGPD, o recurso é algo simples de resolver e ajuda a manter a conformidade com o disposto na lei europeia. Mas como fazer a mudança?

Uma simples linha de código

É isso o que é preciso para acionar o novo recurso do Google Analytics. Independentemente do tipo de biblioteca que do Analytics que esteja a usar no seu website, o Google disponibilizou a ferramenta. São três as possibilidades de inclusão, conforme a biblioteca do Analytics que esteja a utilizar:

Biblioteca ga.js
ga(’set’, ‘anonymizeIp’, true);


Biblioteca analytics.js
ga(’set’, ‘anonymizeIp’, true);


Biblioteca gtag.js
gtag(’event’, ’your_event’, { ‘anonymize_ip’: true })

Como exigir senhas mais fortes no WooCommerce?

Muita gente utiliza-se de senhas simples e fáceis de lembrar. O problema é que esse tipo de palavra passe é fácil também para sistemas de brute force, hackers especializados em roubo de perfis e identidades e ameaças diversas. À luz do RGPD, a empresa torna-se responsável também pelo uso de palavras passe fracas por parte dos seus usuários e clientes, e mesmo funcionários.

Sob esse aspeto, recomenda-se que passwords mais fortes sejam exigidas no momento de efetuar um registo. Em relação a empregados, empresas possuem controlo facilitado e podem exigi-lo. Contudo, no que se refere a clientes, a situação não é tão simples.

Controlo da força das passwords no WooCommerce

O WooCommerce é um plugin poderoso para WordPress, que fora suas opções de configuração via backend, possui imensas funções, actions e filters, que permitem personalizar e modificar praticamente tudo dentro do sistema. Um desses filtros permite configurar o nível de complexidade das palavras chave que será exigido dos usuários durante seu registo. O padrão é o nível “3”, mas pode-se alterar com facilidade para um nível mais alto, bastando utilizar a função a seguir – seja no ficheiro functions.php do seu tema ou por meio de algum plugin personalizado.

/**
* Muda a força mínima para a palavra passe no WooCommerce
*
* Configurações
* 4 = Forte
* 3 = Média(padrão)
* 2 = Razoável
* 1 = Fraca
* 0 = Muito fraca
*/

add_filter( 'woocommerce_min_password_strength', 'change_woocommerce_password_strength' );
function change_woocommerce_password_strength( $strength ) {
  return 4;
}

 

RGPD e as tags RFID

A tecnologia de RFID (Radio Frequency IDentification – identificação por radiofreqüência) nada mais é do que um termo genérico para as tecnologias que utilizam a freqüência de rádio para captura de dados. Uma vez que podem efetuar a recolha de dados dos usuários e clientes desses produtos, as tags RFID também estão sujeitas a regras impostas pelo RGPD.

Para quem achou que o RGPD viria apenas a afetar websites e aplicações online, essa é uma péssima notícia. A verdade é que há normas técnicas já existentes que deverão nortear o uso dessas tags sob as novas regras de privacidade. Em outras palavras, mesmo quando usadas apenas para fins de stocks e armazenamento, as tags RFID deverão seguir regras de proteção e segurança de dados e também assegurar a proteção dos dados pessoais ou não daqueles que, por qualquer razão, estiverem a portar os itens que incluam as tags.

Tags RFID – normas técnicas
Emblema das tags RFID

ISO 29160 – normas técnicas para uso e aplicação e padronização do emblema das tags RFID.

O RGPD traz novas preocupações, mas o facto é que as tags RFID já vinham sendo regulamentadas por normas técnicas de uso e aplicação, tais como a ISO 29160, que entre outros normatiza o emblema RFID que todos os produtos e cargas que possuem tal rastreio devem trazer. Junto do emblema, em conformidade com as normas técnicas e também com o RGPD, deverá constar também:

  • O propósito do uso das tags RFID, com descrição clara do motivo pelo qual encontram-se ali e para que fim são utilizadas, ainda que apenas para stocks ou manuseio e controlo interno por empresas.
  • Dados e informações adicionais que deverão incluir contactos, por exemplo, dos responsáveis pelo processamento e controlo dos dados recolhidos a partir das tags RFID.

Enquanto que as normas técnicas em si constituíam mais uma padronização do que uma obrigação legal, o advento do RGPD criou uma necessidade premente de adequação às normas. Para as tags RFID, os procedimentos a adotar são detalhados em normas como EN 16570 e EN 16571, ambas de 2014.

A norma EN 16571, por exemplo, detalha uma série de procedimentos que culminam na elaboração de um documento conhecido como PIA para as tags, ou Privacy Impact Assessment, uma avaliação dos impactos do uso das tags RFID na privacidade.

 

 

Password “hash” – o que é e como funciona?

A função Hash (Resumo) é qualquer algoritmo que mapeie dados grandes e de tamanho variável para pequenos dados de tamanho fixo. Por esse motivo, as funções Hash são conhecidas por resumirem o dado. A principal aplicação dessas funções é a comparação de dados grandes ou secretos.

Dito isso, para que saiba, a maior parte das palavras passe em qualquer website ou aplicação online costuma ser armazenada em uma base de dados com um mecanismo de hash. Assim, caso haja vazamento dos dados diretamente a partir de um servidor, aqueles que subtraíram os dados em tese não serão capazes de aceder à password diretamente, exceto quando possuírem a palavra-chave que decifra o algoritmo de hash.

As funções hash criptográficas são usadas para segurança de dados, em resumo. Sistemas de CMS amplamente utilizados, como é o caso do WordPress, possuem sistemas de hashing para passwords de usuários. No caso do WordPress, usa-se ainda um sistema de hashing relativamente antiquado, o MD5. As versões mais modernas do PHP, entretanto, incluíram um mecanismo de criptografia e hashing mais poderoso – o Bcrypt. O uso do Bcrypt, em comparação a sistemas como o MD5, é capaz de reduzir significativamente as probabilidades de quebra de palavras-passe por meio de ataques de “brute force“.

Hash – verificação e comparação

Essa é a função do hash – é uma função criptográfica, mas não configura “criptografia” de facto. A encriptação é uma tarefa de mão dupla que você usa sempre que precisa armazenar com segurança uma informação, mas precisa recuperá-la mais tarde através de uma chave simétrica ou privada. Já o hash, é comumente utilizado quando você necessita comparar informações. Em um sistema de login, como o do WordPress, a função hash é aplicada sobre a palavra-passe digitada pelo usuário e o resultado é então comparado ao valor hash já armazenado na base de dados. As funções hash mais popularmente utilizadas incluem:

  • MD5. Foi desenvolvido em 1991 por Ronald Rivest para suceder ao MD4 que tinha alguns problemas de segurança. Por ser um algoritmo unidirecional, uma hash md5 não pode ser transformada novamente no texto que lhe deu origem. O método de verificação é, então, feito pela comparação das duas hash (uma da mensagem original confiável e outra da mensagem recebida). O MD5 também é usado para verificar a integridade de um arquivo através, por exemplo, do programa md5sum, que cria a hash de um arquivo. Isto pode-se tornar muito útil para downloads de arquivos grandes, para programas P2P que constroem o arquivo através de pedaços e estão sujeitos a corrupção dos mesmos. Como autenticação de login é utilizada em vários sistemas operacionais unix e em muitos sites com autenticação.
  • Bcrypt. O Bcrypt foi criado em 1999. Este método apresenta uma segurança maior em relação à maioria dos outros métodos criptográficos que é a implementação da variável “custo” que é proporcional à quantidade de processamento necessária para criptografar a senha. O método é conhecido como hash adaptativo às melhorias futuras de hardware por ter esta característica, pois pode permanecer resistente à ataques do tipo “força-bruta” com o tempo usando custos maiores de processamento. Sua maior segurança fez com que fosse, gradativamente, sendo adicionado a diversas linguagens de programação, como Perl, Python, Java e, mais recentemente, ao PHP.
  • SHA-256 e SHA-512. A família SHA-2 é um conjunto de funções hash criptográficas projetadas pela NSA (Agência de Segurança Nacional dos EUA). SHA significa secure hash algorithm (algoritmo de hash seguro). SHA-256 e SHA-512 são funções hash inovadoras computadas com palavras de 32 bytes e 64 bytes, respectivamente. Eles usam quantidades de deslocamento e constantes aditivas diferentes, mas as suas estruturas são praticamente idênticas, diferindo apenas no número de rodadas.

Como respeitar o “Do Not Track” em PHP?

A grande maioria dos alojamentos utiliza o PHP como base de toda sua programação, até porque a grande maioria dos sistemas de CMS ou e-commerce, ou mesmo de e-learning, são desenvolvidos nessa linguagem. Há sempre plugins, módulos e afins para lidar com particularidades e implementações em sistemas como o WordPress, Joomla, Drupal, Moodle e outros, porém aqueles que percebem o mínimo de programação podem lidar com a questão do “não rastrear” de forma simples.

Como explicamos, o HTTP DNT, ou “Do Not Track”, é um recurso existente hoje em todos os browsers. Ao acioná-lo, o usuário emite um aviso de que não deseja ser rastreado. Contudo, cabe ao proprietário do site incumbir-se do modo de fazê-lo.

Como condicionar o Google Analytics ao HTTP DNT

É possível condicionar o carregamento de scripts de rastreio como o do Google Analytics facilmente utilizando PHP. É preciso detetar a requisição, verificar até que ponto o HTTP DNT possui valor positivo (“1”) e então suspender o carregamento. Para tanto, é preciso inserir o script de rastreio do Analytics dentro de uma rotina condicional em PHP, como mostra o exemplo:

<?php
$DNT = 'HTTP_DNT';
if (isset($_SERVER[$DNT]) && $_SERVER[$DNT] == 1) {
// DO NOT TRACK habilitado
}
else {
// DO NOT TRACK desabilitado - inserir códigos a carregar aqui
}
?>

No exemplo, é possível gerar um comportamento também se o usuário possui o HTTP DNT habilitado. Poderíamos, por exemplo, exibir uma mensagem a alertar o usuário de que os scripts de rastreio estão desligados em respeito à configuração de privacidade e normas do RGPD. Pode-se ainda apenas verificar a existência da instrução HTTP DNT na requisição do usuário e, uma vez que exista e seu valor não seja igual a “1”, só então carregar o script ou scripts de rastreio:

<?php
if (!array_key_exists('HTTP_DNT', $_SERVER) || (1 !== (int) $_SERVER['HTTP_DNT'])):
?>
// DO NOT TRACK desabilitado - inserir códigos a carregar aqui<?php
endif
?>

 

HTTP “Do Not Track” – o que é?

Em vista dos problemas e preocupações relativos à privacidade dos últimos tempos, criou-se um mecanismo que inclui, nos cabeçalhos de requisição dos navegadores, uma diretriz extra – o DNT. O DNT é uma abreviação para “Do Not Track” – em português, literalmente “não rastrear”.

Isso significa que todo e qualquer usuário pode, ao aceder as configurações do seu browser, selecionar a opção de não ser rastreado. Ao fazê-lo, o browser emitirá uma requisição para toda página ou website que o usuário aceder, “avisando” o servidor dessa página que prefere não ser rastreado.

Onde o problema começa?

Apesar de todos os principais browsers já haverem aderido ao HTTP DNT, a verdade é que esse recurso apenas emite um aviso para o site que está sendo buscado. Caso o website não possua recursos programáticos para reagir a esse cabeçalho, simplesmente continuará a rastrear o usuário, atuando assim em desconformidade não apenas com a ética da internet, mas também com o RGPD (face aos direitos do usuário que, desse modo, estariam a ser transgredidos).

O HTTP DNT é apenas uma forma de o browser alertar servidores a respeito das preferências do usuário – é de total responsabilidade do proprietário do site reagir a tal. Para usuários, selecionar tal opção não garante de forma alguma que não haverá rastreio. Contudo, por interpretação à nova legislação europeia, sites que não reajam a tal estarão atuando em desconformidade. Quando o usuário assinala tal opção no browser, suas requisições vão sempre acompanhadas de uma instrução DNT: 1 no cabeçalho HTTP.

Os sites devem então reagir a esse “sinal” desligando, para esse usuário, todo e qualquer script ou ferramenta de rastreio ou monitoramento.

Suporte amplo

A maioria dos browser, para computadores ou telemóveis, atualmente oferece tal recurso. Isso significa que sites devem ter, sob a luz do RGPD, códigos implementados para reagir a essa possibilidade. Em outros tópicos iremos detalhar algumas formas de reagir ao HTTP DNT, particularmente utilizando PHP ou Javascript para interpretar a instrução. A tabela a seguir mostra que todos os navegadores, em desktop e portáteis ou em telemóveis e tablets, oferecem suporte ao “Do Not Track”. O “Yes” mostra suporte integral e, para os quadros onde há números, referem-se às versões a partir das quais o suporte é oferecido.

HTTP Do Not Track

 

Bases legais para o processamento de dados na Política de Privacidade

A Política de Privacidade é um dos aspetos mais importantes do novo GDPR europeu. Como já alertamos, há casos nos quais pesados textos legais na verdade estarão a descumprir o disposto na lei, por sua complexidade e falta de objetividade. A licitude de tratamento e as chamadas bases legais para o processamento dos dados pessoais de usuários segue seis vias possíveis – embora a primeira delas seja a mais comum e aplicável à maioria dos websites. O artigo 6º do GDPR é que trata dessas bases e deve ser observado de forma direta.

A Política de Privacidade, assim sendo, deve conter as bases legais do tratamento de dados, ou mais diretamente, as razões justificáveis pelas quais os dados do usuário poderão ou não ser processados. São seis as razões principais estabelecidas pelo regulamento.

Bases legais – consentimento para quê?

Sempre que o usuário, ou o titular dos dados, conceder consentimento expresso para que sejam processados os seus dados, com o fim de aceder a funcionalidades ou receber serviços ou provisões específicas. Em outras palavras, se um usuário concorda em submeter seus dados para aceder a um desconto numa loja online, isso requer seu consentimento expresso e também atende a uma necessidade: a de vincular o desconto a esse usuário em particular.

Vale ressaltar, contudo, que o consentimento expresso do usuário precisa ser dado ao fim para o qual o processamento dos dados se destina. Isto é, o usuário precisa de facto ser informado das razões pelas quais seus dados virão a ser processados. A recomendação aqui é descrever de forma clara, mesmo em caixas de confirmação em formulários ou textos que antecedam carrinhos e botões, a finalidade da requisição dos dados.

Se uma empresa exige que seja informado um e-mail, por exemplo, precisará descrever o porquê de fazê-lo. Enviará promoções? Uma newsletter? Ou o e-mail servirá apenas para registo e login? Por outro lado, dados pessoais como o NIF ou números do BI e seguridade social podem ser exigidos, mas o controlador dos dados, nesse caso, terá de ser muito mais específico ao descrever as razões pelas quais está a pedir tais dados, ainda que em formulários seja apenas opcional informá-los.

Base legal – vínculo contratual

A segunda das bases de legalidade para uso e processamento dos dados compreende “a execução de um contrato no qual o titular dos dados é parte, ou para diligências pré-contratuais a pedido do titular dos dados”. Isso significa que o próprio contrato no qual o titular dos dados é signatário prevê, de algum modo, a utilização e processamento desses dados como condição para a execução do disposto no contrato.

Em um exemplo claro, se um proprietário de uma aplicação online firma contrato com um indivíduo que irá utilizar esse sistema, para que venha a prestar o serviço contemplado no contrato precisará que o usuário submeta seus dados para login e operação da aplicação. Além disso, o consentimento é dado pelo titular dos dados no contrato assinado.

Base legal – outras possibilidades

As quatro outras bases de legalidade para o processamento e uso dos dados compreendem motivos que estão, em sua maioria, acima do processo de julgamento do próprio controlador dos dados. O artigo 6º do GDPR considera, nesse aspeto, as seguintes bases para processamento dos dados:

  • Cumprimento de obrigação jurídica
  • Defesa dos interesses “vitais” do titular dos dados
  • Interesse público
  • Interesses “legítimos”

No caso deste último item, os interesses “legítimos” são um ponto de discordâncias e contradições. Contudo, sob a óptica da lei, há razões bastantes para que se dê algum processamento dos dados de um usuário. Entre os motivos considerados “justos”, poder-se-ia citar o processamento dos dados com o fim ou objetivo de prevenir fraudes, o que acaba por refletir igualmente no interesse público e também nos interesses individuais do próprio usuário, no sentido de preservar a integridade dos seus dados e da sua identidade digital.

Em relação aos interesses ditos “vitais”, aqui considera-se de facto a existência de perigo ou ameaça que atente contra a vida ou integridade física do titular dos dados. Por exemplo, caso as informações ali retidas possuam dados de interesse médico, na eventualidade do seu titular estar em perigo ou temporariamente incapaz, o uso ou mesmo partilha desses dados poderá ser considerado legal à luz do GDPR europeu.

Utilizar o bom senso

Por mais intrincada que a interpretação do GDPR europeu possa parecer, empresas e instituições devem, primeiramente, atinar a respeito dos fatores de motivação da norma. Em suma, o GDPR aparece como um regulamento cujo objetivo é o de evitar e desencorajar abusos que possam ocorrer por conta do uso indevido ou não consentido dos dados dos indivíduos. Nesse contexto, qualquer utilização dos dados que não configure abuso pode ser considerado legal, uma vez que enquadrado nos seis itens previstos no artigo 6º do GDPR.

 

Tópicos que devem constar de uma Política de Privacidade

Há imensos modelos e muitos advogados a trabalhar na redação de Políticas de Privacidade sob as novas regras do GDPR europeu. Em muitos casos, documentos juridicamente perfeitos, apesar de sua correção legal, falham em atender a um dos mais básicos requisitos da nova lei: a compreensão.

Sob a luz do GDPR europeu, a Política de Privacidade não deve seguir a lógica de antigos “disclaimers”. A norma surgiu exatamente como maneira de contornar problemas de consentimento existentes a partir da não leitura ou incompreensão por parte dos usuários dos termos legais e detalhes ocultados em enormes textos de termos e condições que a maioria dos serviços online submetiam aos seus clientes.

Antes de optar por modelos específicos ou contratar advogados para produzir documentos, é preciso compreender que a Política de Privacidade precisa ser um documento de fácil compreensão e, necessariamente, suficiente para responder às seguintes questões:

  • Quem recolhe e processa os dados dos usuários?
  • Quais são os dados recolhidos nessa circunstância?
  • Quais as bases legais para a recolha e processamento desses dados?
  • Serão os dados partilhados com terceiros?
  • Como os dados e informações são utilizados e para que fim?
  • Por quanto tempo os dados permanecem armazenados?
  • Quais são os direitos do usuário como titular dos dados submetidos?
  • Como os usuários podem realizar reclamações ou denúncias e como podem exercer seus direitos?