[boredpudding]

Any system that can check balance, can link searches to a user. There's no way around it. In your case, Kagi would need to trust the client with the balance, which would be insecure.

There's only one solution, and that is that you need to put a bit of trust in Kagi. Compared to the major one, Google, you can chose between one that promises to not store data, and one that promises it does (and does a lot).

It's always a bit sad that here on HN, when companies try to do better than bigger players, there's always people who think it isn't enough. It has to be absolutely impossibly perfect.

[smsm42]

> Any system that can check balance, can link searches to a user.

I don't think it's true. I can immediately see at least two ways how it can be done without identifying the user.

1. Each user gets X tokens at the beginning of the month. When searching, user supplies a token, which is immediately burned. The token does not contain the user identity, just signature validating it's a valid token.

2. Variation of the above: each user gets a token good for X searches at the beginning of the month. When searching, the system will return a token good for N-1 search each time token good for N searches is presented. Again, no need to contain user identity anywhere in the system.

Of course, both solutions have their downsides (sync between multiple devices, stealing tokens, losing tokens, etc.) but it id definitely possible. And I am sure if somebody spent a little time thinking on it, these ideas can be seriously improved to eliminate the downsides without introducing the need to identify the user.

[phil9909]

In both these cases the search engine provider could easily store your identity together with your token while issuing it and recover the identity once the token is used without any way to prove this from the outside. They could even issue tokens in the form AES_ENC("SOME KEY ONLY THEY HAVE", USER_ID | counter) and you would not notice. You would have to trust them that they won't do this, which is no improvement to the current thing Kagi does (saying they won't collect any data, while admitting they can't prove it, you just have to trust them).

[smsm42]

I think there's a fundamental difference between "X can not be implemented" and "can we trust this provider to implement X correctly"? In this case, it can be implemented without violating privacy. But of course you need to trust them to actually implement what they say and not instead put 9000 trackers in each page and track your every movement like certain other big companies do. But these are different things - the comment upstream claimed that the subscription system can not be implemented with privacy. This is not true - it can be. Whether or not a particular provider would implement it, and whether we can trust them that they did - that's a different question, which is also important but does not change the answer to the original one.

[netsroht]

I'm not a cryptography expert, but from my research, shouldn't it be possible to verify quota on ZKPs server-side? Essentially, the server doesn't need to know the specifics of the user's identity, just that they possess a valid token and haven't exceeded their quota.

You can use search engines like Google without being logged in. When combined with tools like uBlock Origin and Cookie AutoDelete, it becomes more challenging for them to build a singular profile about a user, especially one tied to payment methods such as credit cards.

I genuinely appreciate what Kagi is doing, and I'd absolutely be willing to pay for their service, because if you're not paying for a service, you're the product. I trust companies to uphold their privacy promises, but "Trust is good, but proof is better." ;)

[gizmo686]

The issue is implementing it client side. ZKP means that you cannot simply embed a token in the URL, but instead need to participate in an active protocol. You could implement this in JavaScript, but then you need to trust the JS being served from the server.

Even once you do that, you have all the other tracking mechanisms that the server could use if it wanted to.

[KRAKRISMOTT]

They key word is server side. You have no way to verify that they are not tracking sessions as an user.

[yencabulator]

> Any system that can check balance, can link searches to a user.

For what it's worth, you can buy a physical Mullvad gift card and use that to create a very anonymous account for VPN use.

Even if you buy your gift card from a major online retailer, it comes from a stack of gift cards, nothing tracks which one was sent to whom. You can also exchange gifts among friends.