La raison invoquée pour cette mesure radicale était un manque de sources ou d’instructions sur comment obtenir les sources des dépendances embarquées avec le code de Meta-Press.es.

Lorsqu’on utilise des bibliothèques de fonctions écrites par d’autres et minifiées (pour prendre moins de place) la règle était de fournir un lien vers la source de cette bibliothèque. Alors, depuis 5 ans, je copiais à chaque nouvelle version la liste des dépendances depuis le fichier README du projet dans les Notes adressées aux inspecteurs.

Le message de rejet était présenté dans une interface façon forum de discussion, commençant par leur message de menace.

J’ai donc tenté une réponse :

Je n’ai jamais reçu de réponse et Meta-Press.es fut effectivement désactivée le surlendemain. La version incriminée, ainsi que toutes les versions précédentes depuis 5 ans. D’un coup vous n’apparaissez plus dans le moteur de recherche et la page de l’extension est inconnue sur AMO (erreur 404).

J’ai alors fourni une nouvelle version de Meta-Press.es n’incluant plus de code minifié. J’ai trouvé 14 fichiers JavaScript ou CSS à remplacer par leurs originaux, mis à jour pour l’occasion, à quelque chose malheur est bon). Et puis, un JavaScript libre ne doit pas être minifié…

Mais cette nouvelle version fut elle aussi refusée, avec le même message d’erreur, plus un nouveau ! (ouf)

Ils réclamaient en fait l’URL exacte des fichiers utilisés comme bibliothèques de fonctions tierces. Pourquoi pas, s’il s’agit de vérifier que la version embarquée dans Meta-Press.es est une copie fidèle de l’originale ça a du sens. Et puis, cette fois j’ai eu droit à un lien vers de la documentation en ligne pour éclairer le problème et me guider vers une solution :

J’ai donc pu produire une nouvelle version de Meta-Press.es ainsi que la bonne liste de liens. On notera au passage que si une bibliothèque de fonction n’est pas directement accessible en ligne, il devient compliqué de l’utiliser dans une extension… il faut bien en passer par là pour vérifier automatiquement le code embarqué et c’est un bon point de savoir qu’il n’y a plus l’ombre d’un code mystérieux sur AMO.

Toutefois, le projet CodeMirror v5 par exemple, réparti son code de développement dans plusieurs centaines de fichiers et compile tout pour produire une archive (.zip) unique contenant le code minifié pour chaque nouvelle version. C’est bien pratique pour lors du développement d’avoir un code bien structuré, et c’est pratique pour les utilisateurs de n’avoir qu’un fichier à intégrer.

Mais bon, dans notre cas, comme en fait CodeMirror v5 utilise aussi des plugins, qui entrainent parfois eux-mêmes des dépendances (pour la coloration syntaxique et/ou la détection des erreurs dans du JSON), la maintenance de l’intégration de CodeMirror a Meta-Press.es a été abandonnée à cette occasion. Les sources ajoutées par les utilisateurs le sont désormais en texte brut dans un textarea standard. Peut être que CodeMirror v6 serait plus pratique à utiliser…

Il fallut donc encore plusieurs heures de travail, hors de tout planning, pour se mettre en conformité. Mais bientôt une nouvelle version de Meta-Press.es était proposée à Mozilla.

Mais ce ne fut toujours pas suffisant et cette version fut elle aussi rejetée. Seule consolation : un nouveau message d’erreur était fourni.

La partie coupée au début correspond au premier paragraphes de message d’erreur répétés encore et toujours en préambule. Puis vint le nouveau message d’erreur, correspondant à une nouvelle règle, étayée par une nouvelle documentation.

Si vous apprenez à coder, vous verrez qu’on utilise souvent une variable nommée simplement « i » comme itérateur dans les boucles for. C’est une convention, issue des notations mathématiques et plutôt pratique à l’usage… mais là non, ce n’est plus possible.

Bon, à vrai dire j’utilisais plusieurs autres variables nommées d’une seule lettre dans le code de Meta-Press.es. En effet, ce qui avait commencé comme des situations claires, contenues dans un seul écran d’affichage, où une variable courte était bien lisible, s’est progressivement répandu dans tout le code, en suivant sa croissance et sa structuration en différents fichiers…

Sans autre consigne et toujours dans l’urgence de la situation, il fut décidé de remplacer toutes les variables nommées d’une seule lettre par de confortables trigrammes (voir des groupes de trigrammes : src pour une définition de source, src_key pour la clé d’une définition de source…). Qui aurait été d’humeur a chercher par dichotomie le seuil exact de tolérance de l’algorithme de vérification ?

Habitué à m’adresser à des machines j’en profitai pour accompagner cette nouvelle version de 3 messages expliquant ma démarche… mais, suspens, cette nouvelle version fut refusée !

Au moins, je reçu un nouveau message d’erreur (signe que la précédente réaction avait bien réglé le problème visé) :

Bon, cette fois ce fut facile, en plus de la documentation pointée ils m’indiquèrent le fichier incriminé. Il ne fut pas long de constater qu’une grosse expression régulière était utilisée dans ce fichier pour découper des textes en mots (en essayant de tenir compte de la ponctuation de toutes les langues supportées par Unicode).

En cherchant une autre approche à ce problème une solution plus simple fut découverte, basées sur les récentes catégories générales (\p{Letter}\p{Number}) dans les expression régulières Unicode (alors que la précédente solution s’étalait sur 15 lignes de définition de ranges bordés d’UTF-16 dans une expression régulière relativement absconse.

Cette nouvelle version fut postée le 9 octobre alors qu’une conférence de présentation de Meta-Press.es lors de l' OSSym24 était prévue le lendemain. Tant qu’à parler avec un automate, on pourrait au moins espérer qu’il réponde vite… mais cette version 1.8.17.4 n’a finalement été approuvée que le 16 octobre, presqu’un mois après le début des hostilités.

Aucune nouvelle fonctionnalité dans cette histoire, mais objectivement un meilleur code.

Fin 2017 quand le développement de Meta-Press.es démarrait vraiment, la version courante utilisable pour ce manifeste était la version 2. Il s’agissait déjà d’un mouvement de conciliation de la part de Mozilla qui adoptait ainsi la norme proposée par Google, abandonnant toutes les précédentes extensions basées sur la technologie XUL. Ils n’ont jamais eu peur de jeter du travail, fusse-t-il bénévole. Après, objectivement, j’étais ravi de m’éviter l’utilisation de la pile logicielle XUL au profit d’une solution un peu plus JavaScriptesque.

5 ans plus tard, en 2022, les principales parties prenantes du JavaScript avaient travaillé à une évolution de cette norme pour permettre de nouveaux usages, simplifier certaines API inutilement complexes et améliorer un peu partout la sécurité. Mais pas seulement.

Appliquant la fameuse méthode de Microsoft pour attaquer les standards ouverts bien établis au profit de ces propres produits commerciaux (Embrace, extend, and extinguish), Google décida d’utiliser cette évolution de la norme des WebExtensions (devenue un standard suite à l’adoption par Firefox) pour améliorer le rendement de son activité commerciale de vendeur de publicité en ligne. En effet, ce qui était proposé n’était rien moins qu’un cadre de développement dans lequel il n’était plus possible de faire tenir un bloqueur de publicité.

C’est assez surprenant quand on sait que la WebExtension la plus utilisée, et de très loin, c’est uBlock Origin, un bloqueur de pub efficace et honnête, adopté par 9 millions d’utilisateurs de Firefox.

Saisissant l’opportunité au vol, Mozilla se remit au travail et élabora un moyen d’accepter le manifest v3 comme imposé par Google, mais en gardant les API nécessaires au fonctionnement d’un bloqueur de pub.

Google a semble-t-il été très déçu, car ils ont tout simplement abandonné leur calendrier de déploiement du manifest version 3 pendant 2 ans. Et ce n’est qu’en 2024 qu’ils se décidèrent à abandonner à Mozilla l’exclusivité d’une fonctionnalité recherchée par des millions d’utilisateurs en annonçant un nouveau calendrier de déploiement du MV3 pour 2024.

À l’heure d’écrire ces lignes, uBlock Origin est toujours fonctionnel dans un Chromium à jour, mais un message annonce que : « Ces extensions ne seront peut-être bientôt plus prises en charge ». Voilà une bonne information, bien fiable et solide comme on est fondé d’en attendre d’une multinationale planétaire dont le chiffre d’affaires dépasse le PIB du Portugal ou de la Roumanie (env. 280 milliards de dollars) et une capitalisation boursière supérieure au PIB du Brésil, ou de la Russie (vers 1500 milliards de dollars).

Puisque Firefox fonctionne désormais aussi avec des WebExtension en manifest version 3, Meta-Press.es a été mise à jour vers cette version, avec l’aide du programme NGI Zero via la NLnet.

En l’espèce, pour Meta-Press.es, les différences ne sont pas extraordinaires.

Les précédentes background pages, qui permettaient de laisser un script tourner en arrière plan au lieu de le rattacher forcément à une page web sont remplacés par d’officiels background scripts (sans plus accès aux fonctionnalités d’une page web) côté Firefox et par des service_workers dans Chromium. Dans les deux cas le script en arrière plan se fait suspendre au bout d’un moment s’il n’est pas sollicité. Cela impacte encore actuellement la fonctionnalité de recherches programmées de Meta-Press.es bien que l’API recommandée alarms soit mise en œuvre.

Autre point, les permissions réclamables par la WebExtension ont été revues et l’opportunité en fut saisie pour déclarer une liste exhaustive des sources connues par Meta-Press.es directement dans le manifeste ce qui évite d’avoir à demander ces permissions après l’installation de l’extension. Toutefois, la permission optionnelle <all_urls> a du être conservée afin de permettre aux utilisateurs d’ajouter eux-mêmes leurs sources à Meta-Press.es.