Journal Kagi souhaite libérer les sources d'Orion pour Windows et Linux

Posté par  . Licence CC By‑SA.
Étiquettes :
14
5
oct.
2026

Kagi

Kagi est un moteur de recherche se voulant respectueux de la vie privée de ses utilisateurs : pas de publicité, pas de télémétrie, anonymisation des données. Il repose sur un modèle à abonnement, à partir de 5 $ HT par mois (10 $ HT pour les recherches illimitées)1.

Disclaimer : je suis utilisateur de Kagi depuis son lancement ; sans vouloir faire de prosélytisme, j'apprécie énormément ce moteur, qui m'a permis de quitter complètement Google. À titre personnel, le seul regret que j'aie à son sujet est qu'il ne soit pas européen.

Orion

Orion est un navigateur web développé par l'équipe de Kagi depuis 2020, originellement pour macOS & iOS. Pour citer la page officielle2 :

« The philosophy was clear from day one: build a browser funded by users, not their data. No telemetry, no tracking, no compromise on performance. A browser that respects both the elegance of Apple's ecosystem and the power users demand for customization. »

Que l'on pourrait traduire par :

« La philosophie était claire dès le premier jour : construire un navigateur financé par ses utilisateurs, et non par leurs données. Pas de télémétrie, pas de pistage, pas de compromis sur les performances. Un navigateur respectant l'élégance de l'écosystème Apple et offrant aux utilisateurs avancés les possibilités de personnalisation qu'ils désirent. »

Le financement du navigateur vient entièrement des utilisateurs, via les abonnements Kagi et Orion+ (un abonnement optionnel pour soutenir le développement d'Orion).

Orion repose sur WebKit. Il s'agit d'un choix assumé de l'équipe de développement, afin de bénéficier de l'intégration à l'écosystème Apple, mais également de se détacher de l'hégémonie de Chrome / Blink.

En mars 2025, Kagi annonce le développement d'une version Linux d'Orion3. Une première alpha paraît début 2026, réservée aux abonnés Orion+4, puis une version beta publique en août, distribuée via Flatpak5.

Le 2 octobre 2026, Kagi publie un billet de blog6 indiquant cesser le développement des versions Linux et Windows d'Orion, invoquant des moyens humains et financiers insuffisants pour assurer un développement pérenne sur trois systèmes différents. L'équipe de développement se recentre sur le cœur de cible originel, la plate-forme macOS / iOS.

La beta Linux continue de fonctionner, mais ne reçoit plus de mise à jour, correctifs de sécurité compris, depuis le 2 octobre.

Toutefois, plutôt que de condamner les versions Windows et Linux à disparaître dans les tréfonds obscurs de l'histoire des internets mondiaux, Kagi annonce dans le même billet vouloir en libérer les sources. Des fondations et organisations open source ont été contactées (sans plus de précision). Kagi précise bien qu'il ne restera pas mainteneur principal, et invite toute personne intéressée par la reprise du projet à se manifester.

L'équipe promet plus d'informations dans les 30 jours à venir.

Qu'en penser

Je ne suis pas utilisateur d'Orion. Je reste indécrottablement fidèle à Firefox, et je teste occasionnellement les avancées d'Epiphany. J'étais toutefois plutôt content de voir une société que j'apprécie développer un navigateur pour Linux qui ne soit pas un énième fork de Chrome, et ceci avec un réel souci d'intégration à la plate-forme, notamment par l'utilisation de libadwaita (bien que le respect des GNOME HIG soit… franchement douteux), ou encore l'utilisation de Flatpak comme mode de diffusion.

Et cela, même si le navigateur en question était closed-source. Kagi considérait manifestement Linux comme une cible légitime, au même titre que Windows. Et leur décision d'ouvrir les sources plutôt que d'abandonner complètement le projet me paraît honorable ; j'aimerais voir plus d'entreprises prendre ce chemin.

À noter que l'équipe parlait dès 2022 d'ouvrir le code source d'Orion, « when there is merit ». C'est ironiquement sur un échec que cette libération aura lieu7.

Bref, à suivre dans une trentaine de jours !

  1. https://help.kagi.com/kagi/plans/plan-types.html ↩

  2. https://orionbrowser.com/about ↩

  3. https://kagifeedback.org/d/6479-march-6th-2025-orion-embarks-on-linux-journey-kagi-doggo-art-celebration ↩

  4. https://help.kagi.com/orion/misc/linux-status.html ↩

  5. https://orionbrowser.com/platforms/linux/install ↩

  6. https://blog.kagi.com/update-orion-linux-windows ↩

  7. https://orionfeedback.org/d/3882-open-source-the-browser/2 ↩

  • # La forme du dépôt

    Posté par  . Évalué à -6 (+2/-5). Dernière modification le 06 octobre 2026 à 00:03.

    Une bêta Linux sans correctif depuis le 2 octobre, c’est un navigateur figé. Ouvrir les sources sans mainteneur ne relance pas les mises à jour tout seul.

    Orion est sur WebKit, avec libadwaita et un Flatpak. Si le code publié est une couche au-dessus de WebKitGTK, suivre les correctifs upstream reste imaginable. Si c’est un WebKit à eux, avec des patches qui divergent, la reprise coûte le même prix que ce qui les a fait arrêter. Le billet dit déjà qu’ils ne resteront pas mainteneurs. Dans les 30 jours, la forme du dépôt compte plus que l’annonce.

  • # Situation bizarre

    Posté par  (site web personnel) . Évalué à 7 (+5/-0). Dernière modification le 06 octobre 2026 à 15:56.

    Journal très intéressant, merci.

    Le 2 octobre 2026, Kagi publie un billet de blog6 indiquant cesser le développement des versions Linux et Windows d'Orion

    Donc il vont continuer à faire évoluer leur surcouche côté Apple, mais pas Linux/Windows où elle diffère même dans son "bas niveau" - dans la mesure où 1) ces 2 OS n'ont pas de WebView WebKit par défaut (RHEL n'en fournit même plus par défaut) 2) WebKitGTK diffère significativement du WebKit macOS.

    Dans la mesure où :
    - il sera impossible de se resynchroniser avec le "haut niveau" de la version Apple (restée closed source)
    - Orion est une marque déposée, et ils disent ne plus vouloir garantir ces versions.

    il est très improbable que ça soit contraint de se renommer d'"Orion Linux" en "Fork 43".

    Coincé entre des projets plus porteurs comme Firefox et Servo ; quel serait l'intérêt pour une commu selon toi ? Un navigateur WebKit viable sur un OS non-Apple, qui permette de faire progresser WebKitGTK ?

    • [^] # Re: Situation bizarre

      Posté par  . Évalué à 4 (+2/-0).

      Coincé entre des projets plus porteurs comme Firefox et Servo ; quel serait l'intérêt pour une commu selon toi ? Un navigateur WebKit viable sur un OS non-Apple, qui permette de faire progresser WebKitGTK ?

      Honnêtement, je ne suis pas certain qu'il y ait un grand intérêt communautaire. Le nombre d'utilisateur actuel doit être très restreint, et Epiphany est à mon sens bien plus utilisable.

      Je salue surtout le principe de libérer le code. Peut-être cela permettra-t-il d'améliorer d'autres projets : d'éventuels patches à remonter à WebKitGTK, le système de gestion des plugins, etc.

  • # LibAdwaita

    Posté par  (site web personnel) . Évalué à 4 (+3/-0).

    et ceci avec un réel souci d'intégration à la plate-forme, notamment par l'utilisation de libadwaita (bien que le respect des GNOME HIG soit… franchement douteux)

    Je ne suis pas d'accord. LibAdwaita ne favorise pas l'intégration à linux, seulement l'intégration à GNOME. Sur un système Linux utilisant autre chose que GNOME, l'appli est au contraire très mal intégrée.
    Par exemple, mon environnement de bureau propose une fonctionnalité "enrouler la fenêtre" qui ne fonctionne pas avec les apps LibAdwaita car elles utilisent des décorations côté client. De même les bordures de fenêtre ne sont pas les mêmes, les boutons des fenêtres aussi…

    Pour une bonne intégration à tous les bureaux linux, mieux vaut utiliser GTK4 sans CSD, les widgets LibAdwaita dans une fenêtre GTK sans CSD ou encore Qt.

    Sans compter les risques de sécurité liés au fait de devoir autoriser les décorations côté client (il est alors possible de créer, même sous Wayland, une fenêtre transparente qui laisse passer les clics et les frappe de clavier mais les enregistre = un keylogger alors que Wayland était censé empêcher ce type d'attaques).

    Ce comentaire est sous license CC0: faites en ce que vous voulez tant que vous ne m'atribuez pas de fausses paroles.

    • [^] # Re: LibAdwaita

      Posté par  . Évalué à 3 (+2/-1).

      Je ne suis pas d'accord. LibAdwaita ne favorise pas l'intégration à linux, seulement l'intégration à GNOME. Sur un système Linux utilisant autre chose que GNOME, l'appli est au contraire très mal intégrée.

      C'est vrai, et en tant que fervent utilisateur de GNOME, mon point de vue est biaisé.

      Après, c'est le corollaire de la fragmentation des bureaux : si l'on cherche à ce qu'une application soit « intégrée », au sens ergonomique, on ne vise pas « Linux », mais un environnement en particulier.

      Bon, pour ce qui concerne Orion, c'est plutôt loupé. On a l'impression qu'ils ont cherché à retranscrire le langage visuel de macOS avec libadwaita. Spoiler : ça ne marche pas vraiment.

    • [^] # Re: LibAdwaita

      Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 11 octobre 2026 à 01:01.

      il est alors possible de créer, même sous Wayland,une fenêtre transparente qui laisse passer les clics et les frappe de clavier mais les enregistre = un keylogger

      Vu l'architecture de Wayland, je ne comprend pas comment ça pourrait être possible. Tu aurais un exemple réel ou une source ? Est-ce plutôt un problème d'implémentation d'un compositeur ?

      Si j'ai bien suivi le compositeur Wayland se charge des entrées utilisateurs et il est garant de transmettre la bonne entrée à la bonne application. Une application ne peut pas elle même générer des entrées pour une autre application: le compositeur devrait isoler les fenêtres et refuser ce genre d'action.

      Il y a peut être une exception pour les outils d'assistance à la saisie.

      • [^] # Re: LibAdwaita

        Posté par  (site web personnel) . Évalué à 2 (+1/-0).

        Par exemple avec PyQt on peut faire ça:

        from PyQt6.QtCore import Qt, QObject, QEvent
from PyQt6.QtWidgets import QApplication, QMainWindow, QPlainTextEdit

from subprocess import run

class ClickFilter(QObject):
    def __init__(self, window):
        super().__init__(window)
        self.window = window

    def eventFilter(self, o, event):
        if event.type() == QEvent.Type.MouseButtonPress:
            self.window.hide()
            print(event.position())
            run(["wlrctl", "pointer", "click"])
            run(["wlrctl", "pointer", "click"])
            self.window.show()
            self.window.raise_()
            self.window.showMaximized()
            self.window.activateWindow()
            return True
        return False

class TextWindow(QMainWindow):
    def on_text_changed(self):
        if self.editor.toPlainText()!="":
            self.saved_text += self.editor.toPlainText()
            self.hide()
            run(["wlrctl", "pointer", "click"])
            run(["wlrctl", "keyboard", "type", self.editor.toPlainText()])
            self.show()
            self.raise_()
            self.showMaximized()
            self.activateWindow()
            self.editor.setPlainText("")
            print(self.saved_text)

    def __init__(self):
        super().__init__()

        self.saved_text = ""

        self.setWindowFlags(Qt.WindowType.Window | Qt.WindowType.FramelessWindowHint | Qt.WindowType.WindowStaysOnTopHint | Qt.WindowType.ToolTip)
        self.setAttribute(Qt.WidgetAttribute.WA_TranslucentBackground)
        self.setStyleSheet("background: transparent;")

        self.editor = QPlainTextEdit()
        self.editor.setStyleSheet("""
            * {
                background: rgba(0, 0, 0, 0);
                color: white;
                border: none;
            }
        """)
        self.setCentralWidget(self.editor)

        self.resize(1000, 1000)
        self.editor.textChanged.connect(self.on_text_changed)

        arrow = Qt.CursorShape.ArrowCursor
        self.setCursor(arrow)
        self.editor.setCursor(arrow)
        self.editor.viewport().setCursor(arrow)

        self.editor.setCursorWidth(0)


app = QApplication([])
window = TextWindow()
click = ClickFilter(window)
app.installEventFilter(click)
window.show()
window.showMaximized()
app.exec()

        C'est rudimentaire et ça marche mal puisque Qt n'est pas prévu pour ça et que j'utilise wlrctl au lieu d'utiliser directement les protocoles de Wayland (ce qui rend ce code limité aux compositeurs Wlroot mais il suffit d'adapter le code pour les autres compositeurs). Si on maîtrise l'usage direct des protocoles Wayland, il doit être possible de faire un truc plus discret et qui fonctionne.

        Ce comentaire est sous license CC0: faites en ce que vous voulez tant que vous ne m'atribuez pas de fausses paroles.

        • [^] # Re: LibAdwaita

          Posté par  . Évalué à 4 (+2/-0). Dernière modification le 12 octobre 2026 à 11:59.

          Cela semble relever plus du compositeur que des CSD.

          Le protocole security-context1 permet au compositeur de limiter les fonctionnalités exposées aux applications clientes, par exemple l'injection d'entrées, selon le contexte de sécurité leur ayant été attaché par le moteur de sandboxing. Après, cela suppose :

          • que le moteur de sandboxing tague le contexte de sécurité (seul Flatpak le fait à ma connaissance) ;
          • que le compositeur applique en conséquence les bonnes restrictions.

          1. https://wayland.app/protocols/security-context-v1 ↩

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.