Today we are announcing a new privacy feature coming to Kagi Search. Privacy Pass is an authentication protocol first introduced by Davidson et al., in [1], and recently standardized by the IETF as RFCs [2—4]. At the same time, we are announcing the immediate availability of Kagi’s Tor onion service.
In general terms, Privacy Pass allows “Clients” (generally users) to authenticate to “Servers” (like Kagi) in such a way that while the Server can verify that the connecting Client has the right to access its services, it cannot determine which of its rightful Clients is actually connecting. This is particularly useful in the context of a privacy-respecting paid search engine, where the Server wants to ensure that the Client can access the services, and the Client seeks strong guarantees that, for example, the searches are not associated with them.
As a privacy-respecting search engine, Kagi’s business model is such that we have no incentive to track what an individual user is searching for. We are in the business of selling a search product, not selling user data or attention.
Now, Privacy Pass adds another layer of trust: we can verify that you have the right to search without knowing who you are or what you’re searching for. It’s one thing to promise we won’t track you; it’s another to make it technically impossible. We jumped on the opportunity to implement Privacy Pass as soon as the IETF made it an official standard.
This matters, because for many users, privacy isn’t just about incentives and privacy policies; it’s about proof. When we cannot track you even if we wanted to, that’s genuine privacy.
Initially, we will be offering Privacy Pass to all our plans with unlimited searches: Professional, Ultimate, Family, and Team plans. Privacy Pass will not be available to Trial and Starter plans due to technical limitations at this moment (see below for more info).
To get started with Kagi Privacy Pass right away:
- Download the newest version of Kagi’s Orion Browser (for macOS/iOS/iPadOS) with Kagi Privacy Pass natively integrated. You will need at least 0.99.131 for macOS and 1.3.17 for iOS/iPadOS (they are expected to be rolling out globally today).
OR
- Download the newest version of Kagi for Android app with Kagi Privacy Pass natively integrated. You will need to use at least version 0.29 (this is expected to roll out globally today).
OR
- Download the extension for Firefox or Chrome
- If you are already using the Kagi Search extension, you will want to update it to the latest version (0.7.6 on Firefox, 1.2.2.5 on Chrome) to avoid compatibility issues, or simply disable it.
- Safari is not yet supported due to technical limitations, see the F.A.Q. below.
In addition our implementation of Privacy Pass is open sourced and you can find it here.
When using Kagi Privacy Pass mode, you’ll be truly anonymous – which means your account settings won’t be available since we can’t identify which user you are.
But don’t worry – we’ve made it flexible. You can easily toggle Privacy Pass on or off based on your needs. Think of it as two modes: full features with normal privacy, or maximum privacy with core features. You choose what makes sense for you based on your context and needs.
Privacy Pass uses cryptography to allow a client to authenticate to a server by performing a protocol with two phases: token generation and token redemption.
Token generation
In the initial “token generation” phase, the client interacts with the server to generate some authentication “tokens.”
For the server to willingly participate in this protocol, the client must prove their “right” to generate tokens.
In the case of Kagi’s users, this can be done by presenting their Kagi session cookie to the server.
The tokens eventually generated by the client at the end of this phase are indistinguishable from a randomly generated token from the server’s point of view. They cannot be traced back to the user who generated them, or to other tokens generated by the same user at the same or a different time.
Token redemption
After token generation is performed, a client can initiate a “token redemption” phase.
During this phase, the client actually accesses the services provided by the server, proving the client’s right to access the services by presenting one of the previously generated tokens.
Since the previously generated tokens are unknown and unpredictable to the server, the latter can only tell that the client has successfully completed token generation at some point.
Technically, we say that the techniques used by Privacy Pass result in the two phases being “unlinkable”. While the server is able to tell whether a token presented for redemption was previously generated by interacting with a rightful client, it cannot link the token to a specific token generation phase.
Crucially, tokens are single-use: servers keep track of which tokens have already been redeemed to avoid multiple redemptions. Furthermore, clients should not present the same token twice to prevent different redemption phases from being linked.
Tokens have a fixed life span. If they are too old, they will stop being redeemable. In that case, a new token generation phase must be initiated by the client to obtain new tokens.
Deployment model
As standardized in [2 – 4], the Privacy Pass protocol is able to accommodate many “architectures.” Our deployment model follows the original architecture presented by Davidson et al. [1], called “Shared Origin, Attester, Issuer” in § 4 of [2].
Here, Kagi plays all the “Server roles” (Attester, Issuer, Origin), and Kagi users play the Client role via the new Kagi browser extensions for Privacy Pass, or via native support in Orion. This is what it looks like in practice:
- Once installed, and periodically, the browser extension will generate and store a large number of tokens.
- The user can mark in the extension whether searches should be performed by authenticating classically via a session cookie, or by using Privacy Pass.
- If the user chooses the second option, they will authenticate to Kagi during the search by redeeming one of the tokens it previously generated.
Usage
Using Privacy Pass is as easy as clicking a toggle.
Orion browser
If you are using the latest version of Orion for macOS, select Kagi as your search engine in Settings -> Search
and then enable the checkbox for showing Privacy Pass options on your toolbar.
From there you can easily toggle when you want to use Privacy Pass or standard authentication.
On iOS and iPadOS, Kagi Privacy Pass is natively supported in the latest version of the Orion Browser for iOS and iPadOS and takes just a few clicks to enable.
Note: The Orion iOS app is under review by Apple and will soon be available for download.
Kagi app for Android
Our Android app now supports Privacy Pass mode via an app shortcut. Launching the shortcut allows you to browse Kagi seamlessly in Privacy Pass mode. You can also add the shortcut to your home screen for quick access.
This feature lets you either use Kagi exclusively in Privacy Pass mode or switch effortlessly between modes.
Note: The Android app is currently under review by Google Play and will be available for download soon.
Chrome and Firefox browser extensions
If you are using the Kagi Privacy Pass extension for Chrome or Firefox, once installed you should see the Kagi Privacy Pass icon on your toolbar.
Once installed, the extension automatically generates tokens. To use them, click the extension icon, and make sure the toggle is on.
Note that Safari is not supported at this moment; see the F.A.Q. below for more information.
As used by Kagi, Privacy Pas
21 Comments
outime
The biggest flaw I always saw in Kagi has now been addressed by this. Thank you for listening and working to make the product appealing to (almost) everyone!
ulrikrasmussen
That's a cool idea! Seeing the screenshot I almost immediately figured this would be related to Chaum's digital cash and blind signatures, and it seems to be cited in the linked paper. I had thought of using blind signatures for anonymous authorization, but I was not aware that there was an actual design for that application.
I think government issued digital identities should also use this.
cobertos
What's to stop someone on the Kagi side from just adding a new column to the token table that has the user (with their SessionCookie) who generated the token next to it? I don't see how this can't be trivially connected to the original token generator.
endorphine
Will the extension eventually be made available for Firefox on Android? Right now the Firefox extension link says that it's not compatible.
P. S: I don't use the Kagi app in Android.
mhitza
The post hints at this, but having a shop where one can buy a privacy pass without an account makes sense.
Should support some crypto currency (probably monero), and something like GNU Taler if that technology ever becomes usable.
rawkode
I wonder how this affects gated features and search limits?
AlotOfReading
Pretty cool feature. The unstated downside is that any personalization settings like dark mode, translation, and lens settings are still seemingly tied to account login.
godelski
This seems cool, but I still think the pricing of kagi is rather steep. It is $5/mo for 300 searches a month, which is really going to get you under 10 a day… That's insufficient. Then $10/mo (or $108/yr) for unlimited.
I'm curious if anyone knows, are companies like Google and Microsoft making more than $10/mo/user? We often talk about paying with our data, but it is always unclear how much that data is worth. Kagi does include some numbers, over here[0], but they seem a tad suspicious. The claim is Google makes $23/mo/user, and this would make their service a good value, but the calculation of $76bn US ad revenue (2023) and $277 per user annually gives 274m users. It's close to 80% of the US population, but I though google search was about 90% of global. And I doubt that all ad revenue is coming from search. Does anyone know the real numbers? Googling I get inconsistent answers and also answers based on different conditions and aggregations. But what we'd be interested here is purely in Google /search/ and not anything else.
[0] https://help.kagi.com/kagi/why-kagi/why-pay-for-search.html
drdaeman
Neat! It's rare to see that a service you use actually does something that benefits the user rather that itself. An unexpected, but a really pleasant surprise.
I wish this extension would integrate better with the browser by automatically understanding the context. That is, if I'm in a "regular" mode it'll use my session, but if I'm in a "private browsing" mode (`browser.extension.inIncognitoContext`) it'll use Privacy Pass to authenticate me, without me having to explicitly do anything about it.
(I don't use Orion, as there's no GNU/Linux version.)
eatyourglory
I have been a Kagi subscriber for a while now, but this new addition finally convinced me to start using Kagi in incognito mode! Thank you very much for adding this!
tonygiorgio
This is sick, fantastic work.
I have built blind signature authentication stuff before (similar to privacy pass) and one thing I’m curious about is how you (will) handle multi device access?
I understand you probably launched with only unlimited search users in order to mitigate the same user losing access to their tokens on a different device. But any ideas for long term plans here? When I built these systems in the past, I always had to couple it with E2EE sync. Not only can that be a pain for end users, but you can also start to correlate storage updates with blind search requests.
Either case, this is amazing and I’m gonna be even more excited to not just trust Kagi, but verify that I don’t need to trust y’all. Congrats.
baggachipz
This should placate any potential subscribers who worry that their searches could be logged. Another great feature from a product which keeps getting better all the time.
nottorp
> Privacy Pass does not rely on any blockchain technology.
Lovely!
alepacheco-dev
I think you could use zero knowledge proofs here to accomplish the same thing but without having to worry about renewing tokens etc
daft_pink
Hope they can enable this in Safari so that I can use iCloud Private Relay with it.
alepacheco-dev
Privacy Pass is great for reducing friction, but it still relies on trust in the issuer. A ZK-based approach (e.g., using zk-SNARKs or anonymous credentials) could let users prove they’re paid subscribers without revealing their identity or even interacting with Kagi’s servers beyond the initial proof. This would remove the need for trust while keeping the experience just as seamless. Would love to see more services explore this direction.
voytec
So, you can now use Kagi without giving the company your credit card details with your name? If not – that's not private. Every system is hackable and Kagi renders services under U.S. law.
I'd guess that at least one government body already put an overall "gag order" (Prohibition of Certain Disclosure under 18 U.S.C. § 2709(c) AKA "gag order") on Kagi with additional requirement to stream search terms with metadata. They won't be able to inform users of that because that's a punishable criminal act.
Paid search engine = nothing's private.
And I know HN loves Kagi and you guys can hate me for this comment but you're on for a fun ride with your current federal administration.
retrorangular
[dead]
pavon
This is very cool. I'm curious about why there is a limit on the number of tokens generated per month, when this is only currently offered to unlimited accounts. Since the tokens all expire at the end of the month, tokens can't be horded to use Kagi after a subscription ends. Perhaps it is instead a resource issue where token generation is expensive. In that case though, I would think limiting tokens/day would be more appropriate – there is already going to be a spike to generate new tokens on the first of the month, so if the server can handle that they can handle some users generating a batch of tokens each day.
This is not intended as criticism, just inquisitive.
mortar
I’m not insinuating for even a second that Kagi actually do this, but as a general rule, isn’t any privacy claim dubious at the moment given that more and more governments appear to be able to compel companies to identify their users (especially those searching for illegal content) and further forcefully insist they not disclose it?
It’s disheartening to think the great progress we’re making in this sector could be undermined in a few seconds against any companies efforts with a trivial backdoor.
echoangle
I don’t really understand how the protocol can ensure that the server can’t identify the client.
As far as I understand, the client sends some information A to the server, the server applies some private key X and returns the output B to the client, which then generates tokens C from the output.
If the server uses a different X for every user and then when verifying just checks the X of every user to see which one is valid, couldn’t the server know who created the token?