Privacy-Pass-Authentifizierung für die Kagi-Suche

 (blog.kagi.com)
2 Punkte von GN⁺ 2025-02-14 | 1 Kommentare | Auf WhatsApp teilen
  • Kagi Search führt eine Privacy-Pass-Authentifizierung ein, um kostenpflichtige Suchberechtigungen zu prüfen, ohne Suchanfragen direkt mit Konten zu verknüpfen
  • Dieser Ansatz trennt Token-Erstellung und Token-Nutzung, sodass Kagi die Gültigkeit prüfen kann, aber anhand des Tokens weder den Nutzer noch den Erstellungszeitpunkt zurückverfolgen kann
  • Zunächst wird die Funktion für die Tarife Professional, Ultimate, Family, Team mit unbegrenzter Suche bereitgestellt; Trial und Starter mit Suchlimits sind wegen Problemen durch verlorene Token und mögliche Übernutzung ausgenommen
  • Sie kann direkt in Orion, der Kagi-Android-App sowie in den Chrome- und Firefox-Erweiterungen genutzt werden; Safari wird wegen Einschränkungen der Erweiterungs-API noch nicht unterstützt
  • Allein über Tokens ist es schwer, Suchen mit Konten zu verknüpfen, aber IP-Adresse, Browser-Fingerprints und wiederkehrende Suchmuster bleiben als Side Channels bestehen, weshalb die Nutzung von Tor oder VPN empfohlen wird

Privacy-Pass-Authentifizierung für Kagi Search

  • Kagi hat für Kagi Search Privacy-Pass-Authentifizierung eingeführt und zugleich einen Tor onion service veröffentlicht
  • Privacy Pass ist ein Authentifizierungsprotokoll, mit dem ein Client seine Zugriffsberechtigung nachweisen kann, ohne dass der Server erkennen kann, welcher Nutzer zugreift
  • Als kostenpflichtige Suchmaschine muss Kagi Suchberechtigungen prüfen; diese Funktion ergänzt dafür eine technische Garantie, dass Suchanfragen nicht mit einem bestimmten Konto verknüpft werden
  • Die Implementierung basiert auf Raphael Roberts Rust-Implementierung von Privacy Pass, der Code ist unter kagisearch/privacypass-extension veröffentlicht

Unterstützte Tarife und Clients

  • Privacy Pass wird zunächst Nutzern der Tarife Professional, Ultimate, Family, Team mit unbegrenzter Suche angeboten
  • Trial- und Starter-Tarife werden derzeit nicht unterstützt
    • Beide Tarife haben ein monatliches Suchlimit
    • Wenn durch das Löschen einer Erweiterung erzeugte Tokens verloren gehen, kann das die Nutzererfahrung verschlechtern
    • Da Kagi beim Einsatz eines Tokens weder Konto noch Tarif erkennen kann, wäre theoretisch eine Nutzung von mehr Tokens als die erlaubte Zahl an Suchen möglich
  • Unterstützte Clients sind:
  • Nutzer der bestehenden Kagi-Search-Erweiterung sollten zur Vermeidung von Kompatibilitätsproblemen auf die neueste Version aktualisieren oder sie deaktivieren
    • Firefox: 0.7.6
    • Chrome: 1.2.2.5

Authentifizierungsablauf von Privacy Pass

  • Privacy Pass teilt die Authentifizierung in zwei Schritte: Token-Erstellung und Token-Nutzung
  • Im Schritt der Token-Erstellung weist der Nutzer mit dem Kagi-Session-Cookie seine Berechtigung zur Token-Erstellung nach
    • Erzeugte Tokens sind aus Sicht des Servers nicht von zufälligen Tokens zu unterscheiden
    • Tokens können weder auf den Nutzer zurückgeführt werden, der sie erstellt hat, noch auf andere Tokens desselben Nutzers
  • Bei einer Suchanfrage wird ein zuvor erzeugtes Token vorgelegt, um die Zugriffsberechtigung nachzuweisen
    • Der Server prüft nur, dass dieses Token gültig erzeugt wurde
    • Das Token kann nicht mit einem bestimmten Erzeugungsvorgang verknüpft werden
  • Tokens sind Einmal-Tokens
    • Der Server verfolgt bereits genutzte Tokens, um Mehrfachverwendung zu verhindern
    • Auch der Client darf dasselbe Token nicht zweimal senden, damit unterschiedliche Nutzungsvorgänge nicht verknüpft werden können
  • Tokens haben eine feste Lebensdauer; zu alte Tokens müssen neu erzeugt werden

Kagi-Implementierungsmodell und Sicherheitseigenschaften

  • Das Bereitstellungsmodell von Kagi folgt der Shared Origin, Attester, Issuer-Struktur des Privacy-Pass-Standards
    • Kagi übernimmt zugleich die Rollen Attester, Issuer und Origin
    • Nutzer übernehmen die Client-Rolle über die Privacy-Pass-Browser-Erweiterung oder die native Unterstützung in Orion
  • Die Erweiterung erzeugt nach der Installation und danach regelmäßig eine große Zahl an Tokens und speichert sie lokal
  • Nutzer können per Umschalter wählen, ob bei der Suche mit dem vorhandenen Session-Cookie oder mit einem Privacy-Pass-Token authentifiziert werden soll
  • Es gibt drei Schutzeigenschaften für Nutzer
    • Nichtverknüpfbarkeit zwischen Erzeugung und Nutzung: Kagi kann ein bei der Suche übermitteltes Token nicht mit einem bestimmten Token-Erzeugungsvorgang verknüpfen
    • Nichtverknüpfbarkeit zwischen Nutzungen: Kagi kann allein anhand des Tokens nicht erkennen, ob zwei verschiedene Suchen vom selben Nutzer stammen
    • Schutz vor Missbrauch bei Nutzung: Ein Lauscher, der den Token-Erzeugungsprozess beobachtet, kann das Token nicht allein anhand dieser Informationen stehlen und verwenden
  • Auch für Kagi gibt es Schutzeigenschaften
    • Ordnungsgemäß erzeugte Tokens bestehen die Kagi-Prüfung
    • Ein bösartiger Client kann selbst mit Kenntnis korrekt erzeugter Tokens keine neuen gültigen Tokens fälschen

Eingeschränkte Funktionen im Privacy-Pass-Modus

  • Im Privacy-Pass-Modus kann Kagi den Nutzer nicht identifizieren und daher Kontoeinstellungen nicht anwenden
  • Kagi bietet dies als Wahl zwischen „allgemeiner Privatsphäre und vollem Funktionsumfang“ oder „maximaler Privatsphäre und Kernfunktionen“ an
  • Kagi Assistant ist zum Start nicht mit Privacy Pass nutzbar
    • Kagi Assistant steht nur Ultimate-Mitgliedern zur Verfügung
    • Mit Privacy Pass fehlen die Kontoinformationen, um zu prüfen, welcher Tarif genutzt wird
  • Zum Start dient Privacy Pass nur für die Authentifizierung bei Kagi Search
  • Kagi plant, die Unterstützung in den kommenden Wochen auf folgende Dienste auszuweiten
    • Kagi Assistant
    • Kagi Translate und Kagi Maps
    • Kagi Universal Summarizer und Ask questions about page
  • Wer diese Dienste derzeit nutzen möchte, muss Privacy Pass deaktivieren

Side Channels und Nutzung von Tor

  • Privacy Pass verhindert, dass Token-Erstellung und Token-Nutzung allein über das Token verknüpft werden können, kann aber nicht die gesamte Online-Interaktion vollständig in einem mathematischen Modell abbilden
  • Ein bösartiger Server könnte versuchen, Clients über Informationen aus Side Channels zu verfolgen
    • Wenn jeden Tag zur gleichen Zeit dieselbe konkrete Suche wiederholt wird, könnte angenommen werden, dass diese Suchen von derselben Person stammen
    • Signale wie Browser-User-Agent oder IP-Adresse liegen außerhalb von Privacy Pass
    • Wenn von derselben IP direkt nach einer Token-Erzeugungsanfrage auch eine Token-Nutzungsanfrage kommt, könnte dies als Anfrage derselben Person gewertet werden
  • RFC 9576 empfiehlt, Token-Erstellung und Token-Nutzung zeitlich zu trennen oder räumlich über Anonymisierungsdienste wie Tor zu trennen
  • Die Privacy-Pass-Erweiterung von Kagi und die native Orion-Implementierung entfernen HTTP-Header und Cookies, um den Browser-Fingerprint so weit wie möglich zu vereinheitlichen
  • Kagi stellt eine Onion-Adresse bereit, die direkt über das Tor-Netzwerk erreichbar ist
  • Allein mit Tor wird die IP-Adresse verborgen, aber ohne Privacy Pass können Suchen im eingeloggten Zustand theoretisch weiterhin mit einem einzelnen Konto verknüpft werden
  • Werden Tor und Privacy Pass zusammen genutzt, weiß Kagi nur, dass die Suche von einem Nutzer stammt, dessen Berechtigung zum Erhalt von Tokens zuvor geprüft wurde, nicht aber, welches Konto oder welcher Standort dahintersteht

Anzahl der Tokens, Performance und Speicherplatz

  • Nutzer von Tarifen mit unbegrenzter Suche können pro Epoch, also pro Monat, 2.000 Tokens erzeugen
  • Wenn zusätzliche Tokens benötigt werden, kann dies über support@kagi.com angefragt werden
  • Die Erzeugung von 500 Such-Tokens benötigt auf einem gewöhnlichen Consumer-Laptop etwa 1 Sekunde Rechenzeit
    • Durch Serververbindung und Antwortzeiten können noch einige Sekunden hinzukommen
    • Bei der Installation der Erweiterung geschieht dies möglichst im Hintergrund
  • Ein Token ist 216 Byte groß, der Speicherbedarf pro Token-Erzeugungsanfrage liegt bei etwa 100 KiB
  • Der Server zur Token-Prüfung ist derzeit nur in der Region us-central1 bereitgestellt; Kagi will dies kurz nach dem Start ausweiten

Warum Personalisierung und Einstellungen eingeschränkt sind

  • Bei der Suche mit Privacy Pass kennt Kagi den Nutzer nicht und kann daher keine Ergebnisse auf benutzerdefinierte Einstellungen zuschneiden
  • Kagi hat erwogen, kleine Einstellungen wie (language, region, safe-search) mit jeder Anfrage zu senden, hält dies derzeit aber für eine deutliche Schwächung der Anonymität
  • In einer Beispielanalyse könnte ein Nutzer, der die spezielle Spracheinstellung Lang 10 mitsendet, bei nur etwa 1.000 Privacy-Pass-Nutzern automatisch die Garantie der Nichtverknüpfbarkeit zwischen Nutzungen verlieren
  • Kagi hält diese Schätzung möglicherweise für zu konservativ, aktiviert derzeit aber keine grundlegende Personalisierung für Nutzer mit Privacy-Pass-Authentifizierung
  • Einige manuelle Sucheinstellungen lassen sich über Bangs in der Suchanfrage anwenden
    • Wenn zum Beispiel !de an den Anfang der Suchanfrage gesetzt wird, wird eine Suche für die Region Deutschland ausgeführt
  • Wer eine vollständig personalisierte Suche möchte, muss die bisherige Login-Methode nutzen und Privacy Pass deaktivieren

Einschränkungen bei Safari, privaten Fenstern usw.

  • Privacy Pass nutzt keine Blockchain
    • Verwendet werden elliptische Kurven, Hash-Funktionen und Konstruktionen für verifizierbare oblivious pseudorandom functions
    • Tokens werden nicht auf einer Blockchain erzeugt, gespeichert oder gehandelt
  • In privaten Fenstern von Chrome und Firefox funktioniert die Token-Erzeugung nicht
    • Für die Token-Erzeugung ist Zugriff auf Session-Cookies erforderlich
    • In privaten Fenstern haben Erweiterungen keinen Zugriff auf Session-Cookies
    • In Orion funktioniert die Token-Erzeugung auch in privaten Fenstern
  • Auch bei aktiviertem Privacy Pass kann Kagi aufgrund der Funktionsweise von TCP/IP die IP-Adresse der Suchanfrage sehen
    • Wer sich wegen der Preisgabe der IP-Adresse sorgt, sollte Tor oder ein vertrauenswürdiges VPN verwenden
  • Alle Tokens verfallen bezogen auf den Erstellungsmonat X am ersten Tag des Monats X+2 um Mitternacht
    • So soll vermieden werden, dass ähnliche Ablaufdaten von gleichzeitig erzeugten Tokens zur Identifikation mehrerer Suchen genutzt werden
  • Safari wird derzeit nicht unterstützt
    • Nach Kenntnis von Kagi unterstützt die Safari-Erweiterungs-API nicht das Entfernen von Cookies aus Anfragen
    • Ohne das Entfernen von Cookies erfolgt die Authentifizierung weiterhin über das eingeloggte Konto
    • Wer eine ähnliche native Erfahrung auf WebKit-Basis möchte, kann alternativ den Orion Browser mit integrierter Privacy-Pass-Unterstützung verwenden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-02-14
Meinungen auf Hacker News

  • Es ist gut, dass Kagi jetzt Privacy Pass verwendet, und das Unternehmen selbst wirkt insgesamt auch ziemlich in Ordnung.
    Allerdings hat Kagi im Grunde den IETF-Entwurf [1], an dem ich eine Zeit lang gearbeitet habe, sowie die Rust-Implementierung [2] genommen, darauf einen dünnen Wrapper [3] gebaut und nennt das dann „Kagis Privacy-Pass-Implementierung“.
    Meiner Meinung nach hätte man mir zumindest etwas Credit geben sollen. Arbeit an IETF-Spezifikationen und Open-Source-Software ist größtenteils freiwillig und unbezahlt und findet oft außerhalb der Arbeitszeit statt. Wenn man so behandelt wird, motiviert das nicht gerade. Kagi kann das besser.
    [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...

    • Ehrlich gesagt scheint sich die im Artikel erwähnte „Privacy-Pass-Implementierung von Kagi“ nicht auf den RFC oder die Protokollimplementierung selbst zu beziehen, sondern auf die Integration dieser Funktion in Kagis Server und Clients. Der RFC wird im Artikel ja auch anerkannt.
    • Ich frage mich, ob Kagi die Anforderungen erfüllen würde, wenn sie „Credit an raphaelrobert“ hinzufügen oder irgendwo im Code eine Kopie der Lizenz ablegen.
      Meine eigene Open Source wurde noch nie tatsächlich genutzt, und ich veröffentliche normalerweise unter der MIT-Lizenz, daher würde ich gern wissen, wie andere Gruppen oder Organisationen Lizenzen in der Praxis tatsächlich einhalten.
    • Als ich am 14. Februar 2025 gegen 12:15 Uhr Eastern Time den README-Header erfasst habe, stand dort Folgendes:

      This repository contains the source code of the core library implementing the Privacy Pass API used by Kagi.
      Das fühlt sich definitiv nicht gut an. Allerdings dürften die Leute bei Kagi wohl offen dafür sein, es präziser zu formulieren, etwa als „Kernbibliothek, die einen Crystal-Lang-Wrapper für raphaelrobert/privacypass implementiert“. Wahrscheinlich war das nicht absichtlich, sondern eher ein Fall davon, dass man sich darauf konzentriert hat, es zum Laufen zu bringen, und niemanden abgestellt hat, der den Text noch einmal gegenliest.

  • Schön. Es ist selten, dass man sieht, wie ein Dienst, den man nutzt, tatsächlich etwas tut, das eher den Nutzern zugutekommt als dem Dienst selbst; das ist unerwartet, aber eine sehr angenehme Überraschung.
    Ich würde mir wünschen, dass diese Erweiterung den Browserkontext automatisch versteht und dadurch besser integriert ist. Also: Im normalen Modus soll sie meine Session verwenden, und im privaten Browsermodus (browser.extension.inIncognitoContext) soll sie mich ohne weiteres Zutun per Privacy Pass authentifizieren.
    Orion nutze ich nicht, weil es keine GNU/Linux-Version gibt.

    • Der Grund, warum so etwas selten geworden ist, liegt darin, dass die meisten Unternehmen in diesem Bereich, tatsächlich viele Tech-Unternehmen, ein zweiseitiges Marktmodell genutzt haben: Sie bieten einer Nutzergruppe etwas an und verkaufen die daraus resultierenden Ergebnisse an eine andere Nutzergruppe.
      Da die eigentlichen Umsätze von Letzteren kommen, geraten die Interessen der ersten Gruppe und der zweiten Gruppe grundsätzlich in Konflikt, und die Struktur wird leicht feindlich gegenüber der ersten Gruppe.
      Was Kagi und andere neue Tech-Unternehmen erfrischend macht, ist, dass sie dieses Modell aufgeben und zu einem „altmodischen“ Modell zurückkehren, bei dem die Gruppe, der sie dienen, und die Gruppe, von der sie Umsatz erzielen, dieselbe ist.
    • Wir haben gestern mit der Arbeit an Orion für Linux begonnen.
    • Der Nachteil dieses Ansatzes ist, dass die Anonymität allein durch die IP-Adresse gebrochen werden kann, wenn man sich nicht in einem großen Netzwerk befindet.
      Kagi weiß, dass der Nutzer angemeldet ist, und wenn der Nutzer in einem privaten Fenster sensible Suchanfragen stellt, kann Kagi diese Suchanfragen miteinander verknüpfen. Schnell zwischen den Modi zu wechseln, ist nicht ratsam.
    • Falls du es nicht mitbekommen hast: Gegen Ende 2024 wurde in einem Podcast angekündigt, dass eine Linux-Version von Orion geplant ist.
    • Wenn man Kagi nutzt, gewöhnt man sich daran, dass sie die richtigen Entscheidungen treffen. Es ist wirklich erstaunlich, dass sie sich kaum Fehltritte geleistet haben.
      Ich wünschte, das würde auch für mein Kagi-T-Shirt gelten. Bei der zweiten Wäsche hat sich der Saum gelöst, und jetzt ist es ein Shirt fürs Schlafen und für Gartenarbeit. Ich habe zwar einen Gutschein für ein kostenloses Ersatzshirt bekommen, aber geliefert wurde es noch nicht.

  • Wie der Artikel auch andeutet, wäre ein Shop, in dem man Privacy Passes ohne Konto kaufen kann, sinnvoll.
    Er müsste irgendeine Kryptowährung unterstützen, vermutlich Monero, und etwas wie GNU Taler wäre ebenfalls gut, falls diese Technik irgendwann brauchbar wird.

    • Kagi akzeptiert Bitcoin, aber Gründer Vlad hat im Forum gesagt, dass so wenige Leute diese Option nutzen, dass es sich nicht lohnt, in Monero-Unterstützung zu investieren.
    • Ich stimme zu, dass ein Drittanbieter-Shop, der Tokens ohne Konto verkauft, die ideale Lösung wäre. Ohne Konto verliert man allerdings die Funktionen, die Kagi wirklich nützlich machen, zum Beispiel bestimmte Domains aus den Ergebnissen zu entfernen oder bestimmte Ergebnistypen höher zu priorisieren.

  • Ich frage mich, ob das am Ende Privatsphäre unter der Annahme ist, dass keine Logs geführt werden. Ich will nicht streiten, ich verstehe diesen Punkt wirklich nicht.
    Nehmen wir an, Nutzer A fordert bei Kagi Tokens an, und Kagi sagt: „Okay, ich gebe dir 500 Tokens.“ Wenn Kagi die 500 Tokens protokolliert, die es Nutzer A gerade gegeben hat, kann es dann später, wenn eines davon verwendet wird, nicht wissen, dass dieses Token Nutzer A zugewiesen wurde?
    Klar, wenn Kagi diese Daten nicht speichert, ist das Token selbst nur gültig/ungültig und bleibt nicht als „gültiges Token, das Nutzer A an Tag Y gegeben wurde“ erhalten, dann wäre es in Ordnung. Aber ist das schon alles? Verstehe ich da etwas falsch?

    • Der Server erzeugt die Tokens nicht, sondern der Client erzeugt die Tokens. Der Server muss überprüfen können, ob dieses Token von einem Client erstellt wurde, der die Berechtigung zur Erzeugung erhalten hat, darf aber nicht wissen können, welcher Client es erstellt hat. Zumindest ohne Seitenkanal-Informationen sollte das so sein.

      The main building block of our construction is a verifiable oblivious pseudorandom function (VOPRF)
      Ich weiß nicht genau, wie gut dieses Primitiv geprüft ist, aber es scheint jedenfalls deutlich mehr Struktur dahinterzustecken, als wenn der Server dem Client Tokens aushändigt und dann so tut, als wüsste er nicht, wem er sie gegeben hat.
      Referenz-Paper: https://petsymposium.org/popets/2018/popets-2018-0026.pdf

    • Die Privacy-Pass-Dokumentation [0] behandelt diesen Punkt, aber die tiefere Erklärung steht vor allem im Paper selbst. Der Kern ist aus meiner Sicht, dass die vom Server zurückgegebenen Tokens nicht mit den modifizierten Tokens verknüpfbar sind, die der Client später wieder sendet.
      Der Server kann wissen, dass er bestimmten Nutzern die Tokens A, B, C zurückgegeben hat und später die Tokens X, Y, Z erhält. Er weiß auch, dass X, Y, Z gültig sind, kennt aber nicht die Zuordnung zu den von ihm ausgegebenen Tokens. Dafür wird elliptische-Kurven-Kryptografie verwendet.
      [0] https://privacypass.github.io/
    • Die Idee ist, dass Tokens mit keinem Konto verknüpft sind. Es sind anonyme Tokens.
    • Ich glaube, du hast die Prämisse von Privacy-Pass-Tokens nicht verstanden.
      Der Kern ist, dass der Server nicht weiß, welches Token zu welchem Client gehört. Der Server erzeugt die Tokens nicht.

  • Der größte Mangel von Kagi, den ich immer gesehen habe, ist jetzt behoben. Danke, dass ihr zugehört und daran gearbeitet habt, das Produkt für fast alle attraktiv zu machen.

  • Eine der größten Beschwerden von Leuten, die Kagi noch nicht nutzen, sind Privacy-Bedenken wegen der erforderlichen Anmeldung und Zahlungsinformationen.
    Ich gehörte nicht zu denen, die sich darum Sorgen gemacht haben, aber ich frage mich, in welchem Maß diese Änderung die Bedenken derjenigen mindert, die sich tatsächlich Sorgen gemacht haben.

    • Ich gehörte zu denen, die diese Sorge hatten, und finde es immer noch kaum zu glauben, sich bei einer Suchmaschine einzuloggen. Natürlich weiß ich inzwischen, wie viele Leute das tun.
      Nachdem ich das System kurz geprüft habe, ist es jetzt ziemlich wahrscheinlich, dass ich mich anmelde.
    • Wenn die Kryptografie so funktioniert, wie Kagi sagt, trennt dieser Ansatz Suchanfragen vollständig von Kontoinformationen. Das Konto erstellt mehrere Such-Tokens, und für jede Suchanfrage wird ein Token verbraucht.
      Die Tokens werden auf dem Gerät erzeugt und verlassen das Gerät nicht, bis sie verwendet werden. Theoretisch hat Kagi daher keine Möglichkeit, allein anhand eines Tokens zu erkennen, welches Konto es erstellt hat. Fingerprinting oder IP-Korrelation löst das nicht, aber die Plugins für Firefox und Chrome sollen Maßnahmen ergreifen, um Fingerprinting zu reduzieren. Das ist weder schlechter noch besser, als einfach Google oder DuckDuckGo zu verwenden, und wenn man wirklich Privatsphäre will, funktioniert es auch mit Tor.
      Ich bin mir nicht sicher, wie die Legitimität nachgewiesen wird, ohne die Tokens überhaupt zu teilen, aber vermutlich steckt so etwas wie irgendein ~~Zero-Knowledge-Proof~~ dahinter.
      Edit: Offenbar kein Zero-Knowledge-Proof, sondern Blind Signatures.

  • Ich verstehe nicht, was jemanden bei Kagi daran hindern würde, der Token-Tabelle eine neue Spalte hinzuzufügen, die den Nutzer, der das Token erzeugt hat, und dessen SessionCookie enthält.
    Ich sehe nicht, warum sich das nicht sehr leicht mit dem ursprünglichen Token-Erzeuger verknüpfen ließe.

    • Ich bin der Implementierer. Während des „Issuance“-Protokolls von Privacy Pass erzeugt der Client eine „Nachricht“, die der Server verarbeitet. Die Ausgabe des Servers geht an den Client zurück, und der Client verändert diese Ausgabe weiter, um das endgültige Token zu erstellen.
      Weil diese Tokens im letzten Änderungsschritt auf Client-Seite randomisiert werden, kann der Server nicht erkennen, zu welchem Issuance-Vorgang ein bestimmtes Token gehört.
      Das wirklich Coole ist: Das gilt selbst dann noch, wenn der Server in seinem Schritt etwas Böses versuchen sollte. Deshalb muss der Nutzer nur der Client-Software vertrauen, und wir haben sie als Open Source veröffentlicht: https://github.com/kagisearch/privacypass-extension
      Einige Leute erwähnen Blind Signatures, und tatsächlich kann Privacy Pass diese als Baustein verwenden. Genau genommen nutzen wir bei Kagi aber „Privately Verifiable Tokens“ (https://www.rfc-editor.org/rfc/rfc9578.html#name-issuance-pr...), die auf einer „Oblivious Pseudorandom Function“ (OPRF) basieren; persönlich finde ich OPRFs noch cooler als Blind Signatures.
    • Das klingt nach dem, was in dem zitierten Paper [1] zu kryptografischen anonymen Token-Protokollen beschrieben wird. Es sind keine einfachen Klartext-Tokens.
      https://petsymposium.org/popets/2018/popets-2018-0026.php („Privacy Pass: Bypassing Internet Challenges Anonymously“)
      Cloudflare hat wohl dasselbe implementiert. Zumindest verlinken die HN-Kommentare auf dasselbe Paper.
      https://news.ycombinator.com/item?id=19623110 („Privacy Pass (cloudflare.com)“, 53 Kommentare)
    • Das Token wird im Client „erzeugt“, und der Server gibt dem Client nur gerade genug Informationen, damit dieses lokal erzeugte Token „gültig“ wird. Gleichzeitig kann er dieses Token aber nicht mit einem bestimmten Verifizierungsversuch verknüpfen.
    • Genau diese Frage kam mir auch in den Sinn. Auf Vertrauen in die Serverseite kann man sich nicht stützen, daher frage ich mich, ob ich etwas missverstanden habe.
    • Wenn ich es richtig verstanden habe, verwendet „Privacy Pass“ Blind Signatures, sodass sich das Token in der TokenResponse nicht mit dem Token in Verbindung bringen lässt, das bei einer Suchanfrage übermittelt wird.

  • Funktioniert das in der Praxis wirklich? Tokens können nur einmal verwendet werden, also wird der Client realistisch betrachtet in einer bestimmten Such-Session in eine Schleife geraten, in der er Tokens erzeugt und verwendet; dann wird es sehr einfach, die Paare zu verknüpfen. Im Text heißt es auch:

    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 randomisiert vielleicht den Raum, aber was ist mit der Zeit? Also habe ich nach dem Teil „siehe unten“ gesucht, aber nichts Relevantes gefunden. Ist die Idee, dass sich Clients bei ausreichendem Anfragevolumen zeitlich gegenseitig verdecken?
    Außerdem ist Tor nur begrenzt geeignet, den Raum zu randomisieren, solange man nicht ständig neue Sessions erstellt. Soweit ich weiß, bleibt der Circuit während einer Session fest, und eine neue Session zu erstellen dauert etwa 10 Sekunden. Kann man das dann wirklich als räumliche Randomisierung betrachten?

    • Eine Token-Anfrage kann N Tokens erzeugen. Wir haben N = 500 eingestellt, daher müssen die meisten Nutzer nur ziemlich selten neue Tokens anfordern.

  • Wirklich coole und hervorragende Arbeit.
    Ich habe früher einmal eine Blind-Signature-Authentifizierung ähnlich wie Privacy Pass gebaut und frage mich, wie ihr Multi-Device-Zugriff handhabt.
    Ich nehme an, ihr habt es zunächst nur für Nutzer mit unbegrenzter Suche ausgerollt, um das Problem abzumildern, dass man auf anderen Geräten den Zugriff auf Tokens verliert. Mich würde interessieren, ob es Ideen für den langfristigen Plan gibt. Als ich früher solche Systeme gebaut habe, musste man sie immer mit Ende-zu-Ende-verschlüsselter Synchronisierung koppeln. Das ist nicht nur für Endnutzer umständlich, sondern schafft auch eine Möglichkeit, Speicher-Updates und blinde Suchanfragen miteinander zu korrelieren.
    Jedenfalls wirklich großartig; ich freue mich umso mehr, dass man nun nicht einfach Kagi vertrauen muss, sondern überprüfen kann, dass Vertrauen nicht nötig ist.

    • Genau, Multi-Device ist definitiv nicht einfach. Wir haben mit ein paar Ideen experimentiert, aber das ist kein Problem mit einer offensichtlichen Antwort.
      Im Moment ermöglichen wir Privacy Pass auf mehreren Geräten so, dass jedes Gerät über Rate Limiting unabhängig Tokens erzeugt. Wir werden sehen, wie es läuft, Nutzerfeedback einholen und dann wieder ans Reißbrett zurückkehren.

  • Ist das derselbe Privacy Pass, den Cloudflare genutzt hat, um Clients das Umgehen von CAPTCHAs zu erlauben? Falls ja, ist das eine wirklich elegante Anwendung dieses Systems. Ich hatte nie daran gedacht, dass man es zur anonymen Authentifizierung bei einem kostenpflichtigen Dienst verwenden könnte.