Kagi does not provide Kagi-Client unlinkability as the Client's payment information allows Kagi to trivially determine the identity of the Client. Kagi does provide Search-Client unlinkability (what the RFC calls Origin-Client unlinkability). More formally: If we assume Kagi cannot derive any identifying information from the privacy token (which I understand you dispute), then given any two incoming search requests, Kagi would not be able to determine whether those two requests came from the same Client or two different Clients.

> Kagi are explicitly stating that they provide the guarantees of § 3.3. They even use more plain language:

Not 100% sure I am understanding you correctly but if you are claiming that Kagi promises all the unlinkability properties in § 3.3, I would say that would be unfair, since they explicitly deny this in the FAQ at the bottom of the post.

I think they are citing that section as they reference several definitions from it in the text that follows.

> >Generation-redemption unlinkability: Kagi cannot link the tokens presented during token redemption (i.e. during search) with any specific token generation phase. *This means that Kagi will not be able to tell who it is serving search results to*, only that it is someone who presented a valid Privacy Pass token. > >Redemption-redemption unlinkability: Kagi cannot link the tokens presented during two different token redemptions. This means that *Kagi will not be able to tell from tokens alone whether two searches are being performed by the same user*. > > As it stands, Kagi cannot meaningfully guarantee those things, because the starting point is the client providing a unique identifier to Kagi.

These specific unlinkability properties are satisfied given that the earlier assumption about the token not providing identifiable information is true.

> Sure, but at that point, there is no need for any of the Privacy Pass infrastructure in the first place.

Kagi Privacy Pass in combination with a 3rd party can acheive a level of privacy that cannot be matched by architectures that don't involve the Privacy Pass or some other exotic cryptography.

I claim that a 3rd-party service + Kagi Privacy Pass meets all unlinkability properties in the RFC (except Attester-Origin for obvious reasons). Additionally, it guarantees confidentiality of the search request and response from malicious middleboxes, given the assumption about the token is true and that the user has access to a trusted proxy.

> I disagree. Their marketing here is "we can't link your searches to your identity, because cryptography."

Disagreement acknowledged. And yes, that quote is a fairly accurate summary of the marketing!

> If Kagi is going to insist on being the attester and on requiring uniquely identifiable information as the basis for issuing tokens, then yes, the only way to even try to confirm that they're not acting maliciously is to keep track not only of distinct keypairs, but also of public and private metadata blocks within the tokens, and to share all of that data (in a trustworthy manner, of course) with other confirmed Kagi users. And if a user doesn't understand all of the nuances that would entail, or all of the nuances just discussed here, and instead just trusts the Kagi-written client implicitly? Then it's all just privacy theater.

Yeah, I'm glad you are willing to say it at least, a lot of stuff these days is security theatre, people just kinda stick their heads in the sand I guess? I'm still hoping that people will realize that SSL has been long in need of a successor, and frankly BGP needs a complete rework too. It's also surprising to me that people are still willing to use Linux distros, although realistically modern computing as a whole is rotten at it's core. At least PGP is still alive, but it has its problems too...