Voici un brouillon pour un point de programme, notamment à propos de la dépendance de fait aux GAFAMs dûe aux applis sur smartphone. Qu’est ce que vous en pensez ?
Droit à l’indépendance numérique
Exposé des motifs
La vie courante dans la société moderne est sujette à l’utilisation de services numériques qui peuvent être qualifiés de basiques, tels que :
Services publics
Services bancaires
Les usagers sont amenés à disposer de terminaux individuels tels que les « smartphones » pour pouvoir bénéficier de ces services, remplir leurs obligations de citoyens et participer à la vie en société.
La sécurité de ces services est essentielle, notamment de par leur nécessité d’identification de chaque usager et le traitement de leur données personnelles.
Bien qu’il existe des solutions techniques basées sur des modèles de sécurité ouverts, dans de nombreux cas ces services nécessitent l’installation d’applications qui peuvent entraîner une dépendance de fait à des entreprises privées choisies par les éditeurs de logiciels sans possibilité de choix pour les usagers.
De plus, ces entreprises sont souvent de droit étranger, n’offrent pas de garantie légale suffisante de transparence et de respect de la vie privée, et sont elles-même dépendantes, clientes ou fournisseurs de services à d’autres sociétés sans transparence et possibilité de choix pour les usagers.
Examples
Les cas des applications bancaires et d’identification sont particulièrement représentatifs.
Les banques publiques et privées obligent en pratique les usagers à utiliser des applications qui nécessitent que les terminaux des usagers (smartphone) verouiilés soit sur Google (Android) ou sur Apple (iPhone), et empêchent leur utilisation sur des appareils et avec des comptes utilisateurs qui ne sont pas validés par ces entreprises.
Les fournisseurs d’identité (FI) de services de « France Connect » et « France Identité », de plus en plus nécessaires pour effectuer des démarches administratives, ne proposent que des applications sur smartphone avec les mêmes restrictions que les applications bancaires.
Contenu de la proposition
Les services « basiques » (services publics, bancaires, etc) doivent proposer à leurs usagers des solutions qui n’imposent pas l’utilisation d’appareils verrouillés sur des plateformes tierces ni de comptes crées sur ces mêmes plateformes, et ne dépendent pas d’autres services que ceux des états pour l’identification des citoyens.
Quels sont les mécanismes de détection et de blocage en place aujourd’hui que ca voudrait interdire ?
Et quels sont les promesses de ses restrictions pour qu’elles soient aveugléments adoptées ?
Prenons comme exemple France Identité (FI) sur Android, mais le raisonnement est valable pour iOS et une application de banque.
Au lancement, FI demande à l’API Android si l’installation est certifiée par les services Google : appareil enregistré, sécurisé, installation avec le Google Play Store, etc. Tout cela dépend des services Google avec signatures et crypto fortes (maintenant avec des puces dédiées) et donc que l’utilisateur ait accepté les conditions d’utilisation de Google. Évidemment, rien n’est open source, l’OS communique avec le cloud Google et les droits des USA s’appliquent.
Comme les services Google sont installés avec des privilèges élevés, ils ont potentiellement accès à toutes les données des autres applications. Comme un compte dans le cloud Google est nécessaire, cela donne un pouvoir à l’entreprise et aux autorités américaines à peu près absolu sur l’appareil et toutes les données qui y transitent.
Pour des applications non essentielles on peut toujours arguer que c’est un choix des utilisateurs. Mais les services publiques ou privés essentiels comme les banques obligent en pratique les citoyens à accepter toutes ces conditions.
La promesse de Google est que les applications ont les garanties de l’identité des utilisateurs et de la certification des appareils. Pour l’identité, des solutions ouvertes permettant d’atteindre des hauts niveaux de sécurité existent : MFA (TOTP), OpenID Connect, etc.
Pour l’intégrité de l’appareil : Google impose ses règles et a un contrôle quasi absolu pour son bénéfice (voir par exemple https://keepandroidopen.org/). Difficile de faire plus opaque, autoritaire… et paradoxal, Android tournant sur un kernel Linux (OpenBSD pour iOS). C’est absurde, un peu comme dire que Linux n’est pas sécurisé parce que les utilisateurs peuvent développer ou installer des logiciels non validés par une autorité, surtout quand cette autorité n’est elle-même soumise à aucun contôle.
Les « décideurs » et les éditeurs font clairement le choix de la facilité : interroger une API est simple, mais ils ne mesurent pas l’ampleur des conséquences que cela implique en terme de dépendance (perte de souveraineté comme on dit maintenant), de liberté, etc. En d’autre termes, on nous oblige à donner les clefs de notre sécurité à des entreprises à qui on ne peut et doit pas faire confiance.
La question reste cependant. Ce que met en avant Google, c’est de garantir l’intégrité de l’appareil et de son OS pour éviter une faille de ce côté-là. Car justement, l’application risquerait de ne pas voir un comportement étrange, car masqué « a bas niveau ».
Cependant, je ne pense pas que cela soit totalement inaccessible à l’OpenSource. L’accès aux puces dédié ne me semble pas impossible, tout comme une vérification de la cohérence matérielle du coup.
Reste la garantie d’avoir un OS « fiable ». Je pense que c’est plus complexe, car il est difficile de définir ce qui est fiable et ce qui ne l’est pas ?
Je pense que l’argument massue de Google & Apple : eux seuls seraient en mesure de valider que l’appareil est sécurisé parce qu’ils ont le contrôle absolu, et que toute alternative serait par nature vulnérable. C’est donc aussi une attaque frontale à peine cachée aux modèles Open Source.
Je pense qu’on est tous plus ou moins convaincus ici que c’est absurde, mais on peut développer un peu :
Les “boîtes noires” que sont Google Services et iOS ont des failles patchées au fil de leurs mises à jour, personne ne sait combien de 0-days il reste et cela restera toujours le cas. Si Pegasus a toujours une longueur d’avance, pourquoi pas des groupes de hackers ?
Si Pegasus me vole mon compte bancaire ou mon identité, Google ou Apple ne prennent pas pour autant la responsabilité de ne pas avoir protégé mon appareil. En quoi offrent-ils donc une protection fondamentalement meilleure qu’un OS libre ?
Les problèmes de données personnelles ou sensibles qui sont traitées par ces boîtes noires. Intuitivement, pas grand monde aimerait que les opérations militaires soient menées avec des smartphones enrôlés chez Google. Alors, pourquoi le civil serait moins exposé à des abus de ces plateformes, qui ont un contrôle total sur les appareil et les données ?
Je ne pense pas qu’on puissent définir ce qu’est un système “fiable” avec des critères absolus : la sécurité est toujours un jeu du chat et de la souris. Par contre l’illusion de sécurité est une vulnérabilité.
Le modèle de l’Open Source est évidemment complètement différent, mais peut offrir le même niveau de sécurité, et probablement même mieux. On peut penser au Secure Boot des PCs qui peut être verrouillé sur des OS crypto-signés y compris alternatifs (voir ici). Malheureusement, les fabriquant de smartphones bloquent les bootloaders sécurisés sur les OS de Google ou Apple : c’est une conséquence directe de cette situation de duopole. En pratique, les applications genre France Identité ou bancaires l’imposent à tout le monde.
Idéalement on pourrait imaginer d’obliger tous les fabricants à ouvrir les bootloaders, mais je pense qu’il faudrait voir ça au niveau européen. Fondamentalement je pense que la question est la même, mais avec cette proposition on reste au niveau national.
Il y a GrapheneOS comme exemple : leur “ligne éditoriale” est d’avoir un Android open source (AOSP) dé-googlisé et le plus sécurisé possible, donc ils ciblent les Pixel justement parce qu’ils ont ces fonctions de sécurité.
Mais il y a un débat plus large, car effectivement certaines apps bancaires demandent des téléphones non-rootés (etc) – or en général on est détecté comme ayant rooté son téléphone si on installe un Android tiers –, il est de plus en plus difficile de rooter son téléphone voire de le débloquer pour installer un Android tiers (Samsung a pas mal restreint ces derniers temps), et la réglementation bancaire impose de plus en plus des procédés restrictifs “pour votre saycuritay”.
Du coup en effet on est de moins en moins propriétaires de nos téléphones… et ça risque de s’étendre aux PC, et c’est un vrai combat Pirate qu’il va falloir mener.
Cf, même si c’est un sujet un peu différent, systemd (Linux) qui a décidé de respecter les lois états-uniennes sur l’obligation des OS à inclure l’âge de l’utilisateur.
Belle idée, je proposerais de cadrer ça dans le « droit à l’intégrité numérique » (plutôt que « droit à l’indépendance » proposé et popularisé par notre collègue Pirate franco-suisse Alexis Roussel.
Sur la proposition elle-même : c’est vraiment difficile à rédiger de manière actionnable car qu’est ce qu’une “plateforme tierce”, qu’est ce qu’un “appareil verrouillé”, intuitivement on comprend, mais c’est difficile à formaliser correctement.
Idem sur “services autres que ceux des états”. J’ai d’ailleurs un doute **aussi* sur le fait d’accepter aveuglément des services d’identification d’état, auxquel je ne fais pas beaucoup plus confiance qu’aux GAFAM.
Je proposerais d’inverser la formulation : “Les services « basiques » (services publics, bancaires, etc) doivent proposer à leurs usagers des solutions compatibles avec les plateformes diffusées en sources (logiciels libres et sources ouvertes), sans nécessiter de fonctions matérielles spécifiques à une plateforme particulière. L’usage éventuel de services d’identification doit être réservé aux cas où leur nécessité en est démontrée, et ne pas forcer l’usage d’un service d’identification particulier.”
Enfin, je proposerais d’ajouter :
“Dans le cas des services administratifs publics, pour des raisons d’inclusion numérique, un accès physique classique doit systématiquement rester disponible pour les personnes ne disposant pas de matériel ou d’accès numériques adaptés.” (écrit à l’arrache, peut-être à reformuler).
La réaction est marrante (mais classique) car l’état est le plus gros pourvoyeur d’obsolescence programmée, en réalité, de par la “simple” évolution des normes. Automobile, logements, électricité, informatique, etc.
Hors état, l’obsolescence programmée est assez rare et rarement avérée, si on excepte les arrêts de mises à jour de logiciel, qui ne sont pas de l’obsolescence programmée au sens strict : pas un sabotage volontaire” au sens où on l’entend habituellement, mais une simple question d’intendance sur la durée.
D’ailleurs je proposerais que ce terme d’obsolescence programmée soit utilisé avec prudence et parcimonie, avec de grosses précautions oratoires, car le terme peut vite être dénoté comploplo (cf cas débunké de l’ampoule des pompiers de Livermore).
Pour moi, ce terme n’est pas assez clair. Certes je suis au PP et je comprends ce que ça sous-entend.
Mais je pense que pour la majorité des gens ça ne veut strictement rien dire.
(c’est un peu hors sujet (mais la définition des termes est un de mes combats ))
L’intérêt est d’avoir un terme assez “générique” correspondant à un mot compréhensible.
On comprend quand même qu’il s’agit de protéger les personnes. Étant générique, ça peut avoir valeur “constitutionnelle” pour ensuite être décliné suivant besoins.
Effectivement sa déclinaison ne va pas forcément de soi, on est d’accord. J’ai pas mal discuté avec Alexis et suivi ses avancées, ça a bien accroché en Suisse, donc je suis peut-être un peu “teinté” en le trouvant plus clair qu’il n’est. Peut-être de la pédagogie à faire, mais je trouve bien de se raccrocher à un mouvement déjà existant, mutualisation de l’effort.
Merci @PierreB pour ces commentaires et suggestions qui élargissent le débat. En attendant, voici quelques éléments un peu techniques sur le cadre légal pour les opérations financières en ligne, qui est une loi européenne : DSP 2. On pourrait débattre longuement sur cette directive européenne et son alignement avec les GAFAMs, mais je pense qu’il y a quand même un espace pour avancer.
[TL;DR] Que choisir éclaire un peu, le passage le plus intéressant, selon moi :
En l’absence de téléphone permettant d’utiliser l’application mobile de la banque, cette dernière doit vous proposer une solution alternative. Cela peut être :
l’envoi d’un SMS et l’utilisation d’un code personnel : un code à usage unique reçu par SMS ou service vocal ainsi que votre code personnel ou mot de passe habituel pour vos opérations en ligne ;
l’usage d’un dispositif physique dédié : cela peut être notamment un boîtier autonome qui génère un code à usage unique ou bien un lecteur de carte. Par exemple, au Crédit mutuel, avec le Digipass, il faut scanner le QR code affiché sur l’ordinateur, puis saisir son code sur le boîtier. Cela génère un code à 8 chiffres à usage unique, qu’il faut saisir sur l’ordinateur pour valider l’opération. La Banque populaire propose à ses clients ne disposant pas de smartphone le lecteur Pass CyberPlus.
Selon l’Observatoire de la sécurité des moyens de paiements, la banque doit proposer au moins une alternative gratuite à l’application mobile.
En pratique donc, il suffurait d’un code temporarire reçu par SMS. Alors, pourquoi pas TOTP ? La poste et d’autres sources disent que c’est OK pour donner une authentification forte. Ce rapport de la CNIL suggère qu’il faudrait que l’application soit dévérouillée par biométrie, or cet article précise bien que 2 critères sur 3 doivent être remplis (connaissance, posséssion, inhérence), donc ça ne me semble pas bloquant. D’ailleurs, la validation par SMS est acceptée et il n’est pas nécéssaire de scanner son iris pour lire un SMS…
Bref : il existe bien déjà une obligation aux banques de fournir une alternative aux « apps » et aux OS de Google/Apple, mais dans les faits les banques imposent plus ou moins leurs apps verouillées en distordant une loi européenne que peu de gens connaissent.
Donc il me semble que cette proposition doit être compatible avec la loi DSP 2, mais l’idée est élargir à un spectre plus large de services, dont France Connect/Identité, etc.
Enfin, il y a des débats intéressants dans plusieurs forums orientés geeks qui éclairent sur ces questions (et donnent des idées pour pouvoir faire tourner ces apps sur du matos gégooglisé), par exemple sur linuxfr : ici et là, et une pétition.
Il faut considérer le SMS comme mort en termes de sécurité : il y a de nombreuses attaques assez faciles et peu coûteuses pour un attaquant, et de longue date, pour récupérer des SMS d’une cible particulière. Cette solution pour le MFA a vocation à disparaître, pas à se développer.
[Jack Dorsey, fondateur de Twitter, s’est fait pirater son propre compte de cette façon, et ce n’est pas un exemple isolé
))