[HN Gopher] Privacy Pass Authentication for Kagi Search
___________________________________________________________________
Privacy Pass Authentication for Kagi Search
Author : b3n
Score : 883 points
Date : 2025-02-13 19:57 UTC (1 days 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)
| promiseofbeans wrote:
| Yep, in fact Cloudflare are the original people who came up
| with this, when people were complaining about seeing
| turnstile screens too often
| 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?
| faeranne wrote:
| 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 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
| hansvm wrote:
| If you can get Kagi to agree to it, definitely write a blog
| post on their behalf, please.
| abound wrote:
| FWIW, the person you're replying to _did_ write most of the
| blog post. We work together at Kagi on Privacy Pass.
| hansvm wrote:
| 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 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.
| Thorrez wrote:
| >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.
| 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)
| lawn wrote:
| Lightning just isn't a good option as you first have to
| pay the expensive Bitcoin fees just to be able to use
| it... (And hope that you'll find a route otherwise you'll
| have to do it again.)
| kobieps wrote:
| If $0.27 is an expensive fee then I don't have any
| answers to that.
|
| Yeah routing can suck. First timers should use a
| lightning wallet with built in LSP support like ZEUS,
| BitKit, Phoenix, etc. Then routing is a non-issue.
| lawn wrote:
| Bitcoin average transaction fees is rarely under $1: http
| s://ycharts.com/indicators/bitcoin_average_transaction_f.
| ..
|
| I think it's better to use another cryptocurrency like
| Monero than having to rely on a centralized service just
| to get a half-decent user experience.
| kobieps wrote:
| People regularly overpay, so I'm not sure looking at
| average fees it the right lens. Monero is great, but it's
| trivial to get an excellent user experience with
| lightning nowadays that doesn't require custodians.
| lawn wrote:
| The reason people overpay is that it's impossible to
| foresee what fee will get you into the next block, so
| they overpay to not get stuck potentially for hours or
| more.
|
| Not requiring custodians is just one part, having to rely
| on third-party services for basic functionality is
| another.
| lawn wrote:
| Monero itself has very low fees.
|
| It's almost only Bitcoin that has the absurdly expensive
| fees.
| 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
| arlort wrote:
| Don't know a bunch about cryptocurrencies, but couldn't
| you get the benefits of monero by just converting monero
| to btc before paying?
|
| Are the conversion fees too high?
| akimbostrawman wrote:
| You can but its not only more effort and increases the
| price but also reduces privacy and anonymity because you
| introduce a possible point of tracking with most likely
| KYC exchanged BTC and a publicly viewable blockchain.
| loughnane wrote:
| In addition to what u/akimbostrawman said, I feel like
| doing that would undermine long-term privacy by slowing
| adoption of a tool (monero in this case) in favor of
| something less private.
| jacekm wrote:
| You can, but to retain anonymity you'll need to go
| through decentralized exchange (DEX). This is extra
| hassle, especially if you have never done this before.
| akimbostrawman wrote:
| Nobody wants to use BTC because of high fees and at this
| point its less a usable exchange of value than speculative
| asset. I personally would only ever use and trust a online
| service advertised as private/anonymous if it actually
| supported a private and anonymous currency (like some vpns
| do).
| kobieps wrote:
| Anyone claiming high fees is straw manning
| akimbostrawman wrote:
| Lightning is a meme. Imagine needing a sperate glued on
| system to be somewhat tolerable at the thing it was
| created for.
| kobieps wrote:
| Calling it an experiment would be more accurate than
| declaring it has already failed.
| 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.
| tiltowait wrote:
| Though the post doesn't touch on "community configs", it
| does touch on "the ten most popular configs", which would
| seem to be similar enough for this discussion.
| 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.
| freeAgent wrote:
| If you did that, it would partially to nearly fully de-
| anonymize the searcher though (assuming your parameters are
| unique or near-unique).
| 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 people were able to track down specific
| individuals from their 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 things like 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!
| pimeys wrote:
| This. I used to host my private searxng service which is
| a bit like what Kagi is selling. Yes, Kagi offers site
| blocking, rewrites and pinning which is great. But the
| best part is the access to R1 combined with Kagi search
| which adds context.
|
| You can just quickly write !ai to the toolbar and you
| have a deepseek chat open. Or !sum to summarize the
| current page or video.
| wkat4242 wrote:
| You can also self-host that part. OpenWebUI integrates
| very well with searxng.
|
| But kagi does a good job too, indeed.
| 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.
| asukachikaru wrote:
| I subscribed to kagi's $5/m plan since last March, and my
| usage until now is around 3.3k searches, with the monthly
| distribution similar to yours. Some months it's more, some
| months it's fewer.
|
| Currently I'm debating with myself if I should go for the $10
| plan. I'm all down for supporting kagi, but surprisingly I
| didn't use as many searches as I thought.
| freediver wrote:
| One thing we noticed anecdotally (may not apply to your
| case) is that Kagi users search less when they switch to
| Kagi from other search engines, and the likely reason is
| that they just find things faster. Which is basically the
| main metric we are optimizing the product for - happy
| users, lower cost for us.
| 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
| godelski wrote:
| Honestly, this was a better ad for Kagi than what I got from
| the site. I'll actually check it out. Thanks
| 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.
| themadturk wrote:
| I've been paying $5 a month for over a year and have hit the
| 300 search limit only once. I feel like I'm pretty active on
| the web, but perhaps I just have days where I don't search as
| often as others.
| karaterobot wrote:
| I assume Kagi's customers (of which I've been one since 5/22)
| are apt to value retaining their privacy more than Google
| values selling their data. That is to say, it's worth more than
| $10 (and more than $23 a month) for me to believe my data isn't
| being sold to advertisers. If you don't take that position, or
| set different values on it, I can certainly see why $5 or $10 a
| month wouldn't be worth it to you.
|
| There's also the matter of Google search quality being
| increasingly bad, while Kagi's is consistently... okay. They
| also have a a lot of nice features, liking being able to change
| the weight of different sites in your list of results.
| 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.
| baridbelmedar wrote:
| Playing devil's advocate...
|
| Yeah, the ad supported model has its problems, but it
| also makes the internet way more accessible. If we think
| about it, companies and people with more money are
| basically subsidizing these services for everyone else.
| They're the ones seeing the ads that keeps the lights on
| for users who can't afford to pay.
|
| If everything was subscription only, a ton of people like
| students, low income families, people in developing
| countries would be shut out. "Free" services, even with
| their flaws, create a kind of digital subsidy. It's not
| perfect, but it means way more people can use these
| tools.
| laurex wrote:
| Playing the... angel's advocate...
|
| There's no reason why a subscription model could not also
| be used to subsidize people who can not pay, other than
| that companies are structured to extract as much as
| possible (by law, if they are public).
|
| There are good network effect arguments about why this
| strategy can be effective, not simply 'altruistic.'
|
| Ads simply make the extraction happen across the board,
| except that the ad model somewhat privileges technical
| users who know how to circumvent ads.
| dmoy wrote:
| What's the mechanism by which a private company does e.g.
| income verification to figure out who gets subsidy or
| not?
|
| Or would the idea be to only subsidize students and not
| poor adults?
|
| It would be one thing if we had like a national "verify
| I'm on SNAP or equivalent API"
| abdullahkhalids wrote:
| Think of Discord. Anyone can create and participate in a
| discord server. There are no ads. People with money pay
| for the premium features and perks and that is how the
| company makes money [1].
|
| Not every product category is amenable to such business
| models but many are.
|
| [1] To be fair, Discord likely sells user data to
| advertisers to make additional money.
| kortilla wrote:
| > structured to extract as much as possible (by law, if
| they are public).
|
| This is not true and it's not what fiduciary duty means.
| Stop repeating it, it's really dumb.
|
| Companies very frequently do not monetize things that
| they could under the guise of "building brand
| recognition" or "establishing a user base". It's even as
| easy as "raising the price will alienate customers we
| think are important to long term revenue".
|
| It's trivial to justify not extracting maximum price and
| public companies do it all of the time.
|
| Look at Costco's business model if you want an example
| jorvi wrote:
| I mean, we could also just direct-pay websites (for
| example with Brave's Basic Attention Token model).
|
| Imagine a utopian world where you just pay per site
| visit, and in return all companies selling stuff don't
| have an inflated advertising budget and free market
| effects force them to pass the savings on to you, meaning
| the net cost increase for you is zero. And as a side-
| effect, quality products float to the top, since you hear
| of them mostly by word-of-mouth, meaning products compete
| on value-per-dollar.
|
| Sadly human psychology and economics does not work that
| way haha. We pay what the market will bear, and
| increasing sales via a torrent of ads is cheaper than
| increasing the value-per-dollar ratio of the product.
| kennyloginz wrote:
| Companies are not bound by law to extract as much as
| possible as soon as possible.
| dreamcompiler wrote:
| Correct. Wall Street will punish them for violating this
| principle, not the government.
| eitland wrote:
| Our only recourse is that we punish them with our
| wallets, advice and habits and reward good actors.
|
| I'm a firm believer of this but we need more people to
| join in.
|
| And it already works to some degree.
|
| I've now had a working search engine for almost 3 years.
|
| My last 3 jobs (9 years) haven't forced me to use
| Windows.
|
| I can chat and organize events without Facebook knowing.
|
| And it is not like the quality has gone down either. My
| choices have mostly given me better experiences in a
| number of ways.
|
| Edit:
|
| If more people start
|
| - advocating for better hardware and software,
|
| - canceling subscriptions and memberships when it becomes
| clear they are reducing value or increasing price,
|
| - building skills both to get independent from their
| current cloud (so you can move around or at least having
| a credibile possibility to do so)
|
| - and for individuals to get better jobs
|
| then I think things will change.
|
| For inspiration: at least here in Norway, with several
| gym memberships, if you cancel they will quickly approach
| you with good offers, and they can get really good: I got
| several months free, a friend got offered free months and
| a sizable gift card.
|
| Bonus: if more people join in this will get picked up by
| Wall Street and they will begin punishing this nonsense
| too ;-)
| namtab00 wrote:
| I envy your bubble.
| eitland wrote:
| I admit it is a nice one.
|
| My base salary has doubled and I enjoy my work a lot more
| now that I don't have to accept all kinds of MS
| shenanigans to play a part in how I work.
|
| Having a working search engine shouldn't be
| underestimated either: living from 2012 to 2022 knowing
| that search used to be a solved problem but wasn't
| anymore was really annoying.
| drdaeman wrote:
| Sorry, what do you mean when you say "punish"? How?
| dreamcompiler wrote:
| Indirectly by pushing down the stock price. CEO
| compensation is usually tied to the stock price through
| options, bonuses, etc.
|
| Directly through activist investors and shareholder
| groups (which nowadays usually are institutional
| investors) who vote to change company policies, fire the
| CEO, or in some cases fire the whole board.
| growse wrote:
| Private companies' interest in what Wall Street thinks is
| generally not very large.
| dreamcompiler wrote:
| Which is why GP stated "if they are public." That was the
| context of my comment.
| api wrote:
| > Yeah, the ad supported model has its problems, but it
| also makes the internet way more accessible. If we think
| about it, companies and people with more money are
| basically subsidizing these services for everyone else.
| They're the ones seeing the ads that keeps the lights on
| for users who can't afford to pay.
|
| The problem (other than the obvious privacy and noise
| issues) is that it's not a neutral subsidy. It introduces
| a lot of biases.
|
| Since advertisers are subsidizing the platform, they tilt
| the content toward things they want and away from
| messages they don't. Messages that criticize advertisers
| products (which include things like governments and
| political ideologies since they are advertisers) are de-
| emphasized and marginalized.
|
| Since impressions / clicks / eyeballs are the goal, an
| inherent bias is introduced toward emotionally triggering
| and/or addictive or hypnotic content. The reason social
| media for example is so divisive and negative is that
| this keeps people engaged by triggering simple powerful
| emotions.
| ulrikrasmussen wrote:
| We can still provide subsidized services and media to
| people with low income via other means which don't have
| the negative consequences of ad-tech. This is why we have
| libraries rather than free textbooks with engagement
| optimizing short comics and full-page advertisements.
| kevin_thibedeau wrote:
| The free competitors have raced to the bottom and don't
| provide a useful service any more.
| brookst wrote:
| Disagree. You don't lose, you're just smaller, better,
| and still very profitable.
|
| HBO used this model way back when. It's been a lasting
| business.
| freeAgent wrote:
| But then you can't blitzscale and exit after a few years
| as a centimillionaire!
| codingjourney wrote:
| I think you meant hectomillionaire, actually.
| freeAgent wrote:
| They mean the same thing in this usage.
| stavros wrote:
| How? A centimillionaire has $10k, a hectomillionaire has
| $100m.
| freeAgent wrote:
| LMGTFY: https://www.merriam-
| webster.com/dictionary/centimillionaire
| stavros wrote:
| That's not SI, therefore inadmissible.
| freeAgent wrote:
| Look, I don't make the rules. The English language is
| what it is.
| Twisell wrote:
| However, most of current fremium games are precisely based
| on this model (Fortnite, LoL, TF2, most of mobile games,
| etc...)
|
| The service is subsidized by "whale players" that regularly
| spend a lot of cash, but they are a lot of freeloaders (to
| entertain the whales and to build brand popularity).
| sxg wrote:
| I think this supports my point and the OP's example.
| Video game makers have figured out how to segment their
| customers into two groups (former and latter in the OP's
| example), and this only works because they've made their
| games extremely cheap or free.
|
| A cheap/free game supercharges network effects to amass
| players, each of which incrementally adds value to every
| other player. Most players will never directly pay enough
| to offset their own cost to the game maker. However, they
| will create a real community that draws in a small number
| of whale players who will directly pay for themselves and
| indirectly pay for all of the free players.
|
| Not so different from the two-sided markets on Facebook
| and Instagram.
| basch wrote:
| They would be a good steward of pinboard.in if it were for
| sale / recovery.
| brookst wrote:
| Direct monetization FTW. Charge people for value. Cultivate
| audiences willing to pay for value.
|
| Incentives aligned. Happy customers. Good businesses. Maybe
| you only get 60% gross margins, or, gasp, 40% gross margins.
| But so much less toxic.
| ulrikrasmussen wrote:
| Kagi user here. I agree!
|
| The main driver of hostility to users is due to ad-based
| business models. I think we would see a much more healthy
| internet if we had regulation which prohibited companies from
| choosing ads based on any information associated with the
| user that the ad is shown to. That is, any data collected in
| the past and any data associated with the session and request
| must not be taken into account when choosing the ad; two
| requests by different users in different locations should
| have the exact same ad probability distributions.
|
| I know we are never getting this because it would kill or
| severely harm the business models of some of the most
| profitable businesses in the world.
| numbsafari wrote:
| > 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.
|
| I would generally agree that that's the "default".
|
| However, there are cases where two sides of a market need an
| intermediary with which they can both independently transact,
| and a net benefit of that interaction is felt on both sides.
| The key is to construct the solution such that the
| intermediary depends on the goodwill of both sides of the
| market.
|
| I think Kagi is somewhat flipping the script. By "taking"
| data from publishers for free, they are then selling it to
| readers at a cost. However, there is a trade off. Kagi needs
| to make sure publishers continue to make their content
| available so that it can be searchable, or used in their
| Assistant product. In order to do that, they need to do the
| opposite of what Google is doing by trying to sequester
| traffic on Google.com: Kagi's best interest is to make sure
| that they provide good value to both sides.
|
| Indeed, using the Assistant product, the way it is
| structured, I very often find myself clicking through to the
| referenced original sources and not just consuming the
| summarized content.
|
| How this evolves over time, from a product design standpoint,
| will be interesting to watch.
| 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.
| ignoramous wrote:
| Tor has nothing to do with what GP said, which is, the
| flexibility offered by Kagi (to turn privacy pass on / off)
| is actually self defeating. If (even technical) users walk
| away thinking "why don't other platforms offer this", then
| that tells you all about the foot-gun that this flexibility
| brings.
|
| (Privacy Pass in fact doesn't make sense outside of an
| anonymizing transport, which makes the current announcement
| an exercise in marketing, _at best_ )
| paradox460 wrote:
| With kagi you'll get used to them making the correct choice.
| It's been stunning how they haven't really had any missteps
|
| I wish my kagi t-shit could say the same. Bottom hem unraveled
| on the second wash, and so it's been consigned to the sleep and
| yard work shirts. They issued me a coupon for a free shirt as
| replacement, but it's yet to ship
| cootsnuck wrote:
| I think I can finally buy into the Kagi hype now that I've
| found a sincere negative opinion.
| Sakos wrote:
| Kagi has its share of issues. The whole shirt thing was a
| debacle and I wish they'd just sunk the absurd amount of
| money back into the product. I just often find the
| criticism from non-users to be disingenuous.
| nicholasjarnold wrote:
| Just adding a $0.02 here - I placed an order for the
| free/gifted-with-subscription Kagi shirt and received it
| about a month later. Worn twice so far. Largest
| complaint? It shrank quite a bit in the dryer on medium
| heat.
|
| The search engine works great for me. I will almost
| certainly renew my subscription when it's time to. Glad
| to see them continually delivering user-benefiting
| features.
| freediver wrote:
| > (I don't use Orion, as there's no GNU/Linux version.)
|
| We commenced work on Orion for Linux yesterday.
| WD-42 wrote:
| Amazing!!!
| joshuaturner wrote:
| I remember the announcement for Orion but I haven't followed
| closely at all - any support for container proxies like in
| Firefox? Can't lose that feature
| maples37 wrote:
| I'd agree, at least partially in my case: Container Tabs is
| a killer feature for me with Firefox. Especially compared
| with the Temporary Containers extension on automatic mode,
| basically each new tab is like a fresh browser profile with
| zero cookies/local-storage.
|
| I might consider demoing Orion on Linux even if it doesn't
| have container tabs, but at this time I wouldn't consider a
| full switch without that feature.
| prophesi wrote:
| If you mean Firefox containers[0], the closest you'll get
| is Profiles[1] since Orion is based on WebKit. Its location
| in settings is different from the Safari docs, and that's
| the only difference in Orion's implementation as far as I
| can tell. You can't open a tab in a certain profile,
| instead each profile opens in its own window, which is a
| lot more cumbersome than Firefox containers.
|
| Arc, another Webkit-based browser, has an interesting
| implementation combining Profiles and Arc Spaces[2].
| Instead of switching between windows, you switch between
| "Spaces" in the sidebar that are linked to a profile.
|
| [0] https://addons.mozilla.org/firefox/addon/multi-account-
| conta...
|
| [1] https://support.apple.com/en-us/105100
|
| [2] https://www.youtube.com/watch?v=A5BzkowY_B8
| hurutparittya wrote:
| Any target date for open-sourcing it? :^)
| 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.
| ThePowerOfFuet wrote:
| >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 wrote:
| 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 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 of what would otherwise be
| private and secure systems (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.
| sedatk wrote:
| The difference is cost. Pervasive and unhindered
| surveillance is way cheaper than coordinating an individual
| to be targeted through court orders and all the bureaucracy
| and potential legal battles that come with it. That's why
| EU/UK is trying to coerce Apple to disable end to end
| encryption[1]. If it hadn't made any difference, we
| wouldn't be seeing any complaints from governments.
|
| [1] https://techinformed.com/uk-government-orders-apple-to-
| hand-...
| 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 :)
| Timshel wrote:
| While it's relatively trivial to run something like:
| fetch(new Request("https://kagi.com/search?q=test", {
| method: "GET", headers: new Headers({ "X-Kagi-
| PrivacyPass-Client": true })})).then((r) =>
| console.log(r.headers.get("www-authenticate")))
|
| A simple response in the body to something like
| <https://kagi.com/privacypass> would be easier to check.
|
| And you answered someone else:
|
| > It is also something anyone else could do to keep us
| honest :)
|
| While true I believe for such a feature making it as easy
| as possible for your users to check independently is just
| better.
| hedora wrote:
| Could you jam the bits into dummy ssl cert signing
| requests, then stick the result in the certificate
| transparency log?
| 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!
| kayson wrote:
| I really love this style of explanation. There was another
| one I saw recently (OIDC, I think?) that I wish I'd
| bookmarked but I forgot to
| 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.
| faeranne wrote:
| It appears that the public side of X is sent as the first
| part of the handshake, without any login info yet, and can
| be verified as part of B, thus a varying X would be easy to
| detect... I think.
| 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.
| g-b-r wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| Why would you not want to login to a personalized service
| (unless you really need to be anonymous for some reason)?
| faeranne wrote:
| Assuming the cryptography does what they say it does (am not a
| cryptography expert, so I can't verify that part), this would
| completely disjoin a search request from any account info. The
| account generates several "search tokens", and for each search
| request, one of those tokens is spent. The tokens are generated
| on-device, and until spent, never leave the device, so in
| theory there's no way for Kagi to know which account generated
| the token just from the token alone. This doesn't fix
| fingerprinting or IP associations (though the plugin for
| Firefox and Chrome supposedly takes efforts to try and limit
| fingerprinting too), but this isn't any better/worse than
| simply using Google or Duckduckgo, and functions on Tor if you
| really want some privacy.
|
| Again, not sure on _how_ the tokens are proven legit without
| ever sharing them, but there 's probably some ~~zero-knowledge
| proof~~ stuff going on that covers that.
|
| Edit: Not zero-knowledge proof. Seems to be Blind Signature?
| sedatk wrote:
| > This doesn't fix fingerprinting or IP associations
|
| It solves the problem of using a paid service without
| compromising customer's privacy which is a breakthrough. The
| rest are different problems and they are universal issues
| with various existing solutions as you already pointed out.
| sanbor wrote:
| Most of the time I have ProtonVPN in my phone and computer,
| which solves the IP association problem for me
| 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?
| 1propionyl wrote:
| Sure, I'll try to catch it in action and send you something
| useful.
| themadturk wrote:
| 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 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
| jeroenhd wrote:
| 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 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.
| scroot wrote:
| ditto
| 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
| perdomon wrote:
| 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.
| 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.
| perdomon wrote:
| Very interesting experience. Thanks for sharing. I'm a sucker
| for good UX/UI, and it sounds like the product is
| legitimately useful long-term. I wonder how well it
| integrates into Firefox/Chrome, since I see extensions for
| both browsers. I'll check it out!
| 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.
| hedora wrote:
| I recently ran a search on Google. There were zero results on
| the first page. It was 100% ads. (15" MacBook).
|
| I tried a different search on iPhone to be sure. The first
| result was on the 3rd screen.
|
| When did they start doing that? How do people use that crap?
| Mashimo wrote:
| > 15" MacBook
|
| I just tried it on Duck Duck Go and the first result was
| from Apple.com
|
| On google I get 3 rows of "Products" but the first real
| result is also apple.com
| perdomon wrote:
| Is that his device or his search term? Either way, my
| view of the internet is probably different than the
| average with pihole + ublock. Three pages of ads is kind
| of unbelievable.
| 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
| cube2222 wrote:
| Other than the things others mentioned, with the ultimate plan
| you can use Claude with Kagi web-search, which is not something
| that the Claude web app supports, I believe.
| perdomon wrote:
| That's interesting -- Claude WITH web search. Like Claude
| makes suggestions about search terms? Or maybe helps to
| navigate the results? I'm struggling to picture how google
| search is a 2-"person" job
| jabroni_salad wrote:
| Here is a case for 'not google':
|
| https://i.imgur.com/PQNm1Yc.png
|
| I want a search engine to return useful results. Right now,
| google has been captured by revenue generating results. It
| wouldn't be so bad if useful results were making money, but
| that doesn't seem to be the case.
| perdomon wrote:
| Yeah, those results are ass. Do you happen to have the Kagi
| equivalent of the search? I'm curious to see how they
| compare.
| 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.
| beeflet wrote:
| 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 wrote:
| 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
| 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."
| ripped_britches wrote:
| > They ask God (used here to represent math itself)
|
| Thank you so much, I am 100% stealing this
| AutistiCoder wrote:
| 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 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. 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 wrote:
| That's really smart. You should suggest it to Kagi directly:
| https://kagifeedback.org/
| noident wrote:
| 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-...
|
| [1] https://gitlab.torproject.org/tpo/applications/tor-
| browser/-...
| JumpCrisscross wrote:
| > _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 wrote:
| It must be a small fraction since they released their Tor
| onion service 3 hours ago in the original linked article :)
| JumpCrisscross wrote:
| I'm not diminishing Kagi or Tor, I'm asking for validation
| for the former expanding resources.
| noident wrote:
| 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.
| abound wrote:
| [I work at Kagi]
|
| The extension is open-source [1], including the Rust code
| that produces the WASM [2]. You should be able to produce a
| bit-compatible binary from these repos, and if not, please
| file a bug!
|
| [1] https://github.com/kagisearch/privacypass-extension
|
| [2] https://github.com/kagisearch/privacypass-lib/
| noident wrote:
| Ah, nice, Firefox extension pages don't link to the source
| code and I missed it. Looking forward to digging into this
| more. Thanks!
| Thorrez wrote:
| >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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I hope Protonmail picks up on privacy pass. It would be nice to
| fund anonymous Protonmail accounts with an anonymous "benefactor"
| account.
| mirkodrummer wrote:
| 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 wrote:
| 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 wrote:
| This is really cool. How does the cryptography work?
|
| EDIT: Seems like it works via
| https://en.wikipedia.org/wiki/Blind_signature
| tansan78 wrote:
| 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).
|
| 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 wrote:
| 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 [2]
| 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 wrote:
| 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 wrote:
| hekdaimon Al
| aspensmonster wrote:
| Seeing as I'm not getting any traction in the fediverse
| (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 SS 4 of [2].
|
| From [2] RFC 9576 SS 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 SS 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 wrote:
| 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 SS 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 SS 7.1. "Token
| Caching" and RFC 9577 SS 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 SS 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.
| aspensmonster wrote:
| >3. CLIENT uses it's identity to request token from
| ISSUER/ATTESTER
|
| The ISSUER and ATTESTER are different roles. As previously
| quoted, "Clients explicitly trust Attesters to perform
| attestation correctly and in a way that does not violate
| their privacy." The RFC is explicit that, when all of the
| roles are held by the same entity, the attestation should not
| rely on unique identifiers. But that's exactly what a session
| cookie is.
|
| >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,
| and therefore it can use a timing attack to correlate the
| request to the ORIGIN (1.) with the request to the
| ISSUER/ATTESTER (3.).
|
| No timing or spacing attack is needed here. If I have to
| provide Kagi with a valid session cookie in order to get the
| tokens, then they already have a unique identifier for me.
| There is no guarantee that Kagi is not keeping a 1-to-1
| mapping of session cookies to ISSUER keypairs, or that Kagi
| could not, if compelled, establish distinct ISSUER keypairs
| for specific session cookies.
| nulld3v wrote:
| > The RFC is explicit that, when all of the roles are held
| by the same entity, the attestation should not rely on
| unique identifiers. But that's exactly what a session
| cookie is.
|
| Very true, but again, the RFC describes a completely
| different threat model with much stronger guarantees. The
| Kagi threat model:
|
| - Does not provide Issuer-Client unlinkability
|
| - Does not provide Attester-Origin unlinkability
|
| In particular, the model does not assume a malicious Issuer
| and requires the Client have some level of trust in the
| Issuer. The Client trusts the Issuer with their private
| billing information but does not trust the Issuer with
| their search activity.
|
| The RFC explicitly guarantees the Issuer cannot obtain any
| of the Client's private information.
|
| That said, I will point out that this Issuer-Client
| unlinkability issue can be solved by introducing a 3rd-
| party service or when Kagi starts accepting Monero
| payments.
|
| > There is no guarantee that Kagi is not keeping a 1-to-1
| mapping of session cookies to ISSUER keypairs, or that Kagi
| could not, if compelled, establish distinct ISSUER keypairs
| for specific session cookies.
|
| Also completely valid, but also not something Kagi claims
| to guarantee. They believe the extension should be
| responsible for guarding attainer issuance partitioning. I
| don't think it's implemented currently but it shouldn't be
| too hard, especially since they currently use only 1
| keypair.
| aspensmonster wrote:
| >Very true, but again, the RFC describes a completely
| different threat model with much stronger guarantees. The
| Kagi threat model: > >- Does not provide Issuer-Client
| unlinkability > >- Does not provide Attester-Origin
| unlinkability
|
| If the Client, Attester, and Origin are all a single
| party (Kagi), then it follows from that threat model that
| Kagi does not provide Kagi-Client unlinkability, no?
|
| Further, this is not what Kagi has advertised in the blog
| post:
|
| >What guarantees does Privacy Pass offer? > >As used by
| Kagi, Privacy Pass tokens offer various security
| properties (SS 3.3, of [2]).
|
| Kagi are explicitly stating that they provide the
| guarantees of SS 3.3. They even use more plain language:
|
| >Generation-redemption unlinkability: Kagi cannot link
| the tokens presented during token redemption (i.e. during
| search) with any specific token generation phase. *This
| means that Kagi will not be able to tell who it is
| serving search results to*, only that it is someone who
| presented a valid Privacy Pass token. > >Redemption-
| redemption unlinkability: Kagi cannot link the tokens
| presented during two different token redemptions. This
| means that *Kagi will not be able to tell from tokens
| alone whether two searches are being performed by the
| same user*.
|
| As it stands, Kagi cannot meaningfully guarantee those
| things, because the starting point is the client
| providing a unique identifier to Kagi.
|
| >That said, I will point out that this Issuer-Client
| unlinkability issue can be solved by introducing a 3rd-
| party service or when Kagi starts accepting Monero
| payments.
|
| Sure, but at that point, there is no need for any of the
| Privacy Pass infrastructure in the first place.
|
| >Also completely valid, but also not something Kagi
| claims to guarantee.
|
| I disagree. Their marketing here is "we can't link your
| searches to your identity, _because cryptography_. "
|
| >They believe the extension should be responsible for
| guarding attainer issuance partitioning. I don't think
| it's implemented currently but it shouldn't be too hard,
| especially since they currently use only 1 keypair.
|
| If Kagi is going to insist on being the attester and on
| requiring uniquely identifiable information as the basis
| for issuing tokens, then yes, the only way to even _try_
| to confirm that they 're not acting maliciously is to
| keep track not only of distinct keypairs, but also of
| public and private metadata blocks within the tokens, and
| to share all of that data (in a trustworthy manner, of
| course) with other confirmed Kagi users. And if a user
| doesn't understand all of the nuances that would entail,
| or all of the nuances just discussed here, and instead
| just trusts the Kagi-written client implicitly? Then it's
| all just privacy theater.
| nulld3v wrote:
| > If the Client, Attester, and Origin are all a single
| party (Kagi), then it follows from that threat model that
| Kagi does not provide Kagi-Client unlinkability, no?
|
| Kagi does not provide Kagi-Client unlinkability as the
| Client's payment information allows Kagi to trivially
| determine the identity of the Client. Kagi does provide
| Search-Client unlinkability (what the RFC calls Origin-
| Client unlinkability). More formally: If we assume Kagi
| cannot derive any identifying information from the
| privacy token (which I understand you dispute), then
| given any two incoming search requests, Kagi would not be
| able to determine whether those two requests came from
| the same Client or two different Clients.
|
| > Kagi are explicitly stating that they provide the
| guarantees of SS 3.3. They even use more plain language:
|
| Not 100% sure I am understanding you correctly but if you
| are claiming that Kagi promises all the unlinkability
| properties in SS 3.3, I would say that would be unfair,
| since they explicitly deny this in the FAQ at the bottom
| of the post.
|
| I think they are citing that section as they reference
| several definitions from it in the text that follows.
|
| > >Generation-redemption unlinkability: Kagi cannot link
| the tokens presented during token redemption (i.e. during
| search) with any specific token generation phase. *This
| means that Kagi will not be able to tell who it is
| serving search results to*, only that it is someone who
| presented a valid Privacy Pass token. > >Redemption-
| redemption unlinkability: Kagi cannot link the tokens
| presented during two different token redemptions. This
| means that *Kagi will not be able to tell from tokens
| alone whether two searches are being performed by the
| same user*. > > As it stands, Kagi cannot meaningfully
| guarantee those things, because the starting point is the
| client providing a unique identifier to Kagi.
|
| These specific unlinkability properties are satisfied
| given that the earlier assumption about the token not
| providing identifiable information is true.
|
| > Sure, but at that point, there is no need for any of
| the Privacy Pass infrastructure in the first place.
|
| Kagi Privacy Pass in combination with a 3rd party can
| acheive a level of privacy that cannot be matched by
| architectures that don't involve the Privacy Pass or some
| other exotic cryptography.
|
| I claim that a 3rd-party service + Kagi Privacy Pass
| meets all unlinkability properties in the RFC (except
| Attester-Origin for obvious reasons). Additionally, it
| guarantees confidentiality of the search request and
| response from malicious middleboxes, given the assumption
| about the token is true and that the user has access to a
| trusted proxy.
|
| > I disagree. Their marketing here is "we can't link your
| searches to your identity, _because cryptography_. "
|
| Disagreement acknowledged. And yes, that quote is a
| fairly accurate summary of the marketing!
|
| > If Kagi is going to insist on being the attester and on
| requiring uniquely identifiable information as the basis
| for issuing tokens, then yes, the only way to even _try_
| to confirm that they 're not acting maliciously is to
| keep track not only of distinct keypairs, but also of
| public and private metadata blocks within the tokens, and
| to share all of that data (in a trustworthy manner, of
| course) with other confirmed Kagi users. And if a user
| doesn't understand all of the nuances that would entail,
| or all of the nuances just discussed here, and instead
| just trusts the Kagi-written client implicitly? Then it's
| all just privacy theater.
|
| Yeah, I'm glad you are willing to say it at least, a lot
| of stuff these days is security theatre, people just
| kinda stick their heads in the sand I guess? I'm still
| hoping that people will realize that SSL has been long in
| need of a successor, and frankly BGP needs a complete
| rework too. It's also surprising to me that people are
| still willing to use Linux distros, although
| realistically modern computing as a whole is rotten at
| it's core. At least PGP is still alive, but it has its
| problems too...
| jorams wrote:
| From [2] RFC 9576 SS 4.1 "Shared Origin, Attester, Issuer",
| right before the sentence you quoted:
|
| > In this model, the Attester, Issuer, and Origin share the
| attestation, issuance, and redemption contexts.
|
| I haven't read the RFC in detail, but I believe this is where
| the nuance is: When you enable the privacy pass setting in the
| extension/browser the redemption context is changed relative to
| the attestation context by removing the session cookie, to just
| the information sent by the browser for someone who is not
| logged in. What remains is your IP address and browser
| fingerprinting, which can be countered by using Tor.
| pzo wrote:
| 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 wrote:
| > There's a monthly limit of 2,000 tokens per account to
| prevent abuse
|
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| Thanks for the clarification.
| eviks wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| and they use all of their margin to build a browser because
| why not
| xigoi wrote:
| 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 wrote:
| 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 wrote:
| The idea is that the tokens aren't linked to any account.
| They're anonymous.
| ghayes wrote:
| 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/
| Eji1700 wrote:
| 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 wrote:
| 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.
| readyplayeremma wrote:
| The server does not generate the tokens, the client generates
| the tokens. The server is supposed to be able to verify that
| they were generated by a client who was granted the authority
| to generate them, but not which client did so. At least, not
| without side-channel information.
|
| > The main building block of our construction is a verifiable
| oblivious pseudorandom function (VOPRF)
|
| I am not sure how well tested that primitive is, but it
| definitely appears to be more than the server handing clients
| tokens and then pretending not to know who it gave them to.
|
| The referenced paper:
| https://petsymposium.org/popets/2018/popets-2018-0026.pdf
| dave1010uk wrote:
| This is my understanding of how it works, without knowing the
| actual maths behind the functions: # client
| r = random_blinding_factor() x =
| client_secret_input() x_blinded = blind(x, r)
| # Server y_blinded = OPRF(k, x_blinded)
| # Client y = unblind(y_blinded, r)
|
| So you end up with y = OPRF(k, x). But the server never saw x
| and the client never saw k.
|
| This feels like the same kind of unintuitive cryptography as
| homomorphic encryption.
| rajnathani wrote:
| What I find confusing is: Given that the server is
| essentially authorizing each subsequent client request (eg:
| For Kagi: search queries after a Kagi user has already been
| authenticated) in a way whereby the client is anonymous, what
| is the difference between Privacy Pass and simply providing a
| common authorization token to each user (and thus skipping
| all this cryptography)?
|
| Update: On some thought, for the approach of the server
| providing a common authorization token that there is no
| guarantee to the client that the server is actually providing
| a common token and thus not just simply providing a unique
| identifier to each user. Thus, the Privacy Pass's
| cryptography ensures that the client knows that it is still
| anonymous. Update 2: But, what guarantee exists that the
| server doesn't generate a unique public key (i.e. public-
| private key pair) for each user and thus defeat anonymity
| this way? Update 3: They use zero-knowledge proofs to prove
| that all tokens are signed by the same private-key, from
| their paper: "The work of Jarecki et al. [18] uses a non-
| interactive zero-knowledge (NIZK) proof of discrete log
| equality (DLEQ) to provide verification of the OPRF result to
| the user. Their construction is hence a 'verifiable' OPRF or
| VOPRF and is proven secure in the random-oracle model. We
| adapt their construction slightly to use a 'batch' DLEQ proof
| allowing for much more efficient verification; in short this
| allows a user to verify a single NIZK proof that states that
| all of their tokens are signed by the same private key. This
| prevents the edge from using different key pairs for
| different users in an attempt to launch a deanonymization
| attack; we give more details in Section 3.2.".
| potamic wrote:
| Using a client provided by Kagi can be a side-channel then?
| Should we rather be using an independent, standard client?
| adamtaylor_13 wrote:
| Yeah I think you don't understand the premise behind privacy
| pass tokens.
|
| The whole idea is that the server does not which WHICH client a
| token belongs to. It doesn't generate the tokens.
| eudhxhdhsb32 wrote:
| 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 wrote:
| I'm willing to bet they have not gotten this tested by security
| professionals
| nvarsj wrote:
| 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 wrote:
| 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 wrote:
| Anecdotally I've had zero issues with the Safari extension.
| Amekedl wrote:
| 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?
| ThePowerOfFuet wrote:
| Alas, not compatible with Firefox for Android
| raphaelrobert wrote:
| 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-
| batc... [2] https://github.com/raphaelrobert/privacypass [3]
| https://github.com/kagisearch/privacypass-lib/blob/e4d6b354d...
| alphabetter wrote:
| 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 wrote:
| [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/LI
| CEN...
|
| [2] https://github.com/kagisearch/privacypass-
| lib/blob/e4d6b354d...
| SamuelAdams wrote:
| So if they add "credit to raphaelrobert", or a copy of your
| license to their code somewhere, Kagi will be compliant?
|
| I've never had any of my open source software used, and I
| typically license it with MIT, so I'm curious how other groups
| and organizations actually comply with the license.
| literallyroy wrote:
| They are compliant, the code being used is under the MIT
| license.
| moksha256 wrote:
| Yeah I'm as big of a FOSS fan as the next guy on here but
| you really can't complain about how someone uses your code
| if you used the MIT License...one of the most permissive
| licenses in existence.
|
| If someone wants attribution or something then they should
| use a license that requires that thing.
| brookst wrote:
| There's a gap between what is _legally required_ and what
| is _common courtesy_.
|
| I'm under no obligation to thank someone for holding a
| door for me; if I fail to do so it does not mean that
| person should switch to a different door-holding license
| in the future. It just means I'm a bit of a jerk.
|
| When lifting an entire (permissive licensed)
| implementation it's good form to say thanks.
| moksha256 wrote:
| You're not wrong. But the door-holding example isn't
| really a good one because there's no such thing as a
| license for door-holding.
|
| For FOSS, on the other hand, licenses are a well-
| established thing. And developers have free reign to pick
| a license for their code and they very commonly pick
| MIT...totally on their own volition. Which strips them of
| all privileges. It's like writing a book and explicitly
| setting it into the public domain. If that's what you
| want to do, that's great, but very commonly I don't think
| it's what developers actually want to do.
|
| In the world of copyright, the long-standing legal
| default is for the author to own their work for a certain
| amount of time, whether or not the copyright is
| explicitly claimed. Because making public domain the
| legal default would be utterly insane.
|
| I guess what I'm saying here is my beef isn't with
| entities that choose to be jerks--that's annoying and
| always gonna happen to some extent--it's more with the
| all-too-common decision to use the MIT License. And when
| I see people complain about it...I understand the
| sentiment but I also can't help but think that the folks
| complaining had it coming and it was totally avoidable.
| brookst wrote:
| I knew door holding was weak, but I think the principle
| holds. To me, it is reasonable to release under MIT with
| expectation of helping lots of people, and also to expect
| (not require) some credit if a notable company adopts kit
| and kaboodle.
| azinman2 wrote:
| Door holding falls under a social contract.
| brookst wrote:
| So does saying thanks. That was my point :)
| _Algernon_ wrote:
| You can if they don't include the copyright header: "The
| above copyright notice and this permission notice shall
| be included in all copies or substantial portions of the
| Software."
|
| Which, as far as I can tell they haven't done. Their MIT
| licence claims their own copyright. No reference to the
| library used in readme.
|
| https://github.com/kagisearch/privacypass-
| lib/blob/main/LICE...
|
| https://github.com/kagisearch/privacypass-
| lib/blob/main/READ...
|
| Usually when using apps that use MIT licensed libs they
| also implement a notice in a user-facing way. Google maps
| for instance has a (albeit hidden) section in their
| settings menu referencing at least one MIT licensed
| library.
| ignoramous wrote:
| Kagi isn't MIT compliant _if_ they lifted code and removed
| the copyright of the original author (as claimed by OP)
| only to replace it with theirs.
|
| https://github.com/kagisearch/privacypass-
| lib/blob/83c9be8cb...
| matthews2 wrote:
| Kagi's repository doesn't contain any of raphaelrobert's
| code directly. It's used as a library:
| https://github.com/kagisearch/privacypass-
| lib/blob/main/src/...
| _Algernon_ wrote:
| MIT licence explicitly requires maintaining the original
| copyright header, and licence.
|
| >Copyright (c) <year> <copyright holders>
|
| >Permission is hereby granted, free of charge, to any
| person obtaining a copy of this software and associated
| documentation files (the "Software"), to deal in the
| Software without restriction, including without limitation
| the rights to use, copy, modify, merge, publish,
| distribute, sublicense, and/or sell copies of the Software,
| and to permit persons to whom the Software is furnished to
| do so, subject to the following conditions:
|
| >*The above copyright notice and this permission notice
| shall be included in all copies or substantial portions of
| the Software.*
|
| >[...]
| graypegg wrote:
| Captured 14 Feb 2025 ~12:15pm EST from README header
|
| > This repository contains the source code of the core library
| implementing the Privacy Pass API used by Kagi.
|
| Yeah... that doesn't feel great. Though I do think the folks at
| Kagi would be open to more accurately reframing that as "core
| library implementing a Crystal Lang wrapper for
| raphaelrobert/privacypass". It's likely unintentional, they
| were probably just focusing on getting it working and didn't
| get someone to reread this stuff.
| devwastaken wrote:
| 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 wrote:
| 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 wrote:
| > 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
| throwaway290 wrote:
| This is a nice move. Now they just need to stop paying
| Yandex/Russia and I'd be back...
___________________________________________________________________
(page generated 2025-02-14 23:01 UTC)