Cher journal,
Une dépêche récente m'a amener à penser un peu à l'utilité de faire tourner des logiciels dans des bacs à sable, à la façon des applications pour Android, des Flatpaks, des extensions de navigateur et autres technologies semblables.
Autant que je sache, on parle de faire tourner un logiciel en limitant ce à quoi il a accès, ou plus généralement ce qu'il peut faire à une liste précise de permissions, par exemple :
- lire et Ă©crire des fichiers dans
$XDG_PICTURES_DIR ; - accéder à la caméra ;
- accéder au micro ;
- accéder à Internet.
Cela a, me semble-t-il, un double intérêt :
- cela limite les dégâts en cas de compromission d'un logiciel ;
- cela limite les abus de la part de l'Ă©diteur du logiciel.
Le premier intérêt me semble indiscutable, en revanche le second me semble parfaitement inefficace. Prenons par exemple un jeu vidéo dont l'éditeur souhaiterait faire de la merde avec vos contacts, par exemple vendre les adresses électroniques. Si le jeu n'a pas la permission s'accéder aux contacts, ça ne va pas être possible. Mais en fait, ça n'aide pas, parce qu'il suffit au logiciel de demander la permission sous peine de se petit-suicider, pour que les utilisateurs lui accordent histoire de pouvoir jouer.
D'où une idée qui m'est venue : l'implémentation de permissions bidons devrait sans doute être considérée comme une nécessité si on peut que l'exécution en bac à sable puisse limiter effectivement le pouvoir de nuisance de logiciels aux pratiques abusives.
Concrètement, je parle de ce qui peut se faire à grand prix sous Android, à l'aide d'outils comme Xposed. Il s'agit de permettre à un logiciel qui y tient absolument d'accéder à un faux répertoire de contacts, à une fausse caméra, à un faux micro, etc. C'est plus ou moins facile à imaginer selon la nature de la permission requise, mais ça reste assez concevable.
Tel jeu veut accéder à mes contacts, pour une raison qui m'échappe ? D'accord, vas-y, siphonne ce que tu veux, de toute façon c'est bidon. Ça y est, content, je peux jouer maintenant ?
# J'y avais pensĂ© il y a quelques temps dĂ©jĂ
Posté par totof2000 . Évalué à  4 (+2/-0).
…. mais je doute que Google le permette sur Androïd. En faitil faudrait avoirr un (ou plusieurs ) environnements de type sandbox sur le téléphone, averc un pour les applications "sures" qui doivent accéder légitimement à toutes ces informations, et une pour les applications non sures qui ne partageraient que des fakes infos (un carnet vide, etc …).
On pourrait même éventuellement associer une carte sim (pour les téléphones qui en ont plusieur) à une sandbox donnée.
Il me semblait qu'un téléphone Android pouvait accepter d'utiliser plusieurs comptes, mais je n'ai jamais réussi à le faire fonctionner. Mais ce n'est pas exactement la même chose.
[^] # Re: J'y avais pensĂ© il y a quelques temps dĂ©jĂ
Posté par Psychofox (Mastodon) . Évalué à  4 (+1/-0).
Sur android tu peux effectivement avoir plusieurs utilisateurs
Sur mon pixel 6a sous grapheneos par exemple j'ai mon utilisateur principal sans compte google, j'ai un second utilisateur avec le dernier compte google qui me reste et zero contact ni données perso (mais au final il ne me sert à rien) et je crée parfois des utilisateurs supplémentaires quand je voyage et que par commodité je veux pouvoir installer des applis qui ne me serviront que le temps du voyage et n'ont pas à avoir accès à mes contacts et autres joyeusetées.
[^] # Re: J'y avais pensĂ© il y a quelques temps dĂ©jĂ
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à  6 (+3/-0).
Disons que Google ne font rien pour ça évidemment. Il existe des outils pour le faire, c'est assez compliqué à mettre en œuvre et ça nécessite un téléphone rooté pour commencer.
[^] # Re: J'y avais pensĂ© il y a quelques temps dĂ©jĂ
Posté par bubar🦥 . Évalué à  4 (+1/-0). Dernière modification le 09 avril 2025 à 23:27.
C'était le cas il y a longtemps, oui, et la question se pose tjs de la même manière et avec la même pertinence que ton journal en apparence innocent (pardon si j'interprète trop ou trop vite)
En dehors du fait, et en plus, qu'au final le choix va reposer sur l'utilisateur, qui par facilité va accepter des permissions non nécessaires logiquement, de base, et en plus illégitimes, il y a les nouveautés :
Aujourd'hui des apps vont faire appel à l'integrity check, par exemple, sans raison légitime là non plus, mais c'est bien sûr pour notre sécurité https://developer.android.com/google/play/integrity?hl=fr
si Xposed était particulièrement intéressant, amusant et génial il y a qq années, aujourd'hui il n'est plus suffisant et/ou obsolète et/ou là où il était utile ne l'est plus.
# permissions -> données
Posté par GwenLg . Évalué à  3 (+2/-0).
Pour l'avis sur le second intérêt, je ne pense pas que ça soit inefficace, ça rend la chose plus explicite, donc ça peut-permettre de critiquer plus facilement par exemple. Si on hésite entre deux applications pour faire une chose, avoir cette info peut aider à choisir. Mais je suis d'accords ça ne va pas corriger seul les problèmes de façon magique.
Il me semble que ce n'est pas de permissions bidons, mais de données bidons (fake) dont il est question.
La mise en place ne me semble pas évidente, enfin dans le sens où si on veut avoir des applications qui accèdent aux données valides, et d'autres à des données bidons, il faut que ça soit géré au niveau du système d'accès.
Mais par contre je suis à 100% avec l'idée, j'avais déjà essayé ce genre de chose pour la position gps sur smartphone.
Ça me fait penser une critique que j'ai envers les restrictions d'accès aux fichiers sous Android, et avec les
portailsFlatpak.Aujourd'hui, on peut ne pas autoriser une application à avoir accès aux fichiers de l'utilisateur (par exemple), mais dans ce cas on ne peut pas ouvrir un fichier spécifique avec cette application.
J'aimerais pouvoir interdire l'accès d'une application à tous les fichiers, mais que si je fais "ouvrir avec" à partir de l'explorateur (par exemple), l'application puisse dans ce cas ouvrir le fichier.
Après bien sur ça ouvre des questions qui font que ce n'est pas aussi simple que ça pourrait paraître :
- en lecture seulement ou aussi en écriture, si c'est au choix de l'utilisateur, ça veut dire qu'il faut que ça soit proposé dans l'interface.
- juste pour cette fois, où jusqu'à ce que l'autorisation soit (éventuellement) retirée.
J'ai vu passé des échanges qui pourrais concerner des travaux dans ce sens dans le système de "portails freedesktop", mais je n'ai pas creusé, je ne suis pas certain.
[^] # Re: permissions -> données
Posté par Samuel (site web personnel) . Évalué à  4 (+3/-0).
C'est précisément ce que font les portails. Par exemple le portail FileChooser : l'application Flatpak indique qu'elle veut permettre à l'utilisateur de choisir un fichier, l'environnement présente une fenêtre à l'utilisateur lui permettant de choisir ce fichier, flatpak fait ensuite apparaître ce fichier (et uniquement celui-là ) dans l'espace de fichiers visible par l'application et renvoie à l'application le nom / l'adresse de ce fichier.
[^] # Re: permissions -> données
Posté par GwenLg . Évalué à  4 (+3/-0).
Oui c'est ça.
Par contre l'usage n'est pas encore très répandue il me semble. Vivement que ça se démocratise.
# Privacy Guard
Posté par Thibault (site web personnel) . Évalué à  5 (+5/-0).
Peut-être que je me trompe car ça remonte à un peu loin pour moi, mais c'est ce que permettait Privacy Guard à l'époque de CyanogenMod.
De mémoire l'interface de Privacy Guard permettait de définir à quels trucs une application avait accès sur le téléphone (contacts, caméra, micro, localisation, …)
En parallèle on pouvait aussi ajuster les permissions de manière classique de l'application.
Et il me semble que j'avais des applications "poubelle" qui n'avaient pas d'accès aux contacts dans PG, mais qui avaient l'autorisation activée dans le panneau classique, et qui étaient contentes du coup, mais ne voyaient aucun contact.
# Android & caméra virtuelle
Posté par crak_en . Évalué à  2 (+2/-0).
Sur Android, pour la partie caméra tu as des caméras virtuelles, mais elle nécessite un appareil rooté au-delà d'Android 11 il me semble.
Par exemple : https://xdaforums.com/t/app-ghostcam-virtual-camera-for-android-phone.4697421/
Pour l'isolation des données sinon, tu as des applications qui permettent de virtualiser un appareil Android sur ton appareil sans root (exemple : https://play.google.com/store/apps/details?id=com.clone.android.dual.space&hl=fr)
[^] # Re: Android & caméra virtuelle
Posté par crak_en . Évalué à  5 (+5/-0).
Ah oui et pour bloquer l'accès réseaux à une application il a par exemple NetGuard (pas de root requis) : https://github.com/M66B/NetGuard
# Scopes dans GrapheneOS
Posté par Gesmas . Évalué à  6 (+6/-0).
GrapheneOS permet de limiter une autorisation donnée à une application. Basiquement, la fonction Storage Access permet de définir quel dossier peut voir une application.
Il a également une déclinaison pour les contacts : Conctact Scope. On peut définir des champs exploitables par l’application et/ou quels contacts sont visibles. Par exemple, permettre à Signal de voir uniquement le champs « téléphone mobile ».
L’avantage est que du point de vue de l’application l’autorisation est donnée sans qu’elle puisse savoir qu’elle a été limitée.
# Feedback
Posté par Colin Pitrat (site web personnel) . Évalué à  8 (+6/-0).
Personnellement quand une application fait ça (sauf si c'est ai coeur de l'appli) je supprime direct et met la note minimale avec un commentaire expliquant pourquoi. Si suffisamment de gens font ça, ces applis sont moins visibles et les devs sont obligés de prendre ça en compte.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.