Sur Linuxfr.org, j’avais lu Quel téléphone (plus ou moins) libre en 2021 ? L’article rejoignait mes expériences. Précédemment, j’avais rooté plusieurs smartphones pour y installer Cyanogen, puis Lineage, ou /e/, je soutiens également Librem…
Hélas, Librem est trop inconfortable (pour le moment ?) et Lineage souvent ardu à installer (rien que débloquer un Xiaomi met une semaine) et n’est pas disponible sur les smartphones récents ; or justement l’intérêt est d’installer une nouvelle ROM au moment où l’on change de smartphone.
Bref rien ne me satisfaisait jusqu’au moment où j’ai entendu parler de CalyxOs (qui conserve MicroG, donc pose problème en termes de vie privée) et GrapheneOS (complètement déconnecté de Google), notamment via ce billet de Wonderfall qui attirait l’attention sur les dangers des roms du style Lineage imposant de garder le bootloader ouvert.
Je me suis donc décidé à passer à GrapheneOS. Mais…
Sommaire
- Avertissements
- Le look
- Préparation
- Installation
- Les applications de base
- Remplacer le Play store
- Pub, traqueurs et VPN
- Les mails
- Carnet d’adresse, agenda, notes…
- Les applications installées
- Les applis qui ne fonctionnent pas
Avertissements
- Si vous êtes un vrai geek, vous n’apprendrez rien ici (allez directement voir chez wonderfall). Je ne suis ni opposant Biélorusse, ni un vendeur d’armes, je ne considère pas avoir besoin d’une protection totale et c’est hors de mes compétences. Par contre je pense qu’un certain niveau de bidouillage est accessible à tout le monde et permet une sensibilisation à comment mieux protéger sa vie privée. D’ailleurs je fais des concessions comme on le lira plus loin.
- La ROM GrapheneOS ne s’installe que sur des Pixels. Pourquoi ? Parce que seuls ces smartphones permettent de débloquer le bootloader afin d’installer une ROM alternative, mais ensuite d’être rebloqués, ce qui est indispensable pour des raisons de sécurité. Cet aspect technique devrait être standardisé sur tous les Android.
Le look
Avant d’aller plus loin, je vous mets une image de mon écran. Le site de GrapheneOS est aussi attrayant qu'une porte de prison. Avant de commencer, j’avais peur que la ROM lui ressemble et c’est un peu le cas. Mais en moins d’une minute j’avais installé mon environnement habituel Lawnchair et Abstruct. Ce n’est ni très gamer, ni cyberpunk, chacun trouvera mesure à ses goûts. En fait GrapheneOS ne change pas radicalement d’AOSP/Android pur. Ça ressemble donc à Android sans surcouche.
Préparation
Commençons par faire le ménage et voyons ce qui est installé sur le smartphone que l’on quitte : près de 200 applications ! List My Apps dresse la liste et permet un export, par exemple en tableur ce qui va permettre de voir ce que l’on garde, ce que l’on remplace, ce que l’on jette.
Comme bon outil de vérification, on utilisera Exodus qui donne pour chaque application le nombre de trackers et de permissions. C’est déjà une manière de choisir ses applications.
Comme j’avais déjà une instance Nextcloud, j’y avais déjà installé mon carnet d’adresse et mon agenda (on y reviendra).
Pour remplacer Google Authenticator, j’ai pris Aegis. Sur un téléphone rooté, il permet de récupérer les données de celui de Google et de faire un backup. Si le smartphone n’est pas rooté, il faut le faire manuellement ou utiliser un script du type de celui que l’on trouve dans la Matt's code cave
Installation
Le billet de Wonderfall et la FAQ de GrapheneOS sont à lire en parallèle, ils m’ont servi de guide. Je suggère également d’installer (sur le PC) Element et de se brancher sur le canal GrapheneOS Off Topic, ou via le web, à l'espace Matrix Graphene Community. En cas de problème, la communauté y est très réactive.
Je lance Android, le pixel est neuf, je passe toutes les étapes proposées par Google, demande les accès développeurs, Enable OEM unlocking, etc. puis passe à l’installation via la page web qui est recommandée. Mettez votre système à jour, ouvrez un navigateur « propre », ne cliquez pas partout, suivez les instructions étape par étape, et c’est fait ! Je n’ai jamais vu une installation aussi simple d’une ROM alternative.
Les applications de base
Quelques applications de base sont installées : Vanadium (navigateur), Galerie, Appareil photo, Fichiers, PDF Viewer, Contacts, Calendrier, Calculatrice, un utilitaire de backup et Auditor qui permet (grâce à un autre Android) de valider l’intégrité du système d’exploitation.
Remplacer le Play store
Comme nous n’avons plus accès au Play Store de Google, nous allons installer F-Droid qui permet d’installer de nombreuses applications et (avec F-Droid) Aurora qui va remplacer Google Play. En principe, Aurora fonctionne de manière anonyme, mais cela semble en panne pour le moment. Donc, si l’on veut l’utiliser, il y a lieu d’y encoder son accès Google Play.
Pub, traqueurs et VPN
Plusieurs solutions coexistent pour s’affranchir des pubs & traqueurs
- Il y a, bien sûr, la possibilité de bloquer les pubs dans son navigateur, ce qui est effectué d’office par Bromite ou Brave. Mais cela ne va pas supprimer les éventuelles pubs ni surtout les traqueurs dans d’autres applications.
- Ma préférence va à personalDNSfilter en suivant le tuto de Sebsauvage. Petit problème : personalDNSfilter et mon VPN utilisent tous les deux la fonction VPN d’Android. En principe, un seul peut être actif à la fois. (Une version modifiée d’OpenVPN qui peut fonctionner de concert avec DNSFilter semble exister. J’ai un message d’erreur quand je veux l’utiliser). Donc, j’installe OpenVPN et passe de l’un à l’autre selon mes besoins.
- Plutôt que d’utiliser personalDNSfilter on peut modifier les DNS et passer par exemple par Adguard ou NextDNS dont l’application est d’une grande simplicité. Pour mieux comprendre, voir les explications chez Pixel de Tacking
- Mais ces deux solutions manquent d’élégance, donc à la prochaine échéance, je change de VPN et passe à un VPN qui fait également le filtrage des pubs et traqueurs. (IVPN, Incognet, Privateinternetaccess, Mullvad, surfshark.com, etc.) gageons que cela va peu à peu devenir la norme dans les offres VPN
- Les bidouilleurs trouveront chez wonderfall comment filtrer tout cela via son propre serveur.
Les mails
Pour les mails, outre Protonmail, j’utilisais déjà l’excellent FairEmail (page web), à soutenir, qui fonctionne très aisément pour les comptes classiques.
Maintenant, partons de l’idée que nous avons encore un ou plusieurs Gmail que l’on souhaite encore (provisoirement ?) utiliser. La FAQ de FairEmail est précise, plusieurs options sont possibles.
-
Une option peu sécurisée et non recommandée :
- allez dans votre compte Google et dans les options de sécurité, activez le paramètre « Autoriser les applications moins sécurisées » ;
- dans FairEmail encodez manuellement vos paramètres IMAP. Si nécessaire, vérifiez-les ici : paramètres IMAP & SMTP.
-
L’option recommandée qui va progressivement devenir obligatoire :
- dans votre compte Google (options de sécurité), activez la double authentification et ensuite demandez un mot de passe d’application ;
- dans FairEmail, prenez l’option de configuration manuelle d’un compte, encodez votre adresse mail et remplacez votre mot de passe habituel par le mot de passe d’application de 16 caractères que Google vous a fourni. Dans les paramètres, régler la boite « En continu ». C’est fait une fois pour toutes.
Carnet d’adresse, agenda, notes…
Je dispose d’espace serveur (Infomaniak) pour quelques applications que j’utilise chaque jour.
- Je commence par installer Nextcloud. Dans les paramètres, Nexcloud permet de télécharger DAVx⁵ à paramétrer ensuite pour synchroniser les contacts et l’agenda. Il y a également moyen d’utiliser DAVx⁵ pour se synchroniser directement sur l’agenda et le carnet d’adresse de Google (Voir ici).
- Après avoir paramétré DAVx⁵, l’application native de contact se synchronise, il en va de même pour l’agenda, néanmoins pour avoir le widget sur mon écran je mets Simple Calendar Pro.
- Je termine en installant NextcloudNotes, Tiny Tiny RSS pour suivre mes fils RSS et Shaarlier pour accéder à mes bookmarks Shaarli (encore merci Sebsauvage)
Les applications installées
Je reprends ci-dessous quelques applications installées pour bien montrer que l’on navigue dans un univers (presque) normal. Merci aux commentaires qui auront de meilleures suggestions d’applis :
- navigateurs : comme je passe parfois d’un navigateur à l’autre, j’ajoute Bromite et éventuellement Brave ;
- communication : Signal, Element, Mattermost Telegram, Zoom, Discord (M), Fedilab Lite et… WhatsApp car de nombreux contacts ne sont pas encore passés à Signal notamment car le son et/ou la vidéo restent souvent médiocres. Notons que le push de WhatsApp fonctionne sans Play Services et, si pour celui qui utilise très peu WhatsApp (quelques correspondants), il est toujours possible de le mettre sur un autre profil utilisateur (indépendant de celui du carnet d’adresse) ;
- son : Simple voice recorder et Music Player, AntenaPod, RadioDroid et Callrecorder ;
- video & image : Opencamera, VLC, Snapseed ;
- bureau : WordReference, MoonReader, Openscan ;
- utilitaires : QR Scanner, FindMyDevice, Ooni, Bitwarden, GadgetBridge, TotalCommander ;
- cartographie : Magic Earth et Osmand, Maps ;
- divers : Altimeter Loupe (App2U).
Les applis qui ne fonctionnent pas
Nous arrivons au hic… certaines applications ne fonctionnent pas car elles nécessitent MicroG. On retrouve sur Plexus celles qui s’en passent.
Je n’ai pas tout testé, par exemple les applis utilisées le temps d’un voyage. Mais hélas, certaines applications d’usage courant ne fonctionnent pas sans les services de Google : Bridgefy, Basecamp, Discourse, Waze. Gros problème pour Waze ; on a beau dire qu’Osmand est très bien quand on est dans un embouteillage, on a rarement vu mieux que Waze. Il faut que je teste Maps.
Certaines de ces applis fonctionneraient via Application Web (PWA), pas celles que j’ai testées.
# Lapin compris
Posté par bnurb . Évalué à 5.
C'est quoi les problèmes de vie privée MicroG?
[^] # Re: Lapin compris
Posté par Yth (Mastodon) . Évalué à 9.
Ça se connecte à Google.
Le plus petit élément des Google Apps c'est une API qui va entre autre permettre de regrouper tes notifications de multiples applications pour ne conserver qu'une seule connexion réseau active, et qui permet le push.
En gros, ton appli veut pusher une notification, elle se connecte à ce service chez google, qui permet de retrouver ton téléphone et de t'afficher la notification, mais tout ça sans que ton appli n'ait de connexion active avec ton téléphone.
L'intérêt est d'épargner ta connexion, qui peut coûter des sous, et d'économiser ta batterie : conserver une connexion réseau par application pour avoir en temps réel tes mails, tes chats divers, et autres, ça fait plein de connexions, et ça vide la batterie, parfois très vite si ton réseau est mauvais.
Et pas mal d'applis ne fonctionnent simplement pas avec une connexion directe et ne fonctionnent qu'à travers cette API pour envoyer des notifications.
L'intérêt est évident.
Par contre ça passe par Google, qui, même si les données elles-même peuvent ne pas transiter - le message push vers ton appli peut juste être un « ping : t'as des infos, va les chercher ! », et l'appli crée une connexion pour récupérer le message en lui-même sans passer par google - il y a toujours les metainfos, le fait que tu as reçus à telle heure une notification de telle application.
Par expérience : un téléphone sans aucune forme de Google Apps fonctionne très bien, mais sa batterie dure moins (pas beaucoup beaucoup, mais moins) si tu laisses le réseau activé.
Et certaines applis fonctionnent mal : la banque, ou des trucs de chat qui t'imposent de les activer manuellement régulièrement pour savoir ce qui se passe.
Moi, ça me va, je suis moins spammé en temps réel. Par contre j'ai un autre téléphone, pur wifi, avec des Gapps minimales, pour valider mes paiements bancaires, ou faire de l'authentification multi-facteur avec des outils corporate de l'employeur.
Voilà,
[^] # Re: Lapin compris
Posté par HL . Évalué à 4.
A moins que j'ai raté un truc, je suppose que s'il faut une connexion Internet à MicroG vers Google, c'est pour plus pour le « entre autres » que les notifications ?
Parce que là, je ne vois vraiment pas pourquoi une appli installée sur ton téléphone qui veut t'envoyer une notif sur ton téléphone (en local donc) a besoin de passer par Internet.
[^] # Re: Lapin compris
Posté par Elfir3 . Évalué à 3.
Je pense que par notification, il faut comprendre notification du service derrière l'appli (facebook) à l'application (messenger), pas de l'application à la zone de notification de ton téléphone.
[^] # Re: Lapin compris
Posté par Yth (Mastodon) . Évalué à 2.
Oui, c'est ça, il s'agit de notifications poussées par un service vers ton application.
Abus de langage, amalgame entre le serveur Whatsapp/Signal/blabla… et l'application installée sur ton téléphone.
[^] # Re: Lapin compris
Posté par bnurb . Évalué à 6.
Donc le probleme de viens pas de microG mais de l'appli qui ne respect pas la vie privée, en utilisant l'API "push" de google.
Dire que microG ne respect pas la vie priver me semble être un raccourcis fort regrettable, à la limite de la désinformation.
microG permet d'installer et d'utiliser les appli qui on une dépendance à Google Play Services, un daemon proprio mangeur de batterie et de vie privé.
Il me semble qu'a la base c'était juste un stub (Bouchon_(informatique) en bon Français) de l'API google.
Bref microG c'est bon, mangez-en!
[^] # Re: Lapin compris
Posté par Yth (Mastodon) . Évalué à 3.
Ah bon ?
Et pourquoi ce système de « broker » n'as-t-il pas une API libre ?
Pourquoi n'est-il-pas possible d'installer son propre serveur pour ça ?
Pourquoi ne peut-on pas configurer le téléphone pour utiliser un autre serveur que celui de Google ?
Pourquoi l'API ne permet-elle pas de spécifier aux services en dessous quel serveur de « broker » utiliser pour pouvoir avoir le sien, celui d'un Chatons, ou rester par choix ou commodité sur celui de Google ?
Le service rendu est là:
C'est un démon économiseur de batterie, et de bande passante, puisqu'il y a au mieux une seule connexion réseau pour toutes tes applications qui exploitent le push. Et c'est bien pour ça que ça existe.
Mais le respect de la vie privée ? Nope, désolé, s'il y avait ça, j'aurais la possibilité d'avoir la même chose en auto-hébergé, comme mes mails.
Le stub n'est pas nécessaire : je n'ai pas trouvé d'application qui ne fonctionnait pas en l'absence des services Google.
Par contre j'en ai trouvé pour lesquels certaines fonctionnalités n'existent bien qu'à travers les services Google, rendant en pratique l'appli inutilisable ou sérieusement bridée.
Pour d'autres il y a un fallback : par exemple Signal ou Conversation te gardent une notification active pour conserver une connexion réseau active (À noter que Conversation n'a pas le mode Google Apps, uniquement le mode notification et connexion active).
Et donc par exemple Signal respecte plus ta vie privée si tu n'as pas les Google Apps d'installées.
C'est donc bien un problème de vie privée, même si la qualité des application que tu installes est un autre problème de vie privée avec un potentiel bien plus énorme…
[^] # Re: Lapin compris
Posté par bnurb . Évalué à 5.
Rien ne te force à utiliser les push notifs sur microG, et microG ne se limite pas qu'a ça.
Si on va RTFM de GmsCore, un des composants de microG, et il est écrit pixel noir sur pixel blanc dans la liste des fritures:
«Opt-in», donc par défaut on est en «pas extend», après quelques recherches la version «pas extend» c'est:
Mais ça concerne uniquement
GmsCore, les autres composant commeUnifiedNlp(pour la localisation par antennes/point Wifi) marche très bien sans compte et sans serveur Googl€.Donc il est possible d'utiliser microG sans vendre son âme privée à Googl€. Il faut juste renoncer a une partie de l'API. Mais ça débloque déjà pas mal d'appli qui serait complètement inutilisable sinon (vague souvenir d'une espèce de popup sur des jeux qui te dit "Oulala t'as pas de play store on peut rien faire :(").
Je trouve que c'est respectueux de la vie privée. Mais tout dépend de l'usage qu'on en fait.
[^] # Re: Lapin compris
Posté par Wonderfall (site web personnel) . Évalué à 9. Dernière modification le 11 juin 2021 à 19:14.
microG est mauvaise implémentation des Play Services car nécessite du signature spoofing (moins un problème sur CalyxOS qui whitelist uniquement microG, mais quand même) et n'implémente pas correctement le modèle de sécurité pensé pour les API Play Services (exemple : pas de certificate pinning ou d'autres bonnes pratiques protégeant de MITMs).
microG a encore d'autres problèmes qui leur ont été reportés mais ils ont été peu réceptifs. Par bon sens, il faut donc la considérer comme une surface d'attaque supplémentaire, privilégiée dans l'OS qui plus est, ce qui n'a rien d'anodin (tout comme les Play Services propriétaires, au passage). On ne peut pas promettre de la vie privée sans notion de sécurité derrière pour la soutenir. Sans compter qu'avec microG, tu passes par les serveurs Google, tu envoies des données à Google ; et c'est normal, car c'est une implémentation qui fait exactement cela.
A savoir que GrapheneOS prévoit de développer une implémentation stub justement qui vise à rendre certaines applications compatibles en simulant que les serveurs Play Services sont down. Ce sera une implémentation minimale qui peut être activée et limitée à un user profile.
Enfin, chacun est libre d'utiliser microG, mais il convient de dire les choses clairement et d'éviter de faire une recommandation qui ne convient pas forcément à tout le monde. Il faut faire un choix éclairé : clairement, utiliser microG n'est pas sans conséquences. Et a priori le but de cette dépêche est d'expliquer simplement à tout le monde que oui, utiliser Android (vraiment) sans Google, c'est possible.
Ensuite, chacun mesure les sacrifices qu'il a à faire. Utiliser microG n'est pas une mauvaise chose en soi. Chacun est libre de ses choix, mais la vraie liberté de choix vient avec l'information.
[^] # Re: Lapin compris
Posté par fortytwo . Évalué à 4.
L'inscription du téléphone aux services Google est une option sur microg. Malheureusement, elle est cochée par défaut donc il est préférable si tu veux l'éviter de démarrer le téléphone sans réseau et de désactiver l'option avant d'activer le réseau.
Pourquoi microg sans accès à Google donc sans services Google effectifs ? Ne serait-ce que pour lancer certaines applications dépendant de Google. Au moins comme ça elles se croient connectées et se lancent sans râler.
[^] # Re: Lapin compris
Posté par Wonderfall (site web personnel) . Évalué à 2. Dernière modification le 12 juin 2021 à 02:18.
L'inscription aux services Googles ne suffit pas vraiment à déterminer si tu passes ou non par les serveurs Google. Si tu utilises microG, c'est que tu souhaites par exemple bénéficier d'une alternative à FCM (qui permet de délivrer les notifications push pour les apps sans fallback). Il n'y a pas vraiment de magie derrière, microG ne peut pas être considéré simplement comme "les services Google sans Google".
Ce que tu décris à la fin est plus ou moins ce que GrapheneOS compte développer, microG ne satisfaisant pas les critères (et crois-moi, le cas de microG a été longuement étudié). Comme je l'ai écrit, le but sera de faire une implémentation stub minimale qui fera croire aux applications que les services sont présents alors qu'en réalité la connexion aux API Play Services ne sera même pas programmée dans cette implémentation.
Pour résumer, microG nécessite un accès privilégié et d'être build dans l'OS pour fonctionner. C'est entre autres pour ça que microG n'est pas "simplement" une application qui peut être installée sur GrapheneOS pour qui le souhaite : c'est un ensemble privilégié. Donc c'est en réalité beaucoup plus complexe, et ça aurait été un enfer pour GrapheneOS de le supporter et de garantir sa sécurité. Avant qu'on me le dise : oui, GrapheneOS a tenté de travailler avec microG par le passé mais ils n'ont pas été réceptifs.
TL;DR : si tu utilises microG alors que tu ne veux pas utiliser les API Play Services (FCM et consort, soyons d'accord) dont microG implémente un sous-ensemble, il n'y a aucun sens d'avoir ce code privilégié dans ton OS. Il faut des solutions plus minimales, comme ce que GrapheneOS projette de développer. Ou alors, tu peux te passer complètement de tout ça, trouver des alternatives, contacter les développeurs pour faire des fallbacks à FCM. Mais rien n'est sans conséquence, il faut mesurer la portée de chaque chose.
Pour de plus amples discussions à ce sujet avec des développeurs et contributeurs, vous êtes les bienvenus sur les channels Matrix du projet. Je fais de mon mieux pour vous répondre.
[^] # Re: Lapin compris
Posté par gnumdk (site web personnel) . Évalué à 5.
Vu que y'a moins d'un an, il n'y avait qu'un développeur sur le projet et qu'il n'était plus du tout actif, je sais pas ce que veut dire non réceptif, tu as des liens ?
Ensuite simuler que les services sont down, c'est partir du principe suivant: l'application gère le code d'erreur et fonctionne quand même.
Dans la réalité, soit elle quittera en disant que le service n'est pas disponible soit elle plantera comme une grosse merde ;)
[^] # Re: Lapin compris
Posté par Wonderfall (site web personnel) . Évalué à 1.
Comme je l’ai dit, le channel Matrix est ouvert à tous. Tu peux poser la question, tu auras la même réponse. Pour les détails, tu peux consulter les logs Freenode (tant que c’est encore possible…).
Je n’ai jamais dit que cette implémentation minimale est magique. Elle pourrait juste aider quelques applications, mais ça ne remplace certainement pas FCM, SafetyNet ou toute la suite d’API Google. Nous sommes d’accord. Il faut tout simplement des fallbacks, des alternatives à ces services prévues par les développeurs ; ou bien des applications qui en font complètement l’impasse.
Dans les faits, pour utiliser des versions d’Android sans Play Services ou apparenté depuis des années, beaucoup d’applications même incompatibles sur le papier fonctionnent. J’en fais part en détails dans mon article dont le lien est dans la dépêche.
# pas sûr d'avoir bien compris.
Posté par jp.vitulli . Évalué à 8.
à quoi sert d'avoir un os sécurisé si c'est pour installer dessus whatsapp ou zoom ? il y a un moyen de les cantonner dans un bac à sable ou quelque chose du genre ?
et puis comment installe-t-on whatsapp sans google play ?
enfin bref, pas bien compris.
[^] # Re: pas sûr d'avoir bien compris.
Posté par Veehem . Évalué à 3.
Comme indiqué, l'idée c'est de passer progressivement à du plus sécurisé. Comme on est parfois obligé de conserver des app comme Zoom ou WhatsApp (on est bien d'accord, c'est pas l'idéal) on peut les installer via Aurora et oui, les faire fonctionner de manière séparée.
[^] # Re: pas sûr d'avoir bien compris.
Posté par eingrossfilou . Évalué à 6.
Ces applications hostiles, tu peux les isoler du reste des applications avec Shelter
https://linuxfr.org/users/bubar/journaux/f-droid-shelter-l-usage-du-profil-professionnel-android
[^] # Re: pas sûr d'avoir bien compris.
Posté par Veehem . Évalué à 2.
Sheltyer n'est qu'une fonctionnalité de confort et non d'isolation. Ca ne renforce pas la sandbox d'Android. Pour compartimenter, les user profiles (possibles sur GrapheneOS), sont plus efficaces car ils le font sur un stockage différent avec des clés de chiffrements différentes
[^] # Re: pas sûr d'avoir bien compris.
Posté par Maclag . Évalué à 5.
L’inconvénient de Shelter, c'est quand tu commences à avoir plusieurs applications problématiques pour la vie privée et que tu les fourres toutes dedans.
Comment savoir ce qu'elles apprennent les-unes des-autres (si je peux me permettre)?
J'utilise Lineage for MicroG, et j'ai expédié Whatsapp et Wechat sur Shelter. Je me demande toujours ce qu'elles échangent à travers les photos ou vidéo ou activité en général qui finiraient dans un cache quelque part.
[^] # Re: pas sûr d'avoir bien compris.
Posté par Yth (Mastodon) . Évalué à 8.
Whatsapp, Signal, Zoom, Discord, etc. fonctionnent sans Google Apps, sans Google Play, sans compte Google.
Cf mon post plus haut au niveau des notifications : l'expérience peut être différente, mais ça fonctionne.
Tu peux installer depuis f-droid une appli qui s'appelle Aurora Store et qui permet d'installer des applis depuis le Google Store.
Tu peux configurer ton compte Google si tu en as un, et récupérer ainsi des applications achetées.
Sinon tu peux l'utiliser de façon anonyme (avec un compte bidon mutualisé en fait), et installer des applications gratuites.
En fait, de manière générale, j'aurais tendance à recommander Aurora Store même quand le Play Store est présent : Aurora t'indique si l'application a des publicité ou non, et permet de filtrer sur ce point. Aussi si l'appli nécessite les Gapps ou pas (ce qui ne signifie pas qu'elles ne fonctionnent pas sans les Gapps, mais de façon légèrement différente).
Et aussi ça intègre les résultats d'analyse d'εxodus privacy, donc va t'indiquer le nombre de traqueurs, et lesquels (Google, FB, ou autres, et si chez google il y a juste un crashlytics ou tout l'analytics etles pubs, etc.)
Maintenant, installer ce genre d'appli sur un OS sécurisé, c'est ouvrir un trou consciemment dans sa vie privée et sa sécurité.
On peut dire que quitte à utiliser ce genre d'applis, autant le faire sur un téléphone pas trop pourrave, ça limite quand même un peu…
Par contre on « pourrait se contenter » d'un LineageOS, qui a l'énorme avantage de pas être bloaté par rapport à un Android constructeur de base.
# Google pixel
Posté par MookSkook . Évalué à 4. Dernière modification le 11 juin 2021 à 14:27.
Excellent article j'allais presque sauter à pied joint dans la démarche jusqu’au moment où je me rend compte qu'on ne peut même pas changer la batterie sur ces Google pixel. Du coup je comprends pas trop l'utilité, avoir un téléphone qui dure 2 ans voir 3 ?
[^] # Re: Google pixel
Posté par jyes . Évalué à 9.
C‘est pas un bogue, c’est une friture ! Ton téléphone meurt avant1 que le constructeur cesse de fournir les mises à jour de sécurité.
En fait même pas toujours avant, si tu achètes ton téléphone un peu trop tard par rapport à son pic de fashionitude, Google ne s’engage qu’à 18 mois à partir de la date de vente du dernier téléphone de ce modèle sur son magasin. En fait, par sécurité, il faudrait que GrapheneOS use ta batterie plus rapidement pour éviter ce problème. Je te suggère de soumettre un patch en ce sens. ↩
[^] # Re: Google pixel
Posté par Veehem . Évalué à 2.
Le Pixel 3 supporté est sorti en 2018, mais tu touches là un problème général d'obsolescence. J'ai eu un FairPhone: tu peux changer la batterie, mais c'est d'autres éléments qui ne suivent pas et qu'il n'y a pas moyen de changer. Mais de fait on avancerait déjà très bien en ayant que des smartphones avec batterie amovible et des boatloader qu'il y a moyen d'ouvrir ET de refermer aisément.
[^] # Re: Google pixel
Posté par jcr83 . Évalué à 2.
J'utilise un Nexus 4, acheté en 2012, et la charge dure encore presque une semaine. Donc ça peut durer beaucoup plus que 2 ou 3 ans …
[^] # Re: Google pixel
Posté par Maderios . Évalué à 1.
C'est ce que je croyais mais il faut faire la distinction entre "remplaçable" et "amovible".
Batterie de remplacement
https://fr.ifixit.com/Tutoriel/Remplacement+de+la+batterie+du+Google+Pixel+3a/124322
Poster une information ne signifie pas nécessairement adhésion
# la contradiction dans l'énoncé
Posté par NeoX . Évalué à 7.
se débarrasser de l'OS de Google et des Applis de Google,
pour installer sur une smartphone de marque Google ?
autant acheter un autre smartphone non ?
Bon y a plein de bonnes idées à prendre dans ce tuto quand meme, les stores alternatifs, les possibilités de CalDAVx5, etc
[^] # Re: la contradiction dans l'énoncé
Posté par Veehem . Évalué à 4.
Ben oui car comme dit plus haut, c'est (hélas pour le moment) les seuls dont il y a moyen d'ouvrir ET de fermer le bootloader. En termes de sécurité ca fait toute la différence
[^] # Re: la contradiction dans l'énoncé
Posté par jyes . Évalué à 9.
Faut pas en rajouter non plus. La seule sécurité que ça apporte en plus par rapport au stockage chiffré (par défaut dans presque toutes les déclinaisons d’Android) et une un ROM sans les services Google espions, c’est une protection contre l’injection de code malveillant sur ton téléphone via un accès physique. Je ne dis pas que c’est inutile, mais les premières menaces pour un utilisateur de téléphone mobile, c’est d’abord la fuite des données lors du vol (réglé par un stockage chiffré) ou la fuite de données par des applis espionnes (en ventre libre sur le Play Store). Le type d’attaque dont protège le verrouillage du bootloader est d’un niveau de complexité (et donc de détermination de l’attaquant) qui n’a rien à voir. La différence est là, je ne le nie pas, mais j’ai un problème avec le discours qui laisse entendre que tant que le bootloader n’est pas verrouillable, il n’y a pas de sécurité possible.
Contrairement à mon ordinateur de bureau (qui n’a pourtant même pas secure boot d’activité), j’ai mon téléphone à proximité presque en permanence, ce qui réduit de beaucoup la possibilité de me l’emprunter, y injecter le code malveillant et me le retourner sans que je m’en aperçoive. Quand je vois dans le journal qu’il suggère d’installer Zoom sur GrapheneOS, je me dis que le modèle d’attaque est mal étudié et qu’un Jisti sur LineageOS serait bien plus pertinent du point de vue de la sécurité, même si le bootloader est déverrouillé.
[^] # Re: la contradiction dans l'énoncé
Posté par Wonderfall (site web personnel) . Évalué à 5. Dernière modification le 12 juin 2021 à 14:25.
Il est bon de rappeler que la vérification d'intégrité au démarrage (permise par un bootloader verrouillé) n'est pas "juste" une protection contre les menaces physiques mais aussi une protection générale comme des formes de rootkits quelles qu'elles soient. C'est une mitigation importante pensée dans le modèle de sécurité d'Android, ce n'est pas quelque chose de GrapheneOS, mais c'est quelque chose dont les autres distributions d'Android sont négligentes (ou n'ont pas le choix, mais les Pixel offrent ce choix).
De plus, ce n'est qu'un avantage parmi d'autres des Pixel. Ne parlons pas encore de Titan M qui est bien plus avancé que TrustZone et j'en passe (heureusement, ça va évoluer pour les autres constructeurs avec Android Ready SE). Le sujet n'est pas le Google Pixel en particulier, certainement, mais c'est seulement l'un des critères qui en fait le support idéal actuellement, GrapheneOS n'étant pas attaché aux Pixel an particulier.
GrapheneOS ne se contente pas juste d'être une distribution d'AOSP conservatrice du modèle de sécurité d'Android. CalyxOS le fait déjà plus ou moins. GrapheneOS va encore plus loin : protection contre corruptions de la mémoire, pare-feu sans fuites pour chaque application, désactivation possible des capteurs, et j'en passe. Je t'invite à lire mon article qui a été partagé par l'auteur de cette dépêche.
Ces mesures concernent aussi bien la sécurité que la vie privée. Et comme je le répète souvent, la vie privée sans un certain degré de sécurité est illusoire : donc partir d'une baseline Pixel + GrapheneOS comme l'auteur le fait fait pleinement sens, pour ensuite développer ses nouvelles habitudes.
# Bootloader re-verrouillable
Posté par Astaoth . Évalué à 2. Dernière modification le 11 juin 2021 à 18:40.
Pour information, c'est également faisable sur les Fxtec, qui en plus ont un clavier physique. Comme quoi, les Pixels ne sont pas si seuls.
Euh, on trouve ca dans quelle édition de Donjon et Dragon ? Ou alors ca vient des Mondes des Ténèbres ? :D
J'ai pas pu résister ==> []
Emacs le fait depuis 30 ans.
[^] # Re: Bootloader re-verrouillable
Posté par Wonderfall (site web personnel) . Évalué à 5.
Alors non, ce n'est pas si simple. Le but n'est pas simplement de reverrouiller le bootloader (ce qui est déjà une partie de plaisir), mais d'avoir une implémentation de verified boot fonctionnelle par la suite. Pour ce faire, il doit être possible de pouvoir flasher des clés AVB custom, ce que malheureusement (mais heureusement que ça existe) seuls les Pixels supportent à l'heure actuelle.
Autrement, un bootloader verrouillé seul n'a pas forcément de sens, mais AVB le requiert, et là ça prend tout son sens. (C'est discuté page 2 de ton lien.)
[^] # Re: Bootloader re-verrouillable
Posté par Astaoth . Évalué à 3.
Ah je comprends mieux, je me disais bien que c'était étrange que pratiquement aucun autre smartphone permette de reverrouiller le bootloader, merci pour la précision.
Emacs le fait depuis 30 ans.
# Alternative à Waze et Osmand
Posté par Maclag . Évalué à 7.
Ce n'est pas Libre, mais ça utilise au moins OpenStreetMap.
C'est l'appli qui a été retenue pour /e/ me semble-t-il.
C'est Magic Earth.
Et gros plus: 0 traqueur détecté par Exodus!
[^] # Re: Alternative à Waze et Osmand
Posté par Veehem . Évalué à 1.
Oui, c'est pour cela que je l'ai indiqué dans les app installées. J'utilise plutôt Osmand pour les randonnées et Magic Earth (basé sur Osmand) en voiture. Mais pour ce qui est de la simplicité d'usage et de te sortir des embouteillages, je n'ai malheureusement pas trouvé d’alternative à Waze. Une question de temps peut-être
# Bootloader
Posté par Cyprien (site web personnel) . Évalué à 3.
Petite question : C'est quoi le problème avec un bootloader ouvert ?
[^] # Re: Bootloader
Posté par Wonderfall (site web personnel) . Évalué à 7.
Bonjour, j'ai partiellement répondu à cette question dans certains commentaires. Je me permets de plus ou moins le faire si ça ne dérange pas. :)
Entre autres, un bootloader déverrouillé permet à n'importe quel attaquant physique (on parle de simple "possession" du smartphone) d'exécuter des commandes privilégiées qu'il ne devrait pas pouvoir faire (fastboot et adb). Il permet par exemple d'installer un rookit (un malware persistant), de faire une copie des partitions (les effacer aussi, mais c'est "moins" grave), de pouvoir mener des attaques qui peuvent aller jusqu'à compromettre les données malgré le FDE/FBE (chiffrement de disque/profil). Ce n'est pas alarmiste, ce n'est même pas seulement à la portée d'un attaquant sophistiqué, c'est juste la pierre angulaire du modèle de sécurité mobile.
Android a également cette mitigation que l'on appelle verified boot, c'est la vérification d'intégrité au démarrage du firmware et de l'OS. Elle ne peut pas, par nature, fonctionner avec un bootloader déverrouillé. Elle permet non seulement de lutter contre des attaques physiques mais aussi à distance : les persistances peuvent être détectées, l'idée est de ne jamais démarrer un système compromis et dont il est impossible de retrouver l'état d'intégrité. Le verified boot n'est bien entendu pas propre à GrapheneOS, il est propre à Android mais la plupart des constructeurs en ont une mauvaise implémentation (pour ne pas dire qu'elle ne fonctionne pas). iOS l'a aussi, d'ailleurs.
En d'autres termes, le déverrouillage du bootloader doit être une étape temporaire uniquement lors de l'installation d'un OS custom. L'installateur WebUSB de GrapheneOS l'explique assez bien d'ailleurs, mais n'hésite pas à rechercher pour plus d'informations.
[^] # Re: Bootloader
Posté par Cyprien (site web personnel) . Évalué à 2.
Merci pour cette réponse détaillée !
# Merci
Posté par antistress (site web personnel) . Évalué à 3.
Merci pour ce complément aux dépêches précédentes
Attentions aux Pixel dont l'appareil s'appuie sur les logiciels privateurs Google.
Actuellement il y un contournement qui permet de se passer du logiciel de prise de photo privateur de Google mais il est à peu près certain que cela ne dure pas selon le dev.
# Relocker le bootloader alias mon téléphone est une brique
Posté par gnumdk (site web personnel) . Évalué à 3. Dernière modification le 14 juin 2021 à 15:10.
Salut,
Je vais peut être dire une bêtise mais de mes recherches sur XDA et discussion sur Telegram, GrapheneOS peut «relocker» le bootloader car son image a été signé par Google. Si il était possible de verrouiller le bootloader avec n'importe quel clé custom sur un Pixel, ce serait une catastrophe niveau sécurité: possibilité d'installer facilement un OS espion sans que ce soit visible pour l'utilisateur.
Attention quand même, une fois le bootloader «relocké», si tu fais une seul bêtise lors d'un sideload/maj et que tu ne peux plus accéder à GrapheneOS, tu peux jeter ton téléphone à la poubelle. Je n'ai pas vérifié mais tu peux peut être le récupérer sous Windows avec l'outil de de Qualcomm.
[^] # Re: Relocker le bootloader alias mon téléphone est une brique
Posté par Wonderfall (site web personnel) . Évalué à 2. Dernière modification le 14 juin 2021 à 19:55.
Ce n’est pas tout à fait ça. Sur les Google Pixel par exemple, l’autorisation du déverrouillage est contrôlée par un byte présent sur l’enclave sécurisée, typiquement le TEE (TrustZone) ou un élément sécurisé. Ces enclaves sont particulièrement isolées du reste du système, pour le dire simplement. Les appareils plus négligents stockent ce byte sur une partition, inutile de dire que ça ne protège pas vraiment.
Ce byte est contrôlé par le paramètre OEM unlocking dans les options de développeur sur Android. C’est en fait l’étape finale de l’installation de GrapheneOS ou encore CalyxOS sur Pixel, mais aussi l’étape initiale pour permettre de déverrouiller puis procéder à l’installation de ces images qui sont signées effectivement (mais pas forcément par Google). Pour que Android Verified Boot puisse fonctionner, il faut flasher en effet des clés customs, justement pour cette raison (signées par l’auteur de l’OS en question).
Une fois l’installation finie, on verrouille le bootloader puis on change le byte avec le paramètre OEM unlocking une fois dans Android. Concernant la crainte sur le problème de maj, comme expliqué dans mon article, il y a un système de double partitions au moment de la mise à jour. Au bout de X tentatives ratées, rollback vers la précédente version fonctionnelle.
[^] # Re: Relocker le bootloader alias mon téléphone est une brique
Posté par gnumdk (site web personnel) . Évalué à 1.
Ben du coup, ma crainte est vérifiée, on peut patcher un android pour y mettre un mouchard, le flasher sur un Pixel et reverrouiller le device. Du coup, l'usurpation n'est pas visible pour l'utilisateur.
Avec une autre marque, vu que tu peux pas reverrouiller, t'as un gros warning qui te dit que le device n'est safe et donc de ne rien stocker dessus.
[^] # Re: Relocker le bootloader alias mon téléphone est une brique
Posté par Wonderfall (site web personnel) . Évalué à 1. Dernière modification le 16 juin 2021 à 14:09.
Quoi ? C'est justement le rôle d'Android Verified Boot de prévenir ça.
https://source.android.com/security/verifiedboot
Ensuite pour déverrouiller le bootloader, il faut un accès à l'enclave sécurisée (cf. le post sur le byte OEM unlocking), bonne chance pour le faire sur un Pixel. Ensuite le fait de déverrouiller le bootloader supprime toutes les données, entre autres par une clé de dérivation utilisée en tant qu'input pour le FBE. Ce que tu décris n'est déjà pas possible, mais sera remarqué par l'utilisateur final (et pas qu'un peu !).
Je pense que tu te méprends totalement sur l'intérêt d'un bootloader verrouillé et d'AVB. Merci de ne pas écrire de la désinformation, il y en a déjà beaucoup trop sur la toile… :(
[^] # Re: Relocker le bootloader alias mon téléphone est une brique
Posté par gnumdk (site web personnel) . Évalué à 2.
Pas si c'est toi qui lui donne le téléphone (le bon argument du il ira plus vite après un reset)
# Waze sans service Google
Posté par Nibel . Évalué à 2.
En effet, Waze requiert bien les services Google et le signale par une popup quand on lance l'application sans les services Google. Mais quand j'avais encore mon GS3 sous LineageOS, l'application fonctionnait très bien sans… Je touchais "ok" et l'application fonctionnait comme si de rien n'était.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.