Autenticación Privacy Pass para Kagi Search

 (blog.kagi.com)
2 puntos por GN⁺ 2025-02-14 | 1 comentarios | Compartir por WhatsApp
  • Kagi Search introdujo la autenticación Privacy Pass para verificar el derecho de búsqueda de pago sin vincular directamente las solicitudes de búsqueda con una cuenta
  • Este método separa la generación de tokens del uso de tokens, de modo que Kagi pueda verificar su validez, pero no pueda rastrear hacia atrás al usuario ni el momento de generación solo con el token
  • Inicialmente está dirigido a los planes Professional, Ultimate, Family, Team, que incluyen búsquedas ilimitadas; Trial y Starter, que tienen límites de búsqueda, quedan excluidos porque aún existen problemas de pérdida de tokens y uso por encima del límite
  • Puede usarse directamente en Orion, la app Kagi para Android y las extensiones de Chrome y Firefox; Safari aún no es compatible debido a restricciones de la API de extensiones
  • Aunque con solo los tokens es difícil vincular búsquedas y cuentas, siguen existiendo canales laterales como dirección IP, huella digital del navegador y patrones de búsqueda repetidos, por lo que se recomienda usar Tor o una VPN

Autenticación Privacy Pass agregada a Kagi Search

  • Kagi introdujo la autenticación Privacy Pass en Kagi Search y también publicó un servicio onion de Tor
  • Privacy Pass es un protocolo de autenticación que permite al cliente demostrar su derecho de acceso, sin que el servidor pueda identificar qué usuario se conectó
  • Kagi, como motor de búsqueda de pago, necesita verificar el derecho de búsqueda, pero con esta función agrega una garantía técnica de que las solicitudes de búsqueda no se vinculen con una cuenta específica
  • La implementación tomó como punto de partida la implementación de Privacy Pass en Rust de Raphael Robert, y el código está publicado en kagisearch/privacypass-extension

Planes y clientes compatibles

  • Privacy Pass se ofrece primero a usuarios de los planes con búsquedas ilimitadas: Professional, Ultimate, Family, Team
  • Los planes Trial y Starter no son compatibles actualmente
    • Ambos planes tienen una cantidad mensual limitada de búsquedas
    • Si se pierden los tokens generados, por ejemplo al borrar la extensión, la experiencia de usuario podría empeorar
    • Como Kagi no puede saber la cuenta ni el plan en el momento de usar un token, en teoría podría ser posible usar más tokens que el número de búsquedas permitido
  • Los clientes compatibles son los siguientes
  • Los usuarios que usen la extensión existente de Kagi Search deben actualizarla a la versión más reciente o desactivarla para evitar problemas de compatibilidad
    • Firefox: 0.7.6
    • Chrome: 1.2.2.5

Flujo de autenticación de Privacy Pass

  • Privacy Pass divide la autenticación en dos etapas: generación de tokens y uso de tokens
  • En la etapa de generación de tokens, el usuario demuestra su derecho a generar tokens mediante la cookie de sesión de Kagi
    • Desde la perspectiva del servidor, los tokens generados no se distinguen de tokens aleatorios
    • Los tokens no pueden rastrearse hasta el usuario que los generó ni hasta otros tokens creados por el mismo usuario
  • Al hacer una solicitud de búsqueda, se envía un token previamente creado para demostrar el derecho de acceso
    • El servidor solo confirma que ese token fue generado válidamente alguna vez
    • No puede vincular el token con una etapa de generación específica
  • Los tokens son de un solo uso
    • El servidor rastrea los tokens ya usados para impedir el uso duplicado
    • El cliente tampoco debe enviar el mismo token dos veces, para que distintas etapas de uso no queden vinculadas
  • Los tokens tienen una vida útil fija, por lo que los tokens demasiado antiguos deben generarse de nuevo

Modelo de implementación de Kagi y propiedades de seguridad

  • El modelo de despliegue de Kagi sigue la estructura Shared Origin, Attester, Issuer del estándar Privacy Pass
    • Kagi desempeña los roles de Attester, Issuer y Origin
    • El usuario desempeña el rol de cliente mediante la extensión de navegador de Privacy Pass o el soporte nativo de Orion
  • Después de instalarse, y luego periódicamente, la extensión genera y guarda una gran cantidad de tokens
  • Al buscar, el usuario puede elegir con un interruptor si autenticarse con la cookie de sesión existente o con un token de Privacy Pass
  • Las propiedades de protección del usuario son tres
    • No vinculabilidad generación-uso: Kagi no puede vincular un token enviado durante una búsqueda con una etapa específica de generación de tokens
    • No vinculabilidad uso-uso: Kagi no puede saber solo por los tokens si dos búsquedas distintas provienen del mismo usuario
    • Protección contra robo de uso: un atacante que observe el proceso de generación de tokens no puede robar y usar tokens solo con esa información
  • También incluye propiedades que protegen a Kagi
    • Los tokens generados correctamente pasan la verificación de Kagi
    • Un cliente malicioso no puede falsificar nuevos tokens válidos aunque conozca tokens generados correctamente

Funciones reducidas en modo Privacy Pass

  • En modo Privacy Pass, Kagi no puede identificar al usuario, por lo que no puede aplicar configuraciones de cuenta
  • Kagi ofrece esto como una estructura en la que el usuario elige entre “privacidad normal y funcionalidad completa” o “máxima privacidad y funciones esenciales”
  • Kagi Assistant no está disponible en Privacy Pass al momento del lanzamiento
    • Kagi Assistant solo se ofrece a miembros Ultimate
    • En Privacy Pass no hay información de cuenta, por lo que no se puede verificar qué plan tiene el usuario
  • Al momento del lanzamiento, Privacy Pass solo se usa para la autenticación de Kagi Search
  • Kagi planea ampliar el soporte a los siguientes servicios en las próximas semanas
    • Kagi Assistant
    • Kagi Translate y Kagi Maps
    • Kagi Universal Summarizer y Ask questions about page
  • Actualmente, para usar estos servicios hay que desactivar Privacy Pass

Canales laterales y uso de Tor

  • Privacy Pass impide que la generación y el uso de tokens puedan vincularse solo con los tokens, pero no puede describir por completo todas las interacciones en línea mediante un modelo matemático
  • Un servidor malicioso podría intentar rastrear clientes con información de canales laterales
    • Si se repite la misma búsqueda específica todos los días a la misma hora, puede inferirse que esas búsquedas provienen de la misma persona
    • Señales como el user-agent del navegador y la dirección IP son información externa a Privacy Pass
    • Si una solicitud de generación de tokens y luego una solicitud de uso de token llegan desde la misma IP, podría considerarse probable que sean solicitudes de la misma persona
  • RFC 9576 recomienda separar temporalmente la generación y el uso de tokens, o separarlos espacialmente mediante un servicio de anonimización como Tor
  • La extensión Privacy Pass de Kagi y la implementación nativa de Orion eliminan encabezados HTTP y cookies para hacer que la huella digital del navegador sea lo más uniforme posible
  • Kagi ofrece una dirección onion accesible directamente desde la red Tor
  • Usar solo Tor oculta la dirección IP, pero si se inició sesión sin Privacy Pass, en teoría las búsquedas podrían vincularse con una sola cuenta
  • Al usar Tor y Privacy Pass juntos, Kagi solo sabe que esa búsqueda proviene de un usuario cuyo derecho a recibir tokens fue verificado previamente; no conoce la cuenta ni la ubicación

Cantidad de tokens, rendimiento y almacenamiento

  • Los usuarios de planes con búsquedas ilimitadas pueden generar 2,000 tokens por epoch, es decir, por mes
  • Si se necesitan tokens adicionales, pueden solicitarse a support@kagi.com
  • Generar 500 tokens de búsqueda requiere aproximadamente 1 segundo de cómputo en una laptop de consumo general
    • La conexión con el servidor y el tiempo de respuesta pueden sumar algunos segundos más
    • Al instalar la extensión, se realiza en segundo plano en la medida de lo posible
  • Un token ocupa 216 bytes, y el espacio de almacenamiento por solicitud de generación de tokens es de aproximadamente 100 KiB
  • Actualmente, el servidor de verificación de tokens solo está desplegado en la región us-central1, y Kagi planea expandirlo poco después del lanzamiento

Por qué se limitan la personalización y la configuración

  • En las búsquedas con Privacy Pass, Kagi no sabe quién es el usuario, por lo que no puede ofrecer resultados ajustados a su configuración personalizada
  • Kagi evaluó enviar pequeños ajustes como (language, region, safe-search) en cada solicitud, pero actualmente considera que eso podría reducir mucho el anonimato
  • En un análisis de ejemplo, los usuarios que envían una configuración de idioma específica, Lang 10, podrían perder automáticamente la garantía de no vinculabilidad uso-uso cuando haya alrededor de 1,000 usuarios de Privacy Pass
  • Kagi considera que esta estimación podría ser demasiado conservadora, pero por ahora no activa el nivel básico de personalización para usuarios autenticados con Privacy Pass
  • Algunos ajustes manuales de búsqueda pueden aplicarse agregando bangs a la consulta
    • Por ejemplo, si se agrega !de antes de la consulta, se realiza una búsqueda para la región de Alemania
  • Si se desea una experiencia de búsqueda completamente personalizada, hay que usar el método de inicio de sesión existente y desactivar Privacy Pass

Restricciones en Safari, ventanas privadas y otros casos

  • Privacy Pass no usa blockchain
    • Usa curvas elípticas, funciones hash y una estructura de funciones seudoaleatorias oblivious verificables
    • Los tokens no se generan, almacenan ni comercializan en una blockchain
  • En ventanas privadas de Chrome y Firefox, la generación de tokens no funciona
    • La generación de tokens requiere acceso a la cookie de sesión
    • En ventanas privadas, la extensión no puede acceder a la cookie de sesión
    • En Orion, la generación de tokens también funciona en ventanas privadas
  • Aunque Privacy Pass esté activado, por cómo funciona TCP/IP, Kagi puede ver la dirección IP de la solicitud de búsqueda
    • Si preocupa la exposición de la dirección IP, se recomienda usar Tor o una VPN de confianza
  • Todos los tokens expiran a la medianoche del primer día del mes X+2, tomando como referencia el mes X en que fueron generados
    • Es una forma de evitar que fechas de expiración similares de tokens generados en el mismo momento se usen para identificar varias búsquedas
  • Safari no es compatible actualmente
    • Según entiende Kagi, la API de extensiones de Safari no admite la función de eliminar cookies de una solicitud
    • Si no se pueden eliminar las cookies, la autenticación seguirá realizándose con la cuenta iniciada
    • Si se desea una experiencia nativa similar basada en WebKit, puede usarse como alternativa Orion Browser, que integra Privacy Pass

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-02-14
Comentarios de Hacker News

  • Me parece bien que Kagi ahora use Privacy Pass, y la empresa en sí también se ve bastante bien en general.
    Sin embargo, Kagi básicamente tomó un borrador del IETF [1] en el que trabajé durante un tiempo y una implementación en Rust [2], creó encima un wrapper delgado [3] y lo está llamando “la implementación de Privacy Pass de Kagi”.
    Creo que correspondía darme cierto crédito. El trabajo en el IETF y en software de código abierto es en gran parte voluntario y no remunerado, y muchas veces se hace fuera del horario laboral. Cuando a uno lo tratan así, se pierde la motivación. Kagi puede hacerlo mejor.
    [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...

    • Honestamente, creo que “la implementación de Privacy Pass de Kagi” de la que habla el artículo no se refiere al RFC ni a la implementación del protocolo en sí, sino a la parte de integrarlo con los servidores y clientes de Kagi. El artículo también reconoce el RFC.
    • Me pregunto si Kagi cumpliría con solo agregar “créditos a raphaelrobert” o poner una copia de la licencia en algún lugar del código.
      Mi código open source nunca se usó realmente y normalmente lo publico bajo licencia MIT, así que me interesa saber cómo otros grupos u organizaciones cumplen con la licencia en la práctica.
    • Cuando capturé el encabezado del README alrededor de las 12:15 p. m., hora del Este, el 14 de febrero de 2025, decía esto:

      This repository contains the source code of the core library implementing the Privacy Pass API used by Kagi.
      Esto definitivamente no da buena impresión. Dicho eso, creo que la gente de Kagi estaría abierta a cambiarlo por algo más preciso, como “la biblioteca central que implementa un wrapper de Crystal Lang para raphaelrobert/privacypass”. Es muy probable que no haya sido intencional, sino que se enfocaron en hacerlo funcionar y no asignaron a nadie para volver a leer el texto.

  • Genial. Es raro ver que un servicio que uso haga de verdad algo que beneficia a los usuarios más que a sí mismo; es inesperado, pero una sorpresa muy agradable.
    Ojalá esta extensión entienda automáticamente el contexto del navegador y se integre mejor. Es decir, que en modo normal use mi sesión y, en modo de navegación privada (browser.extension.inIncognitoContext), me autentique con Privacy Pass sin que yo tenga que hacer nada extra.
    No uso Orion porque no tiene versión para GNU/Linux.

    • La razón por la que esto se ha vuelto raro es que la mayoría de las empresas de este sector, de hecho muchas empresas tecnológicas, han usado un modelo de mercado de dos lados: ofrecen algo a un grupo de usuarios y luego venden el resultado a otro grupo de usuarios.
      Como el grupo que realmente genera ingresos es el segundo, por defecto los intereses del primer grupo y los del segundo entran en conflicto, y la estructura tiende a volverse hostil hacia el primero.
      Lo refrescante de Kagi y de otras empresas tecnológicas nuevas es que abandonaron este modelo y volvieron al modelo “a la antigua”, en el que el grupo al que prestan servicio y del que obtienen ingresos es el mismo.
    • Ayer empezamos a trabajar en Orion para Linux.
    • La desventaja de este método es que, si no estás sobre una red grande, la dirección IP por sí sola puede romper el anonimato.
      Kagi sabe que el usuario inició sesión, y si el usuario hace búsquedas sensibles en una ventana privada, puede vincular esas búsquedas. No conviene alternar rápidamente entre modos.
    • Por si no lo sabías, hacia fines de 2024 anunciaron en un podcast que estaban planeando una versión de Orion para Linux.
    • Cuando usas Kagi, te acostumbras a que tomen las decisiones correctas. Es sorprendente que prácticamente no hayan tenido tropiezos.
      Ojalá mi camiseta de Kagi hubiera sido igual. En el segundo lavado se le descosió el dobladillo, así que ahora es una camiseta para dormir y para trabajar en el jardín. Recibí un cupón para una camiseta gratis de reemplazo, pero todavía no me la han enviado.

  • Como también sugiere el artículo, tendría sentido que hubiera una tienda donde se pudiera comprar Privacy Pass sin cuenta.
    Tendría que admitir alguna criptomoneda, probablemente Monero, y también algo como GNU Taler si algún día esa tecnología llega a ser usable.

    • Kagi acepta Bitcoin, pero Vlad, el fundador, dijo en el foro que tan poca gente usa esa opción que no tiene sentido invertir en soporte para Monero.
    • Estoy de acuerdo en que una tienda de terceros que venda tokens sin cuenta sería la solución ideal, pero sin una cuenta se pierden las funciones que hacen que Kagi valga la pena, por ejemplo eliminar ciertos dominios de los resultados o subir la prioridad de ciertos tipos de resultados.

  • Me pregunto si esto al final es privacidad basada en asumir que no se guardan logs. No lo digo para provocar; de verdad no entiendo esta parte.
    Supongamos que el usuario A le pide tokens a Kagi y Kagi dice: “bien, te doy 500 tokens”. Si Kagi registra esos 500 tokens que acaba de darle al usuario A, ¿no podría saber más tarde, cuando se use uno de ellos, que ese token fue asignado al usuario A?
    Claro, si Kagi no conserva esos datos, el token en sí solo queda marcado como válido/inválido y no como “token válido entregado al usuario A el día Y”, así que estaría bien; ¿pero eso es todo? ¿Estoy entendiendo algo mal?

    • El servidor no genera los tokens; el cliente genera los tokens. El servidor debe poder verificar que ese token fue creado por un cliente autorizado a generarlo, pero no debería poder saber qué cliente lo creó. Al menos sin información de canales laterales.

      The main building block of our construction is a verifiable oblivious pseudorandom function (VOPRF)
      No sé qué tan probado esté este primitivo, pero al menos parece haber mucha más estructura que simplemente que el servidor reparta tokens a los clientes y luego finja que no sabe a quién se los dio.
      Paper de referencia: https://petsymposium.org/popets/2018/popets-2018-0026.pdf

    • La documentación de Privacy Pass [0] aborda esta parte, aunque se explica con más profundidad dentro del paper. Creo que el punto clave es que el token que devuelve el servidor es no vinculable con el token modificado que el cliente vuelve a enviar.
      El servidor puede saber que devolvió los tokens A, B y C a ciertos usuarios, y que más tarde recibió los tokens X, Y y Z. También sabe que X, Y y Z son válidos, pero no sabe cuál es la correspondencia con los tokens que emitió. Para esto se usa criptografía de curvas elípticas.
      [0] https://privacypass.github.io/
    • La idea es que los tokens no estén vinculados a ninguna cuenta. Son tokens anónimos.
    • Creo que no entendiste la premisa de los tokens de Privacy Pass.
      El punto central es que el servidor no sabe qué token pertenece a qué cliente. El servidor no genera los tokens.

  • El mayor defecto que siempre le veía a Kagi ya quedó resuelto. Gracias por escuchar y trabajar en esto para hacer que el producto sea atractivo para casi todo el mundo.

  • Una de las quejas más grandes de quienes todavía no usan Kagi son las preocupaciones de privacidad por tener que iniciar sesión y proporcionar datos de pago.
    Yo no era de los que se preocupaban por eso, pero me da curiosidad hasta qué punto este cambio reduce esas inquietudes para quienes sí las tenían.

    • Yo sí era de los que tenían esa preocupación, y todavía me parece increíble tener que iniciar sesión en un motor de búsqueda. Aunque, claro, sé cuánta gente lo hace ahora.
      Después de verificar brevemente el sistema, ahora es bastante probable que me registre.
    • Suponiendo que la criptografía funcione como dice Kagi, este método separa por completo las consultas de búsqueda de la información de la cuenta. La cuenta crea varios tokens de búsqueda, y cada consulta de búsqueda consume uno de esos tokens.
      Los tokens se generan en el dispositivo y no salen de él hasta que se usan, así que, en teoría, Kagi no tiene forma de saber solo a partir del token qué cuenta lo creó. No resuelve el fingerprinting ni la correlación por IP, pero dicen que los plugins para Firefox y Chrome toman medidas para reducir el fingerprinting. Esto no es ni peor ni mejor que usar Google o DuckDuckGo directamente, y si de verdad quieres privacidad, también funciona en Tor.
      No tengo claro cómo se demuestra la legitimidad sin compartir los tokens en absoluto, pero probablemente haya algo como una ~~prueba de conocimiento cero~~ de por medio.
      Edición: parece que no es una prueba de conocimiento cero, sino firmas ciegas.

  • No entiendo qué impediría que alguien de Kagi agregue a la tabla de tokens una nueva columna con el usuario que generó el token y su SessionCookie
    No veo por qué no podría vincularse muy fácilmente con el generador original del token

    • Soy el implementador. Durante el protocolo de “emisión” de Privacy Pass, el cliente genera un “mensaje” que el servidor va a procesar. La salida del servidor vuelve al cliente, y el cliente modifica aún más esa salida para crear el token final
      Como estos tokens se aleatorizan en el último paso de modificación del cliente, el servidor ya no puede identificar a qué proceso de emisión pertenece ese token
      Lo realmente genial es que esto sigue siendo cierto incluso si el servidor intenta hacer algo indebido en su propio paso. Por eso el usuario solo tiene que confiar en el software cliente, y lo publicamos como open source: https://github.com/kagisearch/privacypass-extension
      Varias personas mencionan las firmas ciegas, y de hecho Privacy Pass puede usarlas como componente. Pero, para ser precisos, en Kagi usamos “Privately Verifiable Tokens” basados en una “función seudorandom olvidadiza” (OPRF) (https://www.rfc-editor.org/rfc/rfc9578.html#name-issuance-pr...), y personalmente creo que OPRF es más interesante que las firmas ciegas
    • Parece lo que se describe en el paper citado [1] sobre un protocolo criptográfico de tokens anónimos. No son simples tokens en texto plano
      https://petsymposium.org/popets/2018/popets-2018-0026.php (“Privacy Pass: Bypassing Internet Challenges Anonymously”)
      Creo que Cloudflare también implementó lo mismo. Al menos los comentarios de HN enlazan al mismo paper
      https://news.ycombinator.com/item?id=19623110 (“Privacy Pass (cloudflare.com)”, 53 comments)
    • El token se “genera” en el cliente, y el servidor solo le da al cliente la información suficiente para que ese token generado localmente pase a ser “válido”. Aun así, no puede vincular ese token con un intento de verificación específico
    • Yo pensé exactamente en esa misma pregunta. No se puede depender de la confianza en el lado del servidor, así que me pregunto si estoy entendiendo algo mal
    • Si entendí bien, “Privacy Pass” usa firmas ciegas, por lo que no es posible correlacionar el token incluido en TokenResponse con el token que se entrega en la consulta de búsqueda

  • ¿Esto realmente funciona en la práctica? Como los tokens solo se pueden usar una vez, en la realidad el cliente probablemente terminará en un ciclo de generar y usar tokens dentro de una sesión de búsqueda específica, y entonces sería muy fácil vincular los pares. El texto también dice esto

    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).
    Tor aleatorizaría el espacio, ¿pero qué pasa con el tiempo? Por eso miré la parte de “ver abajo”, pero no encontré nada relevante. ¿La idea es que, con suficiente volumen de solicitudes, los clientes se cubran entre sí en el tiempo?
    Además, Tor también tiene límites para aleatorizar el espacio a menos que se cree una sesión nueva todo el tiempo. Según entiendo, el circuito queda fijo durante la sesión, y recrear la sesión tarda unos 10 segundos. Entonces, ¿de verdad se puede decir que aleatoriza el espacio?

    • Una sola solicitud de tokens puede crear N tokens. Nosotros configuramos N = 500, así que la mayoría de los usuarios solo tendrá que pedir tokens nuevos con bastante poca frecuencia

  • Esto es realmente genial y un trabajo excelente
    Hace tiempo construí una autenticación con firmas ciegas parecida a Privacy Pass, y me da curiosidad cómo manejarán el acceso desde múltiples dispositivos
    Supongo que primero lo lanzaron solo para usuarios con búsquedas ilimitadas para mitigar el problema de perder acceso a los tokens en otros dispositivos. Me interesa saber si tienen alguna idea para el plan a largo plazo. Cuando antes construía sistemas así, siempre tenía que atarlos a sincronización cifrada de extremo a extremo. Eso no solo resulta engorroso para el usuario final, sino que también abre la posibilidad de correlacionar actualizaciones del almacenamiento con solicitudes de búsqueda ciegas
    En cualquier caso, es realmente impresionante, y ahora me entusiasma más poder verificar que no tengo que confiar en Kagi, en lugar de simplemente confiar en Kagi

    • Sí, múltiples dispositivos definitivamente no es algo sencillo. Hemos experimentado con algunas ideas, pero no es un problema con una respuesta clara
      Por ahora, permitimos usar Privacy Pass en varios dispositivos haciendo que cada dispositivo genere tokens de forma independiente mediante límites de velocidad. Veremos cómo evoluciona y escucharemos los comentarios de los usuarios antes de volver a la mesa de diseño

  • ¿Este es el mismo Privacy Pass que Cloudflare usaba para permitir que los clientes evitaran CAPTCHAs? Si es así, es una aplicación realmente elegante de ese sistema. Nunca se me había ocurrido que pudiera usarse para autenticarse de forma anónima en un servicio de pago