Le processus de transformation d’une appli Android en page web

• Travelbound, qui affiche des itinéraires, des informations d’hébergement et des PDF, se contente en pratique d’afficher du contenu reçu depuis le web tout en y ajoutant du suivi et des publicités de voyage ; j’ai donc tenté de le remplacer par une page web fournissant les mêmes informations
• En rootant un appareil Android virtuel et en interceptant le trafic avec HTTP Toolkit, j’ai constaté qu’une API combinant le nom d’utilisateur et le mot de passe dans l’URL renvoyait tout le contenu de l’appli au format JSON
• Avec un script Ruby et Cron, le JSON le plus récent est récupéré périodiquement pour générer du HTML, en excluant les données publicitaires et en n’exposant que les fichiers nécessaires, comme l’itinéraire et les PDF
• La version web permet de copier, imprimer, enregistrer, mettre en favori et rechercher, fonctionne sur davantage d’appareils, et supprime aussi le code de suivi et les publicités de l’appli d’origine
• L’appli d’origine passe de 43 Mo à 124 Mo après téléchargement du contenu, tandis que la page web ne pèse que 0,05 Mo, avec 35 Mo seulement pour les images optionnelles : pour du contenu documentaire en HTML transmis via HTTP, le web est plus adapté

---

Travelbound aurait très bien pu être une page web

• Pour consulter l’itinéraire du voyage à Disneyland, les transports et les informations d’hébergement de l’école d’arts de la scène de mon enfant, il fallait installer l’appli Travelbound
• Le contenu principal de l’appli était constitué de texte, images et liens PDF transmis via le web
• Les fonctionnalités qui la distinguaient d’une page web étaient deux éléments défavorables à l’utilisateur
  • Envoi au développeur de données de suivi associées au Google Account
  • Publicité, sous le nom inspirations, pour d’autres voyages proposés par la même agence
• Une page web permet de copier, imprimer, enregistrer, mettre en favori et rechercher le contenu, de l’utiliser sur presque tous les appareils, et potentiellement d’améliorer aussi l’accessibilité

Intercepter le trafic d’une appli Android

• J’ai créé un nouvel appareil virtuel dans le Virtual Device Manager d’Android Studio et vérifié que adb shell fonctionnait
• J’ai rooté un appareil virtuel Android 33 avec rootAVD

  ./rootAVD.sh system-images/android-33/google_apis_playstore/x86_64/ramdisk.img  
  

• Le root était nécessaire pour faire en sorte qu’une appli utilisant le Certificate Pinning fasse confiance au certificat TLS auto-signé du proxy d’interception
  • Sans root, une appli comme Travelbound considère le certificat comme invalide et refuse la communication
• Après un démarrage à froid, j’ai lancé Magisk et configuré l’autorisation automatique de l’accès su aux applis qui le demandent
  • Sans autorisation automatique, HTTP Toolkit s’exécutait en mode non privilégié sans attendre la réponse de l’utilisateur
• J’ai intercepté le trafic de l’appareil virtuel Android avec HTTP Toolkit
  • Il installe un faux fournisseur VPN pour transmettre le trafic de l’appareil au proxy
  • En raison des contraintes de sécurité d’Android, le certificat CA racine installé devait être ajouté manuellement
• Après avoir installé Travelbound depuis le Play Store, j’ai configuré le proxy pour ne traiter que le trafic de cette appli afin de réduire le bruit

Appels d’API et structure des données

• L’appli appelait une URL d’API au format suivant, en concaténant le nom d’utilisateur et le mot de passe du groupe de voyage

  https://travelbound.api.vamoos.com/api/itineraries/…}  
  

• Le nom d’utilisateur et le mot de passe étaient des identifiants partagés par tout le groupe de voyage
• Le JSON renvoyé par l’API contenait tout le contenu affiché par l’appli
  • Un tableau contenant chaque segment de l’itinéraire
  • Un tableau publicitaire inspirations
  • Un tableau de références croisées contenant des fichiers, comme les images référencées par d’autres sections
• Les données incluaient même le code HTML à afficher par l’appli, ce qui rendait le mode de diffusion du contenu lui-même similaire à celui d’une page web
• Les URL d’images S3 avaient une durée d’expiration relativement courte, ce qui obligeait à récupérer périodiquement le JSON même si le contenu ne changeait pas
  • L’autre méthode consiste à mettre les images en cache localement ; l’appli d’origine semblait utiliser cette approche

Convertir le JSON en HTML

• J’ai écrit un script Ruby et l’ai configuré pour récupérer le JSON le plus récent selon une planification Cron, puis générer une page HTML
• Lors de la génération, les publicités inspirations correspondant à overlayRows dans le schéma de données ont été entièrement exclues
• La page web n’affiche que les informations suivantes
  1. Les éléments de l’itinéraire
  2. Tous les fichiers non référencés par les publicités ou l’itinéraire
• La seconde liste sert de moyen simple de regrouper les liens de téléchargement des PDF au même endroit
• La page générée est protégée par le même mot de passe que celui fourni au groupe de voyage existant
• Le JSON d’origine a été placé dans un élément <details>, afin de vérifier si des données de schéma non prises en compte par le script existant apparaissent plus tard

Une version web plus petite et plus flexible

• La page web est moins tape-à-l’œil que l’appli d’origine, mais elle est beaucoup plus légère et fournit les fonctionnalités de base du web sans implémentation supplémentaire
• Le contenu peut être copié, imprimé, enregistré, mis en favori et recherché, et il est accessible depuis une plus grande variété d’appareils
• En supprimant le code de suivi et les publicités, elle élimine aussi deux fonctionnalités inutiles présentes dans l’appli d’origine
• L’accessibilité n’a pas été auditée formellement, mais l’appli d’origine comportait des éléments qui semblaient plus difficiles à utiliser avec des technologies d’assistance qu’une simple version web

Comparaison de la taille et du mode de distribution

• L’appli Travelbound d’origine pèse initialement 43 Mo et atteint 124 Mo après le téléchargement du contenu supplémentaire
• La page web de remplacement pèse 0,05 Mo, avec 35 Mo supplémentaires si toutes les images sont téléchargées de manière optionnelle
• Les deux approches ont été partagées avec le groupe de voyage, afin que les utilisateurs puissent choisir entre l’appli et la page web
• Les applis sont adaptées à certaines tâches, mais le contenu Travelbound, déjà écrit en HTML et transmis via HTTP, n’est pas un cas qui nécessite une appli
• La distribution via un app store augmente les coûts et la charge de développement ; limiter ce type de contenu documentaire à une appli réduit le nombre de personnes pouvant l’utiliser et les fonctionnalités de base disponibles par rapport à une publication directe sur le web

[GN⁺]

Avis sur Lobste.rs

• J’en ai assez que des services qui, au fond, ne sont rien d’autre que des pages web conduisent à une inflation des apps ; heureusement, je ne suis pas le seul
  Sur Android, la création de raccourcis vers des pages web n’est pas très visible pour l’utilisateur, donc je comprends aussi pourquoi les entreprises préfèrent les apps. Mais pour un service qui envoie un mot de passe par SMS avec un lien vers l’app, une web app est de loin la plus adaptée. Il suffit de créer un lien direct vers la page du mot de passe
  La boutique d’apps de /e/OS a même une section « web apps » qui regroupe des éléments comme la version web de Google Maps. Les PWA elles-mêmes sont faciles à utiliser, mais je ne sais pas à quel point Chrome par défaut ou les Android des constructeurs mettent activement en avant la création de raccourcis et la rendent visible
  Il est clair que la méthode actuelle n’est pas pensée pour les utilisateurs, et il faut réfléchir à la manière de l’améliorer

• Pour l’utilisateur moyen, surtout quelqu’un qui n’est pas à l’aise avec l’informatique, la différence entre une app et une page web se résume en pratique au raccourci sur le bureau ou l’écran d’accueil
  S’il était possible de distribuer directement des raccourcis vers des pages web, ce serait une façon très peu coûteuse de développer des apps, et la plupart auraient peut-être pu être créées ainsi

  • Dans Safari sur iOS, si vous ouvrez une page web puis passez par le bouton de partage, « View More » et enfin « Add to Home Screen », vous pouvez ajouter une icône à l’écran d’accueil
    En appuyant sur cette icône, ce n’est pas un nouvel onglet de navigateur qui s’ouvre, mais une fenêtre autonome comme une app classique. J’ai moi-même distribué de cette manière un outil de suivi des dépenses familiales que j’ai créé, sans le publier sur l’App Store

• Une quantité innombrable d’« apps » pourraient très bien n’être que des pages web. Il est trop souvent frustrant de devoir d’abord installer une app pour utiliser une fonction mineure sans raison valable
  Qu’on utilise une app pour se connecter à un appareil local, c’est compréhensible, mais certains systèmes font quand même communiquer l’app avec l’appareil local en passant par un serveur central. À partir de là, même la seule justification d’installer une app disparaît
  Les premiers iPhone voulaient faire des pages web une plateforme d’apps, mais on a finalement abouti à l’écosystème chaotique que l’on connaît aujourd’hui