Privacy Pass Authentication for Kagi Search

Cryptographic design & how Privacy Pass works

• Commenters link Kagi’s approach to Chaum-style blind signatures and OPRF-based “Privately Verifiable Tokens” (RFC 9578).
• Tokens are generated client-side; the server only signs blinded data and never sees the final tokens until redemption, so issuance and redemption are mathematically unlinkable.
• Kagi’s extension and core library are open source; several people emphasize that you only need to trust the client implementation, not Kagi’s servers.

Unlinkability, threat models & government compulsion

• A recurring question: “What stops Kagi from logging which user got which tokens?”
• Cryptography-focused replies stress that, if implemented correctly, the server cannot correlate issued tokens to redeemed ones—even if it tries to misbehave at issuance.
• Others worry about legal compulsion: governments could force Kagi to change the protocol or ship a backdoored client. Responses say open-source clients and cryptographic design raise the bar but can’t solve all political risks.
• There is debate over whether Kagi’s architecture fully satisfies the stronger unlinkability guarantees in RFC 9576, since Kagi plays Origin/Issuer/Attester and authenticates issuance with a session cookie. Proponents argue time/space separation (batch tokens + Tor) makes linkage impractical; critics call some of the marketing “privacy theater.”

Tor, browser extensions & anonymity limits

• Kagi also launched a .onion service; commenters see the combo of Tor + Privacy Pass as unusually strong for a paid search product.
• Others note Tor Browser discourages extra extensions and analyze the Kagi extension’s WASM and fallback behavior, flagging a path where an onion failure could cause a clearnet request.
• Multiple people point out that IP and browser fingerprinting still apply; Privacy Pass only decouples searches from the account/payment identity.

Token limits, sharing & multi-device

• Tokens are single-use and currently limited (e.g., 2,000/month) to prevent resale or powering downstream services.
• People speculate about secondary markets or pooled “privacy” token banks; Kagi says issuance caps and support resets are their main abuse control.
• Multi-device support is acknowledged as unsolved; for now, each device issues its own tokens within rate limits.

Personalization vs privacy

• Using Privacy Pass disables per-account customization (dark mode, domain boosts/blocks, etc.) to avoid fingerprinting.
• Suggested mitigations include public “config IDs” or small preset bundles (e.g., “developer config”) so many users share the same profile; others note even that can reduce anonymity.
• Some propose client-side filtering/reordering of results (e.g., ship both safe/unsafe or multi-language result sets, filter locally) to keep account-less customization while preserving anonymity.

Platform support & UX wishes

• Users ask for Firefox on Android, Safari integration, and automatic switching: normal mode uses logged-in search, private/incognito uses Privacy Pass.
• There’s tension between convenience and de-anonymization: fast switching within one IP / fingerprint could let Kagi correlate private and logged-in sessions.

Pricing, value & usage patterns

• Many find $10/month unlimited worth it for cleaner results, time saved, and philosophical alignment (not being the ad product).
• Some consider $5 for 300 searches “too low a cap”; others report rarely exceeding it and note they search less because results are better.
• Several justify the $25 “Ultimate” plan because it bundles multiple LLMs and Kagi’s Assistant, replacing separate AI subscriptions.
• Skeptics argue price and search caps are steep compared to “free” Google, or that technical users can self-host alternatives (e.g., searxng + local LLM).

Cryptocurrencies, anonymous payments & PPP

• Multiple comments want truly accountless token shops funded via Monero or similar private coins; Kagi currently supports Bitcoin via OpenNode/Lightning but says usage is low.
• BTC fees vs Lightning usability vs Monero’s privacy and low fees are heavily debated.
• Some say they won’t trust a “private” service that doesn’t accept a private currency; Kagi indicates Monero could be added if demand justifies the engineering cost.
• Requests for regional/PPP pricing are met with the response that margins are thin and there’s no profit to discount from yet.

Search quality & broader business-model discussion

• Many users say Kagi’s results are clearly better than Google’s, especially for technical queries and for avoiding SEO spam, AI slop, and Pinterest-style noise.
• Features praised: domain pin/boost/block, recency sorting, AI-result filters, and tight LLM integration (“!ai”, “!sum”, etc.).
• Others report mixed relevance (e.g., weak reverse image search) and note that personalization features are part of Kagi’s value—harder to get in Privacy Pass mode.
• A long subthread contrasts ad-supported vs subscription models: ad tech is seen as structurally hostile to users and prone to engagement-maximizing harms, but others note ads subsidize access for people who can’t pay and that subsidies could, in theory, be done via subscriptions too.

Open-source credit & implementation details

• One contributor notes that Kagi’s Rust core relies heavily on an existing open-source Privacy Pass implementation and IETF draft work, and expresses disappointment about lack of attribution.
• Kagi staff respond that licensing (MIT) was followed, their “implementation” refers to the whole integration stack, and they later amend the blog post to credit that work.

Overall sentiment

• Enthusiastic Kagi users see Privacy Pass as addressing their biggest remaining concern—logging searches under a persistent identity—while skeptics focus on legal compulsion, residual fingerprinting/IP risks, and price.
• The thread converges on: cryptographically, the approach is sound if correctly implemented and audited; operational and legal realities still require caution about what “private” really means.