Nous avons effectivement des référentiels de pensée différents, peut-être opposés (nous ne sommes pas allés dans le détail non plus), et vraiment je n'ai aucun problème avec cela. La diversité d'opinions est une bonne chose. Malgré tout, je ne pense pas que tout peut être relativisé. Il y a des faits dont peut vérifier l'authenticité. Je ne dis pas que mes articles sont dépourvus de biais, car évidemment des biais même inconscients peuvent se glisser dans ma façon d'agir. J'essaie quand même au maximum de promouvoir les analyses objectives, qui sont parfois froides, mais nécessaires. Je vais essayer d'expliquer brièvement ma pensée sur le sujet.
Pour remettre dans le contexte, Android est un système d'exploitation moderne qui se démarque des autres systèmes traditionnels par son application des bonnes pratiques, notamment un écosystème d'applications signées qui sont contenues dans des sandbox très restreintes. Ce dernier permet l'établissement d'un modèle de permissions qui se modernise au fur et à mesure des itérations d'Android. Ce sont les garanties "fortes" dont je parle. Si je souhaite qu'une application n'ait pas accès à mes contacts, elle ne doit pas avoir accès. Si je souhaite qu'elle ait accès à un dossier, je lui donne la permission pour ce dossier seulement.
Je pense effectivement que la disponibilité du code source ne doit pas être une préoccupation majeure dans le cadre d'une approche pragmatique (et pas forcément éthique), tant le code source peut être complexe à comprendre et auditer. De plus, les applications Android sont souvent précompilées en bytecode Dalvik, qui peut toujours se soumettre à l'ingénierie inverse. Le modèle de développement d'un logiciel quel qu'il soit ne doit pas être un feu vert automatique pour savoir que ce dernier fait seulement ce qu'on attend de lui, ou ne contient pas de code vulnérable inconnu du développeur. C'est pour cela que j'insiste sur les garanties fortes permises par des OS modernes. Je vous assure qu'elles sont suffisantes pour l'écrasante majorité des cas, il incombe ensuite à l'utilisateur de décider des permissions à accorder. Les permissions invasives ne sont jamais octroyées par défaut sur de tels OS.
Pour revenir à F-Droid : par leur "contrôle qualité offrant peu de garanties", j'entends que beaucoup de personnes se contentent de F-Droid en tant qu'autorité pour déterminer si une app est sûre ou non. La réalité est que F-Droid n'audite en rien le code source, et lance simplement des scripts pour chercher des trackers connus ; ce qui encore une fois, est une approche que je trouve faible. J'insiste donc sur le fait que F-Droid est une partie intermédiaire qui ne se substitue en rien à la confiance au développeur upstream. Et on ne peut pas leur en vouloir, il n'est pas raisonnable de se lancer dans des audits de code source qui sont humainement laborieux et imprécis.
Je propose donc de placer cette confiance, pour ceux qui souhaitent suivre une approche pragmatique encore une fois, dans le modèle de sécurité robuste de l'OS. C'est évidemment encore mieux sur GrapheneOS qui ajoute un toggle permettant de révoquer la permission INTERNET (coupant cout les tentatives d'exfiltration), et un autre permettant de fournir des données de capteur nullifiées. Mais même Android upstream s'améliore comme dit : cf. les permissions Nearby Devices, et l'ajout à venir d'un sélectionneur granulaire de photo dans MediaProvider, le scoped storage en vigueur depuis le niveau d'API 30. Même s'il y a exfiltration, l'application ne peut avoir accès qu'aux permissions qu'on lui donne à la base, et donc à des types de données précis. Il est tout à fait possible qu'en pratique les applications open-source soient plus enclines à respecter la vie privée. Cependant, je propose tout simplement de ne pas placer cette forme de confiance tout en haut de la hiérarchie, car elle relève de l'appréciation personnelle et du modèle de menace de chacun.
Je n'ai évidement aucun problème avec le logiciel libre et la culture libre dans son ensemble. Il est vrai qu'à titre personnel je ne m'y reconnais plus bien qu'elle ait bercé mon adolescence (je lisais d'ailleurs linuxfr depuis plus de 10 ans), et je lui dois la découverte de nombreux projets. Dans cet article je m'adresse seulement à des faiblesses de F-Droid, et je souhaite réellement voir émerger d'autres alternatives plus en accord avec le modèle de sécurité pensé par et pour Android, qu'elles viennent de GrapheneOS ou d'ailleurs. Les gens sont libres de continuer à utiliser F-Droid, de leur faire confiance, j'expose simplement quelques problèmes dont certains peuvent être réglés par F-Droid pour le bénéfice de tous.
[^] # Re: Désaccord de principe
Posté par Wonderfall (site web personnel) . En réponse au lien F-Droid: how is it weakening the Android security model ?. Évalué à 2. Dernière modification le 27 février 2022 à 03:58.
Nous avons effectivement des référentiels de pensée différents, peut-être opposés (nous ne sommes pas allés dans le détail non plus), et vraiment je n'ai aucun problème avec cela. La diversité d'opinions est une bonne chose. Malgré tout, je ne pense pas que tout peut être relativisé. Il y a des faits dont peut vérifier l'authenticité. Je ne dis pas que mes articles sont dépourvus de biais, car évidemment des biais même inconscients peuvent se glisser dans ma façon d'agir. J'essaie quand même au maximum de promouvoir les analyses objectives, qui sont parfois froides, mais nécessaires. Je vais essayer d'expliquer brièvement ma pensée sur le sujet.
Pour remettre dans le contexte, Android est un système d'exploitation moderne qui se démarque des autres systèmes traditionnels par son application des bonnes pratiques, notamment un écosystème d'applications signées qui sont contenues dans des sandbox très restreintes. Ce dernier permet l'établissement d'un modèle de permissions qui se modernise au fur et à mesure des itérations d'Android. Ce sont les garanties "fortes" dont je parle. Si je souhaite qu'une application n'ait pas accès à mes contacts, elle ne doit pas avoir accès. Si je souhaite qu'elle ait accès à un dossier, je lui donne la permission pour ce dossier seulement.
Je pense effectivement que la disponibilité du code source ne doit pas être une préoccupation majeure dans le cadre d'une approche pragmatique (et pas forcément éthique), tant le code source peut être complexe à comprendre et auditer. De plus, les applications Android sont souvent précompilées en bytecode Dalvik, qui peut toujours se soumettre à l'ingénierie inverse. Le modèle de développement d'un logiciel quel qu'il soit ne doit pas être un feu vert automatique pour savoir que ce dernier fait seulement ce qu'on attend de lui, ou ne contient pas de code vulnérable inconnu du développeur. C'est pour cela que j'insiste sur les garanties fortes permises par des OS modernes. Je vous assure qu'elles sont suffisantes pour l'écrasante majorité des cas, il incombe ensuite à l'utilisateur de décider des permissions à accorder. Les permissions invasives ne sont jamais octroyées par défaut sur de tels OS.
Pour revenir à F-Droid : par leur "contrôle qualité offrant peu de garanties", j'entends que beaucoup de personnes se contentent de F-Droid en tant qu'autorité pour déterminer si une app est sûre ou non. La réalité est que F-Droid n'audite en rien le code source, et lance simplement des scripts pour chercher des trackers connus ; ce qui encore une fois, est une approche que je trouve faible. J'insiste donc sur le fait que F-Droid est une partie intermédiaire qui ne se substitue en rien à la confiance au développeur upstream. Et on ne peut pas leur en vouloir, il n'est pas raisonnable de se lancer dans des audits de code source qui sont humainement laborieux et imprécis.
Je propose donc de placer cette confiance, pour ceux qui souhaitent suivre une approche pragmatique encore une fois, dans le modèle de sécurité robuste de l'OS. C'est évidemment encore mieux sur GrapheneOS qui ajoute un toggle permettant de révoquer la permission INTERNET (coupant cout les tentatives d'exfiltration), et un autre permettant de fournir des données de capteur nullifiées. Mais même Android upstream s'améliore comme dit : cf. les permissions Nearby Devices, et l'ajout à venir d'un sélectionneur granulaire de photo dans MediaProvider, le scoped storage en vigueur depuis le niveau d'API 30. Même s'il y a exfiltration, l'application ne peut avoir accès qu'aux permissions qu'on lui donne à la base, et donc à des types de données précis. Il est tout à fait possible qu'en pratique les applications open-source soient plus enclines à respecter la vie privée. Cependant, je propose tout simplement de ne pas placer cette forme de confiance tout en haut de la hiérarchie, car elle relève de l'appréciation personnelle et du modèle de menace de chacun.
Je n'ai évidement aucun problème avec le logiciel libre et la culture libre dans son ensemble. Il est vrai qu'à titre personnel je ne m'y reconnais plus bien qu'elle ait bercé mon adolescence (je lisais d'ailleurs linuxfr depuis plus de 10 ans), et je lui dois la découverte de nombreux projets. Dans cet article je m'adresse seulement à des faiblesses de F-Droid, et je souhaite réellement voir émerger d'autres alternatives plus en accord avec le modèle de sécurité pensé par et pour Android, qu'elles viennent de GrapheneOS ou d'ailleurs. Les gens sont libres de continuer à utiliser F-Droid, de leur faire confiance, j'expose simplement quelques problèmes dont certains peuvent être réglés par F-Droid pour le bénéfice de tous.