Hacker News Reader

Comment by EbNar | Hacker News Reader

Just curious, but is this really a big deal? As a customer, you already trust Kagi enough to feed them your entire search history, so I guess you don't think they're bad actors. Thus, why you find problematic the (momentary?) "unopeness" of the browser? I'd gladly try it (I'm on Arch), even just out of curiosity (unlikely to make it my main, though).

Jeez, downvoted for asking about context? People, calm down.

View on HN

Requiring it to be open source is not just about trusting the publisher. There are a bunch of other possible reasons, including wanting to support open source as a counterbalance to proprietary software.

For me, it's a big deal (although not a dealbreaker) for that reason. If I have the option of two different pieces of software, one being open source and the other proprietary, I'll choose the open source one every time unless there's something really exceptional about the proprietary one. But that's very rare.

I was just trying to think of any proprietary software I use outside of work (where I don't have a choice) or games. There must be at least one, but I can't think of what it is.

Understood. Obviously, all things being equal, I prefer (F)OSS too. Anyway, I'll probably play a bit with Orion, if possible.

Side thought: nobody's ever asked us to open source Kagi Search. Curious why the expectation differs.

Kagi Search runs on your computers, Orion runs on ours.

Yup, I was about to comment on that as well, but didn't want my question to be interpreted as polemic.

Code you run on your machine outside of a browser sandbox vs content served by an HTTP endpoint to your machine.

I am pretty sure the expectation would be different if Kagi search could be self hosted. Linux people have come to expect open source for code they run on their own machines. Historically closed source Linux software has run into a lot of problems with dependency version mismatches as libraries get updated through the distributions package manager.

About half a year ago, I ran into an instance of a user who requested more openness[0] regarding the sources Kagi used - initially there was a list that was available, and then it was removed. I know it's not exactly the same, and it's been a long time since that request was made, but if you happen to read this, I second their request.

Personally, I think it would be incredible if you open sourced your search engine. But like someone else said more eloquently, software runs on our computers. And to me, open-source software is table stakes when there are viable alternatives.

https://kagifeedback.org/d/252-show-source-of-results/49

I'm not the one running Kagi on my computer, and the expectations of software ran over a network are and should be different from software I run on my computer

Because Kagi Search is a service I subscribe to. A browser is a program I install. That difference means everything.

But since I have your attention, I just want to add that I'm a huge fan of Kagi Search and it's well worth the money I spend for it. I love the work you guys are doing, and that love is the reason why I'm even thinking about using Orion. But they are two entirely different use cases.

Please do that too!

There aren’t great open-source search engines, so I’m moving from one proprietary option to the next. But there are great, open-source browsers already, and I refuse to go backwards.

If a good, open-source search engine were available, I would leave Kagi for it.

> As a customer, you already trust Kagi enough to feed them your entire search history, so I guess you don't think they're bad actors.

Do I? I'm not going to post sensitive information into a search engine no matter who runs it.

My search history ain't worth much. What the contents of e.g. my bank website are is.

Fine. Thank you for the clarification.

There’s still trusting Kagi that what’s in the binary was built from the open source code right?

I can build it myself and skip that step. Or, if the build process is reproducible, you can make trust less of an issue by having a small handful of independent people run their own builds and post their signatures. That way you need those people to all collude with Kagi to forge a bad build. This is how e.g. bitcoind binaries are handled.

With reproducible builds, and the way most people get packages, from their package manager: No.

> you already trust Kagi enough to feed them your entire search history

Not necessarily, Kagi provides a feature[1] that anonymizes all your searches. I set it up and haven't thought about it since.

1. https://help.kagi.com/kagi/privacy/privacy-pass.html

They give you a key and only if you have a higher tier account. The act of doing that requires that there is a step in the process where they know you’re requesting a key and who you are. They could bind them in the backend if they wanted, before giving it to you.

You’re still trusting them. Not to mention they could round them all up by IP or browser fingerprinting.

There is still some level of trust.

I happen to trust them enough for that; but it is still trust.

I am not an expert in the underlying cryptography, but the claim is indeed that the cryptographic approach makes it impossible for them to link the key to the queries in the backend.

Sure! But there is a stage where they generate those keys for you and give them to you. You need to be logged in to get that page. That is trust there.

No, issuer-client unlinkability is a feature of the design. The token is finalized by the client using private inputs so Kagi never actually sees the redeemable token (until it's redeemed).

https://blog.kagi.com/kagi-privacy-pass#token-generation:~:t....

https://www.rfc-editor.org/rfc/rfc9576.html

Using the example doc you’re citing from kagi.com - though not the RFC, I don’t have the time to dive into that one at the second, I see that a session token plus some other stuff is passed in and a token comes out.

Where does it show that on the Kagi backend they couldn’t, theoretically, save the session key before performing the token response?

Sure, they probably do. Doesn't matter because neither the session key nor the token response can be linked to the tokens.

If you're not going to make an effort to understand how it works, don't make assertions about how it works. Ask your favorite LLM about the RFC if you have any further questions.

> Just curious, but is this really a big deal?

Yes, it's a big deal. I've lived in the non-free software world before and struggled to get out. I'm not going back.

Google started as a company that seemed worthy of trust. The founders had ideals and followed them. Look what happened. Companies can turn evil surprisingly quickly. I'm also a Kagi customer, but I wouldn’t use a closed-source browser either.

Because free (as in the FSF definition) software should be a human right. We deserve to know how our tools work and be able to improve them and use them as we please. Free (as in freedom) software doesn't need to be monetarily free either. Make it so the purchase of orion comes with the binaries and a copy of the source code, or provide it on request. This has proved to be sustainable before, arguably the defacto standard for pixel art is (or was before a license change made it so you can't redistribute the source code) free software, despite costing money

Reply on news.ycombinator.com