Authentification Privacy Pass pour la recherche Kagi

 (blog.kagi.com)
2 points par GN⁺ 2025-02-14 | 1 commentaires | Partager sur WhatsApp
  • Kagi Search a introduit l’authentification Privacy Pass afin de vérifier les droits d’accès à la recherche payante sans relier directement les requêtes de recherche à un compte
  • Cette approche sépare la création des jetons de leur utilisation, de sorte que Kagi puisse en vérifier la validité sans pouvoir, à partir du seul jeton, remonter à l’utilisateur ni au moment de création
  • Elle concerne d’abord les forfaits Professional, Ultimate, Family et Team, qui incluent des recherches illimitées ; les forfaits Trial et Starter, soumis à des limites de recherche, sont exclus pour l’instant en raison des problèmes restants liés à la perte de jetons et à l’usage au-delà du quota
  • Elle est utilisable directement dans Orion, l’application Android de Kagi et les extensions Chrome et Firefox ; Safari n’est pas encore pris en charge en raison des limites de l’API d’extensions
  • Avec les seuls jetons, il est difficile de relier une recherche à un compte, mais des canaux auxiliaires comme l’adresse IP, l’empreinte du navigateur ou des schémas de recherche répétés subsistent, d’où la recommandation d’utiliser Tor ou un VPN

Authentification Privacy Pass ajoutée à Kagi Search

  • Kagi a introduit l’authentification Privacy Pass dans Kagi Search et a également publié un service onion Tor
  • Privacy Pass est un protocole d’authentification qui permet au client de prouver son droit d’accès sans que le serveur puisse identifier quel utilisateur se connecte
  • En tant que moteur de recherche payant, Kagi doit vérifier les droits de recherche, mais cette fonction ajoute une garantie technique permettant de ne pas associer les requêtes de recherche à un compte précis
  • L’implémentation s’appuie sur l’implémentation Rust de Privacy Pass par Raphael Robert, et le code est publié sur kagisearch/privacypass-extension

Forfaits et clients pris en charge

  • Privacy Pass est d’abord proposé aux utilisateurs des forfaits de recherche illimitée Professional, Ultimate, Family et Team
  • Les forfaits Trial et Starter ne sont actuellement pas pris en charge
    • Ces deux forfaits ont un nombre de recherches mensuelles limité
    • Si les jetons générés sont perdus, par exemple lors de la suppression de l’extension, l’expérience utilisateur peut se dégrader
    • Kagi ne peut pas connaître le compte ni le forfait au moment de l’utilisation du jeton, ce qui pourrait en théorie permettre d’utiliser plus de jetons que le nombre de recherches autorisées
  • Les clients pris en charge sont les suivants
  • Les utilisateurs de l’extension Kagi Search existante doivent la mettre à jour vers la dernière version ou la désactiver pour éviter les problèmes de compatibilité
    • Firefox : 0.7.6
    • Chrome : 1.2.2.5

Flux d’authentification de Privacy Pass

  • Privacy Pass divise l’authentification en deux étapes : création des jetons et utilisation des jetons
  • Lors de la création des jetons, l’utilisateur prouve son droit à en générer au moyen du cookie de session Kagi
    • Les jetons générés sont indistinguables de jetons aléatoires du point de vue du serveur
    • Les jetons ne peuvent pas être rattachés à l’utilisateur qui les a créés ni à d’autres jetons créés par le même utilisateur
  • Lors d’une requête de recherche, un jeton précréé est présenté pour prouver le droit d’accès
    • Le serveur vérifie uniquement que ce jeton a bien été généré de manière valide
    • Il ne peut pas relier le jeton à une étape de création précise
  • Les jetons sont à usage unique
    • Le serveur suit les jetons déjà utilisés afin d’empêcher leur réutilisation
    • Le client doit lui aussi éviter de présenter deux fois le même jeton afin de ne pas relier entre elles différentes étapes d’utilisation
  • Les jetons ont une durée de vie fixe ; les jetons trop anciens doivent être régénérés

Modèle d’implémentation de Kagi et propriétés de sécurité

  • Le modèle de déploiement de Kagi suit la structure Shared Origin, Attester, Issuer du standard Privacy Pass
    • Kagi assume à la fois les rôles d’Attester, d’Issuer et d’Origin
    • L’utilisateur joue le rôle de client via l’extension de navigateur Privacy Pass ou la prise en charge native d’Orion
  • Après installation, puis périodiquement, l’extension génère et stocke un grand nombre de jetons
  • Lors d’une recherche, l’utilisateur choisit au moyen d’un interrupteur s’il veut s’authentifier avec son cookie de session existant ou avec un jeton Privacy Pass
  • Les propriétés de protection de l’utilisateur sont au nombre de trois
    • Non-corrélabilité création-utilisation : Kagi ne peut pas relier un jeton présenté lors d’une recherche à une étape de création de jeton précise
    • Non-corrélabilité utilisation-utilisation : Kagi ne peut pas savoir, à partir du seul jeton, si deux recherches différentes proviennent du même utilisateur
    • Protection contre le vol à l’utilisation : un espion qui aurait observé le processus de création des jetons ne peut pas, avec cette seule information, voler et utiliser un jeton
  • Le dispositif inclut aussi des propriétés qui protègent Kagi
    • Les jetons créés correctement passent la vérification de Kagi
    • Un client malveillant ne peut pas forger de nouveaux jetons valides, même s’il connaît des jetons créés correctement

Fonctionnalités réduites en mode Privacy Pass

  • En mode Privacy Pass, Kagi ne peut pas identifier l’utilisateur et ne peut donc pas appliquer les paramètres du compte
  • Kagi présente cela comme un choix laissé à l’utilisateur entre « confidentialité ordinaire et fonctionnalités complètes » ou « confidentialité maximale et fonctionnalités essentielles »
  • Kagi Assistant n’est pas disponible avec Privacy Pass au lancement
    • Kagi Assistant est réservé aux membres Ultimate
    • Avec Privacy Pass, les informations de compte ne sont pas disponibles, ce qui empêche de vérifier le forfait
  • Au lancement, Privacy Pass ne sert qu’à l’authentification de Kagi Search
  • Kagi prévoit d’étendre la prise en charge aux services suivants dans les prochaines semaines
    • Kagi Assistant
    • Kagi Translate et Kagi Maps
    • Kagi Universal Summarizer et Ask questions about page
  • Pour utiliser ces services aujourd’hui, il faut désactiver Privacy Pass

Canaux auxiliaires et utilisation de Tor

  • Privacy Pass empêche de relier la création et l’utilisation d’un jeton à partir du seul jeton, mais il ne peut pas décrire entièrement l’ensemble des interactions en ligne au moyen d’un modèle mathématique
  • Un serveur malveillant peut chercher à suivre le client au moyen d’informations de canaux auxiliaires
    • Si la même recherche spécifique est répétée chaque jour à la même heure, on peut supposer que ces recherches proviennent de la même personne
    • Des signaux comme le user-agent du navigateur ou l’adresse IP sont des informations extérieures à Privacy Pass
    • Si une demande de création de jeton est suivie immédiatement d’une demande d’utilisation de jeton depuis la même IP, il est possible de les considérer comme provenant de la même personne
  • La RFC 9576 recommande de séparer temporellement la création et l’utilisation des jetons, ou de les séparer spatialement au moyen d’un service d’anonymisation comme Tor
  • L’extension Privacy Pass de Kagi et l’implémentation native d’Orion suppriment les en-têtes HTTP et les cookies afin de rendre l’empreinte du navigateur aussi uniforme que possible
  • Kagi fournit une adresse onion accessible directement depuis le réseau Tor
  • Utiliser Tor seul masque l’adresse IP, mais si l’utilisateur est connecté sans Privacy Pass, les recherches peuvent théoriquement être rattachées à un seul compte
  • En combinant Tor et Privacy Pass, Kagi sait seulement que la recherche provient d’un utilisateur dont le droit à recevoir des jetons a été vérifié auparavant, sans connaître son compte ni sa localisation

Nombre de jetons, performances et stockage

  • Les utilisateurs des forfaits de recherche illimitée peuvent générer 2 000 jetons par epoch, c’est-à-dire par mois
  • Si des jetons supplémentaires sont nécessaires, il est possible d’en faire la demande à support@kagi.com
  • La génération de 500 jetons de recherche nécessite environ 1 seconde de calcul sur un ordinateur portable grand public
    • Quelques secondes supplémentaires peuvent être nécessaires en raison de la connexion au serveur et du temps de réponse
    • Lors de l’installation de l’extension, l’opération est effectuée en arrière-plan autant que possible
  • Un jeton pèse 216 octets, et l’espace de stockage par demande de génération de jetons est d’environ 100 KiB
  • Le serveur de vérification des jetons n’est actuellement déployé que dans la région us-central1, et Kagi prévoit de l’étendre peu après le lancement

Pourquoi la personnalisation et les paramètres sont limités

  • Dans les recherches Privacy Pass, Kagi ne connaît pas l’utilisateur et ne peut donc pas fournir des résultats adaptés à ses paramètres personnalisés
  • Kagi a envisagé d’envoyer à chaque requête de petits paramètres comme (language, region, safe-search), mais estime pour l’instant que cela pourrait réduire fortement l’anonymat
  • Dans un exemple d’analyse, un utilisateur envoyant le paramètre de langue spécifique Lang 10 pourrait perdre automatiquement la garantie de non-corrélabilité utilisation-utilisation lorsqu’il y a environ 1 000 utilisateurs de Privacy Pass
  • Kagi considère que cette estimation pourrait être excessivement conservatrice, mais n’active pas actuellement le niveau de personnalisation par défaut pour les utilisateurs authentifiés avec Privacy Pass
  • Certains paramètres de recherche manuels peuvent être appliqués en ajoutant des bangs à la requête
    • Par exemple, ajouter !de au début d’une requête lance une recherche dans la région Allemagne
  • Pour bénéficier d’une expérience de recherche entièrement personnalisée, il faut utiliser le mode de connexion existant et désactiver Privacy Pass

Contraintes liées à Safari, aux fenêtres de navigation privée, etc.

  • Privacy Pass n’utilise pas de blockchain
    • Il utilise des courbes elliptiques, des fonctions de hachage et une structure de fonction pseudo-aléatoire vérifiable à oubli
    • Les jetons ne sont ni générés, ni stockés, ni échangés sur une blockchain
  • Dans les fenêtres de navigation privée de Chrome et Firefox, la génération de jetons ne fonctionne pas
    • La génération de jetons nécessite l’accès au cookie de session
    • Dans les fenêtres de navigation privée, les extensions ne peuvent pas accéder aux cookies de session
    • Dans Orion, la génération de jetons fonctionne aussi en navigation privée
  • Même avec Privacy Pass activé, Kagi peut voir l’adresse IP de la requête de recherche en raison du fonctionnement de TCP/IP
    • Si l’exposition de l’adresse IP pose problème, l’utilisation de Tor ou d’un VPN de confiance est recommandée
  • Tous les jetons expirent à minuit le premier jour du mois X+2, où X est le mois de création
    • Ce choix vise à éviter que des dates d’expiration similaires pour des jetons créés au même moment puissent servir à identifier plusieurs recherches
  • Safari n’est actuellement pas pris en charge
    • Kagi estime que l’API d’extensions de Safari ne prend pas en charge la suppression des cookies dans les requêtes
    • Sans suppression des cookies, l’authentification continue de se faire avec le compte connecté
    • Pour une expérience native similaire basée sur WebKit, Orion Browser, qui intègre Privacy Pass, peut servir d’alternative

À lire aussi

1 commentaires

 
GN⁺ 2025-02-14
Avis de Hacker News

  • C’est bien que Kagi utilise désormais Privacy Pass, et l’entreprise elle-même semble globalement correcte
    Cela dit, Kagi a en fait repris un brouillon IETF [1] sur lequel j’ai travaillé pendant un certain temps, ainsi que l’implémentation Rust [2], puis a créé par-dessus un mince wrapper [3] avant d’appeler cela « l’implémentation Privacy Pass de Kagi »
    Je pense qu’ils auraient dû me donner un certain crédit. Le travail à l’IETF et sur les logiciels open source est en grande partie volontaire et non rémunéré, et se fait souvent en dehors des heures de travail. Être traité de cette façon n’incite pas à continuer. Kagi peut faire mieux
    [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...

    • Honnêtement, il me semble que « l’implémentation Privacy Pass de Kagi » mentionnée dans l’article ne désigne pas le RFC ni l’implémentation du protocole en soi, mais plutôt la partie qui intègre cette fonctionnalité aux serveurs et clients de Kagi. Le RFC est d’ailleurs reconnu dans l’article
    • Je me demande si Kagi serait en conformité en ajoutant un « crédit à raphaelrobert » ou en plaçant une copie de la licence quelque part dans le code
      Mon open source n’a jamais vraiment été utilisé, et je publie généralement sous licence MIT, donc j’aimerais savoir comment d’autres groupes ou organisations respectent concrètement les licences
    • Quand j’ai fait une capture de l’en-tête du README vers 12 h 15, heure de l’Est, le 14 février 2025, il était écrit ceci

      This repository contains the source code of the core library implementing the Privacy Pass API used by Kagi.
      Ce n’est clairement pas très engageant. Cela dit, je pense que les gens de Kagi seraient ouverts à une formulation plus exacte, du type « bibliothèque cœur implémentant un wrapper Crystal Lang pour raphaelrobert/privacypass ». Il est très possible que ce ne soit pas intentionnel, mais qu’ils se soient concentrés sur le fait de faire fonctionner le tout sans affecter quelqu’un à relire la formulation

  • Super. Il est rare de voir un service que j’utilise faire réellement quelque chose qui profite davantage à l’utilisateur qu’à lui-même ; c’est inattendu, mais c’est une très bonne surprise
    J’aimerais que cette extension comprenne automatiquement le contexte du navigateur pour mieux s’intégrer. Autrement dit, qu’elle utilise ma session en mode normal et qu’en navigation privée (browser.extension.inIncognitoContext), elle m’authentifie via Privacy Pass sans que j’aie quoi que ce soit à faire
    Je n’utilise pas Orion parce qu’il n’existe pas de version GNU/Linux

    • Si ce genre de chose est devenu rare, c’est parce que la plupart des entreprises de ce secteur, et en fait beaucoup d’entreprises tech, ont adopté un modèle de marché biface : fournir quelque chose à un groupe d’utilisateurs, puis vendre le résultat à un autre groupe d’utilisateurs
      Comme le chiffre d’affaires réel vient du second groupe, les intérêts du premier et ceux du second entrent par défaut en conflit, et la structure tend à devenir hostile au premier
      Ce qui est rafraîchissant avec Kagi et d’autres nouvelles entreprises tech, c’est qu’elles ont abandonné ce modèle et sont revenues à un modèle « à l’ancienne » où le groupe qu’elles servent et celui dont elles tirent leurs revenus ne font qu’un
    • Le travail sur Orion pour Linux a commencé hier
    • L’inconvénient de cette approche, c’est que si l’on n’est pas sur un grand réseau, l’adresse IP à elle seule peut suffire à briser l’anonymat
      Kagi sait que l’utilisateur est connecté, et si celui-ci effectue des recherches sensibles dans une fenêtre privée, Kagi peut les relier. Passer rapidement d’un mode à l’autre n’est pas souhaitable
    • Au cas où vous ne le sauriez pas, ils ont annoncé vers la fin 2024 dans un podcast qu’une version Linux d’Orion était prévue
    • Quand on utilise Kagi, on s’habitue à les voir faire les bons choix. C’est presque surprenant qu’ils n’aient vraiment pas commis de faux pas notable
      J’aimerais pouvoir en dire autant de mon t-shirt Kagi. À la deuxième lessive, l’ourlet s’est défait, et c’est maintenant un t-shirt de pyjama et de jardinage. J’ai bien reçu un coupon pour un t-shirt de remplacement gratuit, mais il n’a pas encore été expédié

  • Comme l’article le suggère aussi, il serait logique qu’il existe une boutique où acheter des Privacy Pass sans compte
    Elle devrait prendre en charge une cryptomonnaie, probablement Monero, et peut-être aussi GNU Taler si cette technologie devient un jour réellement utilisable

    • Kagi accepte le Bitcoin, mais son fondateur Vlad a dit sur le forum que trop peu de gens utilisent cette option pour que cela vaille la peine d’investir dans la prise en charge de Monero
    • Je suis d’accord pour dire qu’une boutique tierce vendant des jetons sans compte serait la solution idéale, mais sans compte on perd les fonctionnalités qui rendent Kagi intéressant, par exemple retirer certains domaines des résultats ou remonter la priorité de certains types de résultats

  • Je me demande si, au final, c’est une confidentialité qui suppose qu’aucun journal n’est conservé. Je ne cherche pas la petite bête, je ne comprends vraiment pas cette partie.
    Disons que l’utilisateur A demande des jetons à Kagi et que Kagi répond : « d’accord, je te donne 500 jetons ». Si Kagi enregistre les 500 jetons qu’il vient de donner à l’utilisateur A, alors quand l’un d’eux est utilisé plus tard, il peut savoir que ce jeton avait été attribué à l’utilisateur A, non ?
    Bien sûr, si Kagi ne conserve pas ces données, le jeton lui-même n’indique que valide/invalide et ne reste pas comme « jeton valide donné à l’utilisateur A le jour Y », donc ça va, mais est-ce bien tout ? Est-ce que je comprends quelque chose de travers ?

    • Ce n’est pas le serveur qui génère les jetons, c’est le client qui génère les jetons. Le serveur doit pouvoir vérifier que ce jeton a été créé par un client autorisé à le faire, mais ne doit pas pouvoir savoir quel client l’a créé. Du moins pas sans informations issues de canaux auxiliaires.

      The main building block of our construction is a verifiable oblivious pseudorandom function (VOPRF)
      Je ne sais pas à quel point cette primitive a été validée, mais il semble en tout cas y avoir beaucoup plus de structure que si le serveur distribuait des jetons au client en faisant ensuite semblant de ne pas savoir à qui il les a donnés.
      Article de référence : https://petsymposium.org/popets/2018/popets-2018-0026.pdf

    • La documentation Privacy Pass [0] couvre ce point, mais les explications plus détaillées se trouvent surtout dans l’article. À mon avis, l’essentiel est que le jeton renvoyé par le serveur ne puisse pas être lié au jeton modifié que le client renvoie ensuite.
      Le serveur peut savoir qu’il a renvoyé les jetons A, B, C à certains utilisateurs, puis qu’il a reçu plus tard les jetons X, Y, Z. Il sait aussi que X, Y, Z sont valides, mais il ne connaît pas la correspondance avec les jetons qu’il a émis. De la cryptographie sur courbes elliptiques est utilisée pour cela.
      [0] https://privacypass.github.io/
    • L’idée est que les jetons ne soient reliés à aucun compte. Ce sont des jetons anonymes.
    • Je pense que tu n’as pas compris le principe des jetons Privacy Pass.
      Le point clé, c’est que le serveur ne sait pas quel jeton appartient à quel client. Le serveur ne génère pas les jetons.

  • Le plus gros défaut que j’ai toujours vu chez Kagi est maintenant corrigé. Merci d’avoir écouté et travaillé sur ce point pour rendre le produit attractif pour presque tout le monde.

  • L’une des plus grosses plaintes des personnes qui n’utilisent pas encore Kagi concerne les inquiétudes de confidentialité liées à l’obligation de se connecter et de fournir des informations de paiement.
    Ce n’était pas un point qui m’inquiétait personnellement, mais je me demande dans quelle mesure ce changement réduit les inquiétudes des personnes qui s’en souciaient réellement.

    • J’étais de ceux que cela inquiétait, et j’ai encore du mal à accepter l’idée de me connecter à un moteur de recherche. Bien sûr, je sais maintenant combien de personnes le font.
      Après avoir brièvement vérifié le système, il y a de bonnes chances que je m’inscrive désormais.
    • En supposant que la cryptographie fonctionne comme Kagi le dit, cette approche sépare complètement les requêtes de recherche des informations de compte. Un compte crée plusieurs jetons de recherche, et chaque requête de recherche consomme un jeton.
      Les jetons sont générés sur l’appareil et ne le quittent pas avant d’être utilisés ; en théorie, Kagi n’a donc aucun moyen de savoir, à partir du seul jeton, quel compte l’a créé. Cela ne résout pas le fingerprinting ni la corrélation par adresse IP, mais les extensions pour Firefox et Chrome seraient censées prendre des mesures pour réduire le fingerprinting. Ce n’est ni pire ni mieux que d’utiliser simplement Google ou DuckDuckGo, et si l’on veut vraiment de la confidentialité, cela fonctionne aussi avec Tor.
      Je ne sais pas exactement comment la légitimité est prouvée sans partager du tout les jetons, mais il y a sans doute quelque chose comme une ~~preuve à divulgation nulle de connaissance~~.
      Modification : ce ne serait pas une preuve à divulgation nulle de connaissance, mais plutôt une signature aveugle.

  • Je ne vois pas ce qui empêcherait quelqu’un chez Kagi d’ajouter à la table des jetons une nouvelle colonne contenant l’utilisateur qui a généré le jeton et son SessionCookie
    Je ne vois pas pourquoi il ne serait pas très facile de faire le lien avec le générateur initial du jeton

    • Je suis l’implémenteur. Pendant le protocole d’« émission » de Privacy Pass, le client génère un « message » que le serveur va traiter. La sortie du serveur est renvoyée au client, qui la modifie encore pour produire le jeton final
      Comme ces jetons sont randomisés lors de cette dernière étape de modification côté client, le serveur ne peut pas déterminer à quel processus d’émission appartient tel jeton
      Ce qui est vraiment génial, c’est que cela reste vrai même si le serveur essaie de faire des choses malveillantes à son étape. L’utilisateur n’a donc besoin de faire confiance qu’au logiciel client, et nous l’avons publié en open source : https://github.com/kagisearch/privacypass-extension
      Plusieurs personnes parlent de signatures aveugles, et Privacy Pass peut effectivement les utiliser comme brique de construction. Mais, pour être précis, chez Kagi nous utilisons des « Privately Verifiable Tokens » (https://www.rfc-editor.org/rfc/rfc9578.html#name-issuance-pr...) fondés sur une « fonction pseudo-aléatoire inconsciente » (OPRF), et personnellement je trouve les OPRF encore plus élégantes que les signatures aveugles
    • Cela ressemble à ce qui est décrit dans l’article cité [1] sur le protocole cryptographique de jetons anonymes. Ce ne sont pas de simples jetons en clair
      https://petsymposium.org/popets/2018/popets-2018-0026.php (« Privacy Pass: Bypassing Internet Challenges Anonymously »)
      Cloudflare semble aussi avoir implémenté la même chose. En tout cas, des commentaires HN renvoient au même article
      https://news.ycombinator.com/item?id=19623110 (« Privacy Pass (cloudflare.com) », 53 commentaires)
    • Le jeton est « généré » côté client, et le serveur ne donne au client que les informations suffisantes pour rendre ce jeton généré localement « valide ». Tout en ne pouvant pas associer ce jeton à une tentative de vérification donnée
    • Je me suis posé exactement la même question. Comme on ne peut pas s’appuyer sur la confiance envers le serveur, je me demande si je n’ai pas mal compris quelque chose
    • Si j’ai bien compris, « Privacy Pass » utilise des signatures aveugles, ce qui empêche de mettre en relation le jeton contenu dans la TokenResponse avec le jeton fourni lors d’une requête de recherche

  • Est-ce que ça fonctionne vraiment en pratique ? Les jetons ne peuvent être utilisés qu’une seule fois, donc en réalité le client va probablement boucler en générant puis en utilisant des jetons dans une session de recherche donnée, ce qui rend l’association des paires très facile. Le billet le dit d’ailleurs :

    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 randomise l’espace, mais qu’en est-il du temps ? J’ai donc regardé la partie « voir ci-dessous », mais je n’ai rien trouvé de pertinent. L’idée est-elle qu’avec un volume de requêtes suffisant, les clients se couvrent mutuellement dans le temps ?
    Et même Tor a des limites pour randomiser l’espace, à moins de recréer constamment des sessions. À ma connaissance, le circuit reste fixe pendant une session, et en recréer une prend environ 10 secondes. Peut-on alors vraiment dire que l’espace est randomisé ?

    • Une seule demande de jetons peut produire N jetons. Nous avons fixé N = 500, donc la plupart des utilisateurs n’auront à demander de nouveaux jetons que assez rarement

  • C’est vraiment impressionnant, excellent travail
    J’ai déjà construit par le passé une authentification par signatures aveugles similaire à Privacy Pass, et je me demande comment vous allez gérer l’accès multi-appareils
    Je suppose que vous l’avez d’abord lancé uniquement pour les utilisateurs avec recherches illimitées afin d’atténuer le problème de perte d’accès aux jetons depuis d’autres appareils. Je serais curieux de savoir si vous avez des idées sur le plan à long terme. Quand je concevais ce type de système, il fallait toujours l’associer à une synchronisation chiffrée de bout en bout. Non seulement c’est pénible pour l’utilisateur final, mais cela peut aussi ouvrir la possibilité de corréler les mises à jour du stockage et les requêtes de recherche aveugles
    Quoi qu’il en soit, c’est vraiment formidable, et je suis d’autant plus enthousiaste à l’idée de ne plus simplement devoir faire confiance à Kagi, mais de pouvoir vérifier que je n’ai pas besoin de lui faire confiance

    • Oui, le multi-appareils n’est clairement pas simple. Nous avons expérimenté quelques idées, mais ce n’est pas un problème avec une réponse évidente
      Pour l’instant, nous permettons d’utiliser Privacy Pass sur plusieurs appareils en laissant chaque appareil générer ses jetons indépendamment, avec une limitation de débit. Nous allons voir comment cela se passe, écouter les retours des utilisateurs, puis retourner à la planche à dessin

  • Est-ce le même Privacy Pass que celui que Cloudflare utilisait pour permettre aux clients de contourner les CAPTCHA ? Si oui, c’est une application vraiment élégante de ce système. Je n’avais jamais pensé qu’on pouvait l’utiliser pour s’authentifier anonymement auprès d’un service payant