Installer GrapheneOS sur un ordiphone

Links per page: 20 50 100

page 1 / 1

Installer GrapheneOS sur un ordiphone
Problème

Mon Samsung Galaxy S3 acheté d’occasion en janvier 2023 a le même problème technique que son prédécesseur.

Nouveauté : après un énième redémarrage automatique, il ne démarre plus, il reste bloqué sur le bootloader, avant de donner la main au système.

Accès impossible au recovery (là encore, ça reste bloqué sur le bootloader). Pas moyen d’en reflasher un :
```
Session begun.

Downloading device’s PIT file...
ERROR: Failed to receive PIT file size!
ERROR: Failed to download PIT file!
Ending session...
ERROR: Failed to send end session packet!
Releasing device interface...
```
Sauvegarde

Vu que je l’utilise très très peu, je prête aucune attention à mon smartphone. À part mes contacts et la liste de mes applications, je ne sauvegarde volontairement rien (il n’y a rien d’utile). Néanmoins, ma dernière sauvegarde de mes contacts date de 2017, donc j’en ai perdu. Oups, j’ai été négligeant. Certains se retrouvent dans les emails (bien joué à ceux qui rappellent leurs coordonnées dans leur signature), mais ce n’est pas la majorité. Bref, ça peut t’arriver, pense à faire une sauvegarde de ton ordiphone (régulière, aussi exhaustive que désiré, vérifiée, etc.).

Choix d’un remplaçant

Aucune raison valable de partir une 3^e fois sur un Samsung Galaxy S3.

Mes besoins n’ont pas changé : SMS, GPS avec des cartes libres, téléphone, et accès de secours à Internet. Vu mon très faible usage, je veux un prix modeste. Même en échange d’un petit prix, et malgré mon faible usage d’un smartphone, je peine à envisager de renoncer à un système libre et/ou communautaire qui me donne le contrôle (autant que raisonnablement possible) et qui est raisonnablement respectueux de ma vie privée (c’est-à-dire sans Google à tous les étages ni les surcouches des principaux équipementiers).

En cas de système libre et/ou communautaire, je ne veux plus d’un système boiteux. D’abord, je veux un véritable approvisionnement : un cycle de développement (pas de la nightly en permanence), un téléchargement et une installation propres et sécurisées (c’est-à-dire pas des bouts non signés à récupérer à droite et à gauche sur des forums différents), etc. Ensuite, je ne veux plus des dysfonctionnements de mon système LineageOS : l’écran qui s’allume en permanence comme si j’avais touché l’ordiphone, le chiffrement du système qui ne marche pas, le Wi-Fi qui se rallume automatiquement (ce qui impose la mise en place de contournements), l’explorateur de fichiers qui affiche sans cesse une erreur « Hôte MTP a cessé de fonctionner », le transfert de fichiers sur USB en mode MTP qui ne fonctionne pas, le partage de connexion qui cafouille, l’impossibilité de me connecter aux points d’accès FreeWifi_secure, etc. Enfin, mon Galaxy S3 n’était plus pris en charge par LineageOS, donc j’étais bloqué en Android 7, donc j’aimerais avoir un système à jour afin d’éviter un maximum de failles de sécurité, même si c’est assez peu pertinent vu j’ai très peu d’applis et que je navigue sur le web uniquement en dernier recours.

Comme l’année dernière, j’ai eu la giga flemme de me farcir un comparatif des systèmes pour mobile existants et des smartphones avec lesquels ils sont compatibles. Donc j’ai sondé autour de moi. Les libristes et les défenseurs de la vie privée de mon entourage sont soit /e/ (/e/OS) sur Fairphone, soit GrapheneOS sur Google Pixel (de fait, c’est les seuls modèles compatibles).

Concernant Fairphone, je constate que le site web officiel est lourd (11 Mo, 138 requêtes) et qu’il fait télécharger un paquet de ressources web depuis des tiers. Pareil pour celui de LineageOS même si c’est pas mal moins. Ceux d’/e/ et de GrapheneOS sont totalement propres. Celui de GrapheneOS est même bien conçu (55 ko, 9 requêtes), ce qui inspire confiance sur le fait que le système est maîtrisé et qu’il ne sera pas surchargé de merdes. Vu que ça a été un sujet pour moi ces dernières années (voir, par ex. : 1, 2), ça fait des points en plus pour GrapheneOS et /e/.

Concernant /e/, le nom lui-même annonce des recherches web difficiles en cas de problème. Tout comme GrapheneOS, il est possible de l’installer via un navigateur web, ce qui en fait les deux systèmes les plus accessibles et aboutis (à mes yeux). /e/ est préinstallé sur les ordiphones de la société française Murena (mais leur prix de vente est au-dessus de ce que je suis prêt à débourser pour un smartphone) alors que GrapheneOS ne l’est pas.

Concernant GrapheneOS, comme /e/, le projet recourt à la licence MIT (libre) pour ses développements (je rappelle qu’il est très difficile de faire un système pour ordiphone totalement libre, système, pilotes, firmwares, applis, héritage des licences, etc.). J’observe surtout que GrapheneOS a pensé à beaucoup de choses en termes de vie privée et de sécurité : accorder ou non, via l'API standard des permissions d'Android, l’accès au réseau et aux capteurs à chaque appli (pratique contre une application indiscrète comme OSMAnd~ qui envoie un identifiant unique, désactivable dans ses préférences) ; possibilité de restreindre, via l’API des permissions, pour chaque appli, l’accès aux contacts et au stockage à un sous-ensemble (nom : contact / storage scope), pratique contre des applis indiscrètes comme Signal ; transparence totale et explications des connexions sortantes sur le réseau et leur minimisation (moins de données envoyées, pour SUPL, par ex. et serveurs proxy et cache maison pour les tests de connectivité, l’assistance au GPS ‒ A-GPS, SUPL, PSDS ‒, etc.) ; résolveur DNS de repli : Cloudflare au lieu de Google ; MAC aléatoire à chaque connexion Wi-Fi par défaut (au lieu d'une MAC par point d'accès avec un Android de base) ; redémarrage automatique en cas d’inactivité prolongée (18 h par défaut, ça se paramètre ou désactive) afin de compliquer l’accès au stockage (chiffré) ; code permettant d’effacer le stockage en faisant mine de saisir son code de déverrouillage ; possibilité d’installer les services Google Play et Google Play lui-même dans un profil dédié et/ou de ne pas les exécuter avec les privilèges globaux ; possibilité d’utiliser des applis qui exigent l’API Play Integrity pour vérifier l’intégrité d’un système mobile (et donc l’absence de root), comme les applis bancaires ; durcissement de la sécurité (adressage mémoire, chargement de code hors APK, chargement des applis, etc.) ; isolation raisonnable du réseau mobile ; etc. Je ne dis pas que c’est parfait, je dis que ça a été réfléchi, y compris le modèle de menace, les bonnes solutions aux problèmes et sans fausse promesse, donc ça inspire confiance. GrapheneOS a un cycle de développement (alpha, beta, release) et un vrai changelog dispo en RSS (celui d’/e/ est plus difficile à trouver, dans leur gitlab).

Clairement, /e/ et GrapheneOS se démarquent (sérieux, installateur web, site web pas merdique, etc.). GrapheneOS se démarque encore plus par ses fonctionnalités spécifiques (lire le paragraphe précédent) et sa documentation immédiatement mise en avant qui prodigue le niveau d’information technique que je recherche et qui révèle un état d’esprit / une réflexion / préoccupation sur les sujets qui m’intéressent (vie privée, sécurité). Je vais donc m’orienter vers GrapheneOS.

Vu que j’utilise très peu et le moins possible mon smartphone et que j’ai besoin de peu de fonctionnalités, j’ai également pensé à acheter le modèle d’ordiphone le moins cher disponible dans les grandes surfaces (Carrefour, Auchan, Darty, FNAC, etc.) ou chez les reconditionneurs (via BackMarket, Recommerce, etc.). J’ai identifié des modèles à 60-70 € TTC, pas moins, même chez les reconditionneurs. Évidemment, de tels smartphones ne sont pas pris en charge par /e/ ou GrapheneOS, et ils sont équipés d’une vieille version d’Android. Du coup, j’ai longuement hésité.

Vu mon très faible usage, le prix est un critère important. J’ai donc envisagé le reconditionné. Un Fairphone 3 reconditionné, c’est minimum 350 €, donc c’est non, d’autant que je ne crois ni à leur vertu (lire ici + je ne crois pas à l’existence d’une extraction vertueuse des minerais), ni à leur réparation facile. Un Google Pixel 6a (la 6^e est la gamme la plus ancienne encore maintenue par Google), c’est 205 € minimum, ça picote déjà bien assez (relativement à mon non-usage).

Au croisement de tous ces critères (flemme, système libre dégooglisé qui octroie un contrôle raisonnable, sérieux, mises à jour, prix), surtout de la grosse flemme de comparer ce qui existe, et aussi l’envie de découvrir quelque chose (ce qui exclut un Android constructeur ou LineageOS que je connais déjà), le Google Pixel 6a semble bien. J’avoue que la batterie inamovible m’a fait hésiter… Mais bon, quel autre modèle et avec quel système ? Aucune nouvelle version d’Android à partir de mi-2025 et plus de mise à jour de sécurité après mi-2027 (source). Le Pixel 7a aura des mises à jour de sécu jusqu’à mi-2028. Jusqu’à mi-2031 pour les 8a et la 9^e génération. Mais tout ça est hors de prix : 310 € le 7a reconditionné pour gagner un an de mise à jour, c’est non ; > 415 € le 8a reconditionné… Surtout, j’ignore la qualité et la durabilité des smartphones Google, donc le 6a jusqu’en 2027 laisse le temps de voir venir sans trop débourser.

J’ai donc choisi un Google Pixel 6a reconditionné pour y installer GrapheneOS. Ouais, j’ai choisi une voiture de course pour rouler en ville, et je n’en suis pas fier.

Achat et livraison

Reconditionné

J’ai choisi de recourir à un reconditionneur afin d’éviter les embrouilles d’un achat entre particuliers : absence de garantie ; sur Le Bon Coin, plein de revendeurs de Google Pixel ne veulent pas que le paiement s’effectue par l’intermédiaire du Bon Coin, ce qui est, pour moi comme pour d’autres, une alerte rouge ; il faut décrypter les sous-entendus des annonces pour comprendre l’état réel du smartphone ; etc.

J’ai comparé les principaux reconditionneurs et places de marché de reconditionneurs établis en France : BackMarket, Largo, YesYes, SMAAART, et Recommerce.

Il n’y a pas photo : BackMarket m’a permis de trouver le reconditionneur français le moins cher (à l’instant T), et pas qu'un peu, pour un Pixel 6a désimlocké. J’ai donc choisi BackMarket

J’ai choisi un Pixel 6a en « parfait état » à 219 € (dont 4 € de commission BackMarket) car l’écart de prix avec un état « correct » d’un autre colori (205 €) d’une part, et avec un « très bon état » (211 €) de même colori, d’autre part, était insignifiant. L’état « premium » m’a fait hésiter : je n’ai pas besoin d’une batterie pour un usage intensif (BackMarket annonce deux heures supplémentaires), mais les pièces originaires de Google m’ont attiré comme certitude d’avoir aucune embrouille avec GrapheneOS, puis je me suis dit que, si le système de Google fonctionnait sur des pièces non-Google, ce que je pourrais constater dès la réception du produit, GrapheneOS devrait fonctionner, il n’y a pas de raison. L’important écart de prix entre « parfait état », 215 €, donc, et « premium », entre 250 € et 317 € en fonction de la couleur de la coque, ne se justifie pas à mes yeux.

J’ai choisi un revendeur français (BackMarket n’est qu’une place de marché) afin d’éviter les complications transfrontalières si jamais je devais faire intervenir la DGCCRF. De plus, il n’était pas plus cher que des revendeurs allemand ou britanniques.

Ma vie privée s’est envolée durant ma commande : impossible de terminer une commande sans désactiver uBlock origin, NoScript, Smart Referer, etc. Back Market est conçu avec le cul : 10 Mo, 142 requêtes, trouzemilles ressources web téléchargées depuis trouzemilles tiers, etc., ce n’est pas sérieux (et ça, c’est en refusant tous les cookies).

D’après un ami, après commande, BackMarket va envoyer des spams relous. Dans l’email confirmant l’achat, je lis « Nous vous recontacterons d’ici quelques jours pour un rapide sondage à propos de votre achat. ». Donc, oui, ça craint. Et, en effet, la semaine suivant mon achat, j’ai reçu deux emails dont l’un avec un sujet étrange (« On veut des nouvelles de votre Google Pixel 6a 128GB - Negro - Libre. » ‒ negro et libre au lieu de noir et débloqué ‒), Dans mon espace client, j’ai trouvé aucune option pour m’opposer à ça. Heureusement, j’ai utilisé une adresse emails contenant une étiquette que j’invaliderai après réception de ma commande. Et je vais clôturer rapido mon compte (mais il faut envoyer un email au motif qu’une commande serait en cours ou que mon porte-monnaie serait en crédit ou…). Évidemment, les emails contiennent des liens et des images de traçage sans recueil du consentement et le bandeau cookies n’est pas conforme au RGPD (taille, type et couleur différenciés pour le bouton de refus).

Le ton fun, guignol et infantilisant m’a bien bien gonflé et navré : « Vous êtes fatigués ? On-n’est-pas-fatigués ! », dans le formulaire de connexion : « Qui va là ? » - « C’est moi », « Hourra ! Votre achat est confirmé. », « Cet email a été écrit et envoyé avec ♥ depuis un ordinateur reconditionné. », « Bonne nouvelle ! Votre commande est prête à être expédiée », « C’est vrai, quelque chose de spécial est en route. Il semble que votre commande devrait arriver le XX », « Tout le monde à son poste, c’est pour aujourd’hui », etc. Je pensais que le summum figurait sur le bon de commande : « Quelle belle journée, votre commande XXXX expédiée par YYYY vient d’arriver ! En plus, c’est un choix judicieux, autant pour vous que pour la planète. Mais ça ne nous étonne pas de vous. ». Il n’y a rien qui va, genre j’ai sauvé la planète en achetant une merde technologique reconditionnée, mais bien sûûûûr… Mais en fait, l’email pour recueillir un avis après réception de la commande est tout aussi navrant : « Dans l’espoir que les nouvelles soient aussi bonnes que possible, je vous prie de croire en mes sentiments les plus etc, etc. Forza ! ». Ce monde dans lequel tout doit être « good vibes » me donne envie de gerber. Aucun problème ne se résout ainsi. J’ai vraiment l’impression de vivre dans une société de profonds attardés dans laquelle on n’arrive plus à penser, précisément car c’est inconfortable. Ça me terrifie.

ÉDIT DU 01/11/2024 À 15 H 15 : après mon achat, une première connaissance m’a informé que la qualité n’est souvent pas au rendez-vous en passant par BackMarket genre batterie gonflée. Ce témoignage n’était pas qualifié ni de première main et cette connaissance ignorait que BackMarket n’est qu’une place de marché, donc j’avais choisi de ne pas intégrer son retour dans cet article. Après sa publication, une deuxième connaissance m’a remonté un problème de qualité avec BackMarket. Elle gère la téléphonie fixe et mobile de son employeur, donc elle raisonne en volume. Son employeur est souvent obligé de renvoyer les smartphones reçus indirectement via BackMarket (écran décollé, micro HS, pièces internes désolidarisées, etc.). J’ai donc eu de la chance… FIN DE L’ÉDIT DU 01/11/2024 À 15 H 15.

UPS = escrocs

Le livreur choisi par le reconditionneur est UPS.

Comme tous les autres transporteurs, UPS n’a pas accompli sa prestation.

Je passe sur le suivi web qui annonce un jour, puis reporte d’un jour, puis annonce 9 h 30 - 13 h 30, puis, alors que la tournée a commencé à 9 h 45 et qu’il y a au moins une heure de route depuis le dépôt, annonce 9 h - 11 h. Au final, livraison à 11 h 40.

Comme d’habitude quand j’attends un colis, je passe mon temps à presser F5. Soudainement, je lis « Votre colis n’a pas pu être livré. Il est en chemin vers un UPS Access Point™ sécurisé […] ». Le livreur n’a pas sonné, et il n’est pas passé dans la rue, j’en suis raisonnablement très sûr puisque j’avais ma fenêtre ouverte et que je regardais en permanence (sauf quand je faisais F5 sur le suivi UPS).

UPS pourrait se défendre que, lors de la commande sur BackMarket, j’ai saisi un numéro de téléphone invalide. Mais, d’une part, je n’ai pas de téléphone, c’est l’objet du colis, et, d’autre part, c’est une donnée à caractère personnel qui n’est pas strictement nécessaire à la livraison (si le livreur avait fait son taff et était venu, il m’aurait trouvé sans difficulté) donc je suis toujours réticent à la communiquer.

En bas du suivi web, UPS m’indiquait un magasin situé précisément à 157 mètres de chez moi (par la route). (Mais le livreur n’a pas pu se déplacer jusque-là !) Vu que le colis était « en chemin », j’ai foncé là-bas, et je suis tombé sur le livreur.

Déjà, camion pas aux couleurs ni logo d’UPS. Idem pour la tenue du livreur. Je ne suis pas tatillon sur la tenue, mais quand on œuvre dans la relation client, il faut être identifiable.

Je récupère mon colis auprès du point relai. Il ne me fait pas signer alors que le suivi consignait « signature obligatoire ».

Je dialogue avec le livreur UPS, désigné par le tenancier du relai, avec mon colis en main : « ‒ Bonjour, vous êtes le livreur UPS ? ; ‒ Oui ; ‒ Vous auriez pu venir à mon domicile, quand même ; ‒ Oui, je sais, désolé ». Évidemment, il m’a dit ça avec un grand sourire provoquant me signifiant qu’il se fiche de moi.

Je souhaite signaler le problème à UPS. Je rappelle aux naïfs que j’ai payé indirectement ce service (livraison gratuite ne veut pas dire que ce n’est pas répercuté sur le prix du produit).

Évidemment, pour accéder au formulaire de réclamation, il faut créer un compte. Tout comme BackMarket, le site web d’UPS est codé avec le cul, ça dégueule de ressources web téléchargées à droite et à gauche, etc. Mention spéciale au formulaire qui ne valide l’identifiant, saisi sur l’écran précédent, qu’après la validation des CGV sur l’écran suivant, un régal. Évidemment, le formulaire de réclamation, limité aux cas de colis perdu ou endommagé, ne permet pas de saisir du texte libre pour décrire son problème.

Je finis par trouver le formulaire de contact (nommé « Envoyer un e-mail à UPS »). Bien entendu, il m’oblige à saisir un numéro de téléphone (pour un formulaire nommé « Envoyer un e-mail à UPS », hein). Évidemment, les rubriques les plus appropriées, comme « Réception d’un colis », obligent à choisir des sous-rubriques qui ne correspondent pas au problème. Reste la rubrique « Généralités » dont tu sens bien qu’elle sera lue par Dave Null (on dit « IA » de nos jours). UPS propose un champ texte de 500 caractères. Grand seigneur ! C’est vrai que ça coûte cher, les caractères, il faut plus de lutins du Ternet pour les transporter.

J’ai donc envoyé à UPS le message suivant :

Livreur pas venu à mon domicile. Colis livré à mon insu dans un Access Point à 150 mètres de chez moi. J’ai échangé avec le livreur : "- Bonjour, vous êtes le livreur UPS ? ; - Oui ; - Vous auriez pu venir à mon domicile, quand même ; - Oui, je sais, désolé ;" avec un grand sourire provoquant me signifiant qu’il se fiche de moi. Pas professionnel.
Livreur et camion pas aux couleurs d’UPS. Pas pro.
Signature pas demandée.

Je suis très insatisfait. UPS = escroc. Choisissez mieux vos prestataires.

UPS s’engage à répondre sous un jour ouvrable. Le lendemain matin, j’ai reçu :

Bonjour Monsieur <CENSURE>,

Je vous remercie pour votre e-mail, je m’excuse au nom d’UPS pour le retard causé et la gêne occasionnée.
Pour le comportement de chauffeur, je vais passer ces informations à mon supérieur.

Notre système m’indique que vous avez retiré votre colis au point relais indiqué le <CENSURE> à <CENSURE>.

Bien cordialement,

<CENSURE>
UPS Service Clientèle

Bref, une réponse inutile, à moitié à côté de la plaque et à moitié type, et qui ne fera rien avancer.

Déballage

Le reconditionneur ne m’a pas entourloupé : l’état du smartphone est excellent à part quelques micro-éclats sur deux des tranches et quelques rayures sur la coque arrière, ce qui correspond bien au « parfait état » annoncé. Je suis favorablement impressionné.

Première mise en service

Avant d’installer GrapheneOS, je veux tester que l’ordiphone est fonctionnel. Sinon, il sera impossible de désigner la source d’un dysfonctionnement (GrapheneOS ? Matériel ?).

Raboter la SIM

L’emplacement pour la carte SIM s’ouvre avec un outil dédié… ou un trombone.

Ensuite, il faut loger la SIM dans le tiroir retiré de l’emplacement. Il faut une carte SIM au format nano (uniquement la puce) et j’en ai une au format micro (la puce et du plastique inutile autour)… Que c’est relou…

J’avais lu sur le web qu’il est possible de redimensionner soi-même sa SIM, sans en commander une nouvelle auprès de son opérateur téléphonique. D’ailleurs, les opérateurs mobiles envoient une SIM pré-découpée selon plusieurs formats.

J’ai découpé, avec un couteau mais ça se ferait tout aussi bien avec un cutter, le plastique superflu autour de la puce afin de ne laisser qu’elle. Mais ça ne suffisait pas, la SIM n’entrait pas dans le tiroir donc impossible de l’insérer dans le smartphone.

En fait, il ne faut pas avoir peur de rogner sur la prétendue puce (le truc doré). J’y suis allé en grattant, au couteau, trois des côtés de la SIM. Petit à petit, en testant souvent. Ne pas oublier de couper en diagonal l’angle qui doit l’être. Évidemment, je n’avais pas mémorisé quel angle de la SIM était coupé en diagonal. Pour le savoir, on peut regarder le sens d’insertion de la puce (et sa "décoration") dans n’importe quel tuto, comme celui-ci.

Premier démarrage, bonne surprise et mauvaises surprises

Évidemment, mon Samsung Galaxy S3 avait un port microUSB, alors que le Google Pixel 6a a un port USB type C… Reloouu… Merci au reconditionneur d’avoir fourni le câble et le chargeur (BackMarket affichait que seul le câble serait fourni).

Le smartphone démarre. Il me demande le code PIN de ma SIM et l’accepte. Il s’enregistre sur le réseau de mon opérateur mobile. Je peux passer un appel téléphonique à la messagerie vocale de mon opérateur. Je peux envoyer à un SMS à mon opérateur pour obtenir le suivi de ma consommation. Donc carte SIM, téléphone et SMS OK (malgré un redimensionnement peu précis et soigneux de la SIM).

Tester le GPS avec Maps : OK.

Ho, un SMS de Free mobile m’informant que mon hors forfait sur le service Internet dépasse 10 €. Hé oui, Google a téléchargé 260 Mo de mises à jour sur mon forfait 50 Mo (2 €). Pourtant, je n’ai jamais répondu favorablement à sa notification, mais bon, une multinationale, et plus généralement une personne morale, et le consentement, ça fait trouzemille. J’ai coupé les données mobiles pour stopper l’hémorragie… Au moins, cela a testé spontanément l’Internet mobile.

Wi-Fi OK.

Bref, ce smartphone est fonctionnel pour les usages que j’attends de lui.

Forcément, c’est l’explosion de notifications originaires de Google : terminer l’installation de mon Pixel (copier les données depuis un autre smartphone, créer un compte gogole, choisir le navigateur web et le moteur de recherche, saisir un code de verrouillage de l’écran ou utiliser mes empreintes digitales pour ce faire ‒ le capteur est situé dans l’écran ‒), installer des logiciels additionnels sauce Google (bien que j’ai décoché chaque logiciel proposé, je constaterai plus tard qu’il m’en a quand même installé… Google et le consentement, toujours…), mise à jour, régler l’« Ad Privacy » (on dirait la version mobile de la Privacy Sandbox, genre sujet ‒ topic ‒ des pubs, etc.), « learn more on parental control », « Pixel tips », etc. Relou bien comme il faut.

Truc rigolo : dans Settings, Security & privacy, More security & privacy, Encryption & Credentials, « Encrypt phone » dit « Encrypted » et rien ne permet de le désactiver. Le chiffrement du stockage (y compris le système) est obligatoire depuis Android 10, ce qui est une très bonne chose. Pourtant, je n’ai pas encore verrouillé mon smartphone avec un code ou avec mon empreinte, ce qui signifie qu’il existe une clé de chiffrement par défaut. En tout cas, c’était le cas avant.

L’absence des boutons (retour au bureau, liste des applis ouvertes, et retour arrière) me paume. En l’absence de boutons physiques sur un Pixel 6a, on peut faire revenir ces boutons sous forme virtuelle.

Trololo winwin, vraiment ?

Quand j’étions jeune, on rigolait bien sur le compte de Microsoft winwin (à partir de winwin 7), notamment dans les milieux libristes : comment un système peut-il occuper 20 Go ?!

De base, l’Android sauce Google installé sur mon ordiphone occupe… 20 Go. Lala. (Je rappelle qu’Android est généralisé, première place sur le marché des sytèmes mobiles en termes de part de marché.)

De même, on rigolait des mises à jour de winwin : plutôt que de les soumettre à validation d’un bloc et de les ordonnancer lui-même, winwin proposait des mises à jour, puis il imposait le redémarrage, puis il proposait de nouvelles mises à jour, redémarrage, etc.

Android m’a proposé une mise à jour de 659 Mo, puis un redémarrage, puis une màj de 32 Mo puis un redémarrage.

C’est beau, le progrès.

Entendre la sonnerie et le son d’un appel dans des prothèses auditives

Avant d’installer GrapheneOS, j’ai voulu tester une fonctionnalité d’Android.

Quand j’étions un gosse, on pouvait transmettre le son de la TV dans des prothèses auditives, mais il fallait un boîtier intermédiaire. Idem après la généralisation des ordiphones.

Lors du dernier renouvellement de mes prothèses auditives, vu leur coût, j’avais demandé à mon audioprothésiste si les équipementiers ont progressé sur le sujet, c’est-à-dire si l’on fait mieux de nos jours qu’un boîtier intermédiaire. Réponse positive : un smartphone peut directement transmettre du son (sonnerie, appel téléphonique, musique) auxdites prothèses. Bon, évidemment, il faut un système mobile récent, tout ça.

Mes recherches sur le web m’avaient amené vers le Bluetooth et ASHA (Audio Streaming for Hearing Aids) disponible depuis Android 10. Mon LineageOS étant un Android 7 bricolé, c’était même pas en rêve.

Mon Pixel 6a étant doté d’un Android 14, ça se tente.

L’équipementier propose un site web pour tester la compatibilité de son téléphone. Je scanne le QR code (brrrr je déteste ça, absence de sécurité, tout ça). Il me dit que mon téléphone est compatible avec son application et aussi avec le « streaming audio direct vers les aides auditives Rextin Bicore » (note bien, ça aura son importance : « Bicore »). Pourtant, on notera que le texte en dessous mentionne le Pixel 6, mais pas les 6a et 6 pro alors qu’il référence les 7 / 7a / 7 pro. Bref, documentation contradictoire, comme bien souvent.

Je lis la documentation de Google. J’observe qu’il existe plusieurs normes et que les anciennes générations de Pixel ne prennent pas en charge la plus récente. Je vais donc dans Settings, Accessibility, Hearing devices, j’active « Hearing aid compatibility, et après quelques efforts, j’arrive à appairer mes prothèses en Bluetooth, y compris en validant « Also allow access to contacts and call history ? Info will be used for call announcements and more ». Je constate l’effectivité de l’appairage dans le « menu » Bluetooth standard d’Android. Mais elles n’apparaissent pas dans le menu Hearing Devices, sous-rubrique « Available hearing devices ». Et forcément, ça ne fonctionne pas lors d’un appel téléphonique, même en activant l’option dans l’application téléphone.

Je me décide à installer l’application de l’équipementier. Évidemment, elle n’est distribuée que dans les magasins d’applications de Google et d’Apple. Évidemment, le magasin d’applications de Google nécessite la création d’un compte Google, ce que je fais à reculons (on notera que, contrairement à la version web qui demande de valider la création par SMS, là, que dalle, et on rigolera que le si avant-gardiste Google accepte « toortoor75 » comme mot de passe…). Je télécharge l’application. (J’apprendrai plus tard que j’aurai pu utiliser Aurora, un client alternatif et sans compte pour Play.) J’appaire à nouveau mes prothèses via l’application. Je peux les piloter et changer quelques paramètres depuis l’application. Mais toujours pas de transmission de la sonnerie et du son lors d’un appel. Je ne suis pas surpris, le paragraphe précédent montre que, intuitivement, l’audio n’a rien à voir avec l’appli, c’est plus bas dans le système. Bref, application mobile inutile, comme trop souvent.

À l’aide de leur facture, je trouve la fiche produit de mon modèle exact d’aides auditives. Dans les fonctions, je lis « Direct audio streaming / Made for iPhone : •/• ». « • » signifie « équipement standard » (c’est-à-dire pas optionnel). « Made for iPhone » est clair. En revanche, le slash doit-il être compris comme « la fonction Direct audio streaming aussi nommée Made for iPhone » ou bien comme « fonction Direct audio streaming et fonction Made for iPhone » ? Le double rond me fait pencher pour le deuxième cas. Mais un site web expose le contraire.

Je trouve aucun moyen évident de contacter l’équipementier. Je téléphone à la secrétaire-assistante de mon audioprothésiste, lui invente que je dispose d’un smartphone compatible seulement pour aujourd’hui, et lui demande si elle peut me mettre en relation avec l’équipementier. Elle pine pas trop, il faudrait prendre rendez-vous mais c’est pas avant longtemps, blablabla, elle est débordée, elle me rappelle.

Je poursuis mes recherches sur le web. Elles m’amènent au distributeur français exclusif de la marque de mes prothèses : Biotone. (C’est d’ailleurs de ce site que provient la fiche produit de mes aides auditifs sus-pointée.) Aucun moyen de contact rapide (seulement un formulaire web). Mais avec un Google dork et en supposant que la société est située en Île-de-France (ce qu’on peut vérifier dans le registre des sociétés), « site:biotone.fr filetype:pdf "01" », je trouve un numéro.

Je téléphone, j’expose immédiatement que je ne suis pas un professionnel et sollicite la bienveillance. Mon interlocutrice me précise que oui, cette ligne n’est que pour les pros normalement, qu’elle ne sait pas me répondre, mais qu’elle va me mettre en relation avec un collègue susceptible de savoir. À nouveau, je lui précise que je ne suis pas un pro, il me répète que c’est uniquement pour les pros normalement mais accepte d’écouter ma question. Premier point, mon smartphone. Ha, officiellement le Pixel 6a n’est pas pris en charge, seulement les 6 et 6 Pro, le test de compatibilité devait préciser cela en petits caractères (non). Deuxième point, le modèle de mes aides auditives. Aussitôt, il me dit que ce modèle n’est pas compatible. Il n’est compatible qu’avec les produits Apple. C’est donc ce que veut dire la fiche produit ? Oui. Seule la gamme Bicore est compatible Android (en effet, une fiche produit mentionne « Made for iPhone / Android version 10 or higher (ASHA) »). Mais un boîtier intermédiaire, le Smart Mic, peut s’intercaler entre un smartphone Android et des prothèses auditives.

Fin de partie pour moi. Leçon à tous ceux qui pensent que le progrès technique est permanent, blablabla : rien n’a changé en plus de quinze ans.

Aides auditives, Bluetooth et vie privée

L’appairage entre un smartphone et les aides auditives se fait au démarrage de celles-ci. La marque de l’équipementier est alors diffusée par Bluetooth. L’adresse MAC change à chaque redémarrage des prothèses (et même plus fréquemment, j’vais y revenir). Durant l’appairage, elles communiquent une adresse MAC stable (reconnaissable par son OUI réservé par et pour l’équipementier). (Évidemment, le trafic échangé entre un smartphone et cette MAC finale sera visible et pourra être capturé.)

Après l’appairage, durant les connexions, les prothèses communiquent leur vrai nom. Dans mon cas : « Aides aud. de Guil… » (ce n’est pas moi qui tronque).

Après quelques minutes, la marque n’est plus diffusée par Bluetooth, et l’adresse MAC change régulièrement. Un ordi (ou autre) qui fut appairé peut toujours se connecter (sans appariement préalable) aux MAC temporaires et donc obtenir le vrai nom et le niveau de la pile. Un ordinateur qui n’a jamais été appairé voit les MAC mais ne peut pas s’y connecter. Dans les deux cas, aucun appairage possible.

Pour mettre en exergue tout cela, j’ai utilisé blueman (paquet du même nom dans Debian bookworm) et son applet pour Mate ainsi que bluetoothctl (paquet Debian bluez) et rfkill (paquet Debian du même nom) : rfkill unblock bluetooth ; bluetoothctl power on ; bluetoothctl scan on ; bluetoothctl pair <MAC> ; bluetoothctl connect <MAC> ; bluetoothctl disconnect <MAC> ; bluetoothctl power off ; rfkill block bluetooth ; etc.

Attention lors des tests : il semble y avoir de la mise en cache à plusieurs endroits (interface graphique Android, blueman / bluetoothctl, mémorisation des appairages passés côté aides auditives, etc.), donc il faut être très rigoureux et prudent avant de tirer des conclusions.

Récupérer l’apk d’une application installée

Sur mon système définitif, je ne veux pas de Google et encore moins de compte Google (quand bien même GrapheneOS permet de l’isoler dans un profil dédié). Je souhaite donc récupérer l’apk de l’application de l’équipementier de mes prothèses auditives, juste au cas où. Je précise qu’elle n’est pas disponible sur APKMirror et consorts (et que, de toute façon, je n’ai plus envie de récupérer des logiciels depuis ce genre de source). Bien entendu, j’imagine que l’appli exigera les Google Play services ou autre, mais bon, ça coûte rien d’essayer de la récupérer.

Il y a plein de tutos pour ce faire. Celui-ci, par exemple.

En résumé, d’abord on active le débogage USB : Settings, About phone, appuyer sept fois sur « Build number » puis aller dans Settings, System, Developer options, USB debugging. Sur l’ordi, installer adb (paquet du même nom dans les dépôts officiels Debian). Raccorder le smartphone à l’ordi en USB. Les appairer (adb devices pour vérifier).

Ensuite, adb shell pm list packages -3 -f pour lister les logiciels (applis) installés et le chemin vers leur apk.

Enfin, adb pull /data/app/~~dJpAmpUN13iBNO3XVs7pfQ==/com.connexx.rta-IcUvWS5wxd-GLzdhYZ4lfg==/base.apk pour récupérer l’apk.

Installer GrapheneOS

Il suffit de suivre l’installateur web. Je vais consigner quelques remarques.

Je ne comprends pas le pré-requis de 32 Go d’espace de stockage libre sur l’ordi compte-tenu que l’image téléchargée occupe 1,5 Go (et que le système installé en occupe environ 10 Go). En tout cas, j’avais libéré 45 Go et octroyé 4 Go de RAM à mon tmpfs monté sur /tmp. Il me restait donc plus de 16 Go de RAM.

Mon ordi portable n’a pas de port USB à l’arrière, uniquement sur les côtés. Peu importe le port USB que j’utilise, le smartphone est toujours raccordé au même port / hub dans lsusb. En revanche, si je branche un disque dur USB 3 à mon ordi, avec certains ports, il tombe sur le même port / hub et il est limité à 480 mégas, mais avec d’autres, il apparaît alors sur un hub 5 gigas et il transfère à 5 Gbps. Quelque chose m’échappe à ce stade. Néanmoins, j’ai branché mon Pixel 6a à ces ports USB qui peuvent monter à 5 gbps.

Sur mon ordi, j’utilise un système Debian GNU/Linux bookworm (version stable actuelle).

Je suis déçu de constater que Firefox n’implémente pas WebUSB. J’ai donc le choix entre Chrome, Edge, Brave et Chromium… Ça illustre le triste état oligopolistique dans lequel le secteur des navigateurs web se trouve. J’ai choisi Chromium. J’utilise un profil de base (aucune extension, paramètres par défaut). Attention : avec Chromium 130 empaqueté dans Debian bookworm, le flashage échouera avec l’erreur « Error: You need to download a release first! ». Télécharger Chromium étant une vraie plaie, j’ai utilisé ces scripts pour ce faire. Le flashage a fonctionné avec Chromium vanilla version 132. Vu le faible écart de version, je pense que Debian doit activer un paramètre qui sème la zizanie, comme restreindre l’espace de stockage afin de préserver la vie privée en brouillant la prise d’empreinte.

J’ai bien mis à jour mon ordiphone, à l’exception d’Android 15, car j’avais peur que ça bloque l’accès à GrapheneOS. Je suis en Android 14, mise à jour de sécurité du 05/09/2024.

Je n’ai pas le service fwupd sur mon ordi et le paquet logiciel censé le contenir, fwupd n’est pas installé.

Le téléchargement de GrapheneOS est plutôt rapide, 5 mo/s, ça va.

L’installation de GrapheneOS se passe bien avec Chomium 132 non empaqueté dans Debian.

Premier démarrage de GrapheneOS

Huhuhu le gros avertissement indiquant la présence d’un autre système que le système Android sauce Google. Cela fait perdre du temps alors que le système Android de Google démarre super rapidement (je le calcule entre l’appui sur le bouton marche/arrêt et l’arrivée sur l’écran de verrouillage et la demande du code PIN de la SIM).

L’assistant de configuration de GrapheneOS est classique : choix de la langue, connexion au Wi-Fi, choix du fuseau horaire, accorder la permission de chercher la localisation, code de verrouillage de l’écran (ou empreinte digitale), restaurer les applis et les données, tutoriel pour apprendre les gestes pour se diriger dans l’interface graphique (je rappelle qu’on peut ré-activer les trois boutons de navigation à la place), réactiver le verrouillage OEM (désactivé à la première étape de l’installation de GrapheneOS).

Je me suis dit « dommage que l’installateur ne bascule pas en français après le choix de la langue ». Mais, en fait, dans les menus, aucune des fonctionnalités ajoutées par GrapheneOS n’est traduite en français. Le reste du système l’est, bien entendu, puisqu’il s’agit d’Android.

Au final, je me retrouve sur un système Android version 15. Android-GrapheneOS occupe 9,6 Go (mieux que les 20 Go du système de base de Google) et les applis 314 Mo. Malgré plusieurs redémarrages, je constate 1,7 Go de fichiers temporaires (2 Go quand j’écris ce shaarli 10 jours plus tard, donc le système s’encrasse plutôt vite). Comme d’autres, je trouve que le noir (et blanc pour les icônes) des écrans de verrouillage et d’accueil est très austère et surprenant, d’autant qu’aucun fond d’écran n’est fourni…

Configurer GrapheneOS

Je vais simplement pointer les paramètres que je trouve intéressants dans le menu Paramètres.

Le temps de bricoler, je préconise d’allonger la durée avant la mise en veille automatique de l’écran (Paramètres, affichage, « Délai de mise en veille de l’écran ») ou celle avant le verrouillage après la mise en veille de l’écran (Paramètres, sécurité et confidentialité, déverrouillage de l’appareil, verrouillage de l’écran, « Verrouiller après la mise en veille »).

Réseau et Internet :
- DNS privé. En mode automatique, le système essaye d’utiliser DNS-over-TLS avec les résolveurs DNS fournis par DHCP (source). Hors de question d’utiliser les résolveurs DNS de mon opérateur ou du premier point d’accès Wi-Fi venu, DoT ou pas, donc je passe en manuel pour ajouter un récursif DNS de confiance en regrettant de ne pouvoir saisir qu’une seule adresse IP ;
- On peut désactiver les tests de connectivité (quand bien même ils pointent par défaut vers des serveurs de GrapheneOS).
Appareils connectés : désactiver le Bluetooth et le service d’impression par défaut (dans le sous-menu « Préférences de connexion »).

Applications, Accès spéciaux des applis, désactiver « Special access to hardware accelerators for Google maps » (je n’utilise pas de logiciels Google).

Notifications :
- Désactiver les bulles ;
- Désactiver les alertes d’urgence sans fil (t’sais, FR-ALERT, tout ça, qui finit toujours par être utilisé à mauvais escient) ;
- Désactiver les notifications améliorées.
Batterie : désactiver le « gestionnaire de batterie » et activer l’affichage du pourcentage dans la barre d’état.

Son et vibreur :
- Choisir ses sons, les différents volumes sonores (sonnerie, notifs, alarmes, etc.) et désactiver les sons qu’on ne veut pas (pour moi : clavier, appuis et clics, et verrouillage) ;
- Ne pas déranger. Au début, je n’avais pas compris comment passer en mode vibreur : il faut presser volume haut ou bas puis presser l’icône haut-parleur située au-dessus de la barre de volume (je pensais que cette icône informait juste de ce qui est réglé par la barre, à savoir le volume audio, pas qu’il s’agit d’un bouton…). Donc, en palliatif, je voulais utiliser le mode « ne pas déranger » qui peut s’activer depuis la barre d’état. Mais je me suis rendu compte que tout appel ou SMS déclenche la sonnerie… Dans ce sous-menu, on peut faire en sorte qu’aucune personne (téléphone et SMS) ni aucune application (notification) ne puisse interrompre le mode « ne pas déranger » ;
- Multimédia :
  
  Désactiver l’affichage de contenus multimédias sur l’écran de verrouillage (motif : j’ai tout à cacher) ;
  
  Désactiver l’affichage des recommandations de Google Assistant (qui n’est pas installé sur GrapheneOS, de toute façon) ;
- Désactiver le raccourci pour annihiler la sonnerie. Je le trouve peu pratique.
Affichage :
- Écran de verrouillage :
  
  Raccourcis. Je les désactive tous. Pas envie qu’un relou de passage prenne des photos à mon insu pour rigoler, par ex. (histoire vraie) ;
  
  Désactiver l’horloge dynamique c’est-à-dire l’adaptation de la taille de l’horloge à l’espace disponible sur l’écran de verrouillage (si l’on ne met rien sur cet écran, alors sa démesure la rend difficilement lisible) ;
  
  Appuyer pour activer l’écran. Attention : une pression sur l’écran ne produit aucun effet quand le smartphone est branché au secteur.
- Activer le thème sombre.
Fond d’écran et style : aucun fond n’est fourni… J’ai repris celui que j’utilisais sur mon Galaxy S3, c’est-à-dire l’un de ceux fournis par LineageOS.

Sécurité et confidentialité :
- Déverrouillage de l’appareil, verrouillage de l’écran. Désactiver l’accès à la caméra quand le smartphone est verrouillé. C’est également ici qu’on peut configurer un « duress password » (mot de passe sous contrainte), c’est-à-dire un faux code de déverrouillage qui efface le stockage ;
- Paramètres de confidentialité : comme dans la barre d’état, on peut désactiver, en sus de la localisation (GPS ou plus en fonction de ce qu’on a activé dans le menu dédié, cf. infra), l’accès à la caméra et au micro, y compris pour les applis autorisées (qui ont la permission). Les applis demanderont l’accès, y compris la caméra, et le téléphone lors d’un appel entrant (si le téléphone est verrouillé, il faut saisir le code de déverrouillage) ;
- Espace privé : pour masquer des applis (dans le launcher, dans le menu Paramètres, etc.) ;
- Exploit protection : ajouts de GrapheneOS.
  
  Désactiver ou rallonger le délai avant un redémarrage automatique après 18 heures sans déverrouillage ;
  
  USB-C port. Par défaut, Android désactive le transfert de données mais si l’on branche l’ordiphone à un ordi, on voit a minima son nom dans un explorateur de fichiers. C’est équivalent à l’option GrapheneOS « Charging only when locked » de ce menu. Avec l’option « Charging only », plus rien n’apparaît, y compris dans kern.log. Je pense que ça rajoute une mini-protection supplémentaire contre les stations d’extraction des flics. Par contre, j’ai eu une mauvaise expérience : revenir à « Charging when locked » n’a pas fait apparaître la notif qui permet ensuite d’activer le transfert de fichiers, j’ai dû activer les options développeurs. Je n’arrive pas à reproduire ce bug, donc… ;
  
  On peut désactiver le Wi-Fi et/ou le Bluetooth après l’épuisement d’un délai ;
  
  J’ai activé toutes les options de durcissement des applications : blocage du native code debugging, désactivation de Webview JIT, restriction du dynamic code loading via storage pour chaque application que j’ai installé en supplément, et activation du secure app spawning. Tous mes logiciels fonctionnent toujours (je rappelle que j’en utilise très peu). Si une appli dysfonctionne, ces renforcements peuvent être désactivés pour chaque logiciel depuis le menu « Applications » ;
- Sécurité et confidentialité renforcées :
  
  « Allow Sensors permission to apps by default » (désactivation de l’octroi par défaut de la permission d’accès aux capteurs). À faire avant d’installer de nouvelles applis, sinon elles auront la permission (il est possible de la leur retirer une par une) ;
  
  Désactiver l’horodatage des captures d’écran (dans leurs métadonnées) ;
  
  Chiffrement et identifiants. Sous le libellé trompeur « Identifiants de confiance », il est possible de ne plus accorder sa confiance à des autorités de certification x509 (ou d’en installer, afin de faire de l’interception de trafic).
Localisation : on peut activer / désactiver les recherches Wi-Fi et Bluetooth, SUPL, et PSDS.

Sécurité et urgences : désactiver SOS Urgences (l’appui rapide au moins 5 fois de suite sur le bouton marche/arrêt déclenche un son très fort et appelle le 112).

Mots de passe, clés d’accès et comptes : même si je n’ai aucun compte, j’ai désactivé la synchronisation automatique des données des applis.

Système :
- Clavier, clavier à l’écran, appuyer sur le clavier Android de base :
  
  Préférences : désactiver le vibreur et le son à chaque touche, et désactiver la touche de saisie vocale ;
  
  Correction du texte : désactiver le blocage des termes choquants, les suggestions personnalisées, le recours au nom des contacts pour la correction, et la suggestion du prochain mot.
- Gestes :
  
  Désactiver l’ouverture rapide de l’appareil photo depuis l’écran de verrouillage (en appuyant deux fois sur marche/arrêt) ;
  
  Mode de navigation : permet de revenir aux trois boutons ou de piloter l’ordiphone par gestes (sur l’écran) ;
- Utilisateurs : c’est ici que l’on peut créer des profils distincts afin d’isoler des applis, comme une application bancaire et les Google Play services qu’elle requerra ;
- View logs : accès et exportation des journaux système, y compris ceux du GSM (il faut cocher « radio » dans « Log buffers » dans les 3 points en haut à droite).
Dans les paramètres de l’appli SMS/MMS, j’ai désactivé l’émission d’un son lors de l’envoi d’un SMS. Dans les paramètres avancés, j’ai activé la demande d’un accusé de réception automatique par le téléphone du destinataire, ainsi que la réception automatique des MMS, y compris en itinérance. (En sus de l’accusé de réception par le terminal du destinataire, Silence permettait d’afficher la bonne prise en charge d’un SMS par mon opérateur. L’appli SMS/MMS ne le permet pas.)

Dans ses paramètres, Vanadium (le navigateur web livré par GrapheneOS) ne permet pas de choisir Startpage comme moteur de recherche par défaut. Pour cela, il faut configurer Startpage pour utiliser HTTP GET plutôt que POST, puis faire une recherche dans Startpage, puis revenir dans les préférences de Vanadium. Source.

Installer des logiciels additionnels sur GrapheneOS

GrapheneOS propose quasiment aucune appli et nous invite à utiliser le magasin d’applis de notre choix. J'apprends l'existence d'Aurora, un client alternatif et sans compte pour Play.

Ainsi, depuis Vanadium (Chromium configuré et renforcé par GrapheneOS) j’ai téléchargé F-Droid, le magasin d’applis libres.

Intéressante permission pour autoriser un logiciel, comme l’explorateur de fichiers, à installer une application.

Intéressante demande, lors de l’installation d’une appli, de lui octroyer ou non la permission d’accès aux réseaux IP (Wi-Fi, mobile). Très pratique pour désactiver la télémétrie d’une appli avant de lui octroyer l’accès au réseau (voir OSMAnd~, par exemple).

J’ai été contraint d’actualiser ma liste de logiciels pour mobile.

Applis installées sur mon Pixel 6a - GrapheneOS :
- OpenVPN for Android. Client OpenVPN ;
- OSMAnd~. Pour éviter l’envoi d’un identifiant unique, ne pas accorder la permission réseau lors de l’installation, désactiver cela dans les paramètres d’OSMAnd~ (sous-menu paramètres OSMAnd, « Analyses » et « Identifiants »), puis octroyer la permission réseau. Il faudra que je me penche sur Organic Maps qui a moins de fonctions indésirées qu’OSMAnd~ d’après F-Droid (mais j’ai l’impression que les listes sont incomplètes pour les deux applis) ;
- SatStat. L’installation échoue (même en désactivant tous les durcissements proposés par GrapheneOS). GPSTest répond à mon besoin. Attention : comme SatStat, il prétend réussir à importer des données PSDS même quand il n’y a pas de réseau, et forcément, il galère à fixer le GPS… ;
- Simply Do. N’existe plus. Je m’en servais plutôt pour prendre des notes, en réalité. Du coup, j’ai cherché sur F-Droid un logiciel de prise de notes léger qui prend en charge le markdown et qui ne demande aucune permission : Easy Notes répond à ce cahier des charges ;
- VLC. Attention de ne pas en faire le logiciel par défaut pour les contenus multimédias, sinon il devient impossible de lire des vidéos depuis la galerie (je ne sais plus comment j’ai corrigé le tir).
J’ai cessé d’utiliser les logiciels suivants :
- AFWall+ : comme l’indique sa description dans F-Droid, il repose sur DroidWall qui n’est plus maintenu. De plus, il repose sur Netfilter alors qu’Android utilise BPF. Bref, pas ouf niveau pérennité. De plus, il requiert un accès root alors que GrapheneOS ne le permet pas et le déconseille vivement. De plus, la permission permettant d’octroyer ou non l’accès au réseau à chaque appli, le filtrage, par OpenVPN for Android, des applications pouvant l’utiliser, et la fonctionnalité de base d’Android « Bloquer les connexions sans VPN » répondent à mon besoin (lire ci-dessous) ;
- Barcode Scanner : le logiciel Caméra a déjà cette fonctionnalité (et elle fonctionne impec) ;
- Busybox et Terminal Emulator : je trouvais cool d’avoir un accès en ligne de commande à mon système, notamment car j’avais installé Debian sur mon premier smartphone, mais je m’en suis très rarement servi, et je n’avais pas réinstallé ces logiciels sur mes Galaxy S3 ;
- ConnectBot : je trouvais cool de pouvoir me connecter en SSH depuis mon ordiphone, mais, en pratique, j’utilise l’auth par clé sur mes serveurs et il était hors de question de mettre ma clé privée sur un smartphone non-chiffré, et je ne m’en suis jamais servi (pas d’usage), il n’était déjà plus installé sur mes Galaxy S3 ;
- Etar (en remplacement d’Offline calendar et de l’appli agenda de base de LineageOS) : en pratique, je n’ai jamais utilisé d’agenda sur mon ordiphone ;
- Firefox (puis IceCat puis Fennec, historique ici). GrapheneOS propose Vanadium, un Chromium configuré et durci par leur soin, qui inclut un filtrage des merdes via deux listes de blocage, Easylist anglais et Easyprivacy, donc ça ne vaut pas uBlock, mais vu mon non-usage de mon smartphone, ça n’est pas un problème), qui ne permet pas d’installer des extensions. D’un côté, Chromium est devenu un quasi-monopole, donc nous avons besoin de diversité, donc je devrais installer Firefox. D’un autre côté, GrapheneOS a plutôt bien configuré Vanadium (contre-mesure minimale contre les fuites webRTC, pas de prise en charge des DRM ni des cookies tierce partie, activation du state partitionning, de DoT, etc.), mieux qu’un Firefox de base, donc si j’installais Firefox, il faudrait le configurer et assurer le suivi à chaque version vu que Firefox rajoute des fonctionnalités indésirées sans arrêt. Tout ça pour un navigateur web que je n’utiliserai qu’en dernier secours… Fleeeemme. Au final, vanadium me convient ;
- Ghost commander : GrapheneOS ne propose pas un accès root et le déconseille vivement. Sans un tel accès, l’explorateur de fichiers de base est bien suffisant. Je n’utilisais Ghost commander que pour ça, pour explorer l’intégralité du stockage (et, dans un temps reculé, pour modifier des fichiers de configuration) ;
- Hacker’s Keyboard : pratique dans un shell, inutile sinon. Il n’était déjà plus installé sur mes Galaxy S3 ;
- Linphone : je n’en ai plus l’usage depuis longtemps ;
- MuPDF : GrapheneOS fourni déjà une visionneuse PDF ;
- Silence (ex-SMSSecure, fork de TextSecure ‒ remplacé par Signal du même éditeur ‒) : en pratique, je ne chiffre pas mes SMS par absence de correspondants compatibles ; je m’en servais surtout pour chiffrer mes SMS sur le stockage (avec un code de déverrouillage spécifique à Silence) puisque le chiffrement du stockage par le système ne fonctionnait pas. Maintenant qu’il est fonctionnel, Silence perd son intérêt ; aucune mise à jour depuis 2019 et site web officiel HS ;
- Torch : tout comme Android de base et mes Galaxy S3 sous LineageOS, GrapheneOS propose nativement cette fonctionnalité ;
- Wi-Fi Matic : ce logiciel n’est plus disponible dans F-Droid et Android implémente nativement ses fonctionnalités (Paramètres, Réseau et Internet, Internet, Préférences réseau, Activer automatiquement le Wi-Fi). De plus, contrairement à LineageOS, GrapheneOS ne réactive pas automatiquement le Wi-Fi (sauf si c'est configuré explicitement), et j’emporte très rarement mon téléphone hors de mon domicile à l’improviste, donc je n’ai plus besoin de ce logiciel.
Divers

Notification appel manqué / SMS non-lu

Sur mon Galaxy S3, une LED clignotait pour signaler un appel téléphonique manqué ou un SMS non-lu.

Ce n’est plus le cas avec mon Google Pixel 6a qui en est dépourvu et ça me manque. C’est très pratique pour vérifier, de loin, en passant, alors que l’ordiphone est posé sur un meuble, si un événement est survenu et qu’on n’a pas entendu la notification sonore.

Android propose les notifications lumineuses (Paramètres, notifications), c’est-à-dire faire clignoter l’écran d’une couleur choisie et/ou faire clignoter le flash de la caméra. Cette fonctionnalité ne produit un effet qu’au moment de la réception, en même temps que la notification sonore (si l’on n’est pas en vibreur), pas après, donc ça ne répond pas à mon besoin. De plus, tout comme la notification sonore et le vibreur, ça s’active aussi lors de la survenue d’un événement pendant que l’on utilise le smartphone, ce qui ajoute du désagréable.

Sur le web, je trouve un contournement basé sur les notifications répétées cumulées aux notifs lumineuses. Je n’ai pas trouvé ce paramètre dans les menus. Sur F-Droid, on trouve uniquement des applis pour des notifications sonores répétées, mais ça ne m’intéresse pas (ça peut être pénible si t’es plongé dans une activité). Sur Google Play, on trouve quelques applis qui prétendent faire de la notif répétée en allumant l’écran, mais je souhaite utiliser uniquement des logiciels libres et ne pas recourir à Google Play (ni à Aurora, un client alternatif et sans compte Google pour Play).

Autre contournement : Always-On Display, c’est-à-dire écran toujours allumé. A priori, c’est ce mode que je peux activer dans Paramètres, affichage, écran de verrouillage, « Toujours afficher heure et infos ». Mais ça ne convient pas à mon besoin : en cas d’appel manqué (ou de SMS), il y a une toute petite icône sous l’horloge. On est loin de quelque chose qui se voit de loin, qui appelle le regard.

À ce jour, je n’ai pas trouvé de solution satisfaisante.

MMS : par où ça passe ?

Android propose un paramètre « Envoyer et recevoir des MMS lorsque les données mobiles sont désactivées » (Paramètres, réseau et Internet, SIM, choisir la SIM). Elle est disponible uniquement quand les données mobiles sont désactivées.

Johndescs pensait qu’il s’agit d’un contournement, que les MMS transitent bien par les données mobiles, mais que le reste du trafic Internet est bloqué. De mon côté, je me souviens qu’il y a 20 ans, au début des années 2000 donc, je recevais et émettais des SMS depuis un téléphone mobile, un Nokia 3410, dépourvu de données mobiles / d’accès IP (la 3G a été commercialisée en France en 2004), c’était l’époque du WAP, donc je pensais que ça n’utilise pas les données mobiles.

Une fois encore, Wikipédia a la réponse : à l’époque, les MMS utilisaient le WAP. De nos jours, ça utilise bien les données mobiles. Cela se confirme par l’expérience : je désactive les données mobiles, j’échange des images par MMS, puis je constate que mon Pixel a comptabilisé l’usage de 1,71 Mo de données mobiles.

Le fonctionnement des MMS a toujours été une purge, tant sur mon Motorola Moto G et son système d’origine que sur LineageOS. Notamment parce que, si l’on l’utilise, il faut autoriser le bon composant du système dans AFWall+, et que celui-ci a rarement un nom explicite. En tout cas, telle était la cause du dysfonctionnement des MMS sur mon dernier Galaxy S3 (évidemment, je n’ai pas noté le nom du composant logiciel à autoriser dans AFWall+).

Craignant qu’il en soit de même sur GrapheneOS, j’ai donc procédé à quelques tests d’envoi et de réception de MMS, avec le paramètre « Envoyer et recevoir des MMS lorsque les données mobiles sont désactivées » activé :
- Connecté en Wi-Fi + données mobiles désactivées + aucun VPN établi + « Bloquer toutes les connexions hors VPN » : OK. Donc ça contourne la fonctionnalité visant à bloquer les connexions hors VPN ;
- Connecté en Wi-Fi + données mobiles désactivées + VPN établi + « Bloquer toutes les connexions hors VPN » : OK ;
- Sans Wi-Fi + données mobiles désactivées + « Bloquer toutes les connexions hors VPN » : OK ;
- Sans Wi-Fi + 4G + « Bloquer toutes les connexions hors VPN » : OK ;
- Sans Wi-Fi + 4G + VPN établi + « Bloquer toutes les connexions hors VPN » : OK.
Si je désactive le paramètre « Envoyer et recevoir des MMS lorsque les données mobiles sont désactivées » :
- Wi-Fi + données mobiles désactivées + sans VPN + avec ou sans « Bloquer toutes les connexions hors VPN » : pas OK. Donc les MMS n’empruntent pas en Wi-Fi ;
- Sans Wi-Fi + 4G + sans VPN + avec ou sans « Bloquer toutes les connexions hors VPN » : OK.
Bref, la réception de MMS fonctionne. \o/

Sauvegarde réellement opérationnelle ?

GrapheneOS propose Seedvault comme outil de sauvegarde (voir). Il se trouve dans Paramètres, système, sauvegarde.

Il permet de planifier une sauvegarde régulière des applis et des fichiers (expérimentalement). Quid des paramètres du système ?

Il prend en charge WebDAV, Nextcloud (en ne le recommandant pas, sans raison explicite), une clé USB, le téléphone lui-même (avec un avertissement qu’il s’agit d’une très mauvaise idée) ou DAVx (une appli CalDAV / CardDAV). Je peine à déterminer si tous les modes se valent : DAVx, en tant qu’appli CalDAV / CardDAV peut-elle vraiment sauvegarder des fichiers ?

Les sauvegardes sont chiffrées. Le mot de passe est composé de 12 mots anglais choisis aléatoirement.

Vu mon absence d’usage de mon smartphone, je ne suis pas intéressé, j’exporterai mes contacts depuis l’appli dédiée (le reste ne m’intéresse pas), mais j’ai testé le stockage local. Dans ce mode, la sauvegarde est placée dans un dossier « .SeedvaultAndroidBackup » à la "racine" visible depuis l’explorateur de fichiers. Comme son nom l’indique, ce dossier est masqué, il faut demander à l’explorateur, depuis son menu "trois points", d’afficher de tels fichiers et dossiers.

Je ne suis vraiment pas convaincu : ma sauvegarde de mes applis comporte deux fichiers, un de 352 octets, l’autre de 5,23 k. C’est beaucoup moins que le volume de données utilisateurs de plusieurs de mes applis tel qu’il est affiché dans Paramètres, stockage, applis. N’ayant pas d’autres GrapheneOS sous la main ni envie de dégommer le mien, je ne peux pas tester la sauvegarde pour vérifier mes craintes.

Pare-feu

Sur mon Motorola avec le système par défaut puis sur LineageOS, mon utilisation d’AFWall+ visait quatre objectifs :
- Interdire l’accès au réseau sauf à quelques logiciels, notamment bloquer les bloatwares de Motorola. Cela est désormais possible nativement avec la permission « accès au réseau » proposée par GrapheneOS qui est actionnable au moment même de l’installation d’un logiciel puis à tout moment. Néanmoins, les composants du système et les applis de base qui le nécessitent, selon GrapheneOS, ont déjà la permission, ce que je trouve dommage car mon cas d’usage ne le nécessite pas, et faire le tri est fastidieux ;
- Forcer mes applis à utiliser un VPN OpenVPN (d’un fournisseur d’accès à Internet associatif). Cela est désormais possible nativement avec le paramètre « Bloquer les connexions sans VPN » (Paramètres, réseau et Internet, VPN, roue crantée de l’appli VPN). Attention : du trafic contourne ce paramètre : appels téléphoniques sur Wi-Fi (VoWiFi, qui doivent être explicitement activés), MMS, tests de connectivité (qui peuvent être désactivés), DNS (au moins pour établir le VPN), détection d’un portail captif (en toute logique), etc. Pour certains usages, c’est pour le mieux : il n’y a aucun intérêt à faire transiter dans un VPN le trafic destiné à mon opérateur téléphonique mobile. Deuxième point de vigilance : lorsque le VPN est établi, ce paramètre ne bloque donc plus les connexions, et toutes les applis qui ont la permission d’accéder au réseau peuvent emprunter le VPN, voir ci-dessous ;
- Bloquer des destinations précises, comme les résolveurs DNS du FAI qui désert ma maison, afin d’éviter des fuites. Sur mon Pixel, Linphone ne prend en compte que les trois premiers résolveurs DNS qu’il obtient via l’appel système. Comme ils sont classés dans l’ordre "récursifs IPv4 et IPv6 du VPN puis récursifs obtenus par DHCP", Linphone ne fuite pas vers le résolveur de mon FAI, mais c’est un coup de chance. Sur ce point, les solutions proposées par GrapheneOS et présentées dans les deux points précédents, sont impuissantes. Je n’utilise plus Linphone car je n’en ai plus besoin, mais il faut lire ce qui précède comme un exemple ;
- Bloquer les connexions entrantes (qui ne disposent pas d’un état). J’utilise un VPN qui attribue des IP v4 et v6 publiques et sans pare-feu en amont. Je veux donc bloquer les connexions entrantes dans le cas improbable où un logiciel autorisé, y compris système, ouvrirait un port en écoute. GrapheneOS ne propose pas de solution sur ce point. Pour nuancer, seuls la compromission d’une appli autorisée ou le changement de comportement d’un logiciel par son éditeur (sur mes serveurs, ce fut le cas d’OpenDNSSEC, par ex.) exposeraient mon smartphone sur Internet.
Il y a un hic qui m’a échappé dans un premier temps : quand le VPN est établi, toutes les applis qui ont la permission d’accéder au réseau peuvent l’emprunter.

Plusieurs applications peuvent se faire passer pour un VPN afin de proposer des fonctionnalités de filtrage équivalentes à celles d’AFWall+. On en trouve plusieurs sur F-Droid.

L’ennui, c’est qu’Android permet un seul VPN à la fois. Donc si je filtre avec une appli, je ne peux plus établir mon VPN OpenVPN. Même sans cela, sans mettre en œuvre du routage avancé pas facilement automatisable par une application (netns, tables de routage multiples, etc.), il est impossible de router l’ensemble du trafic sur deux interfaces réseau TUN, l’une à la suite de l’autre.

Certaines applis de filtrage proposent prétendument de se chaîner à un VPN. Je ne vais traiter que celles disponibles sur F-Droid, les autres, pas forcément libres, ne m’intéressent pas. NetGuard permet de transmettre le trafic à un proxy SOCKS, qui n’est donc pas un VPN OpenVPN. Rethink permet d’utiliser un VPN WireGuard (en étant lui-même un client WireGuard, je suppose, point de chaînage), mais pas OpenVPN (et ce, pendant encore possiblement longtemps).

OpenVPN for Android propose de bloquer toutes les applis l’empruntant sauf celles sélectionnées ou de bloquer uniquement les applis sélectionnées. L’ennui, c’est qu’il est difficile de savoir quoi autoriser (je rappelle que, sur mon dernier smartphone, la réception des MMS était une plaie car je n’avais pas autorisé un composant système au nom sans rapport avec la fonctionnalité à accéder à Internet). Quant à exclure des applis : si j’ai des soupçons, autant leur retirer la permission d’accès au réseau que de doublonner le filtrage (permissions + OpenVPN).

J’ai surveillé le trafic Wi-Fi émis par mon Pixel en créant un point d’accès Wi-Fi avec mon ordi (avec hostapd) et en surveillant le trafic qui y a transité (avec wireshark). 12 h en mode « Bloquer toutes connexions hors VPN » et 12 h sans. Je n’ai rien vu passer dans le premier cadre. Dans le deuxième, j’ai vu deux connexions à des serveurs de GrapheneOS, dont une pour la synchronisation du temps, et elles sont prévues par la doc’. Encore une fois, GrapheneOS et mes applis inspirent confiance. Ceci dit, mon test est incomplet puisque je n’ai pas utilisé mes applis durant l’interception du trafic. Dès lors, un pare-feu se justifie-t-il ?

Pour info, AFWall+ repose sur Netfilter alors qu’Android utilise BPF pour filtrer et superviser le trafic (pour produire les stats d’usage du réseau par logiciel et comptabiliser l’usage des données mobiles, par ex.).

Permissions

J’ai l’impression que les permissions sont plus fines que sur un Android 7. Sur mon LineageOS, il me semble que, au moment de l’installation d’une appli, je devais autoriser toutes les permissions demandées, c’était à prendre ou à laisser. Sur mon GrapheneOS Android 15, les permissions sont demandées à l’usage, et une par une. Johndescs a le même souvenir que moi.

Inversement, j’ai l’impression qu’aujourd’hui certaines permissions sont silencieusement accordées de base. Je me souviens qu’à l’époque, des applis comme OSMAnd~ demandaient l’accès au stockage (et la notif système disait, en gros, "si tu accordes cette permission, l’appli pourra lire tes photos et vidéos"), plus maintenant alors que plusieurs de mes applis stockent des données utilisateurs (Easy Notes, par ex.). Cela s’explique peut-être par l’absence de stockage externe (carte SD) sur un Google Pixel ? De même, sauf erreur, OSMAnd~ m’a demandé la permission uniquement pour la localisation (et l’accès au réseau), et, dans le menu Paramètres, applications, il disposait des permissions micro, appareils à proximité, etc. avant que je les lui retire.

Pour toutes les applis installées par l’utilisateur, Android a une option « Suspendre l’activité appli si inutilisée » (Paramètres, applications) qui retire automatiquement les permissions et supprime les fichiers temporaires d’une appli si elle n’est plus utilisée pendant plusieurs mois (combien ? Ce n’est pas précisé). Je trouve ça excessif dans mon cas d’usage (j’ai six logiciels, raisonnablement de confiance, etc.), donc j’ai désactivé ça pour mes 6 applis.

J’ai évidemment accordé le moins possible de permissions aux applis que j’ai installé (liste ci-dessus).

En regardant les autorisations octroyées aux applis préinstallées, l’octroi systématique de la permission d’accès aux capteurs m’a intrigué : pourquoi la calculette, la galerie, l’horloge, l’appli infos de GrapheneOS, etc. ont-elles cette permission ? Car il s’agit d’une permission spécifique à GrapheneOS, donc toutes les applis préinstallées l’ont car il serait fastidieux de faire le tri (l’appli caméra en a besoin pour enregistrer une photo au format paysage en tant que telle, par ex.) pour un gain dérisoire de sécurité (source). Dans la section « Configurer GrapheneOS » ci-dessus, j’ai parlé d’un paramètre (dispo dans Paramètres, sécurité et confidentialité, sécurité et confidentialité renforcées) qui permet de désactiver l’octroi automatique de cette permission pour les applis installées ultérieurement, mais elle ne couvre pas les applis déjà installées (même source).

Dans Paramètres, applications, voir toutes les applis, menu trois points, la fonctionnalité « Réinitialiser les préférences des applis » ne restaure par les permissions par défaut, autant pour les logiciels système qu’utilisateur. Autant pour les logiciels fournis de base que ceux installés par l’utilisateur. Tant pour les applis utilisateurs que système, les permissions deviennent un mélange entre la configuration de base et mes modifs. De même, cela n’a pas redonné la pleine permission contacts à l’appli SMS/MMS quand, pour tester, je l’avais mise dans un contact scope et qu’elle n’avait pas apprécié.

J’ai constaté des étrangetés : pourquoi l’appli galerie a-t-elle besoin d’une autorisation pour lire les fichiers image, son et vidéo alors que VLC ne demande même pas une telle permission ? Pourquoi le même logiciel a-t-il besoin de la permission d’accès au réseau ? Pourquoi l’explorateur de fichiers n’a pas besoin de la permission fichiers alors que la galerie en a besoin ? Pourquoi l’appli contacts a-t-elle besoin d’accéder au réseau ? Au téléphone ? Pourquoi l’appli SMS a besoin de la permission téléphone ? Etc.

Après, il y a des permissions de confort : on peut concevoir que le téléphone a besoin de la permission d’envoyer des SMS "pas dispo, je te rappelle", que le téléphone et l’appli SMS ont besoin de l’accès aux contacts pour les afficher ou en créer un à partir d’un appel / SMS reçu, que les contacts ont besoin d’accéder au journal des appels pour l’afficher dans la fiche de chaque contact, mais je me demande pourquoi chaque appli ne fait pas juste son taff et ne collabore pas avec les autres, genre pour créer un contact à partir d’un appel ou d’un SMS, l’appli tél (ou SMS) passe la main à l’appli contacts qui, elle, enregistrera le contact ? La seule réponse que j’identifie est qu’une communication directe entre logicielle est moins sécurisée qu’en utilisant les API système et leurs points de contrôle.

Bref, difficile d’en vouloir à GrapheneOS pour ces permissions un peu lestes : pour favoriser son adoption, il faut aussi qu’un smartphone reste utilisable selon des modalités très proches de ce que permet un Android de base, et il n’existe pas de solution totalement satisfaisante au problème.

J’ai rationalisé autant que possible les permissions données aux logiciels utilisateurs. Puis j’ai découvert les logiciels système (Paramètres, applications, voir toutes les applis, menu trois points, « Afficher le système »). Un GrapheneOS de base comporte environ 170 logiciels et composants système. Les fonctionnalités précises assumées par chacun est faiblement documenté. Le risque de casser une fonctionnalité sans m’en rendre compte est grand, surtout d’une fonctionnalité que je n’utilise pas dans l’instant. Et comme la réinitialisation des préférences ne restaure pas vraiment les permissions (cf. quatre paragraphes plus haut), les conséquences seront très pénibles à assumer. Enfin, en regardant quelques composants au hasard, je me suis rendu compte qu’ils ont uniquement la permission d’accès aux capteurs discutée supra. Face à l’impossibilité de tout vérifier (sauf à y passer un temps déraisonnable), au désir d’éviter la casse, et aux quelques permissions octroyées qui montrent que GrapheneOS est raisonnablement digne de confiance, j’ai décidé de laisser les permissions des logiciels systèmes dans leur état.

… Sauf à « Intent Filter Verification » à qui j’ai retiré la permission réseau après avoir lu la doc’.

Faut-il avoir le contrôle total (root) ?

Comme je l’ai déjà écrit, GrapheneOS ne propose pas un accès root et même le déconseille vivement.

J’ai toujours estimé que, dans mon cas d’usage (je n’utilise pas mon smartphone pour naviguer sur le web en permanence, j’ai très peu d’applis, et je ne suis pas une cible / personne publique exposée, je suis plutôt informé et prudent, etc.), les arguments anti-root, notamment que ça briserait le fameux modèle de sécurité d’Android, relèvent de l’exagération : il faut des pratiques en rapport avec son modèle de menace. De plus, l’implémentation de su que j’utilisais sur mes anciens smartphones demande une confirmation, donc le coup d’une appli malveillante qui devient root me concerne assez peu. Pour être compromis, il faudrait donc un accès physique à mon smartphone (car l’accès root fait sauter le Verified Boot), et encore vu le chiffrement du stockage, ce qui est improbable vu mon absence d’usage de mon smartphone, ou que j’octroie un accès root par inadvertance à une appli malveillante, ce qui est improbable vu mon usage de mon smartphone (j’installe des applis libres, uniquement depuis F-Droid, uniquement à la mise en service de mon ordiphone, dans le calme), ou qu’une de mes applications se fasse véroler, ce qui est improbable vu mon absence d’usage et que je n’octroie l’accès au réseau qu’aux applis dont j’évalue qu’elles en ont besoin pour répondre à un de mes besoins.

Sur mon premier smartphone, je voulais être root pour être root, avant même d’en avoir besoin (pour AFWall+, par exemple). C’est l’obsession de tous les libristes. Alors, qu’au final, des pans entiers de nos systèmes rootés sont opaques (blobs additionnels aux pilotes, BIOS / EFI, firmwares, microcode de CPU, etc.) et/ou échappent à notre contrôle (je pense à tous les logiciels libres qui font des choses derrière notre dos, y compris de la télémétrie et/ou qui changent de comportement par défaut à un rythme effréné), sans qu’un accès root ne permette vraiment d’influer sur ça, même quand on s’en rend compte.

Le contrôle, est-ce l’accès root ? N’est-ce pas là une vision restrictive ? Le contrôle, n’est-ce pas plutôt de parvenir raisonnablement à utiliser son appareil comme on l’entend (toute raison gardée), à en faire ce qu’on en veut, et à avoir raisonnablement confiance qu’il ne trahira pas ? Si ces deux points adviennent sans accès root, à quoi sert-il ? S’il est impuissant dans cette quête (cf. paragraphe précédent), à quoi sert-il ?

Ai-je besoin de l’accès root ? Avant, je l’utilisais pour utiliser Debian sur mon smartphone, pour utiliser un pare-feu, pour configurer l’assistance au GPS, et pour me connecter aux points d’accès Freewifi_secure (lire ici). Je n’utilise plus Debian sur mon ordiphone depuis longtemps. De même, je n’ai plus besoin de modifier des fichiers pour optimiser le GPS ou pour me connecter aux points d’accès Wi-Fi FreeWifi_secure avec EAP-SIM (à la connexion, il suffit de choisir « SIM » dans « Méthode EAP »). Le cas du pare-feu est déjà discuté supra.

Un accès root ferait évidemment sauter les mises à jour auto et/ou demanderait du travail pour le rétablir après chaque màj. Cela contredit donc mon objectif d’avoir un système à jour (sans efforts). De même, il faudrait récupérer une implémentation de su voir une image entière depuis des endroits chelous (sans signature ni rien, quoi). Cela contredit mon objectif d’éviter de telles manips.

Ainsi, je n’ai pas rooté mon Pixel 6a.

Appels téléphoniques via Wi-Fi

J’avais entendu parler du Voice over Wi-Fi (VoWiFi), c’est-à-dire de la possibilité d’émettre et de recevoir des appels téléphoniques en Wi-Fi, mais je n’avais pas pu tester car mon LineageOS 14.1-Android 7 ne proposait pas cette fonctionnalité.

Comme l’expose Wikipédia, et comme j’ai pu le constater (avec hostapd et wireshark), la VoWiFi transporte également les SMS.

Au niveau technique, comme le relate Wikipedia, il s’agit d’un tunnel IPSec entre l’ordiphone et l’opérateur téléphonique.

Plusieurs amis ayant des terminaux et opérateurs téléphoniques différents me rapportent que le VoWiFi dysfonctionne plus ou moins, que ce n’est pas la panacée.

Quelques nuances sur GrapheneOS

Ci-dessous, dans la section « Choix d’un remplaçant » puis tout au long de cet article, je tresse des lauriers à GrapheneOS.

Pour changer, une liste de trucs qui m’ont déplu et/ou qui m’ont fait douter de la réflexion / maîtrise derrière GrapheneOS :
- Je l’ai déjà écrit, mais l’austérité des écrans d’accueil et de verrouillage, et l’absence de fourniture de fonds d’écran m’ont grave étonné ;
- J’ai écrit que GrapheneOS dispose d’un cycle de développement et j’ai sous-entendu que les gens derrière le projet savent ce qu’ils font. Google a publié la version 15 d’Android le 15 octobre 2024. GrapheneOS a publié sa première version basée sur Android 15 le 16 octobre. Durant les 5 jours suivants, le projet a publié une version stable par jour. Certaines corrigent des régressions qui portent atteinte à la vie privée : « Settings: enable our per-connection Wi-Fi MAC randomization feature by default for new networks again on Android 15 instead of the standard per-network approach » (le mot « again » laisse supposer que ce n’est pas la première fois que ça arrive) ; « stop enabling the new Android 15 "Send device name" toggle for Wi-Fi networks by default to continue avoiding sending the device model (default) or user configured device name as a DHCP client hostname » ; plusieurs corrections à la deuxième version post-Android 15. De même, je vois des mini-versions qui ajoutent des fonctionnalités au lieu d’une version « stable » qui regroupe plusieurs fonctionnalités. Je vois également des mises à jour qui mélangent sécurité et fonctionnalités (comme les DSA pour certains logiciels, quoi). Bref, le cycle de développement n’est pas aussi rigoureux qu’il m’est apparu de prime abord ;
- Alors que j’étais à la recherche d’informations sur l’opportunité d’un pare-feu, plusieurs écrits du projet m’ont fait douter de la bonne compréhension des concepts manipulés et/ou de la qualité de la communication autour d’eux. Le summum : « Linux without any special configuration drops new inbound connections unless something is listening on the port. […] eBPF is used to drop all inbound traffic. […] New inbound traffic is dropped by default. Only apps added to the whitelist via the INTERNET permission can listen on a port. » (source). Dans un contexte de pare-feu, on cherche justement à ajouter une couche de protection, notamment pour éviter qu’un logiciel autorisé n’écoute sur un port car on l’a mal configuré et/ou que son comportement par défaut a changé à notre insu (ce fut le cas d’OpenDNSSEC sur mes serveurs, par ex.).
Conclusion

Puisque nous avons terminé les manipulations, je préconise de réduire la durée avant la mise en veille automatique de l’écran (paramètres, affichage, « Délai de mise en veille de l’écran ») ou celle avant le verrouillage après mise en veille de l’écran (paramètres, sécurité et confidentialité, déverrouillage de l’appareil, verrouillage de l’écran, « Verrouiller après la mise en veille ».

Il y a un écart très significatif entre Lineage 14.1-Android 7 et GrapheneOS-Android 15. Certaines fonctionnalités sont apportées par Android (chiffrement du stockage, profils / comptes multiples, prise en charge conditionnelle des aides auditives, granularité des permissions, enregistrement d’un appel téléphonique, permission pour installer des applis tierces qui ne nécessite plus d’activer les outils pour développeurs, mode "MMS uniquement", mode "bloquer toutes les connexions IP hors VPN", EAP-SIM, Wi-Fi qui demeure désactivé quand on le demande, quasiment plus aucune interaction à partir de l'écran de verrouillage sans saisie du code ‒ ça évite les petits farceurs, même s'il est toujours possible de vider la batterie avec la lampe torche ou d'activer le mode ne pas déranger ‒, etc.), d’autres par GrapheneOS (permissions pour l’accès au réseau et aux capteurs, contacts et storage scopes, serveurs relais et minimisation des requêtes réseaux pour SUPL & co, durcissement, conteneurisation de Google Play, désactivation totale des données du port USB, etc.), d’autres par la maîtrise découlant du peu de matériels supportés (comme le Wi-Fi qui reste éteint après une demande de l’utilisateur, comme l’écran qui reste éteint en cas d’inactivité, etc.).

Le niveau d’intégration, d’agencement et de qualité proposé par Android est ouf. :O Un système GNU/Linux sur un ordi peut aller se rhabiller. (Évidemment, je parle d’un système sans Google, sinon c’est un tsunami de notifications.)

La tenue de la batterie, qui n’est même pas neuve, n’a rien à voir avec celles de mes Galaxy S3 : plus de cinq jours, pour environ 6 h d’écran allumé. Pour ne rien faire à part accrocher le réseau mobile, ça me paraît être le minimum. Bon, mes Galaxy S3 étaient d’occasion (pas reconditionnés), leur écran s’allumait toutes les deux minutes (probable bug), et le Wi-Fi s’activait derrière mon dos, donc, forcément, la comparaison est fortement biaisée.

En tout cas, pour quelqu’un qui limite au maximum son utilisation d’un ordiphone, j’en suis au 5^e en dix ans. Ça fait cher par rapport à l’usage. Premier smartphone, neuf, en 2014. trois d’occasion dont un simlocké par erreur, entre 2017 et 2024. Puis, désormais, un 5^e, reconditionné. Certes, je les ai utilisés jusqu’à leur fin sauf le simlocké, mais bon, maigre consolation… Au final, pas sûr que l’occasion et/ou un système qui n’est plus maintenu (oui, j’établis une corrélation entre LineageOS et les dysfonctionnements de mes Galaxy S3) soient le bon plan écolo (un téléphone reconditionné Google avec un système maintenu = 7 ans sauf panne matérielle > 5 ordiphones en 10 ans). À suivre.
Fri 01 Nov 2024 10:03:49 AM CET - permalink -

- http://shaarli.guiguishow.info/?qoTXIg

Links per page: 20 50 100

page 1 / 1

GuiGui's Show

Installer GrapheneOS sur un ordiphone

Problème

Sauvegarde

Choix d’un remplaçant

Achat et livraison

Reconditionné

UPS = escrocs

Déballage

Première mise en service

Raboter la SIM

Premier démarrage, bonne surprise et mauvaises surprises

Trololo winwin, vraiment ?

Entendre la sonnerie et le son d’un appel dans des prothèses auditives

Aides auditives, Bluetooth et vie privée

Récupérer l’apk d’une application installée

Installer GrapheneOS

Premier démarrage de GrapheneOS

Configurer GrapheneOS

Installer des logiciels additionnels sur GrapheneOS

Divers

Notification appel manqué / SMS non-lu

MMS : par où ça passe ?

Sauvegarde réellement opérationnelle ?

Pare-feu

Permissions

Faut-il avoir le contrôle total (root) ?

Appels téléphoniques via Wi-Fi

Quelques nuances sur GrapheneOS

Conclusion