Murena lance son système mobile open source et dégooglisé /e/OS 3.0
Une affaire à suivre
Fondée par Gaël Duval, la société française Murena vient de lancer la troisième version majeure de son système d’exploitation mobile /e/OS. Les nouveautés sont nombreuses et dans la lignée des améliorations dont nous avait parlé le fondateur en février : un renforcement des protections de la vie privée, des services et de la collaboration.
/e/OS est un système d’exploitation mobile basé sur la ROM LineageOS. Ce dernier, successeur de CyanogenMod, est un système de remplacement pour Android, dont il reprend la base via AOSP (Android Open Source Project). /e/OS se veut donc un système débarrassé de tout service Google et conçu pour préserver autant que possible la vie privée de ses utilisateurs. Il peut être installé sur des téléphones existants ou obtenu via un téléphone commercialisé par Murena, y compris des Pixel reconditionnés et le Fairphone 5.
Le système n’est pas une simple reprise de LineageOS. Sa « dégooglisation » est plus prononcée et il intègre par défaut microG, une alternative open source aux Google Play Services. De nombreux petits changements ont été opérés çà et là, par exemple pour la synchronisation de l’heure et les DNS, toujours dans l’optique de préserver la vie privée. /e/OS a également son propre launcher, baptisé Bliss, et est intégré avec un éventail de services, Murena Cloud.
La nouvelle mouture du système prend directement la suite des précédentes et vient appuyer sur les points forts déjà en place. Mais elle vient surtout répondre à plusieurs faiblesses, même si toutes les nouveautés ne sont pas encore détaillées. Une conférence de présentation commence d’ailleurs immédiatement et peut être suivie sur YouTube, Peer.tube et même Telegram.
Les nouveautés majeures de /e/OS 3.0
Cette troisième version majeure est d’abord une modernisation de toute la base. Elle reprend (a priori) les apports d’Android 14 et devrait permettre à bon nombre d’appareils d’être mis à jour vers la nouvelle version. On ne sait pas en revanche quand les processus de migration seront mis en place.
/e/OS 3.0 renforce également sa protection de la vie privée. Le système offre ainsi un aperçu de la manière dont les informations sont traitées. Il génère des rapports hebdomadaires avec des informations détaillées sur les « apps invasives » et les traqueurs. Ces rapports fournissent en outre un score de confidentialité globale et pointent les fauteurs de troubles. Les utilisateurs peuvent partager ces informations sur les réseaux sociaux, même si beaucoup ont un fonctionnement contraire aux valeurs portées par Murena. Il est aussi possible de personnaliser l’accès à la position géographique pour les applications, en distinguant celles utilisant la vraie position de celles servies par une localisation factice.
La nouvelle version apporte aussi une fonction Vault pour l’espace de stockage. Il s’agit d’un coffre-fort dont le contenu est chiffré de bout en bout, basé sur CryptPad. Point important, ce service est compatible avec l’ensemble des fichiers à stocker, y compris les documents faisant l’objet d’un travail collaboratif.
Cet ajout, pour l’instant en bêta, prend place dans le bouquet Murena Workspace et nécessite donc un compte Murena. La version de base, comprenant 1 Go, est gratuite. Les tarifs vont ensuite de 1,99 euro par mois pour 20 Go à 24,99 euros par mois pour 2 To. Les abonnés payants reçoivent d’ailleurs une autre fonction : la dictée vocale, que Murena garantit « en toute confidentialité ».
Mode tablette et contrôle parental
L’un des plus gros apports de /e/OS 3.0 reste le mode tablette. Le système pouvait déjà être installé sur des tablettes (certaines sont d’ailleurs vendues sur la boutique officielle), sans disposer d’un affichage réellement adapté. C’est désormais le cas.
Le système renforce aussi son contrôle parental en lui apportant plusieurs fonctions importantes. On peut choisir la tranche d’âge des enfants et obtenir des réglages par défaut. Surtout, les applications restreintes peuvent désormais réclamer le code parental pour être installées. De plus, les parents peuvent généraliser l’utilisation du code à l’ensemble des installations, pour s’assurer que leurs enfants n’installent rien d’autre que ce qui est déjà en place.
On note enfin deux autres nouveautés. D’abord, la possibilité de retrouver son téléphone perdu via une fonction de recherche par SMS. Nous n’avons pour l’instant pas de détails sur le fonctionnement de cette fonction. Ensuite, la bascule du moteur de recherche par défaut sur Qwant, qui repose en partie sur Bing.
Il manque pour l’instant des informations importantes sur le nouveau système, notamment la version d’Android utilisée, la compatibilité matérielle, le fonctionnement de la recherche d’appareil ou encore de la dictée vocale. Nous mettrons à jour cette actualité lorsque nous aurons les réponses.
Commentaires (44)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 03/06/2025 à 16h49
Le 03/06/2025 à 17h14
Concernant la compatibilité, oui, c'est un aspect sur lequel il faut faire attention, car c'est plus compliqué que ça en a l'air. Le site https://doc.e.foundation/devices/one est pas mal, mais je ne trouve pas clair leur système de versionnement. C'est quoi le rapport en la version S, T, U et la version 3.0 de eOS ?
Le 03/06/2025 à 17h18
Le 03/06/2025 à 18h01
Le 03/06/2025 à 18h23
- S, T et U (voire V maintenant) correspondent à la version d'Android utilisée.
- La version 3.0 de /e/OS correspond à la troisième mouture du service applicatif.
Généralement une version (majeure) de /e/OS couvre plusieurs versions d'Android.
C'est en fonction de l'appareil que l'on peut voir les versions compatibles soutenues officiellement et les versions communautaires.
Par exemple, j'ai un Fairphone 3+ et je suis déjà passé à la version 3.0 de /e/ (huhuuu) et je suis toujours sur la version 13 d'Android (donc la T).
Pour d'informations sur les appareils compatibles, voir ici : https://doc.e.foundation/devices
Le 03/06/2025 à 17h06
Première impression au lancement, je trouve le launcher Bliss infâme... (Merci, grâce à ça j'ai découvert SmartLauncher qui est magique
Outre les divers petits tracas qui m'ont bien fait ronchonner, le gros point qui m'a fait retourner en arrière, c'est l'incompatibilité avec plusieurs applications qui sont non négociables pour moi. (P.ex.: bancaires, ou SwissID qui est obligatoire pour accéder à certains services comme la Poste en Suisse, et qui affiche joyeusement à l'ouverture que le système est détecté comme "alternatif", donc non, passez votre chemin).
Du coup, pas le choix, retour en arrière.
C'est dommage parce que la philosophie du système me plait, mais j'ai vraiment eu l'impression d'être face à un bricolage (certes assez réussi, mais du bricolage quand même).
J'espère sincèrement que /e/OS va continuer à se développer et devenir réellement une alternative solide. Ce jour là, je re-tenterai ma chance.
Le 03/06/2025 à 17h22
Oui, ce souci est vraiment embêtant, j'ai ce problème avec UBS et son application Access qui n'est plus compatible avec eOs depuis quelques semaines, suite à une mise à jour de l'application. De mon côté, je suis en train de chercher une autre banque, mais il faut que je m'assure que l'autre banque propose quelque chose de fonctionnelle avant...
Je n'ai jamais utilisé SwissID, je vais regarder ce que c'est (je suis encore nouveau en Suisse), mais il est probable que je ne l'utiliserai pas.
Sinon, concernant l'aspect bricolage, c'est vrai que le fait que l'OS ne soit pas installé comme un système 'stock' pose de sérieux problèmes de compatibilités (et un peu de sécurité, mais pas autant qu'on voudrait nous faire croire), mais au vu de mon expérience avec iOS de ma compagne, ou les autres systèmes d'exploitation Android, je trouve qu'eOS fait moins bricolage qu'eux.
Le 03/06/2025 à 17h58
Maismon Fairphone 4 a depuis presque son achat, IodéOS, un autre dérivé de LineageOS, aussi avec MicroG à la place de Google Play Services.
Aucun souci avec les applis bancaires ou d'identification (pro). Tout marche.
Le seul souci que j'ai eu c'était une appli de tracker LORA (Invoxia) qui pendant longtemps n''affichait pas sa carte (google maps embeded).
Par contre sur un autre vieux tel avec Lineage Rooté l'appli banque refuse de se loguer pour les raisons que vous supposez. Est-ce que c'est pas ça ton problème ? (si c'est ça il est possible d'enlever root ).
Le 03/06/2025 à 23h10
Forcer l'utilisation d'une application mobile sans autre alternative, c'est un non-sens technique et éthique. D'autant plus quand la solution repose sur une des plus grosses entreprises de surveillance de la planète.
Le 04/06/2025 à 10h44
Donc tant que d'un côté ou de l'autre il n'y a pas de changements, c'est à moi de m'adapter en choisissant une solution qui me convienne.
Le 05/06/2025 à 15h54
Déjà, 2 pisteurs, et trop de permissions demandées : https://reports.exodus-privacy.eu.org/fr/reports/ginlemon.flowerfree/latest/
Oui, l'identifiant publicitaire, ben non en fait.
Ensuite, depuis https://docs.smartlauncher.net/faq/license-and-purchases#i-want-to-buy-a-license-without-using-the-google-play-store :C'est dommage. Même le développeur indépendant de Symfonium arrive à le faire (https://support.symfonium.app/t/how-can-i-pay-for-symfonium-without-google-play/1290/2) en payant 7€ sur Ko-Fi.
Et sans acheter SmartLauncher, y a des pubs dedans (cf https://docs.smartlauncher.net/faq/differences-between-versions#what-are-the-differences-between-smart-launcher-free-and-smart-launcher-pro)
Modifié le 03/06/2025 à 17h14
Il faut compter moins d'1,5 ans de retard sur les versions majeurs d'android pour un téléphone récent. Les patchs de sécurités sont généralement déployés avec les mises à jour normales avec moins d'un mois de retard, exception faite de la v3.0 qui a ralenti l'accès aux patchs de sécurités d'android de 3 mois.
Modifié le 03/06/2025 à 17h36
Les mises à jour avaient souvent quelques mois de retard et appliquées partiellement (ils ont même été pris à mentir en changeant la version affichée dans les paramètres sans appliquer les patchs) sur du matériel au bootloader impossible a revérrouiller sans le briquer.
Le téléphone peut être entièrement compromis en moins de 5 minutes par un amateur !
https://exquisite.social/@h3artbl33d/114462845588460372
Aucun support des fonctionnalités de sécurité type enclave sécurisée, et au contraire ils contournent des fonctionnalités de sécurité des applications bancaires (beaucoup d'applications bancaires bloquent, à raison, les terminaux non sécurisés, et plutôt que de chercher à être considéré comme sécurisé par ces applications, /e/OS a pris le parti de contourner les sécurités).
Google a certes un monopole sur les sécurités (presque uniquement les terminaux certifiés par Google ont accès aux applications bancaires qui implémentent ces sécurités) mais rendre les téléphones vulnérables pour contourner un monopole gênant, c'est niet pour moi.
Ils n'ont aussi aucun chiffrement de bout en bout, donc on se retrouve juste à donner nos données à Murena plutôt que Google.
Plutôt que /e/OS, je conseille clairement un GrapheneOS ou CalyxOS. Ce sont parmi les seuls OS sans Google qui soient potables en termes de sécurité.
Pour une table de comparaison des OS mobiles très complète : https://eylenburg.github.io/android_comparison.htm
Le 03/06/2025 à 18h47
Un tél sous grapheneOS rooté est-il moins sécurisé que sous l'android stock du constructeur ? Ou de l'AOSP avec ses propres applis ?
Ce que j'en vois c'est que les développeurs sont plutôt incité par Google à placer ces protections (notamment car Google documente et promeut l'usage de ses API safenet & autre), mais que c'est dans son intérêt, pour éviter de faciliter le départ de trop de gens vers des OS alternatifs et donc pouvoir continuer à pister (leur valeur est dans la masse de données). Pour autant, ils sont pas très à fond sur le déploiement de patch sur les anciennes versions d'OS avec des failles avérés (en particulier chez les constructeurs tiers)...
Il y a là pour moi un conflit d'intérêt évident.
Le 04/06/2025 à 10h28
Mise à part la mauvaise foi qui mettrait dans le même panier GrapheneOS et un root effectué avec le premier .exe trouvé sur le net, ne faudrait-il pas s'attendre à un « Vous vous êtes faits piraté / arnaqué / ... en ayant installé notre appli sur un teminal que vous avez vous-même trafiqué, on rembourse pas » ?
Le 04/06/2025 à 11h46
Après dans le cas où c'est toi qui valide, que ce soit un OS "non conforme" ou pas, ça change rien ... t'es marron.
Le 04/06/2025 à 11h31
Je n'utilise pas les services Google pour les mêmes raisons de vie privée que vous, mais je reconnais tout de même qu'ils ont des (très) bons ingénieurs et que les Pixel sont (et c'est dommage) les seuls téléphones à même de se mesurer aux iPhone sur la sécurité.
Les puces de sécurité sont très performantes et bien intégrées, le bootloader est revérouillable et aucune fonctionnalité n'est désactivée en changeant d'OS (Samsung par exemple désactive sa puce de sécurité si l'OS est changé), les mises à jour sont très rapides et complètes,...
Tout à fait !
Mais AOSP contient aussi des API de sécurité, qui, même si elles sont moins poussées par la communication de Google, sont tout aussi efficaces et ne dépendent pas d'un quelconque partenariat avec Google.
Le mieux à faire pour les OS alternatifs est d'implémenter correctement ces API ouvertes et de faire du lobbying auprès des banques ou lancer des actions en justice pour qu'elles les utilisent plutôt que les API fermées de Google. C'est la technique de GrapheneOS, qui est en train de communiquer avec la Commission européenne dans ce but.
Ils ont d'ailleurs une page très détaillée à ce sujet : https://grapheneos.org/articles/attestation-compatibility-guide. Pour information, France Identité utilise cette API ouverte, ce qui fait que l'appli marche sur GrapheneOS... mais pas /e/OS.
/e/OS quant à lui n'implémente pas les API ouvertes et tente de contourner les sécurités de l'API fermée (contournements qui finiront nécessairement par être bloqués, c'est jouer au chat et à la souris, et à la fin le géant gagnera dès que la fourmi commencera à un peu trop le chatouiller et qu'ils se pencheront sur les contournements utilisés).
Bien au contraire !
Un des gros problèmes historique d'Android est la fragmentation : chaque constructeur a sa surcouche et c'est les constructeurs qui doivent appliquer les mises à jour. Google maintiens des patchs de sécurités pour les 3 dernières versions majeures de l'OS, et envoie les patchs au constructeur toujours 5 jours avant de publier la liste des failles corrigées et de rendre les patchs open source afin de leur laisser le temps de patcher. Très peu de constructeurs mettent à jour à temps (les Samsung les plus hauts de gamme et les Pixel sont les seuls à avoir les patchs de sécurité en temps et en heures à ma connaissance).
Pour les mises à jour majeures, c'est encore une fois un soucis de constructeurs.
Cette fragmentation est un énorme problème pour Google, un problème marketing surtout (c'est un des principaux arguments contre Android) mais aussi financier (des constructeurs qui mettent à jour plus rapidement, c'est moins de coûts pour supporter d'anciennes versions). Et ils essaient de corriger pas mal parce qu'ils y ont un intérêt : le projet Treble dans Android 8 a permis d'accélérer énormément les mises à jour, et aujourd'hui, ils déploient le projet Mainline pour mettre à jour le plus d'applications systèmes possibles par le Play Store.
Sur ce point, les intérêts de Google, des utilisateurs et des ROMs personnalisées, sont alignés. Ils préfèreraient tous les 3 avoir des mises à jour rapides de la part des constructeurs.
(sur un autre point, Google a aussi tout intérêt à implémenter des fonctionnalités de vie privée comme les permissions fines, le blocage de l'accès aux identifiants matériels ou le blocage des communications inter-applications : ça assure leur monopole puisque seules les applications Google seront en mesure de pister les utilisateurs)
Le souci, c'est que /e/OS a systématiquement du retard sur les mises à jour systèmes (d'accord, ils ont les codes 5 jours après les constructeurs, mais ça ne justifie pas d'avoir 2 mois de retard sur celles-ci) et ne met pas à jour le firmware (seul Android est tenu à jour, les drivers/le firmware sont figés dans la version à l'installation de l'OS, aucun mécanisme de mise à jour n'est prévu). Également, et comme la plupart des constructeurs, les patchs ne sont appliqués que dans leur partie obligatoire.
De mon point de vue, il est préférable pour un utilisateur d'avoir ses données chez Google que de les avoir sur le darkweb.
L'un vends les données à des entreprises qui n'ont aucun intérêt à vous vouloir du mal (elles veulent des thunes, mais par des moyens sinon légaux au moins zone grise), l'autre donne les données à des personnes qui vous veulent du mal (elles veulent des thunes, et n'ont aucune limite sur les moyens).
Il n'est pas impossible, ni même improbable, que des vulnérabilités permettant l'exploitation à distance de téléphones Android existent, on a déjà vu des vulnérabilités rendant possible l'exécution de code arbitraire par le simple envoi d'un SMS...
La vie privée ne va pas sans sécurité. Avoir une vie privée implique nécessairement de sécuriser un minimum ses données.
Le 04/06/2025 à 12h41
Le 04/06/2025 à 14h31
Je reste pas d'accord avec toi sur la fin : "Je préfère avoir mes données chez Google que sur le Darkweb" , en particulier car je pense pouvoir les sécuriser moi-même, et que j'en prends la responsabilité si elles fuitent par mon incompétence.
Je comprends que tout le monde ne peux faire ce choix et que Google représente une solution de facilité.
Je n'accepte pas en revanche le coté "grand frère bienveillant" (et incontournable) de Google et d'Apple. Proposer un service c'est OK, le rendre incontournable pour moi ça ne l'est pas. D'où la discussion sur Graphène ci-dessous.
Pour moi le choix uniquement entre Google et le Darkweb reste un peu caricatural (je comprends que tu parlais de /e/ , mais qu'en est-il des autres ROM )
Merci pour la description des Pixels.
Le problème pur moi c'est que c'est un peu élitiste, ces téléphones étant parmi les plus chers (j'ai jamais mis plus de 120€ dans un smartphone, surtout vu la durée de vie physique avec moi
Je constate que les seuls Pixels supportés désormais sont ceux à base de CPU Google Tensor - pas sur que d'autres modèles soient basés dessus (Google suis ainsi le modèle d'Apple). les Pixels <= 5 sont basés sur du Qualcomm.
Pour autant, il n'y a pas que Google qui sait faire de la sécurité dans le monde ARM, OP-Tee et ATF existent ailleurs et à ma connaissance n'ont pas été mis en défaut... J'entends que les constructeurs de téléphone veulent avant tout du Time-to-market, mais ça doit bien exister les implémentations pas trop déconnantes autre que celle de Google...
Bref, merci encore pour ces pistes de réflexion.
Le 04/06/2025 à 16h40
Les Pixel 5 sont encore supportés en harm reduction.
GrapheneOS est honnête en disant explicitement qu'une ROM custom ne peut pas fournir de mises à jour lorsque le constructeur n'en fourni plus non plus (parce que les drivers sont closed-source, et mettre à jour le système sans mettre à jour les drivers est un nid à failles).
Au contraire de LineageOS et /e/OS qui se vendent comme permettant d'avoir des mises à jour après la fin de vie officielle du téléphone alors qu'ils ne mettent à jour que le front laissant le back plein de trous sans informer les utilisateurs qu'ils vivent sur un gruyère.
Il n'y a pas de dépendance de GrapheneOS sur les Tensor, c'est juste que tous les tous les téléphones non-EOL remplissant les critères de sécurité de GOS ont un Tensor.
J'avais vu passer dans une conversation sur un des canaux de développement de GOS qu'ils pourraient supporter l'Exynos sans soucis si jamais Samsung autorisait le déverrouillage/revérouillage du bootloader et ajoutais 2/3 features de sécurité, les Exynos étant conçus avec une bonne sécu. Par contre ils avaient aussi dit que les téléphone sur SoC MediaTek c'était un no-go puisqu'ils n'implémentent pas la plupart des pré-requis de GOS.
Effectivement viser /e/OS c'est la cible facile. /e/OS prends du temps à se mettre à jour avec LineageOS et n'a pas tous les patchs de ce dernier qui prends lui-même du temps à se mettre à jour sur AOSP et n'a pas tous les patchs de ce dernier.
À peu près toutes les ROMs basées sur Lineage ont les mêmes soucis de sécurité.
Modifié le 06/06/2025 à 09h11
Je conçois parfaitement que dans une logique de sécurisation de la plateforme (et de la même manière qu'Apple) ceci ait du sens.
Par contre, ça implique qu'il faut leur faire confiance. Le fait qu'ils soient éditeur de Android, que leur intérêt direct est qu'il y ait le moins possible de "trous dans la raquette", et qu'ils soient américain donc soumis aux différentes obligations étatique dont Snowden s'est fait l'écho, tout ça fait que je suis quand même un peu dubitatif sur la générosité et l'altruisme de Google sur le fait de fournir des processeurs "sécurisés" sans backdoors , le conflit d'intérêt ici me semble flagrant.
Je peux parfaitement envisager que Google dispose de portes dérobés qui serait en mesure, par exemple, de contrer la fonction DuressPin ou de fournir la clé de chiffrement aux autorités , en tous cas après l'affaire de San Bernardino ça parait plausible à tout le moins.
=> Je ne peux pas m'empêcher de trouver suspicieux le fait que GrapheneOS, présenté comme le plus sécurisé des OS soit supporté uniquement sur les CPU produits par la société qui a le plus intérêt à espionner tout en empêchant d'autres de le faire.
C'est vrai aussi que sur la marché il n'y a pas 50 CPU pour mobile (et qui a envie non plus de faire confiance à Qualcomm, quand on connait la qualité de leur code), mais le fait que les Exynos & les Dimensity (ces derniers embarquant une unité Securyzr dans leurs derniers chip) soient ainsi écarté quand c'est pas carrément dénigré me parait quand même assez flagrant.
(Oui j'aimerais bien qu'un tél RISC-V full open-source avec sécurité et tout existe un jour... mais je suis pas sur de le voir de mon vivant :-) )
En résumé la question reste en qui placer notre confiance. A titre personnel je reste convaincu que le maximum d'opensource reste un gage de confiance (sans sous-estimer les inconvénients c'est forcément mieux que des implémentations fermées), mais que les conflits d'intérêt génèrent aussi des actions nuisibles et donc, pour moi c'est à fuir.
Google en la matière est très bipolaire....
Modifié le 06/06/2025 à 13h26
Ça serait top, mais il faut un financement, parce que ça coûterait EXTRÊMEMENT cher. Mais ça ne me semble pas impossible du tout. Il "suffirait" qu'un ou plusieurs pays européens développent un système pour eux et le rendent ouvert. On a déjà eu l'ANSSI qui a ouvert ClipOS par exemple, et qui développe actuellement le système d'exploitation pour les téléphones de la gendarmerie/police (SecDroid je crois).
Le souci, c'est que, de manière générale, les solutions open-source font très peu gaffe aux systèmes de sécurité avancés.
Typiquement excepté sur Android, il n'existe aucune solution de vérification d'intégrité pour aucun OS open source, alors que tous les OS propriétaires en implémentent une. Une des raisons ? Les entreprises (banques notamment) veulent ces solutions pour confirmer la sécurité d'un terminal, et là où l'open source se fout pas mal de ce que veulent les entreprises, les Windows, iOS et autres Android le prennent très à cœur. Autre raison ? Le « bah tant que ça marche » et le « bah on a jamais eu de pirate » (qui marche bien pour Linux sur desktop, qu'on vante comme "plus sécurisé" que Windows même s'il a bien moins de sécurité en place, il se trouve juste qu'il y a moins de pirates).
On a pas mal de projets open-source qui crient à l'anti-concurrence quand Google implémente un système pour que les applis bancaires puissent refuser de fonctionner sur des appareils ne répondant pas aux normes de sécurité (pour se protéger elles-mêmes, qui sont légalement responsables même en cas d'un piratage du client !).
C'est vrai, le système implémenté contient une logique anticoncurrentielle (il faut respecter la norme + être partenaire de Google), mais AUCUNE ROM custom n'implémente aucun système alternatif.
Quand un juge décidera qu'il faut que Google arrête d'avantager ses partenaires, bah ça ne changera strictement rien parce qu'il n'y a que les partenaires de Google qui respectent la norme (moins quelques partenaires qui ne respectent pas la norme mais ont quand-même la certification, looking at you Fairphone qui a eu son bootloader signé avec les clés de test pendant 3 générations).
Le 06/06/2025 à 18h17
=> Je suis d'accord , mais là tu impliques que l'OS démarre depuis le 1er octet exécuté sur le CPU.
Le kernel linux arrive bien plus tard, donc en effet il ne peux être sécurisé que dans la mesure où il a été lui-même signé & authentifié par les couches d'avant (après ya des choses comme
dm-verity qui me paraissent faire l'affaire, en tout cas c'est ce qui est utilisé en industrie).
Donc t'est "obligé" de faire confiance à OP-Tee et ATF (et je suis d'accord que ça peux ne pas te suffire.
Plus "philosophiquement", pour moi il y a une vrai contradiction entre la liberté des usagers de choisir l'OS qu'ils veulent / les applis qu'ils veulent même hors du store , .... et la volonté des banques de restreindre les gens dans une cage dorée sous prétexte de sécurité & responsabilité.
(Une solution, simple, serait que les banques ne soient pas rendues responsable si tu te fait pirater ton compte via un téléphone rooté et/ou une appli vérolée installée hors-store. Les assurances sont coutumières de s'exclure de toute responsabilité pour tout & n'importe quoi, je vois pas en quoi les banques seraient différente - en plus là ce serait difficile pour le client de plaider l'incompétence technique vu ce qu'implique le root voire le remplacement d'OS sur un tel.
Tu sembles impliquer que tout ce qui est opensource c'est de la merde niveau sécurité, je ne te suivrait pas sur ce terrain-là. Certes coté desktop c'est un peu vrai, mais bon Linux c'est aussi une grosse part de marché sur les serveurs, et là on entends quand même moins parler de problèmes de sécurité tous les 3 jours (ce qui veux pas dire qu'il n'y en a pas du tout, et pourtant des attaques à la con il yen a) - donc le point noir c'est l'utilisateur qui clique partout.
A titre personnel je pense que si d'un coup de baguette magique tous les Windows étaient replacé par des Desktop Linux, on aurait très très nettement moins de problèmes , mais j'admets que c'est une conviction plus qu'un fait (vu que ce cas ne s'est jamais présenté en volume).
"C'est vrai, le système implémenté contient une logique anticoncurrentielle (il faut respecter la norme + être partenaire de Google), mais AUCUNE ROM custom n'implémente aucun système alternatif"
Tu as en tête une norme sur cette question ?
(et oui, "partenaire google" ca reste un problème quand le business model de Google c'est la pub. j'ai pas le même souci avec la Wifi-alliance, par example).
En ts cas encore merci de cette discussion hyper enrichissante (on est pas d'accord sur la question mais ça reste un régal de lire les arguments)
Modifié le 06/06/2025 à 18h48
J'utilise quasiment uniquement de l'open-source chez moi, et on est très loin d'avoir que de la merde (cela dit par contre, si, il y a bien des failles de sécurité dans un composant Linux serveur au moins une fois tous les 3 jours, mais c'est pareil dans Windows et rapidement corrigé).
Et oui, la plupart du temps le problème c'est l'utilisateur qui clique partout.
Le soucis c'est certains projets open-source qui sont en mode "tant que ça marche". Je pense à /e/OS évidemment, mais aussi les centaines de logiciels sur Github avec 254 dépendance dont 76 pas à jour non à jour et 8 dépréciées, logiciels qui ont parfois vocation à finir sur des systèmes d'entreprise (et j'ai peur pour les entreprises qui déploieraient /e/OS, maintenant que Murena a sorti son offre Business avec MDM).
Je suis tout aussi d'accord pour laisser la liberté à l'utilisateur, mais il y a des moments dans lesquels c'est pas compatible avec les entreprises (et ça c'est le système capitaliste). Ici la banque, mais ça inclus aussi les DRM.
Les OS open-source actuels auront bien du mal à prendre de l'ampleur s'ils ne supportent ni les banques ni Netflix (et les trucs en +).
Et pour ça il y a deux solutions :
- insérer les DRM/la vérification de l'intégrité dans ces OS (en informant voire demandant le consentement de l'utilisateur avant des les activer - "attention cette application va restreindre vos possibilités de bidouillage, si vous touchez à tel tel tel système, elle refusera de fonctionner")
- changer le système (pas le système d'exploitation, enfin si... le capitalisme quoi)
Sans ça, ces systèmes resteront minoritaires chez le grand public. (Après, est-ce souhaite d'insérer ces technologique pour prendre des parts à Windows/macOS ? C'est un débat plus profond)
Ou sinon on peut relâcher la pression sur les banques qui sont responsables pour tout et supprimer le droit d'auteur. Sauf que si on relâche la responsabilité, on risque de rendre valide l'argument "le client a tapé son code et validé la transaction, c'est sa faute il a manqué de vigilance informatique" dans les cas des arnaques. Et si on supprime le droit d'auteur j'avoue que je suis curieux de savoir ce qu'il va se passer (en vrai ça serait peut-être positif).
Le 04/06/2025 à 15h19
En effet, c'est une bonne approche de faire du lobbing pour avoir des API ouvertes qui corresponde au besoin de toutes les parties d'avoir de la sécurité.
Toutefois, le but de Murena c'est d'avoir un truc qui marche tout seul pour le grand public, donc ils ont besoin d'avoir la plus large palette de matériel possible. Là ou Graphen OS se limite en matériel. En suite, comme l'indique ton lien, certaines applications utilisent encore des vielles techniques comme Safetynet pour sécuriser l'environnement de l'applications et c'est même parfois mal fait. Je suppose que Murena a donc pris le parti de prendre le plus petit dénominateur commun. Et ils ont embauché le développeur de MicroG pour ça.[
https://community.e.foundation/t/safetynet-and-rootbeer-compatibility-status-on-e-os-phone/56390](https://community.e.foundation/t/safetynet-and-rootbeer-compatibility-status-on-e-os-phone/56390)
https://microg.org/
https://goodtech.info/e-os-participe-au-developpement-de-microg/
https://doc.e.foundation/support-topics/micro-g
Après, si l'UE impose à Google des API ouvertes, je ne vois pas Murena ne pas modifier son code pour les prendre en charge. Il faudra aussi que les développeurs d'applications basculent sur ces API ouvertes. Quand je lis dans ton lien que des applications gouvernementales suisses et italiennes bloquent Graphen OS, je me dis que certaines mentalité de tous miser sur les GAFAM sont assez répandu dans les administrations gouvernementales.
Merci pour ton échange.
Modifié le 04/06/2025 à 16h42
Je peux juste affirmer que l'appli fonctionne sur mon Pixel 7 Pro sous GOS mais pas sous LineageOS (erreur explicite indiquant que l'OS est modifié et pas sécur).
Le 04/06/2025 à 17h47
Le 04/06/2025 à 17h50
Le 04/06/2025 à 18h08
Le 05/06/2025 à 14h56
Le 05/06/2025 à 15h28
Il semble qu'il y ait pas mal de divergence en fonction des téléphones utilisés : https://community.e.foundation/t/france-identite-erreurs/69037
Mais globalement c'est comme je le disais du contournement des sécurités par /e/OS, ça ne marchera plus très longtemps avec le déploiement progressif de la validation par le hardware...
Le 05/06/2025 à 22h53
Le 09/06/2025 à 16h24
Le 03/06/2025 à 19h18
Le 03/06/2025 à 19h38
Le seul "problème" de GrapheneOS est qu'il n'est officiellement supporté que sur Pixel (un peu paradoxal à mon sens), mais il existe des images GSI , et moyennant l'abandon de certains éléments de sécurité (tout en restant bien plus "fort" à ce niveau qu'un AOSP) il serait possible de le porter tout autant qu'un Lineage... => Du coup qu'est-ce qui empêcherais /e/ de se baser dessus plutôt que sur Lineage ?
Au passage , ils ont pas l'air de porter les applis bancaires dans leur coeur : https://grapheneos.org/usage#banking-apps => Il me semble que certaines utilisent des techniques emprunté aux malwares pour valider ou pas si elles s'autorisent à tourner....
Modifié le 04/06/2025 à 11h45
Après GrapheneOS n'a pas pour but de déGoogliser, il a pour but de sécuriser au maximum le téléphone et augmenter la vie privée. Retirer les services Google (ou les sandboxer) est une des mesures pour atteindre ce but. C'est pour ça qu'ils s'autorisent à supporter les Pixels là où d'autres OS visant la déGooglisation se l'interdisent, il n'y a pas de paradoxe.
Il existait bien DivestOS qui faisait un backport des patchs de GrapheneOS sur les mêmes modèles que LineageOS mais c'était ce qu'on appelle de la réduction de risque parce que le seul fait de changer l'OS réduit de fou la sécurité sur la quasi-totalité des téléphones hors Pixel. DivestOS n'existe plus et c'est dommage.
Je ne connais que les Pixel et les Fairphones qui permettent de changer les clés du bootloader sans perdre de fonctionnalités. Les Fairphones ont énormément de problèmes autres que le bootloader qui les rendent impossible à sécuriser correctement, d'où le support exclusif des Pixels.
GrapheneOS est très clair sur le fait que si un jour un téléphone supportait le même niveau de sécurité que les Pixel alors ils le supporteraient dans la foulée. Ils ont une liste des fonctionnalités de sécurité qu'ils demandent du hardware : https://grapheneos.org/faq#future-devices
Le 03/06/2025 à 20h07
Toutes proportions gardées, on pourrait dire que Murena est au monde Android ce que Ubuntu est au monde Linux : une belle proposition orientée utilisateur débutant, un système Android avec une surcouche (lanceur, jeu d'applications installées par défaut, un thème spécifique, etc. propres au projet). Là, où LineageOS serait plutôt comparable à Debian : un Android vanilla et juste quelques applications de base, à toi de bricoler si tu veux ajouter des modules comme MicroG, nanoDroid, etc.
Personnellement, je préfère la proposition de LineageOS with MicroG, qui est entre les deux. C'est un fork de LineageOS qui intègre par défaut les modules MicroG et la logithèque FDroid avec les droits adéquats pour mettre à jour en arrière-plan et silencieusement les applications qui en sont issues, sans intervention de l'utilisateur.
L'ouverture logicielle, c'est vraiment un plus : la version officielle Googlisée de la ROM du Fairphone 3 que j'utilise est bloquée à Android 13 et les mises à jour de sécurité devraient s'arrêter en 2025 (6 ans de support, ça reste quand même beau). Avec Lineage, je peux déjà utiliser Android 15 et profiter des mises à jour de sécurité mensuelles aussi longtemps que le mainteneur sera actif. De quoi faire durer des terminaux encore utilisables au quotidien.
Le 03/06/2025 à 20h13
C'est reposant, vraiment.
Le 03/06/2025 à 22h34
Modifié le 05/06/2025 à 10h59
Je retiens de vos échanges qu'il n'existe pas de proposition simultanément sécure, privacy-friendly et GAFAM-free. A défaut, GrapheneOS (donc, acheter un Google Pixel) est ce qui s'en rapproche le plus sachant que par les temps qui courent la sécurité est primordiale. Je crois que je vais rester sur des iPhone premier prix (iPhone SE, iPhone 16e) qui sont supportés quand même sept ans.
edit: les Google Pixel ont aussi un support de sept ans et le Google Pixel 9a démarre à 549 EUR contre 719 EUR pour l'iPhone 16e. Il reste à ne pas briquer le Pixel en installant GrapheneOS. Apparemment, la méthode la plus simple consiste à passer par l'installeur web.
Le 05/06/2025 à 18h27
Le 06/06/2025 à 12h08
Le 05/06/2025 à 10h25
https://volla.online/en/
Le 05/06/2025 à 21h33
Dans mon utilisation c'est similaire à Murena.
C'est le manque de choix dans les téléphones qui m'a fait partir, du Gigaset rebadgé et vendu bien plus cher.