Privacy Pass Authentication for Kagi Search

[I work at Kagi]

Indeed, this is the intended interpretation of "Kagi's implementation of Privacy Pass" - we're talking about building out the server infrastructure, the UX, the browser extensions, the mobile applications, the Orion browser integration, the support and documentation, the Tor service, etc. The cryptography is obviously an extremely important piece, but it is far from the only piece.

As other commenters have noted, the code in question is MIT licensed [1] and we're pulling it in as a standard dependency [2], it's not like we've gone out of our way to obscure its origin. The MIT license does not require us to do anything more.

That said, I can understand the author wanting more visible attribution, and that's very reasonable, we'll add a blurb to the blog post acknowledging his contribution to Kagi's deployment of Privacy Pass.

[1] https://github.com/raphaelrobert/privacypass/blob/main/LICEN...

[2] https://github.com/kagisearch/privacypass-lib/blob/e4d6b354d...

They are compliant, the code being used is under the MIT license.

The other part to this is that the internet accelerates network-effects, which you can further supercharge by making your product as cheap as possible or free to the former group in your example.

It’s hard to make money by charging a lot to a small group of people since now you’re dealing with anti-network effects. Doubling the price of a product will likely more than halve your user base.

> This by default almost assumes a hostility towards the former group because their interests will of course be at odds with the interests of the latter group.

I would generally agree that that's the "default".

However, there are cases where two sides of a market need an intermediary with which they can both independently transact, and a net benefit of that interaction is felt on both sides. The key is to construct the solution such that the intermediary depends on the goodwill of both sides of the market.

I think Kagi is somewhat flipping the script. By "taking" data from publishers for free, they are then selling it to readers at a cost. However, there is a trade off. Kagi needs to make sure publishers continue to make their content available so that it can be searchable, or used in their Assistant product. In order to do that, they need to do the opposite of what Google is doing by trying to sequester traffic on Google.com: Kagi's best interest is to make sure that they provide good value to both sides.

Indeed, using the Assistant product, the way it is structured, I very often find myself clicking through to the referenced original sources and not just consuming the summarized content.

How this evolves over time, from a product design standpoint, will be interesting to watch.

Kagi user here. I agree!

The main driver of hostility to users is due to ad-based business models. I think we would see a much more healthy internet if we had regulation which prohibited companies from choosing ads based on any information associated with the user that the ad is shown to. That is, any data collected in the past and any data associated with the session and request must not be taken into account when choosing the ad; two requests by different users in different locations should have the exact same ad probability distributions.

I know we are never getting this because it would kill or severely harm the business models of some of the most profitable businesses in the world.

They would be a good steward of pinboard.in if it were for sale / recovery.

Direct monetization FTW. Charge people for value. Cultivate audiences willing to pay for value.

Incentives aligned. Happy customers. Good businesses. Maybe you only get 60% gross margins, or, gasp, 40% gross margins. But so much less toxic.

Any target date for open-sourcing it? :^)

I remember the announcement for Orion but I haven't followed closely at all - any support for container proxies like in Firefox? Can't lose that feature

Amazing!!!

And that's why Kagi has simultaneously rolled out their service availability on tor: http://kagi2pv5bdcxxqla5itjzje2cgdccuwept5ub6patvmvn3qgmgjd6...

Tor has its flaws and criticisms, but it's really not on Kagi to fix them. With the combination of tor and their privacy pass, Kagi has gone further in allowing their paid users access to their services than anyone else.

Disclaimer: Not associated with Kagi in anyway other than being a very happy user.

I think I can finally buy into the Kagi hype now that I've found a sincere negative opinion.

(vlad here) Rather, we are opportunistic about it and we want to focus on things that make impact (which most of the time is search, not billing). If there is enough demand, we will work on Monero support - and yes I agree, buying privacy pass tokens, without even needing an account, is one of those super-cool use cases.

Nobody wants to use BTC because of high fees and at this point its less a usable exchange of value than speculative asset. I personally would only ever use and trust a online service advertised as private/anonymous if it actually supported a private and anonymous currency (like some vpns do).

Kagi's privacy guarantee is more of a "trust me bro" and I say that as a Kagi subscriber. While they may claim that they preserve privacy or anonimity as long as it's tied to a user account, or payment information nothing prevents them from associating searches with user. Even protonmail enabled logging for a particular user at one point. Their guarantee is on the same level.

At the same time, privacy pass is a very foreign concept to me. If they are transferable between devices, one could generate a couple and resell them over some other medium (even in person).

Add the ability to export your account config (yaml?) and use it with privacy pass. Maybe even sync it with git.

To avoid fingerprinting by config, have a page where the community can share and vote on best configs, then clone and use a popular one that suits your needs.

What I find confusing is: Given that the server is essentially authorizing each subsequent client request (eg: For Kagi: search queries after a Kagi user has already been authenticated) in a way whereby the client is anonymous, what is the difference between Privacy Pass and simply providing a common authorization token to each user (and thus skipping all this cryptography)?

Update: On some thought, for the approach of the server providing a common authorization token that there is no guarantee to the client that the server is actually providing a common token and thus not just simply providing a unique identifier to each user. Thus, the Privacy Pass's cryptography ensures that the client knows that it is still anonymous. Update 2: But, what guarantee exists that the server doesn't generate a unique public key (i.e. public-private key pair) for each user and thus defeat anonymity this way? Update 3: They use zero-knowledge proofs to prove that all tokens are signed by the same private-key, from their paper: "The work of Jarecki et al. [18] uses a non-interactive zero-knowledge (NIZK) proof of discrete log equality (DLEQ) to provide verification of the OPRF result to the user. Their construction is hence a ‘verifiable’ OPRF or VOPRF and is proven secure in the random-oracle model. We adapt their construction slightly to use a ‘batch’ DLEQ proof allowing for much more efficient verification; in short this allows a user to verify a single NIZK proof that states that all of their tokens are signed by the same private key. This prevents the edge from using different key pairs for different users in an attempt to launch a deanonymization attack; we give more details in Section 3.2.".

This is my understanding of how it works, without knowing the actual maths behind the functions:

    # client
    r = random_blinding_factor()
    x = client_secret_input()
    x_blinded = blind(x, r)

    # Server
    y_blinded = OPRF(k, x_blinded)

    # Client
    y = unblind(y_blinded, r)

This feels like the same kind of unintuitive cryptography as homomorphic encryption.

Using a client provided by Kagi can be a side-channel then? Should we rather be using an independent, standard client?

After reading your comment I still didn't quite understand how the server couldn't just simply log the tokens A, B, C issued to user X. So I had a look at the website you linked: IIUC the key is that the tokens are actually generated by the user and the server never sees them (unblinded) before their first usage:

> When an internet challenge is solved correctly by a user, Privacy Pass will generate a number of random nonces that will be used as tokens. These tokens will be cryptographically blinded and then sent to the challenge provider. If the solution is valid, the provider will sign the blinded tokens and return them to the client. Privacy Pass will unblind the tokens and store them for future use.

> Privacy Pass will detect when an internet challenge is required in the future for the same provider. In these cases, an unblinded, signed token will be embedded into a privacy pass that will be sent to the challenge provider. The provider will verify the signature on the unblinded token, if this check passes the challenge will not be invoked.

Ah thank you. That's the part I was missing. I know this example is wrong in 100 different ways, but something like "yeah we know a key with prime factor X is valid, and this has one", but there's thousands of those out there, so it can't tie out to whom.

Logging in to a search engine weirded me out at first, but after about a week I was so pleased with the results that I’ve been happily paying for almost a year now.

I honestly feel like any major free search engine is probably doing more to try to track you anyway.

And if you’re going to search something you want to be anonymous, you can just like use another search engine. I honestly haven’t run into the situation where I needed to.

I do worry that some day someone will be able to see how often I forget basic syntax for some JavaScript or Python method - or how often I can’t be bothered to type out a full domain and just search to navigate to it - but that’s a price I’m also willing to pay.

Most people are riding 24/7 with a Google session active, as it carries from Youtube/Chrome to Search. I don't think many realize it

Why would you not want to login to a personalized service (unless you really need to be anonymous for some reason)?

> This doesn't fix fingerprinting or IP associations

It solves the problem of using a paid service without compromising customer’s privacy which is a breakthrough. The rest are different problems and they are universal issues with various existing solutions as you already pointed out.

Most of the time I have ProtonVPN in my phone and computer, which solves the IP association problem for me

If you can get Kagi to agree to it, definitely write a blog post on their behalf, please.

Yep, in fact Cloudflare are the original people who came up with this, when people were complaining about seeing turnstile screens too often

So basically the server signs the token and afterwards the server can verify its own signature for every request with that token?

I think the extension they're using being open source helps with this? because it can be checked in there? not sure

Thanks for the clarification.

[I work at Kagi]

The extension is open-source [1], including the Rust code that produces the WASM [2]. You should be able to produce a bit-compatible binary from these repos, and if not, please file a bug!

[1] https://github.com/kagisearch/privacypass-extension

[2] https://github.com/kagisearch/privacypass-lib/

It must be a small fraction since they released their Tor onion service 3 hours ago in the original linked article :)