GuiGui's Show

J'veux jouer à un jeu vidéo uniquement disponible sur ordinateur de poche sans pour autant détenir un tel smartphone.

Une simple recherche sur le web me dégote un article de Korben sur Anbox, un système libre (GPL et Apache) qui utilise les conteneurs Linux (LXC, Docker, etc.) afin de faire tourner un système d'exploitation Android complet sur un ordinateur (équipé d'un noyau Linux, donc). Il ne s'agit pas d'un émulateur (performances préservées, tout ça).

Comme c'est un peu la galère à installer de bout en bout, voici mes notes d'installation / configuration sur un système Debian GNU/Linux Buster :

• Anbox est empaqueté dans Debian, mais j'utilise snap, car le script d'automatisation de l'installation des bibliothèques de fonction permettant l'exécution d'applications pour l'architecture ARM (voir ci-dessous) ne fonctionne pas sans snap (et vu que c'est la galère à installer à la mano…), et aussi parce que le paquet Debian ne fournit pas d'image système Android (rootfs) (on peut néanmoins en récupérer une sur le site web officiel d'anbox) ;
  
  
• Deux modules Linux sont nécessaires : ashmem_linux et binder_linux. Ils sont présents dans l'image Linux fournie par le projet Debian (pour s'en assurer : find /lib/modules/ -iname '*ashmem*') et ils seront chargés automatiquement au moment propice ;
  
  
• Installer le gestionnaire de paquets snap : sudo apt install snapd ;
  
  
• Installer anbox avec snap : sudo snap install --devmode --beta anbox. Le démon système qui gère le conteneur Android, container-manager, est automatiquement démarré à la fin de l'installation et au démarrage du système hôte ;
  
  

• Récupérer le script qui automatise l'installation des bibliothèques de fonctions permettant l'exécution d'applications mobiles conçues pour l'architecture ARM (source). Sans ça, l'installation d'un logiciel mobile ARM se soldera par l'erreur suivante : adb: failed to install <nom_apk>: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]. wget https://raw.githubusercontent.com/geeks-r-us/anbox-playstore-installer/master/install-houdini-only.sh ;

  • Si l'on veut installer Google Play, la logithèque de Google pour Android, on préférera récupérer un autre script : wget https://raw.githubusercontent.com/geeks-r-us/anbox-playstore-installer/master/install-playstore.sh. Installer le Google Play après avoir déjà installé les bibliothèques ARM a aucun impact. Je rappelle que Google Play nécessite la possession d'un compte Google et que sa création nécessite la validation d'un numéro de téléphone mobile… ;
    • Attention : ce script pour installer Google Play ne fonctionne pas nativement : il se termine très rapidement sans rien afficher. Origine du problème ? La commande « which anbox » de la ligne 108 retourne rien quand anbox est installé via snap. Il faut remplacer cette ligne par ANBOX='/snap/bin/anbox' ;
• Installer les logiciels nécessaires à l'exécution du script récupéré à l'étape précédente qui ne sont pas encore installés : sudo apt install curl lzip ;
  
  
• Installer les bibliothèques de fonctions permettant l'exécution d'applications mobiles conçues pour l'architecture ARM : bash install-houdini-only.sh ;
  
  
• Démarrer le gestionnaire de sessions anbox : snap run anbox session-manager. Il s'agit d'un processus utilisateur, pas système. Attention : cette commande ne rend pas la main, donc on peut la lancer en fond (nohup snap run anbox session-manager &) si l'on le souhaite, mais je préfère ne pas le faire afin de pouvoir la tuer avec un ctrl+c puis la relancer avec un flèche_haut+entrée ;
  
  
• Sans Google Play, l'installation d'applications se fait avec la commande adb. Il faut donc récupérer le fichier apk kiVaBien ;
  
  
• Installer adb : sudo apt install adb ;
  
  
• Installer l'application dans le conteneur : adb install <appli>.apk ;
  
  
• Se rendre dans le menu des applications mobiles installées : snap run anbox launch --package=org.anbox.appmgr --component=org.anbox.appmgr.AppViewActivity ;
  
  
• Lancer l'application mobile. \o/

Commandes utiles :

• Redémarrer le démon système qui gère le conteneur Android : sudo snap restart anbox.container-manager. Cela permet parfois de terrasser un bug genre une application mobile qui ne démarre pas ou le réseau à l'intérieur du conteneur qui n'est pas configuré au démarrage du système hôte ;
  
  
• Lister toutes les applications mobiles installées : adb shell su 0 pm list packages ;
  
  
• Désinstaller une application mobile : adb uninstall <nom_unique>. Pour connaître le nom unique d'une application, on peut lister l'ensemble des applications installées (voir point précédent). Si l'on ne la trouve pas dans la liste, on peut exécuter la commande adb shell su 0 ps pendant que l'application est en cours d'exécution afin de tenter de l'identifier ;

Notes utiles :

• Modifier la date / heure à l'intérieur du conteneur Android, depuis le menu des paramètres ou avec adb shell + la commande date, ne fonctionne pas, même en désactivant la synchronisation par le réseau. C'est normal : il s'agit d'un conteneur LXC. ;) Solution : changer la date / heure sur le système hôte ;
  
  
• Le trafic réseau du conteneur Android arrive sur l'hôte via l'interface réseau anbox0. Le transfert IPv4 est activé par défaut. Rien de plus. Si tu filtres tes accès sortant, il faut donc ajouter une règle Netfilter genre sudo nft add rule inet filter FORWARD iifname "anbox0" counter accept.

Carte de France collaborative de la surveillance sécuritaire de l'espace public : drones, police prédictive, vidéosurveillance automatisée, reconnaissance faciale, capteurs sonors, safe city, etc.

Via https://twitter.com/technopolice_fr/status/1292759840780148738 via https://twitter.com/vincib/ .

Une analyse critique de la généralisation à prévoir de la confidentialité différentielle (manipuler des données personnelles tout en utilisant des statistiques et, éventuellement, de la cryptographie afin d'empêcher des croisements / levées d'anonymat) par les géants du net. Pérennisation du "business as usual" autour des données personnelles face au RGPD (il voit d'un bon œil les stats, la prétendue anonymisation, tout ça, le RGPD) en racontant potentiellement du bullshit (si l'anonymiseur est celui qui bénéficie financièrement du traitement de données persos, comment garantir qu'il ne désanonymisera pas les données pour son propre compte ? ‒ pompier pyromane ‒) et en permettant, de fait, de fuir tout questionnement autour de la protection de notre intimité ("faites-nous confiance, c'est de l'anonymisation military-grade avec tout plein de calculs compliqués dedans !").

Péréniser l’exploitation commerciale des données personnelles en dégradant leur granularité par des mécanismes cryptographiques, c’esi ici une intéressante approche poussée par Google et d’autres.

[…]

Le concept s'appelle confidentialité différentielle, et vous risquez d'en entendre parler ces prochains mois vu que Google commence à envoyer l'artillerie lourde pour pousser ce concept. Rappel des faits : il y a environ un an, Google publiait sa bibliothèque dédiée. Il n'est pas le premier à s'intéresser à ce concept. Apple avait placé ses pions en 2016, mais de manière peut-être moins ostantatoire. Normal car, contrairement à Google, la collecte des données n'est pas la principale source de revenu d'Apple.

[…]

[…] C'est bien ce que propose la confidentialité différentielle en introduisant des aléas mathématique dans les sets de données afin qu'un croisement ultérieur non prévu ne permette pas d'identifier nomminativement une personne.

Quand un acteur soutient qu'il anonymise les données, il se garde souvent d'expliquer par quel procédé il parvient à une anonymisation interdisant à des tiers, mais aussi à lui-même, de "désanonymiser" ces données. […]

[…]

[…] Le RGPD a sifflé la fin d'une récréation et ceci a été anticipé de longue date par quelques gros acteurs qui voient dans l'anonymisation de la collecte une piste pour continuer à exploiter ces données personnelles.

[…]

Selon le principe du pompier pyromane, c'est celui qui collecte qui "anonymise", qui stocke, qui traite, et qui monétise... Au doigt mouillé, c'est ce que l'on appelle un bug d'architecture.

[…]

C'est encore l'un des coups de génie de Google qui va s'approprier la généralisation du concept de confidentialité différentielle. L'objectif est ici de se poser en "tiers de confiance" et ainsi enfermer un peu plus un public déjà captif de professionnels qui pourront brandir ce nouvel argument pour instaurer un climat de confiance avec leurs propres clients... Parce que le client, "il a confiance en Google".

Via https://twitter.com/bearstech/status/1291009891688210433 .

J'aime beaucoup l'exemple exposé dans la fiche Wikipedia de la confidentialité différentielle, car il permet de nuancer la critique enflammée précédente :

La confidentialité différentielle est souvent obtenue en appliquant un procédé qui introduit de l'aléa dans les données. Un exemple simple, qui s'est notamment développé en sciences sociales6, est de demander à une personne de répondre à la question "Possédez-vous l'attribut A ?" selon le déroulement suivant :

1. Lancer une pièce.
2. Si pile, alors répondre honnêtement.
3. Si face, alors lancer à nouveau la pièce et répondre "Oui" si face, "Non" si pile.

La confidentialité surgit du caractère réfutable de chacune des réponses individuelles. En particulier, si A est synonyme de comportement illégal, alors répondre "Oui" n'est pas incriminant, dans la mesure où la personne a une probabilité d'un quart de réponse "Oui", quel qu'il en soit. Mais, de façon globale, ces données sont significatives, puisque les réponses positives sont données à un quart par des personnes qui n'ont pas l'attribut A et à trois quart par des personnes qui le possèdent véritablement. Ainsi, si p est la proportion véritable de personnes ayant A, alors on s'attend à obtenir (1/4)(1-p) + (3/4)p = (1/4) + p/2 réponses positives. D'où une estimation possible de p.

Bien que cette illustration, s'inspirant de la réponse aléatoire, puisse s'appliquer à la divulgation de micro-données (c'est-à-dire de jeu de données contenant une entrée par participant), la confidentialité différentielle exclut par définition ce type de divulgation, en ne permettant que la divulgation de données agrégées par requêtes. En effet, la divulgation de micro-données violerait les axiomes fondant la confidentialité différentielle, dont notamment le déni plausible d'inclusion ou d'exclusion de participants

Résumé : fin juillet 2020 = premières observations publiques d'un blocage, par la censure chinoise, des connexions TLS qui utilisent ESNI afin de masquer le nom du serveur auquel la communication chiffrée est adressée.

Lors de l'établissement d'une connexion chiffrée (HTTPS, IMAPS, etc.), le client (navigateur web, logiciel de courriel, etc.) indique, en clair (sans chiffrement), le nom de la machine à laquelle il veut se connecter. Cela permet au serveur de présenter le bon certificat x509 dans le cas où il héberge plusieurs services différents derrière une même adresse IP (hébergement web mutualisé, par exemple). C'est l'extension Server Name Indication ‒ SNI ‒ de TLS.

Dans le nouveau protocole TLS, le 1.3, et contrairement aux protocoles antérieurs, l'établissement de la connexion est chiffré (voir mon article de présentation de TLS 1.3 pour les détails), donc on peut envisager de masquer totalement le nom du serveur. Le projet le plus avancé se nomme Encrypted Server Name Indication ‒ ESNI. On peut lire le cahier des charges ESNI si l'on veut se rendre compte que le problème n'est pas simple à résoudre, car il est de la forme "œuf et poule".

ESNI n'est pas encore normalisé et il est très très peu déployé, mais, depuis fin juillet 2020, la censure chinoise bloque déjà les connexions chiffrées qui utilisent cette nouvelle extension de TLS. Au moins, les adminsys du gouvernement chinois se tiennent informés, ce qui n'est pas commun dans la profession (même si chacun prétend que, lui, se tient à jour). :)

J'évoquais ce genre de filtrage dans mon article sur les apports et les limites de DNS over HTTPS / TLS et sur ce que ces protocoles changent pour un adminsys. Si l'on chiffre, à raison car il est très bavard / indiscret, le trafic DNS, alors la censure sera déportée sur SNI puis sur ESNI puis sur l'adresse IP, et la seule parade utilisable par le commun des mortels sera une centralisation des contenus chez une minorité d'hébergeurs / fournisseurs de services. La Chine ouvre la voie.

Via https://twitter.com/kkomaitis/status/1292160887206432769 via https://twitter.com/bluetouff .