Le piège JavaScript par Richard Stallman

Vu le developpement croissant du cloud computing, il fallait bien que l’on se pose un jour quelques questions.

Le mois dernier Richard Stallman publiait un article autour des applications en ligne en général et du JavaScript en particulier, qui fit couler pas mal de bits dans la blogosphère.

Parce que des logiciels tels que Gmail ou Google Documents exportent non seulement nos données sur les serveurs qui hébergent les applications (ici les serveurs Google) mais exécutent au passage dans nos navigateurs du code qui ne donne pas, loin de là, les signes d’une totale liberté[1].

La débat est donc ouvert, avec en toile de fond la faible représentation actuelle des applications web véritablement libres.

Le piège JavaScript

The JavaScript Trap

Copyright © 2009 Richard Stallman – Licence Creative Commons By-Nd
(Traduction : Cédric Corazza – URL d’origine de la traduction)

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 maltraitent leurs utilisateurs est familière. Certains d’entre-nous refusent totalement d’installer des logiciels propriétaires, et beaucoup d’autres considèrent que la non-liberté est une attaque contre le programme. Beaucoup d’utilisateurs sont conscients que ce problème s’applique aussi aux plugins que les navigateurs proposent d’installer, car ils peuvent être libres ou non-libres.

Mais les navigateurs exécutent d’autres programmes non-libres pour lesquels ils ne demandent pas votre avis — des programmes que contiennent des pages Web ou vers lesquels elles pointent. Ces programmes sont très souvent écrit en JavaScript, bien que d’autres langages puissent être utilisés.

JavaScript (dont le nom officiel est ECMAscript, mais peu de gens utilisent ce nom) était autrefois utilisé pour faire des effets frivoles, certes jolis mais non-essentiels à la navigation et aux fonctionnalités d’affichage. Il était acceptable de les considérer comme de pures extensions du langage de balises HTML, plutôt que comme de vrais logiciels ; ils ne représentaient pas un problème significatif.

Beaucoup de sites utilisent encore JavaScript de cette façon, mais certains l’utilisent pour des programmes conséquents réalisant des travaux importants. Par exemple, Google Docs télécharge sur votre machine un programme JavaScript qui pèse un demi megaoctet, dans une forme compactée que nous pourrions appeler Obscurscript car il n’y a aucun commentaire et très peu d’espaces, et les noms de méthode ne font qu’une lettre. Le code source d’un programme est la forme préférée pour le modifier ; le code compacté n’est pas du code source, et le vrai code source n’est pas disponible pour l’utilisateur.

Normalement, les navigateurs ne vous disent pas quand ils chargent des programmes JavaScript. La plupart des navigateurs ont un moyen de désactiver JavaScript totalement, mais aucun d’eux ne peut vérifier des programmes JavaScript qui ne sont pas triviaux et non-libres. Même si vous en êtes conscient, cela vous serait difficile d’identifier et bloquer ces programmes. Cependant, 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.

Il est possible de publier un programme JavaScript en tant que logiciel libre, en distribuant le code source sous une licence de logiciel libre. Mais même si le code source du programme est disponible, il n’existe pas de moyen facile d’exécuter votre version modifiée à la place de l’original. Les navigateurs libres actuels ne proposent pas de fonctionnalité permettant d’exécuter votre version modifiée à la place de celle délivrée par la page. L’effet est comparable à la Tivoisation bien que moins difficile à outrepasser.

JavaScript n’est pas le seul langage que les sites Web utilisent pour les programmes envoyés aux utilisateurs. Flash supporte la programmation par l’intermédiaire d’une variante étendue de JavaScript. Nous aurons besoin d’étudier le problème de Flash pour faire des recommandations appropriées. Silverlight semble créer un problème similaire à Flash, excepté qu’il est 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 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, toute sorte d’applet système pose ce genre de problème. Avoir un environnement d’exécution libre pour une applet ne fait que repousser d’un cran le problème.

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, dont la documentation est publiée et que chacun est libre de mettre en œuvre. Avec la présence de programmes dans les pages Web, ce critère est nécessaire mais pas suffisant. JavaScript lui-même, en tant que format, est libre et l’utilisation de JavaScript dans un site Web n’est pas nécessairement mauvaise. Cependant, comme nous l’avons vu plus tôt, ce n’est pas nécessairement bon. Quand le site transmet un programme à l’utilisateur, il n’est pas suffisant pour le programme d’être écrit dans un langage documenté et libre d’entraves ; ce programme doit être libre aussi. « Seule l’utilisation de programmes libres transmis aux utilisateurs » doit faire partie des critères satisfaisants pour un comportement correct des sites Web.

Le chargement et l’exécution silencieux de programmes non-libres est 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 délivré 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é qui travaille 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, même s’ils sont si intimement intégrés que l’on pourrait dire qu’ils font partie d’un seul programme. Cet article ne traite que du problème logiciel côté client. Nous traiterons le problème du côté serveur séparément.

Pratiquement, comment pouvons-nous traiter le problème des programmes JavaScript non-libres dans les sites Web ? Voici un plan d’action.

D’abord, nous avons besoin d’un critère pratique pour les programmes JavaScript non-triviaux. Puisque « non-trivial » 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 réponse correcte.

Notre proposition est de considérer qu’un programme JavaScript est non-trivial s’il définit des méthodes et s’il charge un script externe ou s’il est chargé en tant que script externe, ou encore s’il fait une requête AJAX.

À la fin de cet article, nous proposons une convention par laquelle un programme JavaScript non-trivial dans une page Web, peut déclarer l’URL de l’emplacement de son code source ainsi que sa licence, en utilisant des commentaires stylés.

Enfin, nous avons besoin de modifier les navigateurs libres pour qu’ils supportent la liberté des utilisateurs de pages avec JavaScript. Tout d’abord, les navigateurs doivent être en mesure de prévenir les utilisateurs au sujet des programmes JavaScript non-libres plutôt que de les exécuter. Peut-être que NoScript pourrait être adapté pour faire cela.

Les utilisateurs de navigateur ont aussi besoin d’une fonctionnalité pratique pour indiquer le code JavaScript à utiliser à la place du JavaScript dans une page donnée. (Le code spécifié pourrait être un remplacement total, ou une version modifiée du programme JavaScript libre dans cette page). Greasemonkey est très proche d’arriver à réaliser cela, mais pas tout à fait, car il ne permet pas la modification du code JavaScript dans une page avant que le programme ne s’exécute. Utiliser un proxy local fonctionne, mais c’est trop peu pratique actuellement pour être une réelle solution. Nous avons besoin de construire une solution fiable et pratique, comme les changements dans les sites de partage. Le Projet GNU aimerait recommander les sites dédiés aux changements libres seulement.

Ces fonctionnalités permettront à 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 capables de rejeter et même de remplacer les programmes JavaScript non-triviaux non-libres, tout comme nous avons rejeté et remplacé les paquetages non-libres pour les installations classiques. Notre campagne pour libérer le code JavaScript des sites Web peut alors commencer.

Merci à Matt Lee et John Resig pour leur aide pour la définition de notre proposition de critère.

Appendice : une convention pour publier des programmes JavaScript libres

Pour des références au code source correspondant, nous recommandons

// @source :

suivi de l’URL

Pour indiquer la licence du code JavaScript intégré dans la page, nous recommandons de mettre la notice de licence entre deux notes de cette forme :

@licstart The following is the entire license notice for the JavaScript code in this page. ... @licend The above is the entire license notice for the JavaScript code in this page. Traduction : @licstart Ce qui suit est la totalité de la notice de licence pour le code JavaScript de cette page. ... @licend Ce qui précède est la totalité de la notice de licence pour le code JavaScript de cette page.

Bien sûr, tout ceci doit être contenu dans un commentaire multiligne.

La GNU GPL, comme beaucoup de licences de logiciels libres, nécessite la distribution d’une copie de la licence avec les formes binaire et source du programme. Cependant, la GNU GPL est longue et l’inclure dans une page avec un programme JavaScript n’est pas pratique. Vous pouvez oublier ce prérequis, pour du code dont vous êtes le détenteur des droits d’auteur, avec une notice de licence comme ceci :

Copyright (C) YYYY Developer The JavaScript code in this page is free software : you can redistribute it and/or modify it under the terms of the GNU General Public License (GNU GPL) as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. The code is distributed WITHOUT ANY WARRANTY ; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU GPL for more details. As additional permission under GNU GPL version 3 section 7, you may distribute non-source (e.g., minimized or compacted) forms of that code without the copy of the GNU GPL normally required by section 4, provided you include this license notice and a URL through which recipients can access the Corresponding Source. Traduction : Copyright (C) YYYY Développeur Le code JavaScript de cette page est un logiciel libre : vous pouvez le redistribuer et/ou le modifier selon les termes de la licence GNU General Public License (GNU GPL) telle que publiée par la Free Software Foundation, en version 3 de la licence, ou (à votre discrétion) toute version suivante. Le code est distribué SANS AUCUNE GARANTIE ; sans même la garantie implicite de MARCHANDABILITÉ ou d'ADÉQUATION À UN BUT PARTICULIER. Consulter la GNU GPL pour plus de détails. En tant que permission supplémentaire selon les termes de la GNU GPL version 3 section 7, vous pouvez distribuer des formes « non-source (par ex., minimisées ou compactées) de ce code sans la copie de la GNU GPL normalement requise par la section 4, attendu que vous incluez cette notice de licence et une URL par laquelle les destinataires peuvent accéder au code source correspondant.

Notes
[1] Crédit photo : Wlappe (Creative Commons By)