Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Privacy Pass Authentication for Kagi Search

blog.kagi.com

Post reply on HN
Print view View original

231–240 of 359 posts

Re: Privacy Pass Authentication for Kagi Search

#231

Post by [deleted] »

tiltowait wrote: post #190
swores wrote: post #150

Earlier quoted context omitted.

Their suggestion is that when using Privacy Pass you'd also send "&config=XX" where XX is an ID of a publicly shared config, so that you get the customisation of whatever config you choose without tying the config to yourself, just tying it to the searches you're doing with Privacy Pass. So while it does add a data point that could help track you, it's not defeating the whole point.

Though the post doesn't touch on "community configs", it does touch on "the ten most popular configs", which would seem to be similar enough for this discussion.

[deleted]

Re: Privacy Pass Authentication for Kagi Search

#232

Post by szundi »

brookst wrote: post #205
api wrote: post #140

Earlier quoted context omitted.

This is one of the best explanations I've seen for this phenomenon. If you try to build a network of paid users, you lose because you'll be run over by 'free' competitors monetizing indirectly.

Disagree. You don’t lose, you’re just smaller, better, and still very profitable. HBO used this model way back when. It’s been a lasting business.

[dead]

Re: Privacy Pass Authentication for Kagi Search

#233

Post by Sakos »

Eji1700 wrote: post #230

So....is this privacy through assumed lack of logging? Not trying to be a dick, just legit don't understand a part of this. User A asks kagi for tokens. Kagi says "sure, here's 500 tokens". If kagi then logs the 500 tokens it just gave to user A, it now will know if any of those tokens is redeemed at a later date, that they're assigned to user A? Of course if Kagi just doesn't retain this data, then yeah all is good…

The idea is that the tokens aren't linked to any account. They're anonymous.

Re: Privacy Pass Authentication for Kagi Search

#234

Post by ghayes »

Eji1700 wrote: post #230

So....is this privacy through assumed lack of logging? Not trying to be a dick, just legit don't understand a part of this. User A asks kagi for tokens. Kagi says "sure, here's 500 tokens". If kagi then logs the 500 tokens it just gave to user A, it now will know if any of those tokens is redeemed at a later date, that they're assigned to user A? Of course if Kagi just doesn't retain this data, then yeah all is good…

Privacy Pass docs [0] cover this, but it is mostly referenced deeper in the paper. I believe the idea is that the tokens returned by the server are "unlinkable" to the (modified) tokens passed back by the client. So the server knows it passed back tokens A, B and C to some users, and later receives tokens X, Y and Z. It knows that X, Y and Z are valid, but not their correspondance to the tokens it issued. It uses elliptic curve cryptography for this.

[0] https://privacypass.github.io/

Re: Privacy Pass Authentication for Kagi Search

#235

Post by Twisell »

sxg wrote: post #98
_fat_santa wrote: post #56

Earlier quoted context omitted.

> It's rare to see that a service you use actually does something that benefits the user rather that itself The reason it's become so rare is most companies in this space (heck tons of tech companies period) have used a business model of offering a thing to one group of users and then turning around and selling the results of that thing to another group of users, where the latter group is the one actually driving you…

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.

However, most of current fremium games are precisely based on this model (Fortnite, LoL, TF2, most of mobile games, etc...)

The service is subsidized by "whale players" that regularly spend a lot of cash, but they are a lot of freeloaders (to entertain the whales and to build brand popularity).

Re: Privacy Pass Authentication for Kagi Search

#236

Post by eudhxhdhsb32 »

This is exactly what I've been waiting for to try Kagi.

I want better search results and willing to pay for it, but not at the cost of linking all my searches to my identity.

Also happy to see they're adding tor support.

I feel like I might hit the default limit of 2000 searches per month, but it's not far off.

Re: Privacy Pass Authentication for Kagi Search

#237

Post by Eji1700 »

ghayes wrote: post #234
Eji1700 wrote: post #230

So....is this privacy through assumed lack of logging? Not trying to be a dick, just legit don't understand a part of this. User A asks kagi for tokens. Kagi says "sure, here's 500 tokens". If kagi then logs the 500 tokens it just gave to user A, it now will know if any of those tokens is redeemed at a later date, that they're assigned to user A? Of course if Kagi just doesn't retain this data, then yeah all is good…

Privacy Pass docs [0] cover this, but it is mostly referenced deeper in the paper. I believe the idea is that the tokens returned by the server are "unlinkable" to the (modified) tokens passed back by the client. So the server knows it passed back tokens A, B and C to some users, and later receives tokens X, Y and Z. It knows that X, Y and Z are valid, but not their correspondance to the tokens it issued. It uses ell…

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.

Re: Privacy Pass Authentication for Kagi Search

#238

Post by lawn »

freedomben wrote: post #43
freediver wrote: post #31

Earlier quoted context omitted.

(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.

I'd love to pay for Kagi with crypto, the main thing for me is the steep transfer fees. Nevertheless those can be offset somewhat with bulk payments. How about ability to buy like 3 years of Kagi at a time with crypto? When I try to go into billing in Kagi I just get forwarded to Stripe. Does Stripe process the crypto payments?

Monero itself has very low fees.

It's almost only Bitcoin that has the absurdly expensive fees.

Re: Privacy Pass Authentication for Kagi Search

#239

Post by lawn »

kobieps wrote: post #46
freedomben wrote: post #43

Earlier quoted context omitted.

I'd love to pay for Kagi with crypto, the main thing for me is the steep transfer fees. Nevertheless those can be offset somewhat with bulk payments. How about ability to buy like 3 years of Kagi at a time with crypto? When I try to go into billing in Kagi I just get forwarded to Stripe. Does Stripe process the crypto payments?

paying with bitcoin lightning has close to zero transfer fees edit: on desktop, on the page where you choose your plan, scroll to the bottom and look for the link to paying with OpenNode (btc lightning)

Lightning just isn't a good option as you first have to pay the expensive Bitcoin fees just to be able to use it... (And hope that you'll find a route otherwise you'll have to do it again.)

Re: Privacy Pass Authentication for Kagi Search

#240

Post by codethief »

ghayes wrote: post #234
Eji1700 wrote: post #230

So....is this privacy through assumed lack of logging? Not trying to be a dick, just legit don't understand a part of this. User A asks kagi for tokens. Kagi says "sure, here's 500 tokens". If kagi then logs the 500 tokens it just gave to user A, it now will know if any of those tokens is redeemed at a later date, that they're assigned to user A? Of course if Kagi just doesn't retain this data, then yeah all is good…

Privacy Pass docs [0] cover this, but it is mostly referenced deeper in the paper. I believe the idea is that the tokens returned by the server are "unlinkable" to the (modified) tokens passed back by the client. So the server knows it passed back tokens A, B and C to some users, and later receives tokens X, Y and Z. It knows that X, Y and Z are valid, but not their correspondance to the tokens it issued. It uses ell…

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.

Post reply on HN