Categoria: privacidade

Publicado em in privacidade, Segurança

O Que Torna uma Senha Forte

É obrigatório pela política das empresas. É uma boa prática recomendada por todos. E não é novidade para praticamente nenhum de nós: as senhas devem ser longas, variadas no uso de caracteres (maiúsculas, minúsculas, números, caracteres especiais) e não baseadas em palavras de dicionário. Bastante simples, certo? Mas deixe-me ir um pouco além e fazer uma pergunta não tão simples:

O que é mais forte, uma senha aleatória de 8 caracteres que potencialmente usa todo o conjunto de caracteres ASCII (maiúsculas, minúsculas, números, caracteres especiais (incluindo um espaço)) ou uma senha aleatória de 10 caracteres que usa apenas letras maiúsculas e minúsculas?

Desconsidere por um momento qualquer situação particular; essa não é a questão.

Como fazer uma comparação exata entre as duas senhas? Elas diferem de muitas maneiras. Na literatura especializada, um argumento afirma que uma senha mais longa, mesmo usando um conjunto de caracteres menor, é mais forte. Outro argumento pode afirmar que uma senha mais curta tem potencial de ser mais forte quando extraída de uma lista maior de caracteres potenciais. Um argumento é pela extensão, o outro é pela complexidade. Então, qual é o mais resistente a um ataque?

Esta questão se aplica diretamente a discussões de políticas dentro de uma organização. Como podemos avaliar a solidez de qualquer política de senhas proposta? Seus requisitos de política são arbitrários ou baseados em algum tipo de medida quantitativa? É simples dizer, “torne as senhas suficientemente longas, complexas e não baseadas em palavras do dicionário”, mas seria possivel quantificar o que é “suficiente” para uma determinada situação? Os cenários variam. Todos nós temos necessidades diferentes e os vários sistemas têm vários níveis de suporte de senha. Ainda cabem outras perguntas: existe um ponto de diminuição dos retornos sobre a complexidade da senha? Em que ponto elas se tornam tão longas e complexas que se tornam praticamente inutilizáveis? Existe uma resposta.

A resposta (ou parte dela, pelo menos) a essas perguntas está na quantidade de entropia informacional que a senha carrega. Volumes e mais volumes de discussão já foram impressos sobre os conceitos de entropia de informação e seus usos na comunicação, mas para nossos propósitos vamos apenas dizer que, no final, o conceito de entropia de senha nos fornece uma maneira de comparar empiricamente a força potencial de uma senha com base em seu comprimento e no universo de caracteres que ela pode conter. Para explicar o porquê, deixe-me começar com uma demonstração simples.

Selecione aleatoriamente uma letra de A – Z.

Agora vou tentar adivinhar. Quantas suposições você acha que vou precisar? Eu poderia adivinhar em apenas uma tentativa? Sim. Mas também posso precisar de 25 palpites, certo? Se eu simplesmente começasse a adivinhar aleatoriamente, meu sucesso também seria aleatório. Mas se eu aplicar os conceitos básicos da teoria da informação para a execução da tarefa, algo muito interessante acontece. Não importa qual letra você selecione, sempre precisarei de apenas quatro (4), e nunca mais do que cinco (5) perguntas para adivinhar sua letra. Em contraste, se eu fosse adivinhar ao acaso, precisaria, em média, de 13 tentativas para adivinhar sua letra. Mas quando conceitos de entropia de informação são aplicados, o número de perguntas / suposições cai para consistentes 4 ou 5. O motivo é bastante simples: eu não “adivinho” as letras; eu as elimino. Suponhamos que a letra que você selecionou seja “D”. Aqui está como minha cadeia de questionamento (o algoritmo) se comporta:

Pergunta 1: sua letra está entre N e Z? Resposta: Não.
    Se sim, sua letra está entre N-Z.
    Se não, sua letra é entre A-M.

Pergunta 2: sua letra está entre A e G? Resposta: sim.
    Se sim, sua letra é entre A-G.
    Se não, sua letra é entre H-M.

Pergunta 3: sua letra está entre A-D? Resposta: sim.
    Se sim, sua letra é entre A-D.
    Se não, sua letra é entre E-G.

Pergunta 4: sua letra está entre A-B? Resposta: Não.
    Se sim, sua letra é entre A-B.
    Se não, sua letra é entre C-D.

Pergunta 5: A sua letra é C? Resposta: Não.
    Se sim, sua letra é C.
    Se não, sua letra é D.

Resultado: sua letra é D. Estimativas: 5

Vamos fazer de novo. Desta vez, vamos supor que você escolheu aleatoriamente a letra “H”.

Pergunta 1: sua letra está entre N e Z? Resposta: Não.
    Se sim, sua letra está entre N-Z.
    Se não, sua letra é entre A-M.

Pergunta 2: sua letra está entre A e G? Resposta: Não.
    Se sim, sua letra é entre A-G.
    Se não, sua letra é entre H-M.

Pergunta 3: sua letra está entre H-I? Resposta: sim.
    Se sim, sua letra é entre H-I.
    Se não, sua letra é entre J-K.

Pergunta 4: A sua letra é H? Resposta: sim.
    Se sim, sua letra é H.
    Se não, sua letra é entre I-J.

Resultado: sua letra é H. Estimativas: 4

A imagem abaixo mostra a árvore de decisão usada. Cada ‘x’ laranja é uma pergunta. As letras destacadas em verde serão identificados em 4 questões e as letras destacadas em amarelo serão identificadas em 5. A árvore de decisão na imagem mostra apenas a metade esquerda do alfabeto (A-M). Você pode replicar o lado direito do alfabeto (N-Z) em uma árvore semelhante. Se você examinar o número de questões para todas as 26 letras do alfabeto, verá que seis (6) das letras podem ser identificadas em quatro (4) questões, enquanto as vinte (20) letras restantes serão identificadas em cinco (5) questões.

Árvore de decisão do problema

Então, se fôssemos jogar esse jogo de adivinhação indefinidamente, quantas perguntas, em média, eu precisaria para adivinhar a letra escolhida?

Para calcular o número médio de perguntas que terei que fazer para determinar sua letra, tenho que saber qual será a probabilidade de uma letra ser selecionada. Para este exemplo, estou supondo que cada uma das 26 letras do alfabeto tem uma chance estatisticamente igual de ser selecionada (mais sobre as nuances dessa suposição posteriormente). Um cálculo rápido mostra que 1/26 = 0,0384. Convertendo isso em porcentagem saberemos que cada letra tem 3,84% de chance de ser a letra selecionada aleatoriamente.

Como aqui não fugimos da matemática e valentemente a enfrentamos, há uma equação para essa pergunta. Vejamos:

Esta equação calcula H, que é o símbolo usado para entropia. Para o nosso alfabeto, a equação ficaria assim:

H = – [(0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) +
(0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) +
(0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) +
(0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) +
(0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) +
(0,038log2 • 0,038) + (0,038log2 • 0,038)] = 4,7004

E agora temos a resposta: terei que fazer uma MÉDIA de 4.7004 perguntas para determinar a letra selecionada aleatoriamente no alfabeto.

Mais formalmente, diríamos que existem 4.7004 ‘bits de entropia’.

Se você aplicar esta matemática a um único caractere selecionado aleatoriamente a partir dos diferentes conjuntos de caracteres que existem, você obterá o seguinte:

Binário (0, 1) -> H = 1 (1 bit de entropia)
Terei que fazer uma pergunta para determinar se o valor selecionado aleatoriamente é 1 ou 0.

Decimal (0-9) -> H = 3,32193 (3,2193 bits de entropia)
    Terei que fazer uma média de 3,32193 perguntas para determinar o número selecionado aleatoriamente (0-9).

Hexadecimal (0-9, A-F) -> H = 4.000
    Terei que fazer quatro (4) perguntas para determinar seu valor (a-f, 0-9)

Alfabeto maiúsculo e minúsculo (a-z, A-Z) -> H = 5,7004
    Terei que fazer uma média de 5.7004 perguntas para determinar sua letra selecionada aleatoriamente (a-z, A-Z).

Todos os caracteres ASCII imprimíveis (incluindo espaço) -> H = 6,5699
    Terei que fazer uma média de 6.5699 perguntas para determinar seu valor selecionado aleatoriamente.

Vamos desenvolver isso um pouco mais. Os números acima são para uma ÚNICA letra selecionada aleatoriamente. E se eu pedisse para você escolher duas (2) letras aleatoriamente? Agora, adivinhando uma letra de cada vez, quantas tentativas, em média, eu precisaria para descobrir as duas? A resposta é aditiva, o que significa que você só precisa adicionar a entropia para cada letra. Se a entropia de uma única letra minúscula é 4,7004, a entropia de duas letras selecionadas aleatoriamente é 4,7004 + 4,7004. Isso é 9.4008 perguntas para determinar as duas letras (assumindo a-z, como em nosso exemplo original). Se eu pedisse a você para selecionar uma seqüência de dez (10) caracteres aleatórios, seria necessária uma média de 47,004 perguntas (4,7004 * 10) para adivinhar todos eles.

Tudo bom, tudo bem, mas isso presume que sou capaz de adivinhar apenas um valor de cada vez. Se você escolhesse aleatoriamente 10 letras do alfabeto, eu poderia adivinhar a primeira em cerca de 4,7 tentativas, a segunda em 4,7 tentativas, a terceira em 4,7 tentativas e assim por diante. Mas no mundo real, não é assim que se adivinha senhas (um caractere por vez). Um invasor terá que adivinhar corretamente todos os dez valores de uma só vez para determinar as letras selecionadas aleatoriamente. Isso é, obviamente, uma coisa muito mais difícil de fazer. Mas quão difícil? Para descobrir, vamos voltar à pergunta original que fiz:

O que é mais forte, uma senha aleatória de 8 caracteres que potencialmente usa todo o conjunto de caracteres ASCII (maiúsculas, minúsculas, números, caracteres especiais ( incluindo um espaço)) ou uma senha aleatória de 10 caracteres que usa apenas letras maiúsculas e minúsculas?

Bem, se seu conjunto de caracteres tiver 26 letras minúsculas (az), 26 caracteres maiúsculos (AZ), e sua senha tiver 10 caracteres, haverá 5210 combinações possíveis de letras (26 caracteres (az) + 26 caracteres ( AZ) = 52 caracteres). Esse é um número grande. 144.555.105.949, 057.000 (144,5 quatrilhões), para ser exato ..

Então, para resumir esses valores:

Número de caracteres no conjunto de caracteres (a-z, A-Z): 52
Número de caracteres na senha: 10
Número total de combinações possíveis de sequências de 10 caracteres: = 52^10 = 144.555.105.949.057.000

É aqui que a magia entra em ação:

Qual é a entropia de um único caractere no conjunto completo de caracteres alfa (a-z, A-Z)? Já determinamos que é 5.7004.

Qual é o tamanho da sequência de caracteres selecionada aleatoriamente? 10 caracteres.

Qual é a entropia de uma string de 10 caracteres usando o conjunto de caracteres alfa maiúsculos / minúsculos? 5,7004 * 10 = 57,004

O que é 257,004 ? São 144.555.105.949.057.000 !!! Caramba!!! É o mesmo número que 5210 !!!

Sua string de 10 caracteres, maiúsculas / minúsculas (senha) tem 57,004 bits de entropia. Supondo que um invasor acertaria a string em 50% de todas as suposições possíveis, estimamos que ele / ela terá que fazer 72.277.552.974.528.300 suposições (sim, em média) antes de adivinhar sua string de 10 caracteres.

Para dizer isso de forma mais significativa: Uma senha de 10 caracteres maiúsculos / minúsculos tem 57,004 bits de entropia.

Então, quantos bits de entropia nossa senha concorrente tem? É uma senha de 8 caracteres que utiliza o conjunto completo de caracteres ASCII (incluindo um espaço). Se você voltar ao meio desta postagem, verá que um caractere selecionado aleatoriamente do conjunto completo de caracteres ASCII tem 6,5699 bits de entropia. Isso significa que uma senha de 8 caracteres selecionada aleatoriamente nesse intervalo terá 52.559 (8 * 6.5699) bits de entropia.

Para resumir os valores das senhas de 8 caracteres:

Número de caracteres no conjunto de caracteres (a-z, A-Z, 0-9, todos os caracteres especiais, incluindo espaço): 95
Número de caracteres na senha: 8
Número total de combinações possíveis de sequências de 8 caracteres: = 958 = 6.634.204.312.890.620 (6,63 quatrilhões)

E vemos que a magia é real:

Qual é a entropia de um único caractere no conjunto de caracteres ASCII completo (incluindo espaço)? Já determinamos que é 6,5699.

Qual é o tamanho da sequência de caracteres selecionada aleatoriamente? 8 caracteres.

Qual é a entropia de uma string de 8 caracteres usando o conjunto de caracteres alfa maiúsculos e minúsculos? 6,5699 * 8 = 52,559

O que é 252.559? É 6.634.204.312.890.620 !!! Caramba, de novo !!! É o mesmo número que 958 !!!

Nossa senha de 10 caracteres em maiúsculas / minúsculas tem 57,004 bits de entropia.
Nossa senha de conjunto de caracteres ASCII completa de 8 caracteres tem 52.559 bits de entropia.

Quanto mais bits de entropia uma senha possui, mais forte ela é. E, isso é importante, pois um único bit de entropia representa um aumento EXPONENCIAL na resistencia da senha. Há uma grande diferença entre a força de nossas duas senhas (4,445 ordens de magnitude); isso não é trivial. É algo enorme.

Então, por que usar a entropia como a expressão da força (resistência) da senha? Os gurus da teoria da informação podem certamente dar palestras por dias sobre essas questões, mas há uma resposta simples: os humanos são realmente péssimos para lidar com grandes números. Basta ver como lembramos números de telefone, endereços IP, números de cartão de crédito e números de CPF para evidenciar nossa repulsa por grandes números. Se houver uma maneira de simplificar a expressão de um valor, sempre optaremos por ela. Afinal, o que é mais fácil de dizer e entender ?:

Minha senha tem 5210 possibilidades vs 958 possibilidades.
ou;
Minha senha tem 57,004 bits de entropia vs 52,559 bits de entropia.

Com certeza você achará esta última forma mais agradável.

Quanto maior o número de bits de entropia de uma senha, mais forte ela tem o potencial de ser. Eu uso a palavra “potencial” aqui porque há muitas nuances nessa discussão que podem tornar esses números um reflexo impreciso da força da senha. A principal delas é o fato de que a maioria das senhas são geradas por humanos, não por geradores de números aleatórios. Os humanos são muito, muito ruins em gerar aleatoriedade. Somos terrivelmente péssimos nisso. Isso significa que a equação usada acima, que assume que cada caracter tem uma probabilidade igual de ser selecionado, não é tão precisa quando é uma pessoa que está escolhendo as letras. Quando invasores, com auxilio do poder de computação, começam a fazer suposições realmente boas sobre como as senhas estão sendo criadas (permitindo que eles excluam certos valores, por exemplo), a entropia pode cair muito rapidamente. Isso é não é bom.

É frequente acontecer que um dos sistemas de uma organização pode suportar o uso do conjunto de caracteres ASCII completo ao definir senhas, enquanto outro pode suportar apenas senhas alfanuméricas. Quantos bits de entropia uma senha deve ter para ser adequadamente segura? Quão longa uma senha alfanumérica deve ser para ser tão forte quanto uma senha que usa o conjunto completo de caracteres? Essas são perguntas muito importantes, especialmente quando se trata de uma política corporativa de senhas. Especificar o comprimento da senha pode ser uma medida inadequada de resistencia; especificar requisitos de entropia de senha tem o potencial de ser uma expressão muito mais consistente dos requisitos de segurança. Não tenho uma citação aqui, mas muitas organizações gostam de ter 80 bits de entropia ou mais. Nos dias de hoje, isso é muita entropia. Cheque novamente em alguns anos e certamente veremos que essa declaração se tornou falsa (pela Lei de Moore).

Uma observação final: há muitas variáveis ​​que devem ser discutidas ao explorar o assunto “senhas”. Complexidade, comprimento e entropia são todos ótimos itens para se entender, mas outros fatores podem ser tão importantes quanto. Por exemplo, quais mecanismos subjacentes suas senhas empregam? Qual algoritmo de hash? As senhas são “salgadas”? Há algum tipo de mecanismo de compatibilidade com versões anteriores habilitado (NTLM, etc.)? Essas coisas influenciam a discussão tanto quanto a entropia e podem ter um grande impacto em quanto esforço um invasor terá de fazer para adivinhar a senha. É um grande tópico, digno de muita reflexão e reflexão cuidadosa. A entropia é um ótimo lugar para começar… mas não é a única coisa a se considerar.

Publicado em in Internet, privacidade

Morte à Economia de Vigilância!

Neste exato momento, enquanto você lê este post, algoritmos estão tomando decisões sobre sua vida, com base em seus dados, sem o seu conhecimento e sem o seu consentimento. Algoritmos que muitas vezes não foram testados completamente, muito menos auditados periodicamente. Talvez você seja um dos milhões de negros americanos visados ​​pela Cambridge Analytica na tentativa de impedi-los de votar nas eleições de 2016. Talvez tenham negado a você um empréstimo, um emprego ou um apartamento recentemente.

Imagem: iStock

Se isso aconteceu, é quase certo que seus dados tenham algo a ver com isso. Esses dados pessoais na maioria das vezes são imprecisos, mas você não pode corrigi-los porque não tem acesso a eles. Você pode perder seu emprego devido a um algoritmo com defeito. E como disse o Cardeal Richelieu, “dê-me seis linhas escritas pelo mais honesto dos homens e eu encontarei nelas um motivo para mandá-lo para a forca”.

À medida que as empresas de tecnologia moldam nossas percepções, o preconceito e a discriminação – tão miseravelmente humanos – são incorporados naturalmente a seus produtos e serviços em vários níveis e de várias formas.

A economia de vigilância afronta a igualdade e a justiça. Você e seu vizinho não são mais tratados como cidadãos iguais. Você não tem oportunidades iguais a ele porque é tratado de maneira diferente com base em seus dados. Os anúncios e o conteúdo a que você tem acesso, os preços que paga pelos mesmos serviços e até o tempo que você espera no telefone para falar com o serviço de atendimento ao cliente dependem dos seus dados e de seu “score”.

Somos muito mais competentes para coletar dados pessoais do que para mantê-los seguros. Os dados pessoais são uma ameaça séria e não deveríamos coletá-los se não somos capazes de mantê-los seguros. Usando dados de localização de smartphones adquiridos de um “corretor de dados”, é possível rastrear oficiais militares com acesso a dados sigilosos, advogados poderosos e seus clientes, e até mesmo o presidente de um país (através do telefone de alguém que se considera e é pago para ser um agente do serviço secreto).

Nossa atual economia de dados é baseada na coleta de tantos dados pessoais quanto possível, armazenando-os indefinidamente e vendendo-os a quem pagar mais. Ter tantos dados confidenciais circulando livremente é, no mínimo, imprudente. Ao projetar nossa economia em torno da vigilância, estamos construindo uma perigosa estrutura de controle social, estrutura essa que está em conflito aberto com a liberdade. Na sociedade de vigilância que estamos construindo, não existe nada invisível ao radar. Não deveria ser nossa responsabilidade, como querem as grandes companhias, optar pela não coleta de dados nos navegadores. A não-coleta deveria vir como padrão em todo e qualquer software dedicado à comunicação na Internet.

É hora de acabar com a economia de vigilância. Não permitimos a compra e venda de votos (porque isso prejudica a democracia). Por que então devemos permitir a comercialização de dados pessoais? Não devemos permitir anúncios personalizados. Se os anúncios fossem transparentes sobre o que sabem sobre nós, talvez não fôssemos tão indiferentes ao modo como somos direcionados. As vantagens dos anúncios personalizados para os usuários são mínimas, na melhor das hipóteses, e podem ser alcançadas por meio de publicidade contextualizada. Por exemplo, exibir anúncios de equipamentos esportivos apenas quando o usuário procura equipamentos esportivos.

Precisamos ter certeza de que os algoritmos que afetam nossas vidas são confiáveis. Precisamos saber como os algoritmos estão nos julgando e com base em quais dados. Devemos implementar deveres de depositário fiel de dados: qualquer pessoa que deseje coletar ou gerenciar seus dados pessoais deve se comprometer legalmente a usá-los apenas em seu benefício e nunca contra você. Quem gerencia dados pessoais de terceiros é responsável ​​por eles. Temos que melhorar muito nossos padrões de segurança cibernética, através de lei. E é necessário também excluir periodicamente os dados de que não precisamos mais.

Enquanto a solução definitiva não aparece, escolha produtos compatíveis com a privacidade. Por exemplo, ao invés de usar a pesquisa do Google, use DuckDuckGo; em vez de usar o WhatsApp, use o Telegram; no lugar do Gmail, use ProtonMail. Essas escolhas simples podem ter um impacto muito significativo em nossas vidas. Ao escolher produtos éticos sinalizamos às empresas de Internet que nos preocupamos com a nossa privacidade.

Acabar com a economia de dados pode parecer uma proposta radical. Contudo, é ainda mais extremo ter um modelo de negócios cuja existência depende da violação de nosso direito à privacidade em grande escala.

Na verdade, isso é inaceitável.

Publicado em in Blockchain, Cripto, Internet, privacidade, Segurança

Blockchain e o Voto

De vez em quando sou questionado sobre ideias envolvendo sistemas de votação eletrônicos, remotos e blockchains. Este post fala sobre as propriedades mínimas de segurança que um sistema de votação precisa ter, e sobre onde as blockchains ajudam e onde não ajudam. Usamos como exemplo o sistema criptografado de votação STAR-vote. Pode ser um pouco árido para os usuários não técnicos, mas também pode ser interessante para quem gosta de se envolver mais profundamente no tema.

Uma interface digital abstrata, mostrando pastas com chave pública e dados de hash escritos em código.

A comunidade de computação concorda que sistemas votação rodando em máquinas de votar modernas têm ao seu dispor processadores muito rápidos e uma quantidade enorme de armazenamento. Esse hardware moderno torna menos árdua a tarefa de implementar redes que exigem computação de alta-performance, como a Blockchain. Vamos então usar esse dado estrutural para um experimento mental:

Usando o work-flow da Blockchain, vamos colocar as máquinas de votação em rede, dentro da Blockchain. Assim, voilà, temos uma estrutura descentralizada, com uma cópia de cada voto em cada máquina de votação; podemos até usar o emaranhamento da linha do tempo, para que o histórico de cada máquina seja protegido por hashes armazenados em todas as outras máquinas. O problema da votação eletrônica está resolvido.

Em um sistema eleitoral implementado na Blockchain, todas as máquinas do sistema possuem todos os registros de votos, tornando impossível a fraude. É o mesmo esquema que legitima transações financeiras. Neste caso, a transação é o voto.

Mas qual é o ponto forte de uma blockchain? No aspecto mais fundamental, trata-se de ter um registro histórico inviolável sobre eventos. No contexto de um sistema de votação, significa que uma blockchain é um lugar perfeito para armazenar cédulas e proteger sua integridade. O STAR-Vote e muitos outros sistemas de votação criptografados “ponta a ponta” adota o conceito de “quadro público de avisos” para onde os votos criptografados são enviados para armazenagem até a contagem. Blockchain é a maneira óbvia de implementar o quadro público de avisos.

Cada eleitor do STAR-Vote sai do local de votação com um “recibo” que é apenas o hash de sua cédula criptografada, que por sua vez tem o hash da cédula do eleitor anterior. Em outras palavras, todos os eleitores do STAR-Vote deixam o local de votação com um ponteiro para a blockchain que pode ser verificado de forma independente.

Acontece que mesmo os sistemas de votação baseados em blockchain precisam de muitas propriedades de segurança adicionais antes que possam ser efetivamente confiáveis. Aqui está uma lista simplificada, empregando algum vocabulário típico desta área de estudos para referenciar essas propriedades.

Propriedade “Votado como pretendido”.

Um eleitor está olhando para uma tela de algum tipo e escolhe em um botão: “Alice para presidente”. A máquina de votação prontamente indica isso com um pop-up, ou algum texto destacado, ou sons. Contudo, é totalmente possível que algum malware dentro da máquina possa registrar silenciosamente o voto como “Bernie para presidente”. Portanto, qualquer sistema de votação precisa de um mecanismo para derrotar malware que ameace comprometer a integridade da votação.

Nota: Uma abordagem interessante aqui [e já consagrada pelo costume americano] é ter cédulas de papel impressas (e/ou cédulas de papel marcadas à mão) que podem ser comparadas estatisticamente às cédulas eletrônicas. Outra abordagem é ter um processo pelo qual a máquina pode ser “desafiada” a provar que criptografou corretamente a cédula.

Propriedade “Votado em privacidade”.

É importante que não seja possível identificar um eleitor em particular pela forma como ele votou. A votação moderna deve garantir que os votos sejam secretos, com várias medidas tomadas para tornar difícil ou impossível para os eleitores violarem esse sigilo.

Quando se deseja manter a propriedade de privacidade eleitoral nas máquinas da votação, significa que deve-se evitar que a máquina retenha o estado interno (ou seja, mantenha em seus circuitos uma lista dos votos em texto aberto, na ordem de votação) e também deve garantir que o texto cifrado dos votos, publicado na blockchain, não está vazando silenciosamente, por meio de canais subliminares, informações sobre o texto aberto que o gerou.

Propriedade “Contado como votado”.

Se temos eleitores levando para casa um recibo de algum tipo que identifica seu voto de texto cifrado na blockchain, então eles também podem querer ter algum tipo de prova criptográfica de que a contagem final do voto inclui seu voto específico. Isso acaba sendo uma aplicação direta de primitivos criptográficas homomórficos.

Se olharmos para essas três propriedades, é possível notar que a blockchain não ajuda muito com as duas primeiras, embora seja muito útil para a terceira.

Atingir a propriedade “votado como pretendido” requer uma variedade de mecanismos que vão de cédulas de papel a desafios pontuais para máquinas. A blockchain protege a integridade do voto registrado, mas nada tem a dizer sobre sua fidelidade à intenção do eleitor.

Para alcançar uma propriedade “votado em privacidade”, é necessário bloquear o software na plataforma de votação e, nesse caso, bloquear a máquina de votar. E como essa propriedade de bloqueio pode ser verificada? Precisamos de garantias fortes que possam ser verificadas de forma independente. Também precisamos garantir que o usuário não possa ser enganado e levado a executar um aplicativo de votação falso. Podemos conseguir isso no contexto das urnas eletrônicas comuns, que são utilizadas exclusivamente para fins de votação. Podemos implantar centralmente uma infraestrutura de chave criptográfica e colocar controles físicos sobre o movimento das máquinas.

Mas, se estendermos este experimento mental para incluir o voto pela Internet, um desejo comumente expresso pelo público de alguns países [que talvez aconteça], veremos que não temos infraestrutura hoje para fazer isso usando telefones celulares e computadores pessoais – e provavelmente não a teremos nos próximos anos. O voto remoto [em casa, no escritório, na rua] também torna excepcionalmente fácil para um cônjuge, um chefe ou um vizinho vigiar por cima do seu ombro e “ajudá-lo” a votar da maneira que eles querem que você vote.

As blockchains acabam sendo incrivelmente úteis para verificar a propriedade “contado como votado”, porque obriga todas as máquinas do sistema a concordar com o conjunto exato de cédulas que está sendo tabulado. Se um funcionário eleitoral precisar desqualificar uma cédula por qualquer motivo, esse fato precisa ser público e todos precisam saber que uma cédula específica, ali na blockchain, precisa ser descontada, caso contrário, a matemática criptográfica não vai fechar.

Concluindo, é fácil ver como as blockchains fornecem elementos primitivos excepcionalmente úteis, que podem ajudar a construir sistemas de votação em que a contagem final é consistente com os registros de votos lançados. No entanto, um bom sistema de votação precisa satisfazer muitas propriedades adicionais que uma blockchain não pode fornecer. Embora haja uma certa sedução intelectual em fingir que votar não é diferente do que mover criptomoedas em uma blockchain, a realidade do problema é um pouco mais complicada.

Publicado em in Internet, privacidade

Pros & Cons: o Novo Sistema de Classificação de Usuários do Google

Como já “discutimos” recentemente, e vamos continuar a fazê-lo, o todo-poderoso Google está para introduzir uma nova sistemática para distribuição de seus anúncios dirigidos. O sistema é chamado FLoC, sigla em inglês para Aprendizagem Federada sobre Coortes, e ele pretende substituir os notórios ‘cookies’ em nossos dispositivos. Essa sigla vai passar a fazer parte do cotidiano de todos na rede, portanto o aprendizado virá automaticamente com o tempo. O foco aqui é estimular a discussão dialética dos prós e contras entre os tecnologistas militantes e aspirantes. Assim, delineio abaixo alguns comentários sobre o assunto, tentando enquadrar as duas correntes.

Antes, algumas definições rápidas:

Cookies de site: são os cookies comuns, armazenados pelos sites em seu navegador. Eles podem ser usados para configurar preferências nos sites visitados, mas são rotineiramente abusados para rastreamento.

Cookies de terceiros: são como os cookies de site, mas usados unicamente para rastreamento. O cruzamento das informações que eles carregam revela quem você é e o que está fazendo (largamente alimentados por Smartphones).

FLoC: armazenado em seu dispositivo, rastreia a atividade no navegador e coloca o usuário em um determinado grupo, ou, digamos, um “balde”… Google alega que esse sistema é mais anônimo do que os cookies de terceiros, porque apenas o Google terá a informação sobre seu histórico. Mas mesmo assim, esses “baldes” ainda dizem tudo sobre você. Não há limite à informação que esses baldes podem conter e nem a como ela é usada. Além disso, o Google marca seu ID em todos os navegadores, de forma que é muito fácil converter esse “rastreamento anônimo” de volta à ‘persona’ identificável do usuário

O FLoC classifica os usuários em “coortes” [grupos] com base em seus interesses percebidos. A coorte, que reside em seu computador, é então passada ao site que você visita, para que ele possa segmentar anúncios para você, usando as informações que sua coorte dá a ele. Antes os sites faziam isso usando os chamados “cookies de terceiros.”

Na atribuição de coorte A, os usuários são classificados nas coortes 1 e 2 pelos sites que visitam. Na atribuição de coorte B, os usuários são classificados nas coortes 1 e 2 pelos gostos pessoais.

Basicamente, o problema para o Google é que os cookies de terceiros estão sendo mortos pelas políticas contemporâneas de privacidade dos navegadores e as tecnologias alternativas a eles dificultam o rastreamento adequado de todos. Então o Google é levado a construir o FLoC como uma alternativa fácil para contornar o bloqueio dos navegadores aos cookies de terceiros. Com o FLoC, um site qualquer não poderá usar cookies de terceiros para rastrear os usuários diretamente. Mas então, você não só ainda tem o rastreamento, mas também dá agora muito mais poder ao Google, que é o dono da tecnologia. Todos os seus gostos pessoais e comportamentos estão lá para para que eles façam com esses dados o que bem entenderem.

O Google afirma que esse esquema é melhor para a privacidade, porque todo o rastreamento que interessa é feito no navegador e mantido local [em seu computador]. O site só recebe um identificador geral de coorte, e como as coortes conterão milhares de usuários, elas serão de uso limitado para o rastreamento de indivíduos particulares.

Existem inúmeros problemas com essa tese. Para começar, a implementação é o que chamaríamos de “meia-boca”, com o sistema de atribuição de coorte não sendo suficientemente resistente à deanonimização. Um adversário poderia simular milhares de sessões de navegação e observar quais identificadores de coortes resultam delas. Adicionalmente, se um adversário controla vários sites populares, ele pode usá-los para forçar usuários a frequentar coortes selecionadas.

E há a questão dos temas “sensíveis”. O Google afirma que vai garantir que coortes sensíveis sejam bloqueadas. Portanto, não haverá nada relativo a religião, orientação sexual e semelhantes. Mais uma vez, o problema é que a listagem dos grupos sensíveis que eles vão ter é incompleta e, para piorar, baseada em tabus e problemas sociais ocidentais. De fato, é muito provável que coortes abusivas sejam criadas, colocando as minorias em perigo em regimes autoritários e ditaduras.

O FLoC também quebra o modo privado de navegação. Por padrão, o FLoC envia um valor nulo ao servidor do site quando não há dados suficientes para atribuir um usuário a uma coorte ou quando ele estiver no modo privado de navegação. Isso dá aos adversários uma maneira de detectar, por dedução, a navegação privada.

O Outro Lado

É tentador apenas dizer “sem cookies de terceiros e sem FLoC! Queremos a web privada!”. A realidade é que, se essa abordagem for algum dia adotada por navegadores, os custos seriam empurrados de volta para o usuário de alguma forma. O FLoC não é perfeito, mas é melhor que os cookies, e é, pelo menos, a ideia geral correta para uma solução que possa manter o atual sistema suportado por anúncios rolando, evitando os problemas de privacidade mais egrégios.

Se os usuários / navegadores / plataformas de conteúdo não puderem chegar a algum tipo de consenso com os anunciantes em termos do equilíbrio privacidade versus “anúncios dirigidos“, os anunciantes vão anunciar menos – o que vai prejudicar muitos sites usados por muitas pessoas – ou eles exigirão dos provedores de conteúdo que forneçam soluções de segmentação de anúncios com propriedades ainda piores: coisas como “Login com o Facebook para ver este conteúdo“. Adicionalmente, sites precisarão de mais anúncios (e anúncios mais intrusivos) para gerar o mesmo tanto de receita publicitária.

Epílogo

Pessoalmente, eu adoraria ver algum tipo de sistema de micro-pagamentos tomar o lugar da web suportada por anúncios – mas essa ideia parece ser fortemente rejeitada pela maioria dos usuários, julgando-se pela incrível quantidade de ítens “grátis” consumidos diariamente na rede. A não ser que haja uma mudança significativa no panorama, temo que certas pessoas e instituições vão, como sói acontecer, rejeitar uma solução imperfeita (FLoC) em favor de algo ainda não conhecido e muito pior.

Publicado em in Internet, privacidade

FLoC: A Nova Experiência Controversa do Google

No dia 30 de março último, o Google lançou o “teste de origem” do Federated Learning of Cohorts – Aprendizagem Federada sobre Grupos (que tem o acrônimo inglês FLoC), sua nova tecnologia experimental para segmentação de anúncios. Um comando foi dado em Mountain View, California, e um switch foi silenciosamente acionado em milhões de instâncias do Google Chrome mundo afora: esses navegadores começarão agora a classificar seus usuários em grupos (Cohorts) com base em seu comportamento pessoal, compartilhando os rótulos desses grupos com rastreadores e terceiros anunciantes. Um conjunto aleatório de usuários foi selecionado para o teste, e a eles só foi dada a opção de desativar os cookies de terceiros no navegador.

Embora o Google tivesse anunciado previamente que isso iria acontecer, a empresa até agora foi esparsa em detalhes sobre o teste. Nós bisbilhotamos posts de blogs, listas de discussão, projeto de padrões da Web e o código-fonte do Chromium para tentar descobrir exatamente o que está acontecendo.

A EFF (Electronic Frontier Foundation) já escreveu que o FLoC é uma ideia terrível. O lançamento desse teste pelo Google – sem aviso prévio aos indivíduos que farão parte, muito menos seu consentimento – é uma violação concreta da confiança do usuário, e para completar, a serviço de uma tecnologia que não deveria sequer existir.

Abaixo descrevemos como esse teste funcionará e alguns dos detalhes técnicos mais importantes que soubemos até agora.

Começamos com a decepcionante observação de que o FLoC deveria originalmente substituir os cookies. No teste, ele os complementará.

O Google projetou o FLoC para ajudar os anunciantes a dirigir ao alvo seus anúncios quando os cookies de terceiros desaparecerem no futuro. Contudo, durante este teste, os rastreadores continuarão capazes de coletar, além dos IDs dos FLoCs, os cookies de terceiros.

Isso significa que todos os rastreadores que atualmente já monitoram o comportamento do caro leitor em uma parte da Web usando os cookies, agora vão receber adicionalmete seu IDentificador de grupo gerado pelo FLoC. O ID de grupo é um reflexo direto do seu comportamento em toda a Web. Ele pode complementar os perfis comportamentais dos usuários, o que muitos rastreadores já mantêm.

Foi divulgado que o teste foi originalmente distribuído para 0,5% dos usuários do Chrome em algumas regiões – por enquanto, isso significa a Austrália, Brasil, Canadá, Índia, Indonésia, Japão, México, Nova Zelândia, Filipinas e os EUA. Os usuários nessas regiões serão escolhidos de maneira completamente aleatória, independentemente das configurações de anúncio e privacidade do navegador. Somente usuários que desativaram cookies de terceiros no Chrome serão excluídos.

Além disso, a equipe por trás do FLoC solicitou que o Google aumente a amostra de 0,5 para 5% dos usuários, para que as empresas de tecnologia possam treinar melhor os modelos de Machine Learning usando os novos dados. Se essa solicitação for acatada, dezenas ou centenas de milhões de usuários adicionais serão incluidos no teste. Os usuários foram inscritos no teste automaticamente. Ainda não há como optar por não participar.

Versões futuras do Chrome adicionarão controles dedicados para isto que o Google chama de “Sandbox de Privacidade”, que inclui o FLoC. Mas não é claro quando essas configurações serão lançadas. Assim, por ora os usuários que desejam desligar o FLoC só podem fazê-lo desativando os cookies de terceiros.

Desligar os cookies de terceiros não é uma má ideia em geral. Afinal, esses cookies estão no centro dos problemas de privacidade que o Google diz que quer resolver. Mas desligá-los completamente é uma contramedida bruta, que quebra muitas conveniências (como logon único) nas quais os usuários da Web confiam. Usuários do Chrome conscientes sobre privacidade geralmente empregam ferramentas mais direcionadas, incluindo extensões, como o Privacy Badger, para evitar o rastreamento baseado em cookies. Infelizmente, as extensões do Chrome ainda não são capazes de controlar se um usuário expõe um ID de FLoC. Os sites também não estão sendo solicitados a optar.

O FLoC computa um rótulo de grupo com base no histórico de navegação. Para o teste, o Google vai usar os sites que servem anúncios – isto é, a maioria dos sites na web. Os sites podem optar por ser incluídos em computações de FLoC enviando um cabeçalho HTTP, mas alguns provedores de hospedagem não fornecem aos clientes controle direto sobre os cabeçalhos de seus sites. Muitos proprietários de sites provavelmente não estão cientes do teste.

Isso é um problema porque significa que os sites perdem controle sobre como os dados dos visitantes serão processados. Na prática atual, um administrador de site tem que tomar uma decisão deliberada de incluir o código de um anunciante em sua página. Os sites geralmente podem, pelo menos em teoria, optar por fazer parceria com anunciantes para gerar receita, limitados pelas suas políticas de privacidade. Contudo, agora, informações sobre a visita de um usuário a um site serão embrulhadas em seu ID do FLoC, que será amplamente disponíbilizado pela web (mais sobre isso na próxima seção). Mesmo que um site tenha uma forte política de privacidade e relacionamentos com anunciantes responsáveis, uma visita pode afetar como os rastreadores o vêem em outros contextos. O ID do FLoC de cada usuário – o rótulo que reflete seu histórico de navegação da semana passada – estará disponível para qualquer site ou rastreador que o quiser.

Qualquer um pode se inscrever nesse teste de origem do Chrome. Depois de cadastrado, pode-se acessar os IDs dos FLoCs dos usuários que foram escolhidos para o teste. Isso inclui o vasto ecossistema de anunciantes sem nome ao qual seu navegador se conecta sempre que você visita a maioria dos sites. Se você faz parte do teste, dezenas de empresas podem obter o ID de FLoC de cada site que você visita. Haverá mais de 33.000 grupos possíveis.

Uma das porções mais importantes da especificação do FLoC que ficou indefinida é exatamente quantos grupos existem. O Google fez um experimento preliminar empregando IDs de grupo de 8 bits, o que significa que havia apenas 256 grupos possíveis. Isso limitava a quantidade de rastreadores que poderiam saber o ID de grupo de um determinado usuário.

No entanto, um exame mais recente do Chrome revela que a versão ao vivo do FLoC usa identificadores de grupos de 50 bits. Os grupos são então juntados em lotes de 33.872 grupos, 100 vezes mais do que no primeiro experimento do Google. O Google disse que isso vai garantir que “milhares de pessoas sejam juntadas em cada grupo, de forma a que ninguém possa ser identificado individualmente”. Mas os IDs de grupo ainda vão expor muitas informações – cerca de 15 bits – e vão dar um grande peso a ítens biométricos, como impressões digitais.

O Google prometeu adotar salvaguardas para que os grupos não estejam muito correlacionados com “categorias sensíveis” como raça, sexualidade ou condições médicas. Para monitorar isso, o Google planeja coletar dados sobre quais sites são visitados por usuários em cada grupo. O teste provavelmente durará até julho. O Google liberou um whitepaper descrevendo como será sua abordagem.

Fico feliz em ver uma proposta específica, mas o Whitepaper dá um jeito de contornar os problemas mais prementes. A questão que o Google devia perguntar é: “Podemos, eticamente, segmentar grupos vulneráveis?”; O white paper reduz isso para “Podemos segmentar as pessoas que visitaram um site específico?”. Esta é uma simplicação perigosa. Em vez de trabalhar no problema difícil, o Google escolheu se concentrar em uma versão mais fácil que acredita poder resolver. Enquanto isso, não está conseguindo endereçar os graves potenciais problemas do FLoC.

Durante o teste, qualquer usuário que tenha ativado “Chrome Sync” (deixando o Google coletar seu histórico de navegação), e que não tenha desabilitado nenhuma das várias configurações de compartilhamento padrão, compartilhará o ID de grupo ligado ao seu histórico de navegação..

Na tentativa de mitigar essa potencial intrusão, o Google irá então verificar se cada usuário visitou quaisquer sites que considere parte de uma “categoria sensível”. Por exemplo, o WebMD poderá ser rotulado na categoria “Médica”, ou o Pornhub na categoria “Adulto” (ambas sensíveis). Se muitos usuários em um grupo visitaram um tipo específico de site “sensível”, o Google obfuscará esse grupo. Quaisquer usuários que fizerem parte de grupos “sensíveis” serão colocados em um grupo “vazio” (na tentativa “proteger” esses usuários por obfuscação). É claro que os rastreadores ainda poderão ver que os referidos usuários fazem parte do grupo “vazio”, ​​revelando que, logo, eles eram originalmente classificados como do grupo “sensível”.

Para o teste de origem, o Google está recorrendo ao seu enorme tesouro personalizado de dados de navegação. No futuro, o Google planeja usar outra tecnologia (não especificada) de preservação de privacidade para fazer a mesma coisa sem acessar o histórico de navegação dos indivíduos.

Independentemente de como o Google faz isso, esse plano não resolverá os maiores problemas com FLoC: discriminação e segmentação predatória. A proposta repousa sobre a suposição de que as pessoas em “categorias sensíveis” visitarão sites específicos “sensíveis”, e que as pessoas que não estão nesses grupos não visitarão esses sites. Mas o comportamento humano se correlaciona com a demografia de maneira não intuitiva. É altamente provável que certas demografias visitem um subconjunto diferente da web do que outras demografias, e que tal comportamento não seja capturado pelo simples enquadramento de “sites sensíveis” do Google. Por exemplo, pessoas com depressão podem exibir comportamentos de navegação semelhantes, mas não necessariamente algo explícito e direto, como, por exemplo, visitar o site “depression.org”. Enquanto isso, as empresas de rastreamento são bem equipadas para reunir o tráfego de milhões de usuários, vinculá-lo a dados sobre demografia ou comportamento e decodificar quais grupos estão ligados a quais traços sensíveis. O sistema do Google, conforme proposto, não tem como parar isso.

O Google poderia fazer a escolha de desmantelar os antigos andaimes da vigilância sem substituí-los por algo novo e unicamente prejudicial. O Google não conseguiu abordar de verdade os possíveis danos do FLoC, ou mesmo nos convencer de que esses danos podem ser abordados. Em vez disso, ele está levando a cabo um teste que compartilhará novos dados sobre milhões de usuários desavisados. Este é outro passo na direção errada.

Fonte: Electronic Frontier Foundation – Licença Creative Commons