29 ms·

Privacy Pass Authentication for Kagi Search

• eatyourglory 2y ago
  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!
• outime 2y ago
  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 2y ago
  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 2y ago
  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 2y ago
    Exactly the question I had in mind. You can't rely on server side trust so I'm curious if I just misunderstood something...
    • deleted 2y ago
      [deleted]
    • thibaultmol 2y ago
      I think the extension they're using being open source helps with this? because it can be checked in there? not sure
  • lxgr 2y ago
    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 2y ago
    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 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 https://news.ycombinator.com/item?id=19623110 ("Privacy Pass (cloudflare.com)", 53 comments)
    • promiseofbeans 2y ago
      Yep, in fact Cloudflare are the original people who came up with this, when people were complaining about seeing turnstile screens too often
  • ajayyy 2y ago
    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 2y ago
      So basically the server signs the token and afterwards the server can verify its own signature for every request with that token?
      • faeranne 2y ago
        looking at it from a high level, it doesn't appear the final token ever leaves the client till it's being redeemed. There's a middle step that does get signed, but this part is not what is sent.
  • fvirdia 2y ago
    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 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-protocol-for-priva 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
    • hansvm 2y ago
      If you can get Kagi to agree to it, definitely write a blog post on their behalf, please.
      • abound 2y ago
        FWIW, the person you're replying to did write most of the blog post. We work together at Kagi on Privacy Pass.
        • hansvm 2y ago
          Oh, interesting. Maybe it's just on mobile, but no authors are rendering on the article for me. Anywho, the person I replied to seemed to be willing and able to go a technical level deeper than the article, and that's something I'm also interested in reading. It sounds like they'd be allowed :)
• endorphine 2y ago
  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 2y ago
    Not yet, but seems like I think they probably could do. Request it on https://kagifeedback.org/ https://kagifeedback.org/
  • freediver 2y ago
    Yes, should happen soon.
    • privacyking 2y ago
      How soon?
• mhitza 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
        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.
      • Thorrez 2y ago
        >as long as it's tied to a user account, or payment information Privacy Pass unties the searches from the user account and payment information.
• rawkode 2y ago
  I wonder how this affects gated features and search limits?
  • deleted 2y ago
    [deleted]
  • AlotOfReading 2y ago
    That's one of the the technical limitations behind gating it to unlimited accounts for now.
    • bloomingkales 2y ago
      They could embed the subscription level into the blind signature.
      • dgacmu 2y ago
        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 2y ago
          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 2y ago
  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 2y ago
    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.
    • freeAgent 2y ago
      If you did that, it would partially to nearly fully de-anonymize the searcher though (assuming your parameters are unique or near-unique).
  • freediver 2y ago
    > 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 https://blog.kagi.com/kagi-privacy-pass#faq
    • Melatonic 2y ago
      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!
• godelski 2y ago
  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 https://help.kagi.com/kagi/why-kagi/why-pay-for-search.html
  • bqmjjx0kac 2y ago
    Wow! I wouldn't be surprised if I make more than 100 searches per day.
  • yoshicoder 2y ago
    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 2y ago
      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 2y ago
    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.
• drdaeman 2y ago
  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 2y ago
    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 2y ago
    > 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 2y ago
      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.
• tonygiorgio 2y ago
  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 2y ago
    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 2y ago
  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 2y ago
  > Privacy Pass does not rely on any blockchain technology. Lovely!
• alepacheco-dev 2y ago
  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 2y ago
    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 2y ago
  Hope they can enable this in Safari so that I can use iCloud Private Relay with it.
  • ThePowerOfFuet 2y ago
    >Hope they can enable this in Safari so that I can use iCloud Private Relay with it. What are you hoping to gain with that?
    • daft_pink 2y ago
      Being able to use this feature while hiding my ip while I browse. It’s not that I want to hide my ip from Kagi it’s more that it’s not convenient to use Kagi for search on chrome while browsing in safari
• alepacheco-dev 2y ago
  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 2y ago
    Privacy Pass is an anonymous credential scheme that does exactly what you describe.
• voytec 2y ago
  [deleted by author]
  • ransom_rs 2y ago
    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 2y ago
      [deleted by author]
      • echoangle 2y ago
        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.
        • deleted 2y ago
          [deleted]
  • fvirdia 2y ago
    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
• retrorangular 2y ago
  Ironically, I couldn't access this page while using Tor. Reading it from another device though, it seems like a great announcement, I love the idea. I also would be interested in a service like this for attestation on other sites. Device attestation has chilling privacy implications, but if you could have a paid service with a presumably trusted entity like Kagi attest that you are a legitimate user (but hide your identity), maybe more of the Internet could be browsed anonymously, while still minimizing spam. I get why many sites currently block Tor and VPN users, or even users in incognito or without a phone number, as the Internet is essentially unusable without anti-spam measures. That said, I do think anonymity has its place (especially for browsing, even if commenting weren't allowed), and maybe ideas like this could allow for anonymity without the Internet being riddled with spam.
• pavon 2y ago
  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 2y ago
    The reason they give in their docs is to “prevent abuse” (https://help.kagi.com/kagi/privacy/privacy-pass.html 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 2y ago
      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 2y ago
    [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 2y ago
  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 2y ago
    If the system is implemented correctly then Kagi cryptographically can't link a particular search to a particular user.
  • __MatrixMan__ 2y ago
    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 2y ago
    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 2y ago
      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.
• echoangle 2y ago
  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 2y ago
    See section 5.5 of the linked paper https://petsymposium.org/popets/2018/popets-2018-0026.php 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 2y ago
      Thanks for looking it up, that makes sense.
    • abound 2y ago
      [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 2y ago
        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?
        • 2y ago
• esafak 2y ago
  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".
• Kralxxx_666 2y ago
  [flagged]
• MostlyStable 2y ago
  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.
  • g-b-r 2y ago
    > 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. I am, it's mind-blowing to me that anyone would login to a search engine (yes, I know how many do it, now). After a brief verification of the system, I'm pretty sure I'll sign up, now
    • ericrallen 2y ago
      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.
    • mvieira38 2y ago
      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
    • xigoi 2y ago
      Why would you not want to login to a personalized service (unless you really need to be anonymous for some reason)?
  • faeranne 2y ago
• 1propionyl 2y ago
  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 2y ago
    We haven't heard about this issue before, do you mind reaching out to support@kagi.com with more details so we can debug?
    • 1propionyl 2y ago
      Sure, I'll try to catch it in action and send you something useful.
  • themadturk 2y ago
    Just as a data point, I haven't seen this in Safari on desktop or mobile, or in Edge (on my Windows work machine).
• amazingamazing 2y ago
  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 2y ago
    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 2y ago
      Which search engine sells results directly?
• cyanydeez 2y ago
  When does the API. become GA. I really want a reason to spend on a valuable search engine.
  • freediver 2y ago
    In about two months!
    • cyanydeez 2y ago
      Cool. I think I can get my work to pay if I can get an API too.
• Ajedi32 2y ago
  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 2y ago
    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-2018-0026.pdf https://www.petsymposium.org/2018/files/papers/issue3/popets... [2] https://en.m.wikipedia.org/wiki/Ecash https://en.m.wikipedia.org/wiki/Ecash
  • jeroenhd 2y ago
    Yes, though Cloudflare has ended their privacy pass trial as far as I know. I remember Safari as the only browser that implemented it natively, but I guess Orion has it now too.
• perdomon 2y ago
  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 2y ago
    If you don't immediately notice the difference between Kagi's and Google's results, Kagi is not for you.
    • trvr 2y ago
      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.
      • scroot 2y ago
        ditto
  • mayneack 2y ago
    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 https://kagi.com/stats?stat=leaderboard
    • perdomon 2y ago
      This is the exact sort of QOL feature that could convert me. I get tired of seeing the same recycled AI listicles for certain search genres, and it sounds like Kagi could help me manage that for my preferences.
• beeflet 2y ago
  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 2y ago
    Unlimited is only $10, more than worth it for me.
    • beeflet 2y ago
      I will try it for more technical queries, but the results seem to be worse than Google/DDG. The reverse image search sucks and has never returned a single result for me. I suppose the advantage is that it whitelists/blacklists against spam, but it frequently comes up empty handed. So maybe it needs to crawl/scrape the web deeper or it needs a better search algorithm or trust model. I could probably get better results by crawling the web myself at home.
      • mdaniel 2y ago
        Heh, that's one of the more aggressive "how hard can it be?!" that I've seen in a while I invite you to look at the number of threads of people complaining about Cloudflare locking their perfectly normal browser out of a stupid amount of the Internet and then carefully consider how you would circumvent those anti-bot controls
  • deleted 2y ago
    [deleted]
  • dingnuts 2y ago
    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 2y ago
  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."
  • ripped_britches 2y ago
    > They ask God (used here to represent math itself) Thank you so much, I am 100% stealing this
    • AutistiCoder 2y ago
      I mean, invoking God kind of works for describing the idea that “math” sometimes knows a secret and can tell someone how to act on that secret without telling them the secret.
• aryonoco 2y ago
  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.
  • deleted 2y ago
    [deleted]
• Klaus23 2y ago
  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. The same could be done with languages, where you at least get the results for the bigger ones. Blacklists would hide your blocked crap sites. It may even be possible to implement the ranking adjustments to some extend. Client-side filtering would put more load on the server and search sources, but I hope the cost increase is tolerable. Blacklisting and reordering could be virtually free. This could make Privacy Pass available to many more users who don't have overly complex account rules.
  • xzjis 2y ago
    That's really smart. You should suggest it to Kagi directly: https://kagifeedback.org/ https://kagifeedback.org/
• noident 2y ago
  I'm not affiliated with the Tor Project organization, but I have some questions. From Tor docs [0]: > Add-ons, extensions, and plugins are components that can be added to web browsers to give them new features. Tor Browser comes with one add-on installed: NoScript. You should not install any additional add-ons on Tor Browser because that can compromise some of its privacy features. How does Kagi square this with Privacy Pass, which requires a browser extension rejected by Tor [1]? Did Kagi analyze whether it is possible to bucket users of Tor into two distinct groups depending on whether the extension is installed? Do I need to trust another organization other than the Tor project to keep the signing keys for the extension safe? Was there any outreach to the Tor community at all prior to releasing this feature? It's great that they're Torifying the service, but depending on a 3rd party extension is not ideal. [0] https://support.torproject.org/glossary/add-on-extension-or-plugin/ https://support.torproject.org/glossary/add-on-extension-or-... [1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/24321 https://gitlab.torproject.org/tpo/applications/tor-browser/-...
  • JumpCrisscross 2y ago
    > Was there any outreach to the Tor community at all prior to releasing this feature? Do we know what fraction of Kagi users access it through Tor?
    • noident 2y ago
      It must be a small fraction since they released their Tor onion service 3 hours ago in the original linked article :)
      • JumpCrisscross 2y ago
        I’m not diminishing Kagi or Tor, I’m asking for validation for the former expanding resources.
  • noident 2y ago
    I sat down on my desktop to take a closer look at how Kagi implemented this. It turns out that the privacy pass extension isn't the one implemented by CloudFlare (and rejected by Tor), but a new extension called Kagi Privacy Pass. Ok, let's look at the source. curl -L https://addons.mozilla.org/firefox/downloads/file/4436183/kagi_privacy_pass-1.0.2.xpi > /tmp/extension.xpi unzip /tmp/extension.xpi -d /tmp/extension cd /tmp/extension Alright, here's some nice, clean, easy-to-read Javascript. Nice! Wait, what's that? // ./scripts/privacypass.js /* * Privacy Pass protocol implementation */ import init, * as kagippjs from "./kagippjs/kagippjs.js"; ... // load WASM for Privacy Pass core library await init(); I opened ./kagippjs/kagippjs.js and was, of course, greeted with a WASM binary. I personally would not install unknown WASM blobs in Tor browser. Source and reproducible build, please! Let's continue. // get WWW-Authenticate HTTP header value let origin_wwwa_value = ""; const endpoint = onion ? ONION_WWWA_ENDPOINT : WWWA_ENDPOINT; try { const resp = await fetch(endpoint, { method: "GET", headers: { 'X-Kagi-PrivacyPass-Client': 'true' } }); origin_wwwa_value = resp.headers.get("WWW-Authenticate"); } catch (ex) { if (onion) { // this will signal that WWWA could not fetch via .onion // the extension will then try normally. // if the failure is due to not being on Tor, this is the right path // if the failure is due to being on Tor but offline, then trying to fetch from kagi.com // won't deanonymise anyway, and will result in the "are you online?" error message, also the right path return origin_wwwa_value; } throw FETCH_FAILED_ERROR; } What?? If the Onion isn't reachable, you make a request to the clearnet site? That will, in fact, deanonymize you (although I don't know if Tor browser will Torify `fetch` calls made in extensions). You don't want Tor browser making clearnet requests just because it couldn't reach the .onion! What if the request times out while it's bouncing between the 6 relays in the onion circuit? Happens all the time.
• Thorrez 2y ago
  >We are working on enabling this feature for Trial and Starter plans, which have access to a limited number of monthly searches. [...] and theoretically, users on this plan could redeem more tokens than the limit of searches allowed on their plan (again, we do not know who the user redeeming the tokens is, or what plan they are on). This doesn't make sense. Is this saying they're worried about a user on a trial or starter plan using someone else's tokens? That can still happen when tokens are disabled for trial and start plan users: the trial or starter plan user can use tokens generated by someone on an unlimited plan.
  • dalenw 2y ago
    They're saying that when someone uses a privacy token to search, they cannot track which account it's tied to. Therefor, they cannot track limits & billing.
    • solardev 2y ago
      What's to stop a single unlimited user from generating and sharing infinite tokens with the rest of the world, then? Edit: Each account is limited to 2000 tokens per month, unless they email support to request more. (from the FAQ near the bottom). Still seems like there could be a secondary market for resold tokens, though. Not just as a money making system, but possibly as a privacy initiative? If enough accounts pooled tokens into a shared pool and withdrew a random one from it each time, it would be a further safeguard.
    • Thorrez 2y ago
      The whole point of privacy tokens is you don't need to track usage. You track generation instead. They can track limits and billing at generation time. They know this. The sentence I previously quoted says so in the [...] section: > We are working on enabling this feature for Trial and Starter plans, which have access to a limited number of monthly searches. Therefore, they risk a worse user experience if their generated tokens are lost (for example, due to uninstalling the extension) If they don't track limits and billing at generation time, then there's no "risk [of] a worse user experience if their generated tokens are lost". This ""risk [of] a worse user experience if their generated tokens are lost" is a logical reason to not enable privacy tokens for Trial and Starter plans. The risk of "users on this plan could redeem more tokens than the limit of searches allowed on their plan" is not a logical reason to not enable privacy tokens for Trial and Starter plans.
• tonymet 2y ago
  I hope Protonmail picks up on privacy pass. It would be nice to fund anonymous Protonmail accounts with an anonymous “benefactor” account.
• hollowturtle 2y ago
  Just out of curiosity, how is Kagi(the company) financially going? And his fortune really is because google search sucks so hard? Genuine curiosity
• bpev 2y ago
  Amazing! I used kagi at the very beginning, but my biggest concern was always this (that logging in is inherently less private than using something like duckduckgo, so I'm just forced to trust Kagi's will). This is the kind of thing that will force me to take a second look again.
• agnishom 2y ago
  This is really cool. How does the cryptography work? EDIT: Seems like it works via https://en.wikipedia.org/wiki/Blind_signature https://en.wikipedia.org/wiki/Blind_signature
• tansan78 2y ago
  I am just thinking there might be other better ways to preserve user's search privacy: using LLM embeddings (https://en.wikipedia.org/wiki/Word_embedding https://en.wikipedia.org/wiki/Word_embedding). The browser creates embeddings of user query, then send the embeddings to the server. To complete a search, the server is a machine and it does not really need text to understand what a user want. A series of numbers, like LLM embeddings, are totally fine (actually it might even be better, because embeddings map similar words closely, like Duck and Bird have similar embeddings). On the privacy side, LLM embeddings are a bunch of numbers. Even the embeddings are associated with a user, other people cannot make meaning out of the embeddings. Therefore the user's privacy is preserved. What do you think?
  • 3s 2y ago
    This is an interesting idea, and indeed such an approach to providing privacy has been formalized to different degrees and varying levels of success (eg. [1][2]). [1] https://arxiv.org/abs/1204.2136 https://arxiv.org/abs/1204.2136 [2] https://arxiv.org/abs/2210.03458 https://arxiv.org/abs/2210.03458 Unfortunately, as described, such a solution would only satisfy a somewhat meaningless notion of privacy. Specifically, the embeddings by definition contain potentially private information about the user, revealing things like "I'm asking about birds" to use your example. Even though it might "compress" the query in a slightly lossy way, it would still reveal a great deal of information about the query. A true solution to this problem would require something like differential privacy and adding noise to the embeddings. However, the noise required would (likely) end up destroying too much information from the embedding to preserve accuracy of the LLM.
  • VHRanger 2y ago
    While this is a neat sounding idea, there's a few issues here: 1. Embeddings are very close to a reversible function. It's not hard to take an embedding and query back the closest query semantically from the source LLM. 2. We already don't log any queries from the users. I'm aware this has to be taken on faith from Kagi users. But you can believe that not having any user query data at all anywhere is a significant speed bump for us in feature development, bug tracking and roadmapping.
• ijul 2y ago
  hekdaimon Al
• aspensmonster 2y ago
  Seeing as I'm not getting any traction in the fediverse (https://tenforward.social/@aspensmonster/113999217587309328 https://tenforward.social/@aspensmonster/113999217587309328), maybe I can ask here instead. ================================= From their blog: >As standardized in [2 - 4], the Privacy Pass protocol is able to accommodate many “architectures.” Our deployment model follows the original architecture presented by Davidson et al. [1], called “Shared Origin, Attester, Issuer” in § 4 of [2]. From [2] RFC 9576 § 3.3 "Privacy Goals and Threat Model" : >Clients explicitly trust Attesters to perform attestation correctly and in a way that does not violate their privacy. In particular, this means that Attesters that may be privy to private information about Clients are trusted to not disclose this information to non-colluding parties. Colluding parties are assumed to have access to the same information; see Section 4 for more about different deployment models and non-collusion assumptions. However, Clients assume that Issuers and Origins are malicious. And From [2] RFC 9576 § 4.1 "Shared Origin, Attester, Issuer" : >As a result, attestation mechanisms that can uniquely identify a Client, e.g., requiring that Clients authenticate with some type of application-layer account, are not appropriate, as they could lead to unlinkability violations. Womp womp :( This is not genuinely private in any meaningful sense of the term. Kagi plays the role of all three parties, and even relies on the very thing section 4.1 says is not appropriate: to use mechanisms that can uniquely identify a client. They utilize a client's session token: "In the case of Kagi’s users, this can be done by presenting their Kagi session cookie to the server." Frankly, that blog post is disingenuous at best, and malicious at worst. ================================= I want to be wrong here. Where am I wrong? What am I missing?
  • nulld3v 2y ago
    This would definitely seem like a big concern if you were just looking at the RFC, but the key here is that Kagi's system has a different set of security/privacy/functional requirements and therefore the issues mentioned in the RFC do not necessarily apply. In the RFC's architecture, the request flow is like so: 1. CLIENT sends anonymous request to ORIGIN 2. ORIGIN sends token challenge to CLIENT 3. CLIENT uses its identity to request token from ISSUER/ATTESTER 4. ISSUER/ATTESTER issues token to CLIENT 5. CLIENT sends token to ORIGIN You can see how the ISSUER/ATTESTER can identify the client as the source of the "anonymous request" to the ORIGIN because the ISSUER, ATTESTER and ORIGIN are the same entity, so it can use a timing attack to correlate the request to the ORIGIN (1.) with the request to the ISSUER/ATTESTER (3.). However you can also see that if a lot of time passes between steps (1.) and (3.), then such an attack would be infeasible. Reading past your quote from RFC 9576 § 4.1., it states: > Origin-Client, Issuer-Client, and Attester-Origin unlinkability requires that issuance and redemption events be separated over time, such as through the use of tokens that correspond to token challenges with an empty redemption context (see Section 3.4), or that they be separated over space, such as through the use of an anonymizing service when connecting to the Origin. In Kagi's architecture, the "time separation" requirement is met by making the client generate a large batch of tokens up front, which are then slowly redeemed over a period of 2 months. The "space separation" requirement is also satisfied with the introduction of the Tor service. There is some more discussion in RFC 9576 § 7.1. "Token Caching" and RFC 9577 § 5.5. "Timing Correlation Attacks". One question you may have is: Why wasn't this solution used in the RFC? This can be understood if you look at the mentions of "cross-ORIGIN" in the RFC. This RFC was written by Cloudflare, who envisioned it's use across the whole Internet. Different ORIGINs would trust different ISSUERs, tokens from one ORIGIN<->ISSUER network might not work in another ORIGIN<->ISSUER network. This made it infeasible for clients to mass-generate tokens in advance, as a client would need to generate tokens across many different ISSUERS. Of course, adoption was weak and there ended up being only one ISSUER - Cloudflare, so they adopted the same architecture as Kagi where clients would batch generate tokens in advance (batch size was only 30 tokens though). RFC 9576 § 7.1. also mentions a "token hoarding" attack, which Cloudflare felt particularly threatened by. Cloudflare's Privacy Pass system worked in concert with CAPTCHAs. Users could trade a completed CAPTCHA for a small batch of tokens, allowing a single CAPTCHA completion to be split into multiple redemptions across a longer time period. However, rudimentary "hoarding"-like attacks were already in use against CAPTCHAs through "traffic exchanges". Opening up another avenue for hoarding through Privacy Pass would have only exacerbated the problem.
• pzo 2y ago
  Wouldn't this allow people to abuse and share token amount many users? People used to buy one subscription and share among friends e.g. Netflix but only shared amount family or friends - you wouldn't want random people know what movies you like to watch. Similarly people would less likely share their chatgpt plus account because everyone can see history and change settings. But with such privacy pass those issues don't exists I guess so more likely this can be abused.
  • kurtoid 2y ago
    > There's a monthly limit of 2,000 tokens per account to prevent abuse https://help.kagi.com/kagi/privacy/privacy-pass.html https://help.kagi.com/kagi/privacy/privacy-pass.html So I guess you _could_ share them, but only with so many people or so many searches.
• grg0 2y ago
  Does this actually work, though? The token can only be redeemed once, which means that, realistically, the client is going to be in a loop generating and redeeming tokens in a given search session, which makes the pairs trivial to correlate. The article even states it: > For this reason, it is highly recommended to separate token generation and redemption in time, or “in space” (by using an anonymizing service such as Tor when redeeming tokens, see below). Sure, Tor will random the space. But what about the time? I then went to "see below" and didn't see anything relevant. Or is the idea that, with sufficient request volume, clients mask each other in time? Also, Tor will only randomize the space insofar as you keep re-establishing a session; the loop remains static for the duration of a session afaik. And re-establishing a session takes like 10 seconds. So is it really randomizing the space?
  • abound 2y ago
    > The token can only be redeemed once, which means that, realistically, the client is going to be in a loop generating and redeeming tokens in a given search session, which makes the pairs trivial to correlate. One token request can produce N tokens. We have it configured where N = 500, so most users will be requesting more tokens fairly infrequently.
    • grg0 2y ago
      Thanks for the clarification.
  • deleted 2y ago
    [deleted]
• eviks 2y ago
  Cool feature, curious, does the bangs solution (! Language ! Region ! Safe search) to the inability to use your config not introduce the same privacy concerns? > allowing users to send a small configuration with every request (language, region, safe-search) to automatically customize your search experience to some extent. However, we currently believe this would quickly result in a significant loss of anonymity for you and for other users. > For manual search settings customization, you can always use bangs in your search query to enable basic settings for a specific query.
• italiancheese 2y ago
  I want to pay for Kagi, but it's priced way too high (for me). Would love it if they implemented Purchasing Power Parity (PPP).
  • eudhxhdhsb32 2y ago
    Where do you live and how much lower do you expect them to go? Starting at $5 a month seems very reasonable to me for a non-essential premium search experience.
  • thibaultmol 2y ago
    problem is that they have small margins because they have to pay a lot for their upstream providers (and those don't care about what region kagi users are from so charge the same)
    • bugtodiffer 2y ago
      and they use all of their margin to build a browser because why not
  • xigoi 2y ago
    https://kagifeedback.org/d/687-implement-regional-pricing/5 https://kagifeedback.org/d/687-implement-regional-pricing/5 > Regional, student, annual...discounts are not possible because we are not currently making any profit to discount it off from.
• Eji1700 2y ago
  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 because the token itself is only marked as valid, not valid and given to user A on date Y, but....that's it right? Or am I misunderstanding something?
  • Sakos 2y ago
    The idea is that the tokens aren't linked to any account. They're anonymous.
  • ghayes 2y ago
    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/ https://privacypass.github.io/
    • Eji1700 2y ago
      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.
    • codethief 2y ago
      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.
• eudhxhdhsb32 2y ago
  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.
• bugtodiffer 2y ago
  I'm willing to bet they have not gotten this tested by security professionals
• nvarsj 2y ago
  I still cannot get iOS to reliably use Kagi as my default search engine. I've tried the extension, etc. but nothing works reliably. It's madness - how is it market fairness when iOS literally forces you to use Google? I know Google is paying Apple to do exactly that, but it's so beyond anti-consumer I can't believe it.
  • Sakos 2y ago
    Meanwhile, Google gets hit with the anti-competitive judgment and Apple gets off by way of being more anti-competitive. Wild, isn't it?
  • TingPing 2y ago
    Anecdotally I’ve had zero issues with the Safari extension.
• Amekedl 2y ago
  I've read the post and saw the references, but can anyone easily explain how it works? Can the server not just store whatever is generated to link it back to the user using it?
  • deleted 2y ago
    [deleted]
• ThePowerOfFuet 2y ago
  Alas, not compatible with Firefox for Android
• raphaelrobert 2y ago
  I love that Kagi now uses Privacy Pass, and they look like a cool company in general. That being said, they essentially took the IETF draft I worked on for a while [1] and also my Rust implementation [2]. They built a thin wrapper [3] around my implementation and now call it "Kagi’s implementation of Privacy Pass". I think giving me some credit would have been in order. IETF work and work on open-source software is mostly voluntary, unpaid, and often happens outside of working hours. It's not motivating to be treated like that. Kagi, you can do better. [1] https://datatracker.ietf.org/doc/draft-ietf-privacypass-batched-tokens/ https://datatracker.ietf.org/doc/draft-ietf-privacypass-batc... [2] https://github.com/raphaelrobert/privacypass https://github.com/raphaelrobert/privacypass [3] https://github.com/kagisearch/privacypass-lib/blob/e4d6b354dd2a39e7f9e43a5164cd79da3e563446/src/core/Cargo.toml#L36 https://github.com/kagisearch/privacypass-lib/blob/e4d6b354d...
  • alphabetter 2y ago
    Honestly, I think what TFA calls "Kagi’s implementation of Privacy Pass" is the integration of the feature into their server and clients, not the RFC (which they acknowledge), or the protocol implementation.
    • abound 2y ago
      [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/LICENSE https://github.com/raphaelrobert/privacypass/blob/main/LICEN... [2] https://github.com/kagisearch/privacypass-lib/blob/e4d6b354dd2a39e7f9e43a5164cd79da3e563446/src/core/Cargo.toml#L36 https://github.com/kagisearch/privacypass-lib/blob/e4d6b354d...
• devwastaken 2y ago
  This is meaningless with a paid for service. Kagi can and will be required by court order to collect and track a subscribers use. It doesn't matter if your tech is supposed to be “anonymous”, they have to make it happen. You must operate in a country that cant compel this and be willing to jump ship when your nsa equivalent gets upset.
• sebastiangula 2y ago
  I can't explain this rationally, but my brain just rejects any other search engine. For example, in the case of Kagi, black links instead of blue feel off-putting. I guess years of using Google has hardwired into my brain how a search engine should look.
  • DavideNL 2y ago
    > For example, in the case of Kagi, black links instead of blue feel off-putting. Not exactly sure what you're getting at, but: "Using CSS, you can fully customize Kagi's search and landing pages from your Appearance settings." : https://help.kagi.com/kagi/features/custom-css.html https://help.kagi.com/kagi/features/custom-css.html
  • deleted 2y ago
    [deleted]
• throwaway290 2y ago
  This is a nice move. Now they just need to stop paying Yandex/Russia and I'd be back...
• korjavin 2y ago
  [dead]
• bteamfilms 2y ago
  [dead]