C'est l'histoire d'un smartphone Pixel de Google sur lequel il n'y a absolument rien... Vous l'allumez, pas une icône d'application, rien à faire défiler, pas de widget météo et ce genre de conneries... Non, vous avez juste l'heure, un gros bouton "micro" au milieu de l'écran et une ligne de saisie tout en bas pour ceux qui préfèrent taper.

L'écran d'accueil au complet : l'heure, le bouton à maintenir pour parler, et la ligne de saisie pour ceux qui préfèrent taper.

Ce truc ça s'appelle RistOS, et c'est un firmware pour Google Pixel 10a qui a pour objectif de remplacer le lanceur d'Android par un assistant vocal. Tout ce qui reste ensuite du téléphone tient dans un menu qui apparaît sur le côté : Téléphone, messages, appareil photo, galerie, cartes hors ligne (c'est Organic Maps, embarqué dans l'image), lampe torche et réglages.

Sept accès, et c'est fini. Pas d'app store, pas de navigateur, pas de compte Google, et évidemment aucun moyen d'ajouter quoi que ce soit.

Le menu sorti sur le côté, ses sept entrées, et rien d'autre à faire glisser.

Le projet repose sur GrapheneOS, sans être affilié ni à celui-ci ni à Google, et il ne tourne que sur le Pixel 10a (lien affilié), que Google vend encore la "modique" somme de 389 €.

Bref, par défaut, si vous appuyez sur ce gros bouton micro, absolument rien n'écoutera ce que vous avez dit, parce que l'image publique ne contient aucune adresse de serveur. Pour que cela fonctionne, vous devrez aller dans les réglages et remplir le champ dédié afin de lui indiquer l'URL de votre backend Rist. C'est donc le serveur, que vous devez installer comme ceci , qui récupèrera l'audio encodé et qui ensuite vous répondra au travers du téléphone.

L'idée, c'est que comme ça, on peut changer de téléphone sans souci, puisque tout est centralisé sur le serveur. C'est donc assez tranché comme usage, surtout que l'install efface tout ce qui est sur l'appareil. Mais bon, c'est peut-être ça le futur... Une coquille vide qui discute avec un serveur IA personnel, qui se trouve chez vous.

Par contre, n'espérez plus pouvoir utiliser votre téléphone pour appeler, par exemple, un service d'urgence, ça ne fonctionnera pas. Et si vous préférez simplement virer l'emprise de Google de votre téléphone sans avoir à vous monter un serveur entier derrière, /e/OS fera le travail .

Source : RistOS sur GitHub

Il y a 2 jours, GrapheneOS que vous connaissez tous parce que c'est l'Android que la police déteste, a détaillé une fonction baptisée secure paste, qui change la façon dont Android sert le contenu du presse-papiers aux applications. Le principe c'est qu'une application peut relire ce qu'elle a copié elle-même, mais rien de ce que les autres ont copié.

Android dans sa version de base n'est pas resté les bras croisés sur ce sujet, mais il s'est arrêté en chemin et depuis Android 10, seules l'application affichée à l'écran et le clavier par défaut peuvent lire le presse-papiers, ce qui a fermé la porte à celles qui tournent en arrière-plan. Puis Android 12 a ajouté une notification à la première lecture d'un contenu venu d'ailleurs, et enfin Android 13 vide le presse-papiers au bout d'un moment.

Mais depuis, plus rien...

Le trou qui reste, Microsoft l'a documenté en mars 2023. La version 7.9.2 de l'application SHEIN (oui, le site de fringues), téléchargée plus de cent millions de fois, lisait périodiquement le presse-papiers, et si elle y trouvait en même temps un signe dollar et un "://", elle expédiait le contenu vers un serveur distant.

Et la restriction d'Android 10 n'a rien empêché, tout simplement parce que l'application tournait au premier plan. Le comportement problématique de l'app SHEIN a ensuite disparu en mai 2022, après un signalement à Google, mais le problème de fond n'a jamais été réglé. Et j'imagine que d'autres apps actuellement sur le PlayStore appliquent la même technique sans que personne ne l'ait encore remarqué.

Secure paste de GrapheneOS s'attaque donc à ça en changeant la règle plutôt qu'en ajoutant un avertissement, et cette fois être affiché à l'écran ne donne plus droit à rien. Une application privée d'accès sait toujours qu'un élément est disponible, et peut en inspecter le type, l'horodatage de copie et la présence de mise en forme. Mais le contenu lui-même, son libellé et ses données annexes ne lui sont plus offerts sur un plateau d'argent.

Et le "collage" continue de marcher lui, parce que c'est vous qui l'autorisez. Que vous colliez depuis la barre de sélection de texte, depuis le clavier, depuis un service d'accessibilité ou avec un raccourci clavier, le système délivre une autorisation courte, liée à l'application qui reçoit et à l'élément en cours. Et pour les applications qui dessinent leur propre barre de sélection, comme celles codées en Flutter, un bouton "Coller" est visible dans le clavier par défaut.

Le plus vif d'esprit qui me lisent sont déjà debouts sur leur chaise et hurlent à travers leur écran : Et comment ça se passe pour "couper" ? Qui décide ?? Hé bien le réglage existe en version globale et par application, et il est autorisé par défaut, pour ne rien casser des applications déjà installées. Autrement dit, personne ne sera protégé sans l'avoir décidé et c'est à vous d'aller basculer en collage seulement celles à qui vous ne faites pas confiance.

Maintenant, calmez-vous les groupies de GrapheneOS parce que rien de tout ça n'est encore livré. Le code est visible dans une pull request ouverte depuis le 22 août dernier mais toujours pas fusionnée. GrapheneOS dit vouloir l'intégrer bientôt, sans donner de date et le mécanisme ne porte que sur la lecture, donc il ne dira rien des applications qui écrivent dans le presse-papiers pour y remplacer ce que vous venez de copier (coucou les détourneurs de transactions crypto)...

La même annonce parle aussi de l'application Messaging, dont l'interface vient d'être refaite en Compose, et le projet lâche au passage un chantier autrement plus lourd : faire du RCS directement dedans, chiffrement de bout en bout compris, pour ne plus avoir besoin de Google Messages. Héhé... Aujourd'hui, RCS marche très bien sur GrapheneOS, mais uniquement avec l'application de Google et sa couche Google Play isolée et c'est de ça dont ils veulent se passer.

Comme le RCS n'est pas une plateforme ouverte en pratique (pas autant que le SMS et le MMS quoi) et que tout cela repose sur l'infrastructure de Google et des opérateurs, le plan, c'est donc de refaire d'abord la partie que Google Messages assure, en gardant Google Play isolé pour l'activation, puis de s'en passer chez les opérateurs qui le permettent... à condition qu'ils acceptent le client de GrapheneOS, ce qui n'est pas gagné...

Quand je pense que Google, ces grands hypocrites qui ont passé des années à réclamer qu'Apple adopte RCS au nom de l'ouverture, coupe lui-même le service depuis 2024 sur les téléphones rootés et une partie des ROM alternatives. GrapheneOS y échappe mais ça donne quand même l'idée de l'accueil qu'un client maison pourrait espérer... On verra bien.

Mais bon, si vous êtes sur GrapheneOS, je serais vous, je surveillerais cette histoire de presse-papiers sécurisé parce que quand ça arrivera, vous serez encore plus béton face aux apps problématiques.

Source : le fil d'annonce de GrapheneOS et Android Authority

Après une semaine de travail, les développeurs de GrapheneOS annoncent qu'ils n'arrivent pas à porter leur système sur les Pixel 11. En cause : l'absence du marquage mémoire matériel (MTE), une protection présente sur tous les Pixel depuis 2023. Le projet déconseille désormais l'achat des nouveaux smartphones de Google et envisage de sauter toute la génération.