Le piège JavaScript

par Richard Stallman

Vous exécutez peut-être des programmes non libres sur votre ordinateur chaque jour sans même vous en apercevoir – par l'intermédiaire de votre navigateur web.

Dans la communauté du logiciel libre, l'idée que les programmes non libres nuisent à leurs utilisateurs est familière. Certains d'entre nous défendent leur liberté en interdisant l'accès de leur machine à tous les logiciels privateurs¹ et beaucoup d'autres considèrent que la non-liberté d'un programme est un point négatif.

Beaucoup d'utilisateurs sont conscients que ce problème s'applique aussi aux modules que les navigateurs proposent d'installer, puisqu'ils peuvent être libres ou non. Mais les navigateurs exécutent d'autres programmes non libres sans vous demander votre avis ni même vous prévenir – des programmes inclus dans des pages web ou vers lesquels elles ont des liens. Ces programmes sont le plus souvent écrits en JavaScript, bien que d'autres langages puissent être utilisés.

JavaScript (dont le nom officiel, mais peu utilisé, est ECMAScript) servait autrefois à orner les pages web de fioritures mineures, comme des fonctionnalités de navigation et d'affichage agréables mais non essentielles. Il était acceptable de les considérer comme de pures extensions du langage de balises HTML et d'ignorer le problème.

Certains sites utilisent encore JavaScript de cette façon, mais beaucoup l'utilisent pour des programmes conséquents réalisant des tâches importantes. Par exemple, Google Docs essaie d'installer dans votre navigateur un programme JavaScript qui pèse un demi mégaoctet, sous une forme compactée que nous pourrions appeler ObfuScript. Cette forme compactée s'obtient à partir du code source en supprimant les espaces supplémentaires qui rendent le code lisible ainsi que les remarques explicatives qui le rendent compréhensible, et en remplaçant chaque nom évocateur par un nom court arbitraire pour qu'on ne puisse pas savoir ce qu'il est censé représenter.

Le logiciel libre est par définition un logiciel qui, entre autres, permet aux utilisateurs d'avoir accès à son code source (c'est-à-dire à son plan). Le code source d'un programme est la forme préférée des programmeurs pour effectuer des modifications – et il comprend les espaces supplémentaires, les remarques explicatives et les noms évocateurs. Le code compacté est un substitut bidon et inutile au code source ; le véritable code source de ces programmes n'est pas disponible pour les utilisateurs, donc ces derniers ne peuvent pas le comprendre ; par conséquent, le programme est non libre.

Outre qu'ils ne sont pas libres, beaucoup de ces programmes sont malveillants parce qu'ils espionnent l'utilisateur. Pire encore, certains sites utilisent des services qui enregistrent toutes ce que fait l'utilisateur quand il regarde une page. Ces services sont censés « caviarder » les enregistrements pour en exclure certaines données sensibles dont le site web ne doit pas avoir connaissance. Mais en admettant même que cela soit fait de manière fiable, le but de ces services est de donner au site d'autres données personnelles qu'il ne devrait pas posséder.

Normalement, les navigateurs ne vous disent pas quand ils chargent des programmes JavaScript. Certains d'entre eux ont un moyen de désactiver JavaScript totalement, mais même si vous êtes conscient du problème, vous aurez beaucoup de mal à identifier les programmes non triviaux et non libres pour les bloquer. De toute façon, même au sein de la communauté du logiciel libre, la plupart des utilisateurs ne sont pas conscients de ce problème ; le silence des navigateurs tend à le dissimuler.

D'abord une mise au point : le langage JavaScript n'est pas intrinsèquement meilleur ou pire pour la liberté des utilisateurs que n'importe quel autre langage. Il est possible de publier un programme JavaScript en tant que logiciel libre, en distribuant le code source sous une licence libre. Si le programme est autonome (c'est-à-dire si son fonctionnement et son but sont indépendants de la page qui l'a amené), tout va bien ; vous pouvez le copier dans un fichier sur votre machine, le modifier, puis l'exécuter en lisant ce fichier avec votre navigateur. Il est même possible de l'empaqueter pour l'installer comme les autres programmes libres et l'invoquer avec une commande du shell. Ces programmes ne posent pas de problèmes éthiques différents de ceux des programmes C.

Le problème du piège JavaScript s'applique lorsque le programme JavaScript accompagne la page web visitée par l'utilisateur. Ces programmes sont conçus pour fonctionner avec une page ou un site particulier, qui en dépend pour fonctionner.

Supposons que vous modifiez le code JavaScript de la page. Alors se présente un autre problème : même si le code source du programme est disponible, les navigateurs ne proposent aucun moyen d'exécuter votre version modifiée à la place de l'original lorsque vous êtes sur cette page ou ce site. L'effet est comparable à la tivoïsation bien qu'il soit, en principe, un peu moins difficile à contourner.

JavaScript n'est pas le seul langage que les sites web utilisent pour les programmes envoyés aux utilisateurs. Flash permettait la programmation à l'aide d'une variante étendue de JavaScript, mais cette époque est révolue ; si un jour nous avons un lecteur Flash libre suffisamment complet, il nous faudra traiter le problème des programmes Flash non libres. Microsoft Silverlight est susceptible de poser un problème similaire à Flash, en pire, car Microsoft l'utilise comme plateforme pour des codecs non libres. Un remplacement libre de Silverlight ne ferait pas l'affaire pour le monde du libre, à moins qu'il ne propose normalement des codecs de remplacement libres.

Les applets Java s'exécutent aussi dans le navigateur et soulèvent des problèmes similaires. En général, n'importe quel système d'applet pose ce genre de problème. Avoir un environnement d'exécution libre pour un applet ne fait que déplacer le problème.

Il est théoriquement possible de programmer en HTML et CSS, mais en pratique les possibilités sont limitées et c'est assez pénible ; le simple fait de réaliser quelque chose par cette technique est un hack impressionnant. De tels programmes doivent être libres, mais aujourd'hui, en 2019, cela ne pose pas de réel problème pour la liberté de l'utilisateur.

Un fort mouvement s'est développé qui appelle les sites web à ne communiquer qu'avec des formats et des protocoles libres (certains disent « ouverts ») ; c'est-à-dire des formats dont la documentation est publiée et que chacun est libre de mettre en œuvre. Cependant, la présence de programmes JavaScript dans les pages web rend ce critère insuffisant. Le langage JavaScript lui-même, en tant que format, est libre ; utiliser JavaScript dans un site web n'est donc pas nécessairement mauvais. Cependant, comme nous l'avons vu plus haut, cela peut être mauvais si le programme JavaScript est non libre. Quand le site transmet un programme à l'utilisateur, il ne suffit pas que le programme soit écrit dans un langage documenté et libre d'entraves ; ce programme doit aussi être libre. « Ne transmet que des programmes libres aux utilisateurs » ; cette règle doit faire partie des critères définissant un comportement correct des sites web.

Le chargement et l'exécution silencieux de programmes non libres est l'un des nombreux problèmes soulevés par les « applications web ». Le terme « application web » a été conçu pour ne pas tenir compte de la distinction fondamentale entre un logiciel fourni aux utilisateurs et un logiciel s'exécutant sur un serveur. Il peut faire référence à un programme client spécialisé qui s'exécute dans un navigateur ; il peut faire référence à un logiciel serveur spécialisé ; il peut faire référence à un programme client spécialisé travaillant main dans la main avec un logiciel serveur spécialisé. Les côtés client et serveur soulèvent des problèmes éthiques différents, bien qu'ils soient si intimement intégrés qu'on pourrait les considérer comme parties d'un seul et même programme. Cet article ne s'occupe que du logiciel client. Nous traitons le problème du serveur séparément.

Pratiquement, comment pouvons-nous traiter le problème des programmes JavaScript non triviaux et non libres dans les sites web ? La première étape est de ne pas les laisser s'exécuter.

Que voulons-nous dire par « non trivial » ? Puisque c'est une question d'interprétation, il s'agit de concevoir un critère simple qui donne de bons résultats, plutôt que de déterminer la seule réponse correcte.

Actuellement, nous considérons un programme JavaScript comme non trivial s'il répond à l'une des conditions suivantes :

• il est appelé en tant que script externe (à partir d'une autre page) ;
• il déclare un tableau contenant plus de 50 éléments ;
• il définit une entité nommée (fonction ou méthode) qui appelle autre chose qu'une primitive ;
• il définit une entité nommée comprenant plus de trois éléments de construction conditionnels et une construction en boucle ;
• le code n'appartenant pas aux définitions nommées appelle autre chose que des primitives et des fonctions définies plus haut dans la page ;
• le code n'appartenant pas aux définitions nommées comprend, au total, plus de trois éléments de construction conditionnels et une construction en boucle ;
• il fait appel à eval ;
• il fait des requêtes Ajax ;
• Pour accéder de manière dynamique aux propriétés des objets, il utilise une notation crochet qui ressemble à objet[propriété].
• il modifie le DOM ;
• il utilise des constructions dynamiques JavaScript qui sont difficiles à analyser sans interpréter le programme, ou bien il est chargé en même temps que des scripts qui utilisent de telles constructions ; cela concerne plus précisément l'utilisation avec certaines méthodes (Obj.write, Obj.createElement, etc.) de tout élément de construction autre qu'une chaîne de caractères constante.

Comment savoir si du code JavaScript est libre ? Dans un autre article, nous proposons une méthode qui permet à un programme JavaScript non trivial inclus dans une page web d'indiquer l'URL de son code source, ainsi que sa licence, en utilisant des commentaires stylisés.

Enfin, nous devons modifier les navigateurs pour qu'ils détectent et bloquent le JavaScript non trivial et non libre dans les pages web. Le programme LibreJS [en] détecte le JavaScript non libre et non trivial dans les pages que vous visitez, et le bloque. LibreJS est intégré à IceCat et peut être ajouté à Firefox en tant que module complémentaire.

Les utilisateurs de navigateurs ont aussi besoin d'une fonctionnalité facile d'emploi, indiquant le code JavaScript à substituer au JavaScript d'une page donnée (le code spécifié pourrait être un remplacement total, ou une version modifiée du programme JavaScript libre de cette page). Greasemonkey arrive presque à le faire, mais pas tout à fait, car il ne garantit pas de modifier le code JavaScript d'une page avant que le programme ne commence à s'exécuter. On peut utiliser un proxy local, mais c'est trop malcommode actuellement pour constituer une réelle solution. Nous avons besoin de construire une solution fiable et pratique, ainsi que des sites pour partager les modifications. Le projet GNU voudrait recommander les sites dédiés exclusivement aux modifications libres.

Ces fonctionnalités rendront possible pour un programme JavaScript inclus dans une page web d'être réellement libre. JavaScript ne sera plus un obstacle particulier à notre liberté – pas plus que C et Java ne le sont maintenant. Nous serons en mesure de rejeter et même de remplacer les programmes JavaScript non triviaux et non libres, tout comme nous avons rejeté et remplacé les paquets non libres pour les installations classiques. Notre campagne pour libérer le code JavaScript des sites web pourra alors commencer.

Entre-temps, il existe un cas où il est acceptable d'exécuter un programme JavaScript non libre : l'envoi d'une réclamation aux opérateurs du site web leur demandant de libérer le code JavaScript de leur site, ou bien de l'éliminer. N'hésitez pas à activer JavaScript temporairement pour faire ça – mais n'oubliez pas de le désactiver après coup.

Remerciements: Je remercie Matt Lee et John Resig pour leur aide dans la définition de notre proposition de critère, et David Parunakian pour avoir porté ce problème à mon attention.