Le danger des extensions
Version originale par David Baron
Traduit de l’anglais par Flore Allemandou
David Baron travaille à la Mozilla Corporation et participe à l’élaboration de Mozilla depuis 1998. Il est actuellement le responsable du module « style system », du composant Bugzilla et il est un « super-reviewer » de code. Il fait également partie du groupe de travail du W3C sur les CSS.
Depuis quelques temps, je suis préoccupé par la qualité des extensions de Firefox et j’aimerais expliquer pourquoi. Pour commencer, je pense que la motivation originelle pour un système d’extensions dans Firefox était de réduire la demande de fonctionnalités supplémentaires qui ne sont utilisées que par peu de personnes ou qui sont expérimentales. Ceci ne me pose pas de problème. En revanche, que les extensions soient vantées auprès de nombreux usagers comme un des avantages de Firefox est plus préoccupant. Je pense que ça risque de revenir hanter la communauté Mozilla.
J’ai l’impression que les extensions sont couramment utilisées et pas uniquement par les utilisateurs les plus avancés de Firefox. Ce qui signifie que les problèmes dus à des extensions changent du tout au tout la perception de la qualité des produits Mozilla par l’utilisateur. Mais les extensions ne sont pas de la même qualité que les applications qu’elles étendent.
Le contrôle qualité des applications Mozilla
Que veux-je dire par qualité ? Chacun a sa propre définition. C’est là le nœud du problème. Cela pourrait vouloir dire que le programme fait ce qu’il est censé faire. Ou que son interface est simple à comprendre pour l’utilisateur. Ou qu’il n’a pas de trou de sécurité. Ou qu’il n’utilise pas une quantité excessive de mémoire ou n’a pas de fuite de mémoire [1] au cours du temps. Ou qu’il est rapide. Ou encore qu’il respecte les conventions de l’environnement dans lequel il tourne (Windows, MacOS, Gnome, etc.). Ou bien d’autres choses.
Les applications Mozilla sont développées dans un environnement et avec des outils et conventions conduisant à l’ouverture et à la responsabilité. Ceci permet à différentes personnes de travailler à améliorer différents critères de qualité et ainsi améliorer la perception par l’utilisateur de la qualité de l’ensemble. L’arbre des sources est accessible de nombreuses façons, il est facile de surveiller les changements qui y sont faits (en gardant à l’esprit la réputation des personnes qui font ces changements), la majorité de ces changements a été discutée publiquement sur des bugs et le code vérifié par des « reviewers », lesquels en sont responsables. Ce qui est changé, la raison de ce changement et qui l’a fait sont généralement clairement mentionnés. Et suffisamment de personnes (« eyeballs ») ayant ces différentes idées de qualité surveillent les changements, ce qui fait que les modifications altérant la qualité selon la plupart des critères définis sont rapidement repérées.
De plus, comme le code source de Mozilla est dans un seul dépôt, il est possible d’améliorer la qualité selon un critère donné ou un autre. Il est facile de chercher dans tout l’arbre un dépassement de tampon causé par l’utilisation de strcat. Ou une fuite de mémoire due à des appels à addObserverver non suivis d’appel à removeObserver. Et ainsi de suite pour de nombreuses évaluations de qualité que j’ai énumérées au-dessus.
Et celui des extensions ?
Les extensions ne bénéficient pas de ces mécanismes communautaires. Il n’y a aucun dépôt central pour les codes sources des extensions hébergées sur addons.mozilla.org. Il n’y a aucun mécanisme général pour surveiller les changements. Il n’y a aucun moyen de savoir qui a vérifié le code d’une extension, encore que j’ai entendu dire qu’il y a un processus de contrôle avant que les extensions ne soient référencées. (Contrôle de quoi ? Mystère. Mais rappelez-vous que le contrôle « pré-checkin » n’est qu’une petite partie de la vérification que subissent le cœur de Mozilla et les applications).
Ainsi, les pressions pour améliorer la qualité d’une extension proviennent de sources moins diverses : les connaissances en programmation de l’auteur et du « reviewer » et les retours sur des problèmes par les utilisateurs de l’extension qui savent que leurs problèmes sont causés par l’extension et non par l’application (généralement cela ne concerne que le comportement normal et l’interface utilisateur de l’extension). Donc, de nombreux aspects du contrôle-qualité sont omis. Et un ver dans un fruit peut gâter toute la corbeille. Si un utilisateur a installé 10 extensions dont une plante souvent et une autre provoque des fuites de mémoires, la perception que l’utilisateur aura du programme sera qu’il plante souvent et prend beaucoup de mémoire.
Il y a encore d’autres problèmes avec les tests. Ainsi, certaines personnes regardent le code source en cherchant des problèmes spécifiques, d’autres testent dans des domaines spécifiques comme la vitesse, l’utilisation de la mémoire, différents types de problèmes de sécurité ou juste le fonctionnement basique et l’ergonomie. Les extensions posent ici un problème différent : il y a une augmentation combinatoire des configurations à tester. Une personne s’intéressant suffisamment aux fuites de mémoires pour faire quelques tests à ce sujet n’aura pas forcément installé les extensions les plus coupables. La personne qui contrôle les bugs de sécurité avec mangleme peut ne pas avoir installé les extensions qui contiennent les vulnérabilités les plus sérieuses.
Ce problème empire encore parce que les versions d’extensions sont totalement séparées des versions de l’application. Il est inutile de tester la fenêtre d’affichage du code source de Firefox 1.0.3 avec la version 1.5. Mais les utilisateurs sont susceptibles d’utiliser différentes versions d’une extension sur une même version du navigateur, et ainsi chaque combinaison ne sera testée que partiellement.
Concrètement, quels problèmes cela pose-t-il ?
Par ailleurs, ceci est encore aggravé par le fait que les extensions peuvent interférer entre elles. Le cas le plus flagrant serait celui où 2 extensions chercheraient à ajouter un bouton au même endroit et ceci provoquerait la rupture de l’interface, juste parce que tous les boutons n’ont plus assez de place. Mais la même chose peut arriver avec les fuites de mémoire, le ralentissement dans le chargement des pages ou n’importe lequel des critères de qualité. Je doute qu’il y ait eu beaucoup de tests poussés sur les fuites de mémoire, les performances ou d’autres domaines de qualité avec différentes combinaisons d’extensions.
Cette augmentation combinatoire génère un grand nombre de petits problèmes. Et beaucoup de petits problèmes sont moins susceptibles d’être remarqués et corrigés qu’un petit nombre de gros problèmes.
Je m’inquiète surtout parce que ceci n’est pas qu’un souci théorique. Combien de rapports de fuite énorme de mémoire dans Firefox 1.5 sont causés parce que N des M différentes versions/forks d’AdBlock ont une fuite à chaque page visitée ? (On m’a dit que N est différent de zéro, mais je n’ai pas testé moi-même.). Et je m’inquiète parce que la communauté Mozilla joue sa réputation communautaire sur quelque chose qu’elle ne contrôle pratiquement pas.
[1] Une fuite de mémoire est une zone de mémoire utilisée un court instant par une application, mais que celle-ci oublie ensuite de libérer pour le système. Cela rend cette zone indisponible tant pour l’application fautive que pour toutes les autres applications, jusqu’à ce qu’elle soit fermée.
Articles dans la même rubrique
- Un dictionnaire français intégré par défaut dans Firefox, Thunderbird et Seamonkey (8 février 2008 - 9795 visites - popularité 14%)
- Déplacer un profil Firefox ou Thunderbird (16 juillet 2007 - 29657 visites - popularité 19%)
- Le mode sans échec, ou safe mode, pour Firefox et Thunderbird (13 février 2007 - 30051 visites - popularité 12%)
Commentaires
(Si vous recherchez de l'aide pour l'utilisation d'un produit, veuillez utiliser les forums de Geckozone. Les commentaires concernent uniquement l'article. Merci.)
Afficher les commentaires (19) Ajouter un commentaire
