Autenticação Privacy Pass para a busca do Kagi

• O Kagi Search passou a adotar autenticação Privacy Pass para verificar o direito à busca paga sem vincular diretamente as consultas à conta
• Esse método separa geração de tokens e uso de tokens, permitindo que o Kagi valide a autenticidade sem conseguir rastrear retroativamente o usuário nem o momento da geração apenas com o token
• O público inicial são os planos Professional, Ultimate, Family e Team, que incluem buscas ilimitadas; Trial e Starter, que têm limite de buscas, ficaram de fora por ainda haver problemas de perda de tokens e uso acima do permitido
• Pode ser usado diretamente no Orion, no app Kagi para Android e nas extensões para Chrome e Firefox; o Safari ainda não é compatível por limitações da API de extensões
• Só com o token já é difícil ligar a busca à conta, mas endereço IP, fingerprint do navegador e padrões repetidos de busca continuam existindo como canais laterais, por isso o uso de Tor ou VPN é recomendado

---

Autenticação Privacy Pass adicionada ao Kagi Search

• O Kagi lançou a autenticação Privacy Pass no Kagi Search e também publicou junto um Tor onion service
• Privacy Pass é um protocolo de autenticação que permite ao cliente provar o direito de acesso sem que o servidor consiga identificar qual usuário acessou
• Como o Kagi é um mecanismo de busca pago, ele precisa verificar o direito de uso, mas com esse recurso adiciona uma garantia técnica de que as requisições de busca não ficam ligadas a uma conta específica
• A implementação partiu da implementação Rust de Privacy Pass de Raphael Robert, e o código está público em kagisearch/privacypass-extension

Planos e clientes compatíveis

• O Privacy Pass será oferecido primeiro aos usuários dos planos de buscas ilimitadas Professional, Ultimate, Family e Team
• No momento, Trial e Starter não são compatíveis
  • Esses dois planos têm limite mensal de buscas
  • Se os tokens gerados forem perdidos, por exemplo ao remover a extensão, a experiência do usuário pode piorar
  • Como o Kagi não sabe qual conta ou plano está usando o token no momento do uso, teoricamente seria possível usar mais tokens do que o número de buscas permitido
• Os clientes compatíveis são os seguintes
  • Orion Browser: integração nativa no macOS/iOS/iPadOS
  • Kagi for Android: versão 0.29 ou superior
  • Extensão para Firefox e extensão para Chrome
• Usuários da extensão existente do Kagi Search devem atualizar para a versão mais recente ou desativá-la para evitar problemas de compatibilidade
  • Firefox: 0.7.6
  • Chrome: 1.2.2.5

Fluxo de autenticação do Privacy Pass

• O Privacy Pass divide a autenticação em duas etapas: geração de tokens e uso de tokens
• Na etapa de geração, o usuário prova com o cookie de sessão do Kagi que tem autorização para gerar tokens
  • Do ponto de vista do servidor, os tokens gerados não se distinguem de tokens aleatórios
  • Os tokens não podem ser rastreados até o usuário que os gerou nem a outros tokens criados pelo mesmo usuário
• Ao fazer uma busca, é enviado um token previamente gerado para provar o direito de acesso
  • O servidor apenas confirma que aquele token já foi gerado de forma válida em algum momento
  • Não é possível ligar o token a uma etapa específica de geração
• Os tokens são de uso único
  • O servidor rastreia tokens já usados para impedir reutilização
  • O cliente também não deve enviar o mesmo token duas vezes, para que etapas diferentes de uso não possam ser conectadas
• Os tokens têm validade fixa, então tokens antigos demais precisam ser gerados novamente

Modelo de implementação do Kagi e propriedades de segurança

• O modelo de implantação do Kagi segue a estrutura Shared Origin, Attester, Issuer do padrão Privacy Pass
  • O próprio Kagi exerce os papéis de Attester, Issuer e Origin
  • O usuário atua como cliente por meio da extensão de navegador Privacy Pass ou do suporte nativo do Orion
• A extensão gera e armazena um grande número de tokens após a instalação e depois periodicamente
• Ao pesquisar, o usuário pode escolher por alternância entre autenticar com o cookie de sessão existente ou com um token Privacy Pass
• Há três propriedades de proteção ao usuário
  • Não vinculação entre geração e uso: o Kagi não consegue ligar um token enviado em uma busca à etapa específica em que foi gerado
  • Não vinculação entre usos: o Kagi não consegue saber, apenas pelo token, se duas buscas diferentes vieram do mesmo usuário
  • Proteção contra roubo no uso: um interceptador que observe o processo de geração não consegue roubar e usar o token apenas com essa informação
• Também há propriedades de proteção para o Kagi
  • Tokens gerados corretamente passam na verificação do Kagi
  • Um cliente malicioso não consegue forjar novos tokens válidos mesmo conhecendo tokens corretamente gerados

Recursos reduzidos no modo Privacy Pass

• No modo Privacy Pass, o Kagi não consegue identificar o usuário, então não pode aplicar as configurações da conta
• O Kagi descreve isso como uma escolha entre “privacidade normal e funcionalidade completa” ou “privacidade máxima e recursos essenciais”
• O Kagi Assistant não pode ser usado com Privacy Pass no lançamento
  • O Kagi Assistant é oferecido apenas a membros Ultimate
  • No Privacy Pass não há informação de conta para verificar qual plano está em uso
• No lançamento, o Privacy Pass serve apenas para autenticação no Kagi Search
• O Kagi pretende expandir o suporte nas semanas seguintes para os seguintes serviços
  • Kagi Assistant
  • Kagi Translate e Kagi Maps
  • Kagi Universal Summarizer e Ask questions about page
• No momento, para usar esses serviços é preciso desativar o Privacy Pass

Canais laterais e uso do Tor

• O Privacy Pass impede que geração e uso do token sejam ligados apenas pelo token, mas não consegue descrever matematicamente toda a interação online de forma completa
• Um servidor malicioso pode tentar rastrear o cliente usando informações de canais laterais
  • Se alguém repetir todos os dias, no mesmo horário, a mesma busca específica, pode-se inferir que essas buscas vieram da mesma pessoa
  • Sinais como user-agent do navegador e endereço IP são informações fora do escopo do Privacy Pass
  • Se um pedido de uso de token vier logo após um pedido de geração de token a partir do mesmo IP, ele pode ser interpretado como vindo da mesma pessoa
• A RFC 9576 recomenda separar temporalmente a geração e o uso do token, ou separá-los espacialmente com um serviço de anonimização como o Tor
• A extensão Privacy Pass do Kagi e a implementação nativa do Orion removem cabeçalhos HTTP e cookies para tornar a fingerprint do navegador o mais uniforme possível
• O Kagi oferece um endereço onion acessível diretamente pela rede Tor
  • kagi2pv5bdcxxqla5itjzje2cgdccuwept5ub6patvmvn3qgmgjd6vid.onion
• Usar só o Tor esconde o endereço IP, mas se o usuário estiver logado sem Privacy Pass, teoricamente as buscas ainda podem ser ligadas a uma única conta
• Ao usar Tor junto com Privacy Pass, o Kagi só sabe que aquela busca veio de um usuário cujo direito de receber tokens foi validado antes, sem saber a conta nem a localização

Quantidade de tokens, desempenho e armazenamento

• Usuários de planos com buscas ilimitadas podem gerar 2.000 tokens por epoch, ou seja, por mês
• Se forem necessários tokens adicionais, é possível solicitar em [e-mail]
• Gerar 500 tokens de busca exige cerca de 1 segundo de computação em um notebook comum de consumo
  • Isso pode levar alguns segundos a mais por causa do tempo de conexão com o servidor e da resposta
  • Na instalação da extensão, isso é feito em segundo plano sempre que possível
• Cada token tem 216 bytes, e o espaço de armazenamento por requisição de geração de tokens é de cerca de 100 KiB
• No momento, o servidor de validação de tokens está implantado apenas na região us-central1, e o Kagi pretende expandi-lo logo após o lançamento

Por que personalização e configurações ficam limitadas

• Em buscas com Privacy Pass, o Kagi não sabe quem é o usuário, então não pode fornecer resultados ajustados às configurações personalizadas dele
• O Kagi considerou enviar pequenas configurações em cada requisição, como (language, region, safe-search), mas no momento entende que isso pode reduzir bastante o anonimato
• Na análise de exemplo, um usuário que envie uma configuração de idioma específica como Lang 10 pode perder automaticamente a garantia de não vinculação entre usos quando houver cerca de 1.000 usuários de Privacy Pass
• O Kagi considera que essa estimativa pode ser conservadora demais, mas por enquanto não habilita o nível padrão de personalização para usuários autenticados com Privacy Pass
• Algumas configurações manuais de busca podem ser aplicadas adicionando bangs à consulta
  • Por exemplo, ao colocar !de no início da busca, é feita uma pesquisa para a região da Alemanha
• Quem quiser uma experiência de busca totalmente personalizada precisa usar o método tradicional de login e desativar o Privacy Pass

Restrições do Safari, janelas privativas e outros pontos

• O Privacy Pass não usa blockchain
  • Ele usa curvas elípticas, funções hash e uma estrutura de função pseudoaleatória verificável e oblivious
  • Os tokens não são gerados, armazenados nem negociados em blockchain
• Em janelas privativas do Chrome e Firefox, a geração de tokens não funciona
  • A geração de tokens exige acesso ao cookie de sessão
  • Em janelas privativas, a extensão não consegue acessar o cookie de sessão
  • No Orion, a geração de tokens funciona mesmo em janelas privativas
• Mesmo com o Privacy Pass ativado, o Kagi consegue ver o endereço IP da requisição de busca por causa do funcionamento do TCP/IP
  • Se houver preocupação com a exposição do IP, é recomendado usar Tor ou uma VPN confiável
• Todos os tokens expiram à meia-noite do primeiro dia do mês X+2, com base no mês X em que foram gerados
  • Isso evita que datas de expiração semelhantes entre tokens criados no mesmo momento sejam usadas para identificar várias buscas
• O Safari não é compatível no momento
  • Pelo que o Kagi apurou, a API de extensões do Safari não oferece suporte para remover cookies das requisições
  • Sem remover os cookies, a autenticação continua sendo feita pela conta logada
  • Quem quiser uma experiência semelhante e nativa baseada em WebKit pode usar como alternativa o Orion Browser, que já integra Privacy Pass

[GN⁺]

Comentários do Hacker News

• É bom ver a Kagi agora usando Privacy Pass, e a empresa em si também parece boa no geral
  Ainda assim, a Kagi basicamente pegou o rascunho da IETF [1] e a implementação em Rust [2] em que trabalhei por um tempo, fez um wrapper fino [3] por cima e está chamando isso de “implementação de Privacy Pass da Kagi”
  Acho que eu deveria ter recebido pelo menos algum crédito. O trabalho na IETF e em software open source em grande parte é voluntário, não remunerado e muitas vezes feito fora do horário de trabalho. Ser tratado assim desmotiva. A Kagi pode fazer melhor
  [1] https://datatracker.ietf.org/doc/draft-ietf-privacypass-batc...
  [2] https://github.com/raphaelrobert/privacypass
  [3] https://github.com/kagisearch/privacypass-lib/blob/e4d6b354d...

  • Sinceramente, a “implementação de Privacy Pass da Kagi” mencionada no texto parece se referir não à implementação do RFC ou do protocolo em si, mas à parte de integrar essa funcionalidade aos servidores e clientes da Kagi. O RFC é reconhecido no próprio texto
  • Fico curioso se a Kagi estaria em conformidade só adicionando “crédito ao raphaelrobert” ou colocando uma cópia da licença em algum lugar no código
    Meu open source nunca foi usado de fato, e normalmente eu publico sob licença MIT, então queria saber como outros grupos ou organizações costumam cumprir a licença na prática
  • Quando capturei o cabeçalho do README em 14 de fevereiro de 2025, por volta de 12h15 no horário do leste dos EUA, estava escrito o seguinte

    This repository contains the source code of the core library implementing the Privacy Pass API used by Kagi.
    Isso certamente não passa uma boa impressão. Ainda assim, parece provável que o pessoal da Kagi esteja aberto a mudar para algo mais preciso, como “biblioteca principal que implementa um wrapper em Crystal Lang para raphaelrobert/privacypass”. Parece mais provável que eles estivessem focados em fazer funcionar e não tiveram alguém para revisar o texto com mais atenção, do que algo intencional

• Legal. É raro ver um serviço que eu uso realmente fazer algo que beneficia o usuário em vez de a si mesmo, então foi uma surpresa inesperada e muito agradável
  Seria bom se essa extensão entendesse automaticamente o contexto do navegador para se integrar melhor. Ou seja, no modo normal usar minha sessão, e no modo de navegação privada (browser.extension.inIncognitoContext) me autenticar com Privacy Pass sem que eu precise fazer nada à parte
  Não uso o Orion porque ele não tem versão para GNU/Linux

  • Isso ficou raro porque a maioria das empresas desse setor, e na verdade muitas empresas de tecnologia, têm usado um modelo de mercado de dois lados: oferecem algo a um grupo de usuários e depois monetizam vendendo o resultado a outro grupo de usuários
    Como é o segundo grupo que gera a receita de fato, a estrutura tende por padrão a colocar os interesses do primeiro grupo em conflito com os do segundo, e a ser hostil ao primeiro
    O que torna a Kagi e outras novas empresas de tecnologia revigorantes é que elas abandonaram esse modelo e voltaram a um modelo “à moda antiga”, em que o grupo que elas atendem e o grupo de onde tiram receita são o mesmo
  • Ontem comecei a trabalhar no Orion para Linux
  • A desvantagem dessa abordagem é que, se você não estiver em uma rede grande, o anonimato pode ser quebrado apenas pelo endereço IP
    A Kagi sabe que o usuário fez login e, se ele fizer buscas sensíveis em uma janela privada, pode correlacionar essas buscas. Ficar alternando de modo rapidamente não é desejável
  • Caso você não soubesse, no fim de 2024 anunciaram em um podcast que estavam planejando uma versão Linux do Orion
  • Ao usar a Kagi, a gente se acostuma a ver escolhas corretas. Chega a ser surpreendente como quase não houve erros
    Queria que isso também valesse para a minha camiseta da Kagi. A barra soltou na segunda lavagem, então agora ela virou camiseta de pijama e de mexer no quintal. Recebi um cupom para uma camiseta de reposição grátis, mas ela ainda não foi enviada

• Como o texto também sugere, faria sentido haver uma loja para comprar Privacy Pass sem conta
  Teria de aceitar alguma criptomoeda, provavelmente Monero, e talvez também GNU Taler se essa tecnologia um dia ficar viável

  • A Kagi aceita Bitcoin, mas o fundador Vlad disse no fórum que tão poucas pessoas usam essa opção que não faz sentido investir em suporte a Monero
  • Concordo que uma loja terceirizada vendendo tokens sem conta seria a solução ideal, mas sem conta você perderia recursos que tornam a Kagi realmente útil, como remover domínios específicos dos resultados ou aumentar a prioridade de certos tipos de resultado

• Fiquei na dúvida se, no fim das contas, isso é privacidade assumindo que os logs não são mantidos. Não estou tentando arrumar confusão; é que realmente não estou entendendo essa parte
  Digamos que o usuário A peça tokens ao Kagi e o Kagi diga: “beleza, vou te dar 500 tokens”. Se o Kagi registrar os 500 tokens que acabou de dar ao usuário A, então quando um deles for usado depois ele não conseguiria saber que aquele token foi atribuído ao usuário A?
  Claro, se o Kagi não guardar esses dados, o token em si só fica marcado como válido/inválido e não como “token válido dado ao usuário A no dia Y”, então tudo bem, mas é só isso mesmo? Estou entendendo algo errado?

  • Não é o servidor que gera os tokens; é o cliente que gera. O servidor precisa conseguir verificar se aquele token foi criado por um cliente autorizado a gerá-lo, mas não deve conseguir saber qual cliente o criou. Pelo menos, deveria ser assim na ausência de informação de canal lateral

    The main building block of our construction is a verifiable oblivious pseudorandom function (VOPRF)
    Não sei o quão bem validada essa primitiva é, mas pelo menos parece haver bem mais estrutura aqui do que um servidor entregando tokens ao cliente e depois fingindo que não sabe para quem entregou
    Artigo de referência: https://petsymposium.org/popets/2018/popets-2018-0026.pdf

  • A documentação do Privacy Pass [0] aborda essa parte, mas a explicação mais profunda está principalmente nos artigos. Pelo que entendo, o ponto central é que o token devolvido pelo servidor é impossível de vincular ao token modificado que o cliente envia de volta depois
    O servidor sabe que devolveu os tokens A, B e C para certos usuários, e depois recebeu os tokens X, Y e Z. Ele também sabe que X, Y e Z são válidos, mas não conhece a correspondência entre eles e os tokens que emitiu. Isso usa criptografia de curva elíptica
    [0] https://privacypass.github.io/
  • A ideia é que o token não fica ligado a nenhuma conta. É um token anônimo
  • Acho que você não entendeu a premissa dos tokens do Privacy Pass
    O ponto principal é que o servidor não sabe a qual cliente qualquer token pertence. O servidor não gera o token

• O maior defeito do Kagi, na minha opinião, que eu sempre vi, agora foi resolvido. Obrigado por ouvirem e trabalharem nisso para tornar o produto atraente para praticamente todo mundo

• Uma das maiores reclamações de quem ainda não usa o Kagi é a preocupação com privacidade por exigir login e informações de pagamento
  Eu não estava entre os que se preocupavam com isso, mas fico curioso em saber até que ponto essa mudança reduz a preocupação de quem realmente estava

  • Eu era uma dessas pessoas, e ainda é quase inacreditável para mim a ideia de fazer login em um mecanismo de busca. Claro, hoje eu sei quantas pessoas já fazem isso
    Depois de validar o sistema rapidamente, agora é bem provável que eu me cadastre
  • Supondo que a criptografia funcione como o Kagi disse, essa abordagem separa completamente as consultas de busca das informações da conta. A conta cria vários tokens de busca, e cada consulta consome um token
    Os tokens são gerados no dispositivo e não saem dele até serem usados, então em teoria o Kagi não tem como saber, olhando só para o token, qual conta o criou. Isso não resolve rastreamento por fingerprint nem correlação por IP, mas dizem que os plugins para Firefox e Chrome tomam medidas para reduzir fingerprinting. Isso não é nem pior nem melhor do que simplesmente usar Google ou DuckDuckGo e, se você realmente quer privacidade, também funciona no Tor
    Não tenho certeza de como a legitimidade é provada sem compartilhar o token em si, mas imagino que entre algum tipo de ~~prova de conhecimento zero~~
    Edit: não é prova de conhecimento zero, parece ser assinatura cega

• Não está claro para mim o que impediria alguém do lado da Kagi de adicionar uma nova coluna à tabela de tokens com o usuário que gerou o token e seu SessionCookie
  Não vejo por que isso não poderia ser vinculado com bastante facilidade ao criador original do token

  • Sou o implementador. No protocolo de “emissão” do Privacy Pass, o cliente gera uma “mensagem” que o servidor vai processar. A saída do servidor volta para o cliente, e o cliente modifica essa saída mais uma vez para criar o token final
    Como esses tokens são randomizados na última etapa de modificação feita pelo cliente, o servidor não consegue identificar a qual processo de emissão aquele token pertence
    O mais legal é que isso continua valendo mesmo que o servidor tente fazer algo malicioso na etapa dele. Então o usuário só precisa confiar no software cliente, e nós o publicamos como código aberto: https://github.com/kagisearch/privacypass-extension
    Algumas pessoas estão mencionando assinaturas cegas, e de fato o Privacy Pass pode usá-las como componente. Mas, para ser preciso, na Kagi estamos usando “Privately Verifiable Tokens” baseados em uma “Oblivious Pseudorandom Function” (OPRF) (https://www.rfc-editor.org/rfc/rfc9578.html#name-issuance-pr...), e pessoalmente acho OPRF ainda mais legal do que assinaturas cegas
  • Parece ser o que é descrito no artigo citado [1], sobre protocolos criptográficos de tokens anônimos. Não é um simples token em texto puro
    https://petsymposium.org/popets/2018/popets-2018-0026.php (“Privacy Pass: Bypassing Internet Challenges Anonymously”)
    Acho que a Cloudflare também implementou isso. Pelo menos os comentários no HN estão linkando o mesmo artigo
    https://news.ycombinator.com/item?id=19623110 (“Privacy Pass (cloudflare.com)”, 53 comments)
  • Os tokens são “gerados” no cliente, e o servidor só fornece ao cliente informação suficiente para que aquele token gerado localmente se torne “válido”. Ainda assim, ele não consegue vincular esse token a uma tentativa específica de verificação
  • Eu pensei exatamente nessa pergunta também. Como não dá para depender de confiança no lado do servidor, queria saber se entendi alguma coisa errado
  • Se entendi corretamente, o “Privacy Pass” usa assinaturas cegas, então não é possível correlacionar o token contido em TokenResponse com o token fornecido na consulta de busca

• Isso realmente funciona na prática? Como os tokens só podem ser usados uma vez, na realidade o cliente vai acabar entrando em um loop de gerar e usar tokens dentro de uma sessão específica de busca, o que tornaria muito fácil correlacionar os pares. O próprio texto diz isso

  For this reason, it is highly recommended to separate token generation and redemption in time, or “in space” (by using an anonymizing service such as Tor when redeeming tokens, see below).
  O Tor randomizaria o espaço, mas e o tempo? Então fui ver a parte do “see below”, mas não encontrei nada relevante. A ideia é que, com volume suficiente de requisições, os clientes acabam se encobrindo mutuamente no tempo?
  Além disso, o Tor também tem limites para randomizar o espaço, a menos que você recrie a sessão o tempo todo. Até onde eu sei, o circuito fica fixo durante a sessão, e recriar a sessão leva uns 10 segundos. Então isso realmente conta como randomizar o espaço?

  • Uma única solicitação de token pode criar N tokens. Nós definimos N = 500, então a maioria dos usuários só precisa solicitar novos tokens bem raramente

• Trabalho realmente incrível
  Já tentei construir algo parecido com o Privacy Pass, com autenticação por assinatura cega, e tenho curiosidade sobre como vocês pretendem lidar com acesso em vários dispositivos
  Imagino que o lançamento inicial apenas para usuários com buscas ilimitadas tenha sido para mitigar o problema de perder acesso aos tokens em outros dispositivos. Queria saber se há alguma ideia para o plano de longo prazo. Quando eu já construí sistemas assim no passado, sempre acabava tendo de amarrar isso a sincronização com criptografia de ponta a ponta. Além de ser incômodo para o usuário final, isso também abre margem para correlacionar atualizações do armazenamento com requisições cegas de busca
  De qualquer forma, é realmente impressionante, e agora fico ainda mais animado por poder verificar que não é apenas uma questão de confiar na Kagi, mas de não precisar confiar nela

  • Sim, múltiplos dispositivos definitivamente não é algo simples. Já experimentamos algumas ideias, mas não é um problema com uma resposta clara
    Por enquanto, estamos permitindo usar o Privacy Pass em vários dispositivos por meio de rate limiting, com cada dispositivo gerando tokens de forma independente. Vamos ver como isso evolui, ouvir o feedback dos usuários e depois voltar à prancheta

• Esse é o mesmo Privacy Pass que a Cloudflare usava para permitir que clientes burlassem CAPTCHA? Se for, é uma aplicação realmente elegante desse sistema. Nunca tinha pensado em usá-lo para autenticar anonimamente em um serviço pago

  • A criptografia [1] em que o Privacy Pass se baseia na verdade veio do Ecash[2], então no fim das contas foi como dar uma volta completa
    [1] https://www.petsymposium.org/2018/files/papers/issue3/popets...
    [2] https://en.m.wikipedia.org/wiki/Ecash
  • Sim. Mas, até onde eu sei, a Cloudflare encerrou a fase de testes do Privacy Pass
    Lembro que o Safari era o único navegador com implementação nativa disso, mas parece que o Orion agora também oferece suporte