Google NoCAPTCHA reCAPTCHA 84

Um exemplo de CAPTCHA de classe II desta natureza é o “Google NoCAPTCHA reCAPTCHA” (SHET, 2014). Para falarmos sobre ele, é necessário dar um pouco de histórico do projeto reCAPTCHA (AHN et al, 2008). Esse foi proposto em 2008 por Ahn et al (2008) como uma forma de aproveitar o tempo e esforço de pessoas que respondem os desafios em

uma espécie de sistema de informação altamente distribuído, com elementos não resolvidos e resolvidos, sendo os últimos constituídos por imagens que não foram reconhecidas satisfatoriamente por um OCR. Quando o usuário responde ambos os elementos, metade do seu trabalho valida o desafio e a outra metade é capturada como trabalho para o sistema distribuído.

Tal sistema é atualmente usado na conversão de trabalhos impressos, ou seja, imagens digitalizadas em textos digitais. Um exemplo da utilização do reCAPTCHA pode ser encontrado na Figura 5.4.

Figura 5.4 - reCAPTCHA

Fonte: http://www.google.com (2015)

Por sua vez, o Google NoCAPTCHA ReCAPTCHA busca simplificar a experiência de confirmação se determinado usuário é humano ou não, por meio da introdução de uma interface que permite que um número significativo de usuários previamente autenticados, ou que disponibilizem evidências suficientes que são humanos, cliquem apenas em um checkbox, conforme a Figura 4.6. Nos casos contrários, nos quais os usuários não foram autenticados

anteriormente e em que tais evidências não estejam disponíveis, o desafio terá que ser respondido, conforme a Figura 5.6.

Além do óbvio processo de facilitação para usuários finais na utilização do sistema reCAPTCHA, afinal os usuários vão apenas rapidamente clicar para seguir em frente, o argumento da equipe técnica é que os CAPTCHA tradicionais se confiam na incapacidade de robôs resolverem textos distorcidos. No entanto, uma pesquisa recente do próprio Google mostrou que a tecnologia de OCR é capaz de resolver o tipo mais difícil de texto distorcido em uma taxa de acerto de 99,8% (SHET, 2014).

Figura 5.5 – “No CAPTCHA reCAPTCHA” do Google

Fonte: http://www.google.com (2015)

A ferramenta de análise de riscos desenvolvida pela equipe do Google passa a considerar diversos fatores de engajamento do usuário para determinar se o mesmo é humano, para confiar cada vez menos no texto distorcido, considerado inseguro. Em contrapartida, uma melhor experiência para os usuários será oferecida, já que os mesmos, na maioria das vezes, poderão apenas clicar e seguir em frente, como demonstrado na Figura 5.5.

No entanto, naqueles casos em que a ferramenta de análise de riscos não consegue prever com um nível de segurança alto o suficiente se determinado usuário é humano, tipicamente, o “Google noCaptcha reCAPTCHA” apresenta um reCAPTCHA clássico para levantar mais pistas, conforme a Figura 5.6 apresenta, aumentando assim o número de pontos de checagem para confirmação. Para usuários em dispositivos móveis, um CAPTCHA clicável será exibido e o usuário pode utilizar o touchscreen para selecionar as respostas adequadas, ao invés de um reCAPTCHA, já que estes tornam necessária a digitação de texto. Para usuários em desktops, o administrador do site invocando a interface pode escolher se deseja a exibição de um reCAPTCHA clássico ou um clicável nessas situações.

Figura 5.6 – reCAPTCHA tradicional exibido no “No CAPTCHA reCAPTCHA”

Fonte: http://www.google.com (2015)

Além da autenticação prévia, semelhante ao processo explicado por Juels, Jakobsson e Jagatic (2006), o sistema utiliza “pistas comportamentais” para determinar se determinado usuário é humano, tais como: padrão de clique, cadência de digitação ou por quantos milissegundos o ponteiro do mouse fica descansando em determinado ponto antes de uma ação. Tantos detalhes, facilidade de uso e confiabilidade levaram empresas como Snapchat, Buzzfeed e Wordpress adotá-lo rapidamente (CONSTANTIN, 2014).

Entretanto, a forma como a ferramenta olha para o comportamento humano é muito parecida com aquela que a solução de e-mails do Google, o Gmail, utiliza para busca de spam e detecção de robôs, denominada Botguard (DANCHEV, 2014). Antes de mais nada, durante a verificação, ela olha se o usuário possui um cookie do Google na máquina. Então o Google NoCAPTCHA reCAPTCHA coloca seu próprio cookie no navegador, e busca por impressões pixel a pixel na janela de navegação do usuário, por informações como (HOMAKOV, 2014): objetos javascript, tamanho da tela, resolução, data, língua e plug-ins, endereço IP, informação CSS das páginas visitadas e uma impressão sobre o uso do mouse. Além disso, o CAPTCHA do Google vai pesquisar e utilizar qualquer cookie enviado por outros produtos do Google nos últimos seis meses, a crença é que os produtos do Google são utilizados de determinadas formas particulares e tais formas podem ser detectadas.

Toda essa informação é criptografada e enviada de volta para o Google. Ou seja, o uso do domínio google.com é intencional, e se os usuários permitirem, a empresa pode deixar cookies que ficam ativos por muito tempo nos computadores dos usuários, ignorando inclusive bloqueadores de anúncio, desde que o computador tenha utilizado algum serviço do Google anteriormente. Assim, são possíveis, basicamente, três situações (NACHI, 2014):

1.   Se os cookies do Google estão presentes, o usuário clica e segue em frente;

2.   Se os cookies do Google foram deletados, será necessário responder o desafio;

3.   Se algum plugin que impossibilite o acesso à identificação estiver sendo usado, independente da presença dos cookies, será necessário responder o desafio.

Devido ao exposto acima, podemos perceber que o Google NoCAPTCHA reCAPTCHA é, portanto, em sua essência, um CAPTCHA de Classe II que habilita um aspecto de autenticação baseada em histórico de uso e utilização dos usuários e se preocupa em incorporar aspectos de usabilidade na experiência com o usuário. Isso é evidenciado no fato de

os engenheiros terem tornado a versão desktop configurável e hoje é possível ignorar o desafio escrito completamente: em nossas configurações, habilitamos apenas a versão clicável do mesmo do reCAPTCHA para o passo 2 descrito acima, tanto para dispositivos móveis como para a versão do protótipo utilizada pelo computador. Dessa forma, por ser essa uma solução que foca nos aspectos de engenharia de software descritos neste Capítulo 4 para CAPTCHA de classe II e descreve tais requisitos com foco no usuário, mas sem deixar aspectos de segurança computacional de lado, propomos a adoção desse modelo de CAPTCHA na nossa abordagem.

No entanto, também há pontos a serem questionados neste tipo de CAPTCHA. É possível que o Google não esteja utilizando o novo CAPTCHA para saber apenas se um usuário é ou não humano, mas potencialmente exatamente qual humano ele seja, já que a combinação da autenticação por cookies com padrões de navegação pode ser mapeada para um indivíduo específico – e a grande maioria dos usuários clicando em “I’m not a robot” nunca entenderá realmente isso. Isso possibilita, indiretamente, ligar uma atividade de navegação realizada muitas vezes fora dos domínios do Google, sob a chancela da segurança computacional, ao conhecimento do Google sobre o indivíduo realizando a atividade, sem dar a tal usuário a possibilidade de se negar a prover tal conhecimento (HOMAKOV, 2014), o que pode possuir impactos em privacidade e confidencialidade.