[HN Gopher] Privacy Pass Authentication for Kagi Search
___________________________________________________________________
Privacy Pass Authentication for Kagi Search
Author : b3n
Score : 335 points
Date : 2025-02-13 19:57 UTC (3 hours ago)
(HTM) web link (blog.kagi.com)
(TXT) w3m dump (blog.kagi.com)
| outime wrote:
| 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 wrote:
| 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 wrote:
| 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.
| SomeoneOnTheWeb wrote:
| Exactly the question I had in mind. You can't rely on server
| side trust so I'm curious if I just misunderstood something...
| thibaultmol wrote:
| I think the extension they're using being open source helps
| with this? because it can be checked in there? not sure
| lxgr wrote:
| I believe "Privacy Pass" uses blind signatures, so the token
| that the TokenResponse contains can't be correlated to the one
| provided in the search query, if I understand it correctly.
| perihelions wrote:
| That's apparently explained in their citation [1], the paper
| about cryptographically anonymous token protocols. It's not a
| simple plaintext token.
|
| https://petsymposium.org/popets/2018/popets-2018-0026.php ( _"
| Privacy Pass: Bypassing Internet Challenges Anonymously"_)
|
| I think Cloudflare implemented the same thing? At least the HN
| comments link to the same paper,
|
| https://news.ycombinator.com/item?id=19623110 ( _" Privacy Pass
| (cloudflare.com)"_, 53 comments)
| ajayyy wrote:
| The tokens are "generated" on the client, and the server just
| gives the client enough information to make that locally
| generated token become "valid", without being able to link that
| token to a specific validation attempt
| sebazzz wrote:
| So basically the server signs the token and afterwards the
| server can verify its own signature for every request with
| that token?
| fvirdia wrote:
| Implementor here. During the Privacy Pass "issuance" protocol,
| the client will generate a "message" that the server will
| process. The output from the server is returned to the client,
| that further modifies this output to produce the final tokens.
| The last client modification randomises these tokens in such a
| way that the server will be unable to identify to what issuance
| they belong.
|
| The very cool thing is that this is the case even if the server
| tries to misbehave during their phase. This means that users
| only need to trust the client software, which we open sourced:
| https://github.com/kagisearch/privacypass-extension
|
| Some posters are mentioning blind signatures, and indeed
| Privacy Pass can utilise these as a building block. To be
| precise, however, I should mention that for Kagi we use
| "Privately Verifiable Tokens" (https://www.rfc-
| editor.org/rfc/rfc9578.html#name-issuance-pr...) based on
| "oblivious pseudorandom functions" (OPRFs), which in my
| personal view are even cooler than blind signatures
| endorphine wrote:
| 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.
| thibaultmol wrote:
| Not yet, but seems like I think they probably could do. Request
| it on https://kagifeedback.org/
| mhitza wrote:
| 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.
| jacekm wrote:
| Kagi accepts bitcoins but Vlad (the founder) mentioned on their
| forum that so few people use this option that it does not make
| sense to work on accepting Monero.
| mhitza wrote:
| 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).
| freediver wrote:
| We implemented Privacy Pass exactly so that you do not need
| to trust any claims we make but as a user have a (provable,
| cryptographically) mechanism that guarantees this, with one
| click, whenever you need it.
| thibaultmol wrote:
| the privacy pass extension is open source exactly because
| users can then verify the process. and yeah, to prevent
| reselling they've made it so you can't get infinite tokens.
| freediver wrote:
| (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.
| freedomben wrote:
| 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?
| kobieps wrote:
| 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)
| loughnane wrote:
| I know I'm just one guy, but lack of Monero support kept me
| away.
|
| This feature looks like it narrows the gap a bit though.
|
| Nice work
| autoexec wrote:
| I agree that third party stores selling tokens without any
| account at all would be the ideal solution, but without an
| account you'd be missing out on many of the features that make
| kagi worth using like being able to remove certain domains from
| results or prioritizing types of results over others.
| dsp_person wrote:
| 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.
| CGamesPlay wrote:
| This defeats the purpose of Privacy Pass. Something similar
| is discussed in the post: https://blog.kagi.com/kagi-
| privacy-pass#:~:text=customizatio...
| swores wrote:
| 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.
| rawkode wrote:
| I wonder how this affects gated features and search limits?
| AlotOfReading wrote:
| That's one of the the technical limitations behind gating it to
| unlimited accounts for now.
| bloomingkales wrote:
| They could embed the subscription level into the blind
| signature.
| dgacmu wrote:
| But they still couldn't do accounting / query limiting for
| users on a limited queries per month plan. So you could do
| "yes you have assistant" or "no you don't" but their
| $5/month taster plan has a query limit.
| bloomingkales wrote:
| Yeah, I guess the only way would be to keep reissuing an
| updated embedded signature with updated query count.
|
| I don't know the cost or liability of that at scale.
| AlotOfReading wrote:
| 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.
| rafram wrote:
| Couldn't those be passed as query parameters?
|
| Though those still get passed to the server, and your
| combination of personalization settings is likely to be
| globally unique, and it's almost certainly unique among the
| subset of users that are paranoid enough about their privacy
| not to store preferences in their session... But still.
| freediver wrote:
| > The unstated downside
|
| It is clearly stated in the blog post :)
|
| We even considered variations of having some settings preserved
| in local storage and impact of that on anonymity. Ultimately
| decided that was not worth it.
|
| Check the FAQ section (towards the end) for full details and
| analysis:
|
| https://blog.kagi.com/kagi-privacy-pass#faq
| Melatonic wrote:
| You could have a few built in options (like for domain
| filtering and customisation) for the privacy people. Could
| even be community sourced so there's no onus on Kagi itself.
|
| So for example there could be a built in "developers" preset
| that might make domains useful to coding higher ranked (and
| down rank or block things like stack overflow clones). Etc
| etc.
|
| Basically this could allow a smaller amount of customisation
| with less ability to identify a specific user.
|
| I also use Orion and I do like the idea someone else had of
| integrating an option for Kagi Privacy mode into the
| "incognito" tabs specifically as an option!
| autoexec wrote:
| Not only that but your searches themselves likely give Kagi
| more than enough information to identify you as an individual.
| We saw that nearly 20 years ago when AOL searches were
| published and users were able to track down specific
| individuals from search terms.
| (https://www.nytimes.com/2006/08/09/technology/09aol.html)
| godelski wrote:
| 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
| bqmjjx0kac wrote:
| Wow! I wouldn't be surprised if I make more than 100 searches
| per day.
| yoshicoder wrote:
| I don't have exact numbers, but I wouldn't be surprised if
| 80-90% of google ad revenue comes from the ad prices they can
| charge for US users. I would be shocked if the percentage was
| less than 50-60% of revenue from US alone, which would put the
| value extraction per user for google at ~10$/month/user
| godelski wrote:
| Sorry, I mean that the revenue seems to not just be search ad
| revenue but ad revenue. Google's ad revenue comes from a lot
| of places, such as in your Android app. I assume it also
| includes adsense and other things.
| atonse wrote:
| I support them ($10/mo) because they do a good job and I
| figured, if I pay, then the likelihood of them using sketchy
| ways of making money is reduced.
| RussianCow wrote:
| I pay $10/month just to have search results that aren't
| littered with SEO spam. The time savings alone make it totally
| worth it for me. Everything else is a giant bonus.
| redserk wrote:
| $10 felt a bit steep until I realized there is probably the
| economies of scale at play here.
|
| 1) There is a marginal payment overhead. I'd assume $0.50-0.75,
| leaving their amount down to $9-ish.
|
| 2) It's a fairly niche product with a still-small userbase.
| ~40k users at ~$9/mo = $360k/mo (I know there's $5/mo users and
| $25/mo users but I'd assume there are far more $5/mo and $10/mo
| users than $25/mo users)
|
| 3) They have to keep the service running 24/7/365, so you have
| to hire devs either across multiple time-zones or compensate
| them enough to be OK fighting fires at 2am.
| autoexec wrote:
| As the user of a service. payment overhead, a small userbase,
| and dev salaries aren't my problem. My only concern is what
| I'm getting for what I'm paying..
|
| $5 a month for fewer than 10 searches a day is clearly not a
| good deal. $10 a month might be worth it for some, but an
| extra $15 a month on top of that for AI results is kind of
| crazy.
| phren0logy wrote:
| For me, it's also about voting with my wallet. I'm not
| enthusiastic about invasive ad tech. As it stands, nobody
| else offers what Kagi offers at any price. If there were an
| equivalent service for $5/month, I'd give it a look, but
| there isn't.
| jjice wrote:
| That extra $15 a month is for access to LLMs. They
| currently support the Claudes, the GPTs (not o1), Mistral,
| Gemini, Llamma, Qwen QWQ, Nova, and DeepSeek. It's
| currently unlimited access in the standard chat format.
|
| You can also choose if you want the chat to RAG search
| results into the context for additional info, and then cite
| those sources. To me, replacing a Claude/ChatGPT
| subscription with $15 on top of a company I already like,
| while also getting a bunch of other models was a no-
| brainer.
| autoexec wrote:
| That makes a lot more sense!
| MostlyStable wrote:
| The way I think about it is how much time do I save by
| having better search results. I'm on a family plan
| currently, but was on an unlimimited 10/month plan. At the
| rate I value my time, Kagi needs to save me well under an
| hour per month through better search results. I'm quite
| confident it reaches and exceeds that bar relative to
| google. And that's even before you get into any
| philosophical/moral preferences for being the direct
| customer rather than being the product (as in ad-supported
| services).
| redserk wrote:
| Perhaps the product isn't for you.
|
| I don't know Kagi's financials, but this is usually the
| case for a lot of products with a smaller customer base.
| For example, a block of Kraft cheddar will be a lot cheaper
| than an equivalent-sized block from an organic local dairy.
| There's always a customer base that is willing to pay for a
| differentiating feature or value.
|
| I'm satisfied paying for it because the product works well
| and saves me time. I can't say the same for a lot of the
| random $10 impulse buys I make in a month.
| hedora wrote:
| If you can pay $10/month for a better search experience, then
| Google's making way more than that much off your data.
|
| Kagi saves me much more than $10 of time every month. I
| definitely don't regret the subscription cost. Their LLM thing
| (append "?" to your internet search query) is worth more than
| that on its own.
| dcow wrote:
| I've been paying for Kagi for a long time through all their
| pricing model changes and updates. I have never once hit the
| search limit. I know they base their tiers on market research
| of search volume balanced against cost of serving a query. If
| you're looking for reasons not to pay for search, you'll find
| them. But the pricing model is hardly one. If you want an
| amazing and respectful search experience, and want to back a
| company that's truly doing right by users and innovating at the
| same time, give Kagi a try!
| thoughtpalette wrote:
| FWIW I signed up about 4 months ago on the starter plan and I'm
| definitely going to run over. I could be smarter about my
| searches though. I've switched to kagi on ALL of my devices,
| including work devices. And I could have searched to using
| google for most gifts/maps stuff instead.
|
| some anecdotal data:
|
| 11/2024: 183 searches
|
| 12/2024: 360
|
| 1/2025: 376
|
| 2/2025: already at 222
|
| Will definitely (happily) have to upgrade to the $10 plan. It's
| been great.
| freedomben wrote:
| I thought this too but at this point I've been subscribed well
| over a year. On a typical workday I might use 20+ searches, but
| I frequently use little to no searches on weekends and
| holidays, etc. Ultimately I end up using right around 300 per
| month (averaged out across the year), so I think their pricing
| isn't as wild as it initially looks.
| MyOutfitIsVague wrote:
| I don't know nor do I really care what other search companies
| are making. I pay $10/month for Kagi because it works for me
| and it's good. I don't even care about Kagi as a company (I
| don't care about any company); their search works. It's a good
| product, and I'm happy to keep paying for it as long as it
| keeps being useful while all the free competitors are still
| terrible. I use about 2k searches per month.
|
| edit: Even just the ability to rank, pin, and block domains
| alone is crazy useful. I never need to see Pinterest in any
| image search results again. If I see a crappy blog spam site, I
| just block it and it never shows up again. It feels like these
| are basic, fundamental features that every search engine should
| have had a long time ago. It's pretty sad that Kagi is getting
| so much praise for doing things that really should have been
| standard for at least a decade (not sad in any negative way
| toward Kagi, but because our standards and expectations for
| search have dropped this low).
| frereubu wrote:
| So funny that blocking Pinterest comes up in all discussions
| on Kagi (I've mentioned it myself in the past). I almost
| think people might pay $1 a month just to block Pinterest.
| miohtama wrote:
| HackerNews discussion to remove Pinterest from Google
| search results (2018)
|
| https://news.ycombinator.com/item?id=16613996
| jorvi wrote:
| > 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.
|
| You can split your searches with search engine shortcuts on the
| desktop, and the search engine quickbar on mobile.
|
| When I still was on the starter plan, I used Kagi whenever I
| had a search that if I use google, I know I will:
|
| - get a bunch of listicles and AI slop (Kagi downranks and
| bundles these)
|
| - get a buch of AI images (again, Kagi clearly labels and
| downranks these)
|
| - have to do multiple google searches for, but can instead use
| Quick Answer for
|
| - will get a bunch of Reddit pre-translated results for
|
| - technical / scientific questions, because of the sites I can
| uprank/downrank/block
|
| I used google for things like:
|
| - highest building in the world
|
| - $bandname Wikipedia / Discogs
|
| - name of thing I can't remember but have the approximate word
| for
|
| You get the idea.
| red_hare wrote:
| You can't expect world percentages to match US percentages. The
| US is only 5% of the world's population and has a very
| different relationship to search. Also, only 63% of the world
| is online, so what does "90% of global" even mean?
|
| Back-of-the-envelope:
|
| - 2tn searches per year.
|
| - US is 20% of all searches.
|
| - Us revenue is 76bn
|
| $76bn / (2tn * 0.2) = $0.19 / search
|
| So, getting 300 searches for less than $0.02 per search sounds
| like a pretty good deal.
| HanClinto wrote:
| I subscribe to an unlimited family plan. When considering how
| much cleaner my web experience is, it's a no-brainer. Default
| search engine on all our phones and devices.
|
| They're my portal to the web. It's less like an optional web
| service (like a streaming service), and it feels more like I'm
| paying for them to be my ISP.
| daft_pink wrote:
| The reason why it's worth it is because its search works really
| well. I've tried DuckDuckGo, Bing and always subconsciously
| ended up back at Google. This is the only search service I've
| used that works better than Google search and I think it's a
| combination of them not putting ads on the search and the way
| they let you tweak the search to block poor quality sites. How
| much it costs them or how much google profits vs your payment
| is not really relevant to me. It's the best working search
| engine in my opinion.
| sedatk wrote:
| Kagi Ultimate plan ($25/mo) includes Kagi Assistant with more
| than 15 different models (including Claude 3.5 Sonnet, Gemini
| 2.0, ChatGPT 4o + o3 mini, DeepSeek R1 etc). That plan suddenly
| becomes the cheapest, IMHO. I know that paid versions of LLM
| services offer more advanced models, but you at least get ahead
| of the rate limits this way.
| flkiwi wrote:
| It's just about the best Internet-related money I spend. I get
| fast, quality results on a service that doesn't obviously bend
| over backwards to monetize me. Ironic, in a way. I thought it
| was spendy at first, and now I can't imagine cancelling my
| subscription.
| BeetleB wrote:
| Depends on how you use it. For non-developers, under 10
| searches per day on average sounds right. Not everyone has a
| job where they sit on a computer all day.
|
| For me, I use Kagi only at home for personal use. And most
| months, I don't exceed 300. Of course, if I included work
| related searches, then yes - 10 searches won't get me far.
| drdaeman wrote:
| 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.)
| thibaultmol wrote:
| yeah, same. I would only use privacy pass for icognito searches
| COUGH P0RN COUGH mainly (let's be honest). Feel free to submit
| the idea on kagifeedback.org
| _fat_santa wrote:
| > 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
| your revenue. 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.
|
| What's refreshing about Kagi and other new tech companies is
| they have dumped this model in favor of having just one group
| that they serve and drive revenue from (ie. the 'old' model).
| sxg wrote:
| 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.
| api wrote:
| 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.
| theschmed wrote:
| FYI in case you're not aware, they announced in a podcast near
| the end of 2024 that a Linux version of Orion is planned.
| Klaus23 wrote:
| The downside of this is that if you are not on a larger
| network, the IP address will probably deanonymise you. Kagi
| knows you are logged in, and if you open a private browsing
| window to do a spicy search, they could link the searches. Fast
| switching between modes is undesirable.
| aryonoco wrote:
| And that's why Kagi has simultaneously rolled out their
| service availability on tor: http://kagi2pv5bdcxxqla5itjzje2c
| gdccuwept5ub6patvmvn3qgmgjd6...
|
| 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.
| eatyourglory wrote:
| 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 wrote:
| 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.
| fvirdia wrote:
| Yes, multi-device is definitely not easy. We've played with a
| few ideas, but it is definitely not a question with an obvious
| answer. For now, our rate-limiting allows you to use Privacy
| Pass on a few different devices by having each generate tokens
| independently. We will see how this goes and listen to user
| feedback before going back to the drawing board.
| baggachipz wrote:
| 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 wrote:
| > Privacy Pass does not rely on any blockchain technology.
|
| Lovely!
| alepacheco-dev wrote:
| I think you could use zero knowledge proofs here to accomplish
| the same thing but without having to worry about renewing tokens
| etc
| ransom_rs wrote:
| A problem with "zero knowledge" proofs is that Kagi needs to
| verify that the user has paid for the service, which requires
| the server to have some knowledge about the client at some
| point.
| daft_pink wrote:
| Hope they can enable this in Safari so that I can use iCloud
| Private Relay with it.
| alepacheco-dev wrote:
| 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.
| FiloSottile wrote:
| Privacy Pass is an anonymous credential scheme that does
| exactly what you describe.
| voytec wrote:
| [deleted by author]
| ransom_rs wrote:
| You have to generate the tokens while signed in, but once you
| have the tokens, you can use them without your searches being
| associated with your account (cryptographically provable).
| voytec wrote:
| [deleted by author]
| echoangle wrote:
| If the method works as described (which is a cryptography
| issue and can be verified?), there's no way to track you.
|
| Your claim is a bit like saying ,,it's impossible to
| encrypt mail, the government wouldn't allow it". But PGP
| still exists.
| fvirdia wrote:
| I believe you should currently be able to - create an account
| under a pseudonymous email address - pay for a plan using a
| pseudonymous Bitcoin wallet - use your login session to
| generate Privacy Pass tokens - search with such tokens via the
| Tor browser on Kagi's .onion domain
| pavon wrote:
| 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 wrote:
| The reason they give in their docs is to "prevent abuse"
| (https://help.kagi.com/kagi/privacy/privacy-pass.html).
|
| It feels like they picked a number no user should hit, while
| keeping it low enough to not pass Kagi out "free" to all their
| friends.
| pavon wrote:
| Ah, that makes sense. It would be harder to detect sharing
| with this system than with account sharing. My thoughts went
| in a completely different direction when I read "abuse" the
| first time.
| abound wrote:
| [I worked on building this at Kagi]
|
| Since we have no idea who is issuing search requests in Privacy
| Pass mode, if there was no limits on token issuance, you could
| simply generate infinite tokens and give them out (or use them
| as part of some downstream service), and we'd have no other
| recourse for rate-limiting to prevent abuse.
|
| Setting a high, but reasonable limit on issuance helps prevent
| abuse, and if you run out of tokens, you can reach out to
| support@kagi.com and we'll reset your quota.
| mortar wrote:
| 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.
| ransom_rs wrote:
| If the system is implemented correctly then Kagi
| cryptographically can't link a particular search to a
| particular user.
| __MatrixMan__ wrote:
| It depends on how hard those companies work beforehand to
| prevent themselves from being able to comply with such requests
| beforehand. Signal is a good example of this, Kagi seems to be
| onboard also.
|
| I haven't looked closely enough at this token thingy Kagi is
| doing but it seems on the surface like it might scratch the
| itch by letting them decouple the accepting-payment part of
| their service from the providing-results part such that they
| know that you've paid, but not which payer you are.
| alexwebb2 wrote:
| I think the idea here is that it literally can't be traced to
| the user - at no point is there anything passed that would
| allow Kagi to make the association between the user and the
| query.
| mortar wrote:
| Thanks, yes completely agree! I guess the part I'm concerned
| with is the politically side whereby they could be
| potentially compelled to change the method slightly after the
| fact and be forced to slip something in somewhere in a quite
| technical process now making it possible.
|
| I'd love to assume this will never happen, I'm just concerned
| that even if it did I'd never find out - Because
| unfortunately the more popular this service gets for bad
| actors, the more of a target it becomes for the government
| with identification of users.
|
| I guess as a search engine, we could assume the government
| may leave them well alone and still just focus on content
| creators.
| prophesi wrote:
| The best that we can do is to continue working on FOSS
| solutions that make it technically impossible to backdoor.
| I haven't grok'd the protocol yet, but it seems to claim
| you only have to trust the client. The client is open
| source, so it would be hard for it to be backdoor'd without
| the community noticing.
|
| Cryptography is a literal godsend for people living under
| oppressive regimes.
| mortar wrote:
| I see this now, thanks for the clarity!
| lukev wrote:
| XKCD #538 strikes again, and definitely extends to forcing
| people to lie about algorithms and possible backdoors.
|
| I don't think, however, that this means we need to give up on
| crypto entirely. Just... be aware of the threat model for what
| you're encrypting.
| echoangle wrote:
| Isn't the whole point that this method is secure by design so
| even if they wanted, they couldn't track you?
|
| Or are you saying the method is designed to look secure but
| there's an intentional weakness that makes tracking possible?
| mortar wrote:
| Definitely suggesting the method is secure, assuming the
| company does all the things they'll say they do, which I also
| agree they'll do. I'm just concerned the government can
| destroy this all, just by compelling them not to, and change
| a well intentioned method at any moment.
| echoangle wrote:
| But what would the government compel them to do? If the
| method is secure, you don't need to trust the server. And
| if they backdoor the open source client, people could
| notice it in an audit.
| mortar wrote:
| The method is secure until they change it. Their docs
| mention that generating a token is not anonymous, but
| using a token is. Considering they already know who
| generated it, it could be trivial for them (to change
| something server side where the validation occurs, if
| compelled) to link a particular search to a user.
| echoangle wrote:
| You don't get the token itself from the server though,
| you get something so you can make your own token for
| which the server doesn't know who created it. So they can
| do whatever they like on the server, they can't identify
| you.
| mortar wrote:
| Indeed, thanks for clearing that up!
| mortar wrote:
| I think you're right, perhaps I'll do some more reading
| about it - It seems like it all relies on what the
| extension does, and if this extension is open source
| someone will notice as you said. Thanks for the clarity!
| sedatk wrote:
| Government's power over companies does not negate cryptographic
| privacy protections. For example, one criminal who used
| ProtonMail got caught because ProtonMail handed over their
| recovery GMail address to the law enforcement after they were
| compelled[1]. However, that means end-to-end encryption worked:
| that was the only thing they could hand over. I think the same
| principle applies here.
|
| [1] https://www.techradar.com/computing/cyber-security/proton-
| ma...
| autoexec wrote:
| The government forces companies to backdoor their systems and
| use compromised implementations (see for example
| https://en.wikipedia.org/wiki/Lavabit). It's also worth
| noting that the only thing preventing your searches being
| linked to your account via IP address and browser
| fingerprinting is to use Tor which conveniently will also not
| protect your from the US government either. Account settings
| can also link a person's searches to their account.
|
| The good news is that while the NSA will absolutely be
| tracking everything you search for while using Kagi they also
| do the exact same thing with every other search engine you
| use so what difference does it make.
| echoangle wrote:
| 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?
| stebalien wrote:
| See section 5.5 of the linked paper
| https://petsymposium.org/popets/2018/popets-2018-0026.php. I'm
| not sure if/how Kagi implemented this, but the idea is that
| Kagi's "public" component can be committed to publicly (e.g.,
| in the browser extension itself).
| echoangle wrote:
| Thanks for looking it up, that makes sense.
| abound wrote:
| [I implemented this at Kagi]
|
| And you can validate this, if you try to issue a Privacy Pass
| search without a private token, you'll get a `WWW-
| Authenticate` header that kicks off the handshake, and that
| should be the same for all users for a given epoch (month).
| E.g. curl -v -H 'X-Kagi-PrivacyPass-Client:
| true' 'https://kagi.com/search?q=test'
| echoangle wrote:
| But how do I validate that I'm actually getting the same
| value as everyone else? Is the value I should get published
| somewhere (in a verifiable and not editable way) so I can
| see that I'm not being tracked?
|
| Or does the extension validate this and the correct value
| is hardcoded in the extension like stebalien suggested?
| abound wrote:
| There's no auth required at this stage of the handshake,
| so you can test from any number of
| devices/locations/networks/etc and confirm you get the
| same value. We could publish it, but it will change every
| epoch/month. Plus, if you don't trust the service to not
| issue special key pairs to track you, you probably won't
| trust us to not do the same when publishing the key
| material. There are schemes involving third-parties we
| could employ, but it's trust and turtles all the way
| down.
|
| A malicious server could maintain separate key pairs for
| users it wanted to track, but you can't do it for every
| user because 1) it'd be clear from the WWW-Authenticate
| header changing, and 2) you'd have to validate tokens
| against every key, which would quickly get too slow to
| work.
| echoangle wrote:
| Makes sense in general, but to make sure I understand it:
|
| > Plus, if you don't trust the service to not issue
| special key pairs to track you, you probably won't trust
| us to not do the same publishing the key material.
|
| You could publish it on some sort of blockchain to make
| sure it can't be changed and is public for everyone,
| right?
|
| > A malicious server could maintain separate key pairs
| for users it wanted to track, but you can't do it for
| every user because 1) it'd be clear from the WWW-
| Authenticate header changing, and 2) you'd have to
| validate tokens against every key, which would quickly
| get too slow to work.
|
| Makes sense, thanks for explaining!
| abound wrote:
| > You could publish it on some sort of blockchain to make
| sure it can't be changed and is public for everyone,
| right?
|
| Your understanding is correct, that's definitely
| something we could do. It is also something anyone else
| could do to keep us honest :)
| jerf wrote:
| Here's a resource I found that walks through the ideas of the
| protocol, starting with simple implementations that have a
| problem, and then solving the problem one by one:
| https://privacypass.github.io/protocol/
|
| I think that's the best conceptual overview of a crypto
| protocol I've ever seen.
| dan353hehe wrote:
| That is an excellent explanation of how the protocol works.
| Thank you for bringing it to the discussion!
| wasabi991011 wrote:
| In the simplest terms, the token generation process B->C is
| done with the user's private key. So even if the server knows
| A,X,B they can't link it to the token C.
| echoangle wrote:
| But if the server is allowed to vary X, it can basically act
| like different servers to each client, and can then when
| given a token check for which server would have been valid.
| The solution I got from the other replies is to make sure
| that the server uses the same X for everyone by verifying it
| as a client.
| esafak wrote:
| I love this company and product. I noticed another great feature
| today: the ability to filter AI slop in image search! It's the
| right-most filter: "AI Images".
| MostlyStable wrote:
| One of the biggest complaints about Kagi from people who have not
| yet adopted it is their privacy concerns around having to login
| and have payment information.
|
| I'm not one of the people that has been concerned about that, but
| I'm curious to what extent this alleviates those concerns among
| those that have had them.
| 1propionyl wrote:
| In general I am a very happy Kagi subscriber, but I have noticed
| in the past month or so that sometimes my searches (via the
| Safari extension) just hang. Navigating it kagi.com also hangs.
|
| When I'm in a rush this forces me to fall back to Google which
| often doesn't provide good results for my queries, which is
| unfortunate
|
| It generally resolves itself in under a minute, but it is still a
| mildly irritating availability issue that wasn't present earlier.
| Maybe something to do with load balancing? No clue.
| freediver wrote:
| We haven't heard about this issue before, do you mind reaching
| out to support@kagi.com with more details so we can debug?
| amazingamazing wrote:
| Do people have news articles of Microsoft, Google et al using
| search history to the searcher's detriment? How frequently does
| this happen? I'm imagining it must be like one in a million.
| Bromeo wrote:
| Per-user search history can directly be sold to advertisers,
| no? I was under the impression Google and Microsoft do that, or
| at least use it internally to build a profile of each user,
| again used for advertising.
| amazingamazing wrote:
| Which search engine sells results directly?
| Ajedi32 wrote:
| Is this the same Privacy Pass that Cloudflare was using to allow
| clients to bypass CAPTCHAs? If so, this is a really neat
| application of that system; it never occurred to me that it could
| be used to anonymously authenticate to a paid service.
| RupertWiser wrote:
| The cryptography privacy pass is based off [1] actually comes
| from Ecash[2] so we've gone full circle.
|
| [1]
| https://www.petsymposium.org/2018/files/papers/issue3/popets...
| [2] https://en.m.wikipedia.org/wiki/Ecash
| perdomon wrote:
| Can someone make a case for Kagi? I'm using Google + Claude for
| all my websearch needs. I don't feel like there's a gap there,
| but maybe that's because I've never experienced anything better
| and can't imagine it?
|
| I do value privacy, but I wouldn't pay extra for more private
| search results. I might pay extra for __better__ search results,
| but that's hard to measure.
|
| Just curious if anyone has had a legitimately great experience
| with this product and can communicate its benefits. Bonus points
| if you're in software dev.
| esafak wrote:
| If you don't immediately notice the difference between Kagi's
| and Google's results, Kagi is not for you.
| trvr wrote:
| This is so true. I've been on Kagi since March 2024. On the
| occasion that I find myself on Google on someone else's
| computer, I find it completely unusable from a search result
| perspective. It's all just junk. Kagi has me as a paying
| customer forever.
| mayneack wrote:
| For me the killer kagi feature is that I can manually up and
| down weight domains in results. I can "pin" and always get
| wikipedia results or "block" and never get pintrest or raise or
| lower as needed. Brave search has a similar feature, but they
| only seem to support "block" not "lower", which is what I use a
| lot more often.
|
| https://kagi.com/stats?stat=leaderboard
| furyofantares wrote:
| If you can't imagine a gap then I think it might not be for
| you.
|
| I tried kagi after finally getting sick of some of my google
| results. Kagi was able to deliver on some of those results.
|
| It's not like, shockingly better results. I do think they're
| better on average, but I'm not sure.
|
| However, in the cases where I couldn't find what I was looking
| for on google and could on kagi, well, that's a binary result.
| I'll take the success and not the failure.
|
| I _was_ surprised by how much better I found the UI. That 's
| actually the thing that sold me on the subscription to begin
| with. Going in, I would not have expected UI to sell me on such
| a thing.
|
| I have since customized it somewhat; there are sites I usually
| really like results from and they are upranked, and sites I
| don't care for which are downranked. I've felt like this has
| lead to even better experience, but I haven't gone back to
| google to compare.
| cmehdy wrote:
| Auto filter for sources, downrank sources you dislike, sort
| results by recency, have an engine that actually respects what
| country or language you're trying to search into, and finally
| present results visually the way you want them. It's worth
| trying to use it actively for a month or so, and you'll see if
| you need it or not. I would not to back to google even if
| Google paid me.
| mulderc wrote:
| For me, Kagi felt like a godsend as my Google searches had
| become polluted, and I had to dig way deeper in the search
| results to get anything decent. They also have an AI assistant
| that gives you access to all the major AI models and integrates
| with their search in a way that I have found very useful.
|
| I would recommend at least giving it a try to see if you notice
| a difference. For my job, the monthly fee more than pays for
| itself
| cyanydeez wrote:
| When does the API. become GA. I really want a reason to spend on
| a valuable search engine.
| freediver wrote:
| In about two months!
| beeflet wrote:
| It's a shame that their $5 tier is only 300 searches/month, or 10
| searches per day. It's kind of ridiculously low. I could burn
| through half of that in a single day of debugging
|
| Also I just tried it and you can't really search for porn
| mulderc wrote:
| Unlimited is only $10, more than worth it for me.
| xlbuttplug2 wrote:
| Google video search works sufficiently well for porn imo. Lets
| me browse amateur content without running into
| shocking/disturbing thumbnails (iykyk).
| dingnuts wrote:
| that's because you're a computer professional and the
| professional plan is more appropriate for you.
|
| I gave a hundred searches to some normies I know and they told
| me that they save them to use when Google can't find what they
| want because Kagi works better (!) so they hoard the searches
| as backups to Google.
|
| All I know is that I haven't used Google on purpose for a year
| and it's really turned into an eyesore
| AutistiCoder wrote:
| Trying to understand Privacy Pass here.
|
| My understanding is, it's analogous to writing a note to your
| manager.
|
| That note is a random number written in ink your manager can't
| actually read; all they can do with that note is sign it. They
| ask God (used here to represent math itself) how to sign this
| note, and God gives them a unique signature that also
| theoretically cannot be used to calculate the number that's
| written. This signature also proves what you're authorized to do.
| And then your manager hands the note back to you.
|
| The note's sole function past that point is so you can point to
| the signature thereon and say "this signature proves I can do
| this, that, etc."
| aryonoco wrote:
| The way I feel about Kagi reminds me of how I felt about Google
| circa 1999.
|
| The cynic in me wants to stop myself from becoming a fanboy
| because we all know how the story of tech startups goes and it's
| bound to repeat itself again; the optimist in me still wants to
| believe that there can be forces of good on the web.
| Klaus23 wrote:
| If account settings are not possible because you could
| fingerprint users, then client-side filtering or reordering might
| be a solution.
|
| Safe-search or not, just transfer both result lists and make the
| client only show the one you want. Blacklists would hide your
| blocked crap sites, and the same could be done with languages,
| where you at least get the results for the bigger ones. It may
| even be possible to implement the ranking adjustments to some
| extend.
|
| Client-side filtering would put more load on the server, but I
| hope the cost increase is tolerable. It could make Privacy Pass
| available to many more users who don't have overly complex
| account rules.
___________________________________________________________________
(page generated 2025-02-13 23:00 UTC)