Par curiosité, sur quel téléphone ? 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...
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 ?
GrapheneOS n'est pas rooté, et est plus sécurisé que l'OS stock des Google Pixel, qui est lui-même bien plus sécurisé que l'OS stock de la plupart des autres constructeurs.
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,...
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)
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).
Pour autant, [Google] 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)...
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.
Pour moi le fait que Google trace toute mon activité et serve ces infos à qui veux bien les payer, autorités comprises, ou bien que Google choisisse ce que j'ai le droit de faire ou pas avec un appareil qui est a moi est BIEN plus problématique qu'un hypothétique piratage
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.
Bonjour, je n'ai jamais eu de soucis avec France Identité sur /e/OS depuis que je l'utilise depuis le 01/2024, j'ai même pu tester l'identité numérique certifiée sans soucis. L'application fonctionne parfaitement sur ce système.
Je l'utilise depuis 2 ans ca marche vraiment bien, mon téléphone (un fairphone 4 qui était sous android 11) a passé toutes les mises à jours de murena sans encombres (j'ai hâte du passage sous android 15, il est maintenant sous murena 2.9 android 14), j'ai du avoir deux soucis d'applications, l'un avec chatgpt (mais relativement je remercie le système de l'avoir bloqué ) et un soucis d'une application qui plante, pour testé j'avais mis mon compte google dessus ce qui bloquant l'application à cause d'un token d'authentification expiré et le système semblait ne pas le mettre à jour (en supprimant le compte google tout est revenu dans l'ordre). Donc les deux bugs sont en faites des features (des apps comme france identité, yris, la carte vitale, compte ameli, boursobank, les impots, bitwarden ... fonctionnent parfaitement).
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.
C'est France Connect, pas France Connect+, et il y a une option "créer un compte" (qui nécessitera une vérification physique que c'est bien vous qui avez porté plainte).
ça me paraît être une mesure tout à fait raisonnable.
Bonjour, pour précision la vérification physique peut tout de même se faire en ligne en moins de 5 minutes, comme par exemple avec l'application YRIS où il est nécessaire de capturer son document d'identité pour se créer un compte.
Mince, je comptais justement changer de config pour un 2700X :‘( comment peuvent-il être autant libriste sur les cartes graphiques et autant fermé sur les processeurs …
T’arrive après la guerre autant Proton (le fork wine de Valve), qui vient juste de sortir sur la branche stable de steam tourne super bien, sans aucune configuration … autant faire ce que tu dis est complexe et non viable pour un jeu vidéo … rien que de citer une variable comme WINEPREFIX est la mort quand tu compares le jeu vidéo sur windows ou sur console.
Donc oui on peut faire énormément de chose sur wine, mais pas sans la ligne de commande (et ne pas citer d’interface comme PlayOnLinux qui ne possède ni vcrun2015 ni vcrun2017 et dont l’installation de .NET est foutu, les scripts sont vieux comme le monde). (read only pour des jeux en ligne c’est mort).
Le soucis ce n’est plus avec DX … mais c’est plus pour toutes les autres librairies et astuces nécessaires pour faire fonctionner tel ou tel jeu avec Wine, éléments qui ne sont pas si facilement accessible (genre des dll à activer ou à désactiver). Et encore tout ça sans parler de .NET qui ne marche toujours pas avec Wine en x64.
Quand ça se passe mal, je me retrouve facilement à perdre 2 ou 3 heures pour config un jeu et qui souvent ce solde par un échec (genre SpaceEngineers, Anno 2070, Astroneer qui marchait mais qui marche plus …). Ce n’est clairement pas viable.
Je pense que l’intérêt c’est de donner accès aux jeux existants qui n’auront jamais de portage Linux. Et ça représente bien 99,9999% du catalogue je pense " />
Par exemple on peut jouer à AoE2 HD avec Wine.
Je suis bien d’accord, mais ça reste trop complexe/trop long pour être utilisable par tout le monde et je ne vois pas Valve tester tous les jeux pour les configurer, ils vont juste regarder les dépôts de redistribuable auquel un jeu est lié, et l’intégrer dans un Wine et c’est tout. Je serais assez surpris que ça fonctionne réellement dans plus de 5% des cas ;) sauf peut être les jeux indés qui sont sous Unity, mais souvent ceux là sont portés pour GNU/Linux (en tout cas avec un truc comme ça, ils ne seront plus portés).
Spéculation, spéculation, quand tu nous tiens HAHAHA :)
Wine c’est clairement pas la bonne solution … une mise à jour du jeu ou de wine et paff on se retrouve à se retaper toute la config, tu format et paff reconfig, tu vas sur un autre pc et paff reconfig …
Après il y a déjà des wrappers pour wine comme le vieux PlayOnLinux (plus vraiment mis à jour en attendant la version 5 qui n’arrivera jamais), ou CrossOver le payant …
Un wrapper Steam, la bonne blague, surtout lorsque l’on regardes les jeux only 64 bits (ce qui est de plus en plus fréquent) et qui utilise .NET, et voilà plus rien de marche.
Par contre il y a des projets largement plus intéressant comme
winepack : faire un conteneur flatpak d’une app ou d’un jeu avec un
wine préparé aux petits oignons pour le jeu en question, si Steam Play utilise ce principe, là par contre ça pourrait être intéressant ;)
Naneday a écrit :
Ahhh ca prouve juste le flop de Linux pour le gaming
Pourquoi pas un truc du genre:
Windows only: 30% de frais steam
Windows + Mac: 25% de frais steam
Windows + Mac + Linux: 20% de frais uniquement
Avec ca, j’suis sur que ca va faire bouger les choses
Bien pour que ce soit un flop, les deux boites qui se tapent la majorité des portages de AAA devraient faire faillites (Aspyr & Feral Interactive) … jusqu’à présent ce n’est pas le cas. Mais sinon l’histoire des frais dégressif, c’est vraiment une bonne idée ;)
Pour ma part un petit ttrss fait le taf sur un rpi2 depuis déjà 3 ans et je ne pense pas changer.
Il arrive maintenant souvent que je ne suive pas des sites qui m’intéresse juste parce qu’ils ne fournissent plus de RSS, tant pis pour eux :p (sans flux rss, je ne lirais pas non plus nextinpact ^^).
PFFF, j’y ai cru jusqu’au premier commentaire (être crédule, c’est dure), il faudrait supprimer le 1er avril … c’est marrant gamin on colle des poissons sur le dos des copains, mais à un moment on grandit … ou pas " />
Moi j'ai juste désactivé les mises à jour recommandés et quand une
apparaît, je lis ce qu'elle fait et c'est fini, et encore en les lisant c'est là qu'on voit que 90% de ses maj ne servent à rien ... en même temps, je tourne sous Windows assez rarement, avec GNU/Linux pas de surprise :p
C’est pas trop tôt que Microsoft pense un peu à ça. J’attends toujours Office sur Linux :)
(cette vague de sword XD )
Office sur GNU/Linux, je n’y crois pas du tout ;) tout ce qui se dirige vers le multi-plateforme de la part de Microsoft reste des outils pour les développeurs et les professionnels de l’informatique …
16 commentaires
Le 05/06/2025 à 22h53
Le 05/06/2025 à 14h56
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.
Le 01/11/2024 à 11h52
Le 12/08/2021 à 18h24
Ils n’ont pas pensé à emmener un aspirateur malheureusement ;)
Le 25/10/2018 à 17h23
Mince, je comptais justement changer de config pour un 2700X :‘( comment peuvent-il être autant libriste sur les cartes graphiques et autant fermé sur les processeurs …
Le 29/08/2018 à 18h55
T’arrive après la guerre autant Proton (le fork wine de Valve), qui vient juste de sortir sur la branche stable de steam tourne super bien, sans aucune configuration … autant faire ce que tu dis est complexe et non viable pour un jeu vidéo … rien que de citer une variable comme WINEPREFIX est la mort quand tu compares le jeu vidéo sur windows ou sur console.
Donc oui on peut faire énormément de chose sur wine, mais pas sans la ligne de commande (et ne pas citer d’interface comme PlayOnLinux qui ne possède ni vcrun2015 ni vcrun2017 et dont l’installation de .NET est foutu, les scripts sont vieux comme le monde). (read only pour des jeux en ligne c’est mort).
Le 21/08/2018 à 21h42
Bon ba on a les réponses :p
https://steamcommunity.com/gid/103582791433699581#announcements/detail/169605585…
Le 21/08/2018 à 17h08
Le soucis ce n’est plus avec DX … mais c’est plus pour toutes les autres librairies et astuces nécessaires pour faire fonctionner tel ou tel jeu avec Wine, éléments qui ne sont pas si facilement accessible (genre des dll à activer ou à désactiver). Et encore tout ça sans parler de .NET qui ne marche toujours pas avec Wine en x64.
Quand ça se passe mal, je me retrouve facilement à perdre 2 ou 3 heures pour config un jeu et qui souvent ce solde par un échec (genre SpaceEngineers, Anno 2070, Astroneer qui marchait mais qui marche plus …). Ce n’est clairement pas viable.
Le 21/08/2018 à 10h15
Le 20/08/2018 à 15h12
Wine c’est clairement pas la bonne solution … une mise à jour du jeu ou de wine et paff on se retrouve à se retaper toute la config, tu format et paff reconfig, tu vas sur un autre pc et paff reconfig …
Après il y a déjà des wrappers pour wine comme le vieux PlayOnLinux (plus vraiment mis à jour en attendant la version 5 qui n’arrivera jamais), ou CrossOver le payant …
Un wrapper Steam, la bonne blague, surtout lorsque l’on regardes les jeux only 64 bits (ce qui est de plus en plus fréquent) et qui utilise .NET, et voilà plus rien de marche.
Par contre il y a des projets largement plus intéressant comme
winepack : faire un conteneur flatpak d’une app ou d’un jeu avec un
wine préparé aux petits oignons pour le jeu en question, si Steam Play utilise ce principe, là par contre ça pourrait être intéressant ;)
Le 31/01/2018 à 20h56
Pour ma part un petit ttrss fait le taf sur un rpi2 depuis déjà 3 ans et je ne pense pas changer.
Il arrive maintenant souvent que je ne suive pas des sites qui m’intéresse juste parce qu’ils ne fournissent plus de RSS, tant pis pour eux :p (sans flux rss, je ne lirais pas non plus nextinpact ^^).
Le 01/04/2016 à 14h18
Cette fois, c’est trop gros, ça n’entre pas
" />
Le 01/04/2016 à 12h27
PFFF, j’y ai cru jusqu’au premier commentaire (être crédule, c’est dure), il faudrait supprimer le 1er avril … c’est marrant gamin on colle des poissons sur le dos des copains, mais à un moment on grandit … ou pas
" />
Le 10/03/2016 à 16h48
HAHAHA
Le 09/03/2016 à 16h21