Kagi releases alpha version of Orion for Linux

Post by freedomben » Fri, Jan 09, 2026, 9:11 PM UTC

freediver wrote: post #98

freedomben wrote: post #27

Earlier quoted context omitted.

I hope freediver will shed some light on the open source plans, because that's a deal breaker for me too. I'm a long time paying customer and huge proponent (even evangelist) of Kagi, but a closed source browser is just too many steps backwards for me no matter who makes it. I get (though wouldn't necessarily agree with) keeping it closed while it's still in the works, but would like to know if the plan is to open so…

Wish granted!

Post by JumpCrisscross » Fri, Jan 09, 2026, 10:05 PM UTC

drdaeman wrote: post #225

freediver wrote: post #92

Earlier quoted context omitted.

Kagi founder here. Orion isn't open source yet primarily because we're a 5-person team that spent 6+ years building this and created significant IP doing so, and we're not in a position to defend our work against a well-funded company using it as a base (we care very much about the business model of the browser surviving). Restrictive licenses help in theory but enforcing them against a company with a larger legal bu…

> managing an open source codebase of this size would add real strain to our small team Can you please elaborate what do you mean when you say this? This is something I do not understand. How licensing terms affect your codebase management beyond setting things up so the code is available to users? Publishing something under a FLOSS license doesn’t mean anything except that you grant end-users certain rights (the fou…

Post by imbnwa » Fri, Jan 09, 2026, 10:48 PM UTC

rixthefox wrote: post #123

Fiveplus wrote: post #83

Earlier quoted context omitted.

Hmm good point. The issue is also the distinction between widevine L1, i.e hardware-backed DRM and L3 (the software backed one). Correct me if I'm wrong but to stream 4K, studios require a hardware root of trust and a verified media path. They need a guarantee that the video frames are decrypted inside a trusted execution environment and sent directly to the display without the OS kernel or user space being able to r…

> Am I right in this assumption? Yes. I tried using Chrome on Linux just to watch movies that I purchased on Youtube at HD/4K and watched as the stream was limited to 240P. IMHO regardless of what Google says in their ToS they have already broken the trust agreement by not providing what I paid for. Regardless of what the studios want, all this does is push me back towards piracy because once again the industry fails…

Post by yunwal » Fri, Jan 09, 2026, 11:10 PM UTC

brockers wrote: post #171

There is some strange irony in this. Apple initially used the khtml code-base to build Safari but it quickly became impossible to back-port the changes from the Safari branch of khtml back into Konqueror. Now, 20 years later, someone has made an open source version of Safari.

Post by hamdingers » Fri, Jan 09, 2026, 11:22 PM UTC

t-writescode wrote: post #238

hamdingers wrote: post #236

Earlier quoted context omitted.

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 ?