Ativação de câmera oculta pelos navegadores: Big Brother ou erro de cálculo da tecnologia?

Olá pessoal!

Meu nome é Vadim e sou um dos consultores técnicos e, ao mesmo tempo, administrador do sistema do RosKomSvobody .

Mas este post não será sobre mim. Será uma história sobre uma situação suspeita (em termos de privacidade no contexto de telefones celulares) que encontramos recentemente.
Pode ser no estilo de "Aaaaaaaaa! Olha, o Big Brother (Google) está nos seguindo"), mas tentarei fazer algum tipo de análise e apresentar hipóteses plausíveis sobre por que o que aconteceu pode acontecer.

Peço desculpas antecipadamente se alguém não gostar do formato à "revista} {akep to zero". Escrever - serei corrigido.

Então Um de nossos leitores se aproximou de nós, alegando que, ao entrar em nosso site (que, ironicamente, o topo da nossa campanha contra o reconhecimento de rosto - o BanCam fica no topo), a câmera frontal é ativada.

O fato é que ele é o proprietário de um telefone de uma nova geração de telefones sem "grilhões", nos quais a câmera frontal é colocada em uma bandeja "de saída" separada. O que, de fato, sai ao acessar a câmera.

Como você provavelmente adivinhou, meus primeiros pensamentos foram suspeitas de que, de alguma forma, éramos milagrosamente, apesar de todos os "mecanismos de segurança" que eu estava construindo, ainda hackeados e "construídos".

No entanto, a investigação revelou que tudo está em ordem com o nosso site.

Depois de conduzir a investigação acima mencionada e discutir suas descobertas no bate-papo técnico do RosKomSvoboda, lembrei-me de que já havia encontrado em vários fóruns na Internet que o Trojan "escapou" através de redes de banners (ao abrir o fórum a partir de um telefone Android) pacotes apk (aparentemente, na esperança de que o usuário os instale, pensando que este é o cliente oficial deste fórum).

Depois de pensar nessa idéia, sugeri tentar verificar os "rastreadores" que estavam na lista de permitidos (este leitor usa o Firefox e o complemento uBlock instalado).

Algumas horas de experimentos mostraram que a câmera para de se mover se você bloquear o acesso ao domínio google.com . Além disso, em algum lugar ao mesmo tempo, esse usuário disse que essa situação também está sendo reproduzida no site kod.ru (antes disso, trabalhamos com a versão “only with us”).

Depois de me aprofundar um pouco mais nas escavações, descobri que os pedidos ao google.com provocam não apenas os rastreadores do Google (também conhecidos como "analytics"), mas também a "incorporação" usual de vídeos do YouTube em uma página. A reprodutibilidade da saída da câmera no kod.ru também caiu nessa teoria (como se viu, também havia um vídeo do YouTube na página testada).

Para confirmar ainda mais essa teoria, pesquisei em um post aleatório no blog como "como inserir um vídeo do YouTube em um blog, uma instrução em vídeo" com um vídeo embutido, e a situação também foi reproduzida nele.

Então Bom No momento, temos essas informações em nossas mãos: a presença de um vídeo interno do YouTube na página aciona o carregamento de alguns scripts do google.com e esses, por sua vez, acionam a saída da câmera.

Ok, cave mais.

Pesquisando nas ferramentas de depuração do navegador, descobri que um estranho e terrivelmente ofuscado (tanto que nenhum dos desobfusadores que eu tentei nos resultados da pesquisa suportava) carregado em www.google.com (ou seja, www ) carregado, mesmo com um nome e que ofuscado (conhecendo o Google, posso assumir que, depois de um tempo, esse script desaparecerá e, em seu lugar, será colocado um script com um nome diferente (mas igualmente ilegível). Então, aqui está o código , apenas no caso).

Uma rápida olhada no script não mostra nenhuma referência à câmera aqui e não há tempo e oportunidade para aprofundar ainda mais a depuração e interpretar o que ela faz lá (embora se algum de vocês leitores quiser, você pode fazê-lo).

Tentamos entrar do outro lado:
Pessoalmente, tenho um telefone sem uma câmera de saída, por isso é tão fácil atrair um apelo para ela que não consigo. Mas eu posso conectá-lo via USB e fazer adb logcat | grep -C5 camer adb logcat | grep -C5 camer ( grep - porque, caso contrário, há muito lixo irrelevante para cada espirro, inclusive tocando na tela com o dedo ou movendo o telefone no espaço). O que estou realmente fazendo ...

Então, a primeira tentativa: vou aos sites testados e ... nada!

O pensamento surge, que o problema parece, afinal, estar do lado do usuário.

Paralelamente a esse processo, estamos discutindo a situação no bate-papo técnico do RosKomSvobody acima mencionado. Depois de algum tempo, um dos participantes recebeu a opinião de que, segundo eles, os navegadores móveis são astutos: nem sempre solicitam direitos de acesso global à câmera e, se não forem concedidos, em alguns casos, talvez não!

Vou para as configurações do aplicativo e vejo que sim, não defini permissões para a câmera do Firefox. Eu o ligo, verifico novamente e vejo uma folha para algumas "telas" com o seguinte:

Sim! Apelar para a câmera, então ainda há!
Além disso, imediatamente após a linha com "obter informações do dispositivo", há uma abertura explícita do dispositivo da câmera:

 12-12 17:10:14.734 751 6924 I QCamera : <HAL><INFO> int qcamera::QCamera2Factory::cameraDeviceOpen(int, struct hw_device_t **): 405: Open camera id 0 API version 256 

Verifico o mesmo com o Chrome e tudo é reproduzido: se os direitos da câmera forem retirados, no registro "silêncio dos cordeiros" e se for emitido - a mesma folha que o acesso à câmera aparece com a tampa de açafrão.

Então o problema é:
a) não é local para o usuário,
b) não específico ao navegador.

Curiosamente, durante todos esses eventos, nenhum desses navegadores tentou dizer uma palavra sobre solicitar permissão para acessar a câmera de qualquer um dos sites participantes do teste (e de fato também do YouTube e do google.com ).

À luz do exposto, duas hipóteses nasceram para mim:

1. Ou o Big Brother, no entanto, está observando você, ou
2. esse script horrivelmente ofuscado na realidade chama alguma parte da API da câmera nos navegadores para impressões digitais do usuário, mas não acessa a câmera diretamente. Portanto, não há solicitação de acesso a ele (no entanto, se você observar o vídeo no início do artigo, poderá ver como o LED pisca entre abrir e fechar a câmera, o que faz você pensar).

Os navegadores, no entanto, seguem a lógica aqui: "ao inicializar a API da câmera, se não houver acesso à câmera, não fazemos nada (nem solicitamos até que haja uma necessidade real); se houver, inicializamos as câmeras e verificamos quais dispositivos temos lá e o que eles podem "(para os quais, aparentemente, o dispositivo é" descoberto ").

Ao que parece, o fornecedor de telefone do usuário não se aprofundou na invenção de muletas de software sobre a câmera e resolveu o problema simplesmente (pelo qual ele, a propósito, respeita): ao acessar a câmera, ela sai. Quando você abre o dispositivo e troca dados com ele, o diodo pisca.

No total, verifica-se que o problema não é tão fatal como parecia no começo e, esperançosamente, ninguém tira fotos (embora isso, no entanto, ainda não seja "preciso", porque minha competência em saber Os códigos-fonte do Android não são suficientes para garantir inequivocamente, nesse caso, a folha de chamadas para a câmera no logcat fala sobre a foto tirada e na qual - apenas sobre as conversas seculares do aplicativo com o dispositivo).

No entanto, no entanto, o fato de a abertura de qualquer página da Web na qual haverá um iframe com um vídeo embutido do YouTube leva a uma chamada para a câmera (e até algum tipo de negociação com o dispositivo) ainda é bastante triste no contexto de privacidade e, parece-me, ainda vale a discussão da comunidade.

O que você acha?

PS Em inglês, este post foi publicado no Medium .

UPD : obrigado aos berez e ksil habrachians por um pacote de correções ortográficas (caso contrário, quando você lê e reescreve diferentes partes do texto, como de costume, "corrigir alguns bugs, trouxe muitos outros")