Resumo sobre Cookies

O que são Cookies, de verdade?

Cookies são pares de informação do tipo NOME=VALOR que são armazenados em um cliente HTTP
(user agent), que pode ser um navegador, um app, ou qualquer outro programa que ofereça está
funcionalidade.

Não importa como o navegador o armazena! O chrome, por exemplo, armazena todos os cookies de
todos os domínios em um único arquivo binário, por exemplo, ao contrário dos “pequenos arquivos
texto” que a maioria das definições erradas trazem.

Por que, diabos, inventaram isso?

Quando você acessa uma página em um navegador, e clica em algum hiperlink, sendo direcionado
para outra página, esta página não tem ideia de nada que aconteceu antes. É o que chamamos de
stateless em computação: O estado não é preservado entre as páginas, inclusive dentro de um
mesmo site. (Você até consegue saber de onde você veio, mas nada que ajude muito)

Quando os sites começaram a ficar um pouco mais complexos, com sistemas de “login”, por
exemplo, ficava muito difícil avisar a próxima página que o usuário já estava “logado”, e ainda assim
era muito inseguro (dava para simular um login facilmente).

Assim, definiu-se um protocolo para preservar o estado entre requisições HTTP, e surgiram os
cookies. Para quem quiser ver, tá aqui (https://tools.ietf.org/html/rfc6265).

Então, eles não serviam para rastrear as pessoas?

Não. O Uso principal de um cookie era o seguinte:

Ao fazer o login em um site, o servidor escrevia algo como “LOGIN:OK” num cookie. Ao clicar na
próxima página, este par de informação era enviado para o servidor que testa se o LOGIN for igual a
OK, mostra a página, senão, vai pra página de login,,,,,

Mas, como todo protocolo, aberto, começaram usar os cookies pra outras coisas, como por
exemplo, guardar preferências de linguagem (para sites que tinham mais de uma língua), ou outras
coisas. O importante é que, desde o começo, estes cookies eram acessados somente por que o
escreveu.

Hoje, basicamente, as boas práticas sugerem que se usem cookies criptografados, e com o mínimo
de informação possível, mantendo as informações relativas às funcionalidades nos servidores.
Óbvio, pode ter sites que guardam dados pessoais abertos nos cookies, mas isso não é a prática. Isso
é o caso particular, errado!

Além disso, existe um padrão chamado JWT para autenticação em APIS que pode usar cookies, mas
basicamente segue os mesmos princípios. No entanto, as vezes, temos mais informações nestes
tokens!!!
Quem pode criar um cookie?

Os cookies são “criados” por um comando enviado de uma página WEB ou num cabeçalho HTTP
recebido do servidor (conforme o standard mostrado acima).

Em palavras mais simples, um site pode criar um cookie, seja mandando o comando lá do seu
servidor, seja mandando o comando pela própria página, via javascript, por exemplo.

Quem pode ler um cookie?

A própria página (usando javascript) ou o servidor QUE CRIOU o cookie. Os cookies são restritos aos
seus criadores. Assim, quando você acessa o www.site1.com você não vê os cookies criados pelo
www.site2.com e vice-versa.

(Vou citar o Google, por ser um exemplo conhecido, mas o mesmo vale para inúmeros outros sites)

Então como o Google, por exemplo, consegue ler os cookies em vários sites que passei?

Está é a pergunta certa!

Os navegadores aceitam que, dentro de um site, via javascript ou requisições de imagens e scripts,
sejam carregados conteúdos de outros servidores. Por exemplo, ao colocar um vídeo do youtube na
sua página, você está carregando informações lá do youtube. Mas isso vale para qualquer coisa
mesmo. Quando você insere uma imagem vinda de outro servidor, você pode estar carregando
muito mais do que a imagem. E mais... VOCÊ ESTÁ ENVIANDO várias informações para este outro
servidor. (Depois a gente discute este fato)

Vou usar, de novo, um exemplo do Google, o Analytics, mas serve para qualquer serviço.

Assim, quando alguém coloca uma TAG do Google Analytics no seu site, com o objetivo de ter um
relatório bonitinho sobre as visitas que aconteceram nele, temos duas implicações imediatas:

A primeira é que o Google cria um cookie (ou mais, mas poderia ser só 1) no navegador com um ID
que ele conhece.

A Segunda é que várias informações podem ser enviadas para os servidores do Google (e para
qualquer outro lugar, via scripts), incluindo os próprios cookies, mas não restritas a eles.

Então imaginem, como exemplo, que você acessou o www.site1.com e ele tem o Analytics. O Google
cria um cookie lá no navegador, chamado ga_id, por exemplo.

E agora que a mágica acontece: Quando você abre o www.site2.com (que também tem o Analytics),
e que não pode ver os cookies do www.site1.com, o Google consegue ver o ga_id que ele criou lá no
outro site!!!! Por que? Porque o cookie ga_id está vinculado ao domínio (servidor) do Google
Analytics e não ao domínio do site1. E no site2, o Analytics pode ler este cookie, já que está no
mesmo domínio que foi criado, mesmo o site2 não tendo acesso a ele.

Isso é o que chamamos de cross-domain cookie ou third-party cookie. Na verdade, pode até ser mais
simples, já que, via javascript é possível ler os cookies do navegador, e ao inserir um código
javascript de terceiros, este código é executado como se fosse da sua página, e pode obter todos os
cookies que lá estão escritos, e enviar, em background, estas informações para onde quiser,
inclusive para um terceiro ou quarto! Pior, é possível fazer tudo isso sem usar cookies, usando o
localstorage.

Mas afinal, os cookies guardam mesmo dados pessoais?

Podem guardar, sim, já que eles podem guardar qualquer coisa que um site queira.

Mas note, eles guardam apenas as informações que são solicitadas por um site. Todas as demais
inferências, nada tem a ver com os cookies, mas sim com a transferência de informações para
servidores que acontece quando inserimos uma TAG ou acessamos um recurso (imagem) em outro
servidor, por exemplo.

Seguindo, ainda, o mesmo exemplo do Analytics, não são cookies que indicam o IP, o navegador, a
resolução da tela, o tempo de uso do site, os locais clicados, ou por onde o mouse se moveu, nada
disso, não são cookies que agrupam por localidade, por sexo, ou por qualquer outro meio de
segmentação! Estas informações são obtidas por scripts nas páginas e/ou por header do HTTP (o
protocolo da internet), e são enviadas para terceiros ativamente ou passivamente, que é o que mais
ocorre. E junto com estas informações, o ga_id, que por um acaso está armazenado em um cookie, é
enviado junto. De posse dele, o Google sabe tudo o que precisa.

Assim, os cookies permitem que um usuário (ou um navegador, no limite) seja “seguido”, mas a
culpa não é do cookie, e sim de poder carregar uma TAG de um site em vários sites! Isso vale para
pixels do Facebook, para APIS das mais variadas, para os re-capchas da vida, para aquele lance de
“faça o login com sua conta da rede social”, para hotsites do RD ou links do mailchimp, etc.

O que tem de errado em transferir informações para terceiros?

Se as informações que estão sendo enviadas para terceiros forem dados pessoais, mesmo que o
titular não esteja identificado no site, mas possa ser identificado no terceiro, está acontecendo uma
coleta e uma transferência de dados pessoais. E a LGPD obriga que o site tenha uma hipótese de
tratamento válida para isso, e que a finalidade esteja bem determinada, e que dentre todas as
outras exigências da Lei, que, pelo menos, os princípios da necessidade e da transparência sejam
respeitados. Tem uma decisão judicial na Europa que considerou que um site que colocou um botão
de curtir do Facebook em seu site também é controlador dos dados que estão sendo enviados para
o Facebook, mesmo que ele, o site, sequer tenha acesso a estes dados!

Mas eu tenho uma política de cookies!!!!

Sim, a maioria esmagadora das políticas de cookies, e dos respectivos avisos de cookies,
simplesmente, não faz nenhuma ação útil para cumprir com o que a LGPD exige. Na verdade, eles
solicitam uma espécie de consentimento (totalmente em desacordo com o consentimento da LGPD)
para escreverem (ou usarem) cookies. Como já foi descrito anteriormente, o uso dos cookies é só
um pedacinho MUITO pequeno dos tratamentos que ocorrem, e achar que os dados pessoais (além
do ID) estão armazenados nos cookies, é ideia de quem nunca os usou, de fato. Duvido muito que,
em caso de questionamento, uma política de cookies proteja alguma empresa de uso indevido de
técnicas de obtenção de perfil por mapas de calor ou movimento do mouse.
E as iniciativas de substituir os cookies?

Os cookies não devem ser substituídos. Talvez os third party sejam bloqueados, ou somente o
domínio “principal” possa ler os cookies. Mas, se forem, os serviços de anúncios, por exemplo,
podem arrumar alternativas imediatamente para continuar “seguindo” um usuário. Ou pior, uma
grande empresa pode “inventar” uma solução e acabar com o livre mercado “em nome da
privacidade”...

Para se evitar abusos, na realidade, basta seguir a Lei e fazer duas coisas, inicialmente:

Primeiro, questionar a hipótese de tratamento para um site transferir os dados para um terceiro.

Segundo, questionar a hipótese de tratamento para o terceiro fazer uso dos dados recebidos.

Quer um exemplo prático? Um site www.site1.com tem uma área de anúncios, e instala uma TAG
para um terceiro exibir os anúncios no seu site. Neste momento, usando cookies ou não, o terceiro
recebe informações do cliente, eventualmente identifica quem é o usuário (ou as vezes apenas se
este usuário acabou de entrar no site das havaianas) e exibe um banner de produtos indicados para
um perfil ou um retarget (um banner das havaianas)...

Como garantir a legalidade disso? Se abolirmos os cookies, alguém vai achar outro jeito de contornar
a situação! Então, primeiro, questionamos: www.site1.com, enviar informações para o terceiro é um
tratamento de dados que tem uma finalidade específica X. Qual a hipótese de tratamento que você
está usando? Imagine agora que esta pergunta seja respondida!!!! Vem a segunda: Terceiro, você
recebeu alguns dados do site1, e realizou alguns tratamentos para decidir qual banner mostrar. Qual
a hipótese de tratamento que te autoriza a tratar estes dados?

Se ambas as perguntas tiverem resposta, o banner poderá ser enviado como hoje! Se não, não!
Simples assim.

Algumas alternativas falam em criar identidades com os cuidados necessários, etc, etc... Estas
iniciativas estão aparecendo para ajudar responder a pergunta 2. O próprio iRespect tem uma
solução bastante interessante para isso, que cuida muito bem da privacidade dos usuários, mas que
depende, realmente, das pessoas aderirem a ela, das empresas aderirem ou começarem a usar
autorizações criptográficas para o controle de acesso, ou seja, solução há, e o problema deve haver
também, senão os grandes players não estariam arrumando uma alternativa! Uma solução só faz
sentido se ela for aberta e disponível para todos.

Feliz 28 de janeiro de 2021

Gustavo Zaniboni