JavaScript est maintenant utilisé de manière assez généralisée sur le web, mais c'est aussi un outil de tracking et parfois un risque de sécurité. Des chercheurs de Lille ont analysé quelle part du web est encore navigable sans utiliser ce langage.
Vous, lecteurs de Next INpact, utilisez peut-être le navigateur Lynx, qui ne prend pas en charge le code JavaScript des pages web, pour lire votre média en ligne préféré. Ou peut-être utilisez-vous l'extension NoScript sur Firefox, Chrome, Vivaldi ou Brave (ou d'autres comme uMatrix) ? Celle-ci permet notamment de désactiver le JavaScript sur votre navigateur.
JavaScript est très intéressant pour rendre une page web plus interactive, mais il permet aussi de tracer plus facilement un internaute et introduit des failles de sécurité. L'extension NoScript est d'ailleurs intégrée par défaut dans le navigateur Tor Browser pour éviter le pistage de ses utilisateurs et sécuriser leur navigation.
Mais, à bloquer JavaScript, on se coupe aussi de certaines fonctionnalités des pages web que l'on consulte jusqu'à les rendre, pour certaines, inutilisables. Des chercheurs de Lille (du CNRS et d'Inria) ont analysé ce qu'ils nomment des « ruptures » lorsque JavaScript est désactivé, pour identifier les fonctionnalités manquantes. Ils ont détaillé leurs travaux dans un article scientifique [PDF], publié dans la revue ACM Transactions on Internet Technology.
43 % des pages non dépendantes à JavaScript, 67 % des pages utilisables
Selon eux, dans plus de 40 % des pages étudiées, le fait de désactiver JavaScript n'a pas de conséquences problématiques pour consulter la page : « Même en tenant compte de l'ensemble de la page, 43 % des pages présentent encore toutes leurs principales caractéristiques, ce qui signifie que l'ensemble de la page fonctionne probablement comme prévu, même si JavaScript est bloqué », expliquent-ils dans leur article.
Et même, pour 2/3 des pages, les informations principales sont lisibles : « On constate que 67 % des pages présentent toutes les caractéristiques principales de la section principale, ce qui signifie qu'elles sont susceptibles d'être utiles à l'utilisateur, même si JavaScript est désactivé ».
Désactiver l'utilisation de JavaScript bloquerait, dans le même temps et selon leur étude, 85 % des requêtes de tracking.
Création d'un framework de détection
Pour étudier cette dépendance à JavaScript, les chercheurs ont créé un framework côté client qui permet de détecter qu'une fonctionnalité ne marche plus. Mais la création d'un tel outil n'est pas si simple. D'une part, même si le HTML sépare normalement les éléments interactifs des éléments non interactifs, en pratique, tout élément HTML peut être utilisé pour créer des éléments interactifs de la page. Et les chercheurs expliquent aussi qu'une page cassée pour une personne peut ne pas être vue comme telle par une autre.
Dans leur article, ils dénombrent plusieurs cas problématiques, par exemple les images qui peuvent être affichées en basse résolution sans JavaScript sur certains sites, l'impossibilité de soumettre un formulaire, le mauvais fonctionnement de boutons de formulaires, les problèmes d'ancres HTML, le remplacement d'adresses email par le texte « [email protected] » ou encore le fait qu'une page n'ait pas de texte du tout.
Ensuite, ils expliquent s'être tournés vers la définition technique du document en utilisant le Document Object Model (DOM) obtenu après le chargement initial de la page, qui décrit la composition d'une page web.
Évidemment, sans utiliser JavaScript, ils ne peuvent savoir si la page affiche les contenus que son auteur veut présenter. L'idée est de localiser les éléments de la page qui sont cassés ou incomplets. Cette approche a l'intérêt de permettre d'objectiver l'existence ou non d'un problème dans le document, sans se poser de question sur le rendu final. Cependant, il ne permet pas de s'attarder sur les symptômes possibles, c'est-à-dire sur ce que l'utilisateur voit vraiment en comparaison de ce qu'il s'attend à voir.
Test sur 6 384 pages de 3 774 domaines
Après avoir créé leur framework, les trois auteurs de l'étude ont composé une liste de pages à tester. Ils ont utilisé un sous-ensemble de la liste Hispar, créée par des chercheurs du MIT et du Max-Planck-Institut für Informatik. Celle-ci recense un nombre important de pages d'accueil et de pages internes de site web. Pour ce travail, le sous-ensemble contient 100 000 URL.
Puis, ils ont automatisé l'exploration de ces URL avec la bibliothèque Puppeteer en utilisant Firefox Nightly 88.0a1 (pour des raisons de compatibilité avec Puppeteer à l'époque), en désactivant JavaScript avec le paramètre javascript.enabled à « false ».
Différence avec la perception générale
Ces résultats peuvent paraître étonnants pour quelqu'un qui navigue régulièrement sur le web en bloquant le JavaScript. Les chercheurs tentent d'expliquer la différence entre cette perception et leurs résultats par le fait que « la plupart des sites web très visités dépendent fortement de JavaScript », citant notamment les services de Google, de Twitter ou d'Instagram.
Ils expliquent aussi que si React et Vue.js sont des frameworks JavaScript très connus des développeurs et que ces deux projets « figurent en effet parmi les 10 premiers dépôts sur GitHub sur la base du classement par étoiles », React et Vue ne sont, de fait, utilisés que « sur une très petite partie des sites web effectivement déployés ».
Commentaires (26)
#1
Je vis avec Noscript, la moitié des sites passent, et le tiers de ce qui reste fonctionne avec le JS activé juste sur le domaine racine.
Le nombre de scripts utilisés par certains sites est proprement hallucinant.
#1.1
Effectivement et il y a parfois pas mal de tâtonnement à faire pour savoir quel domaine autoriser pour avoir un site qui fonctionne, obligé parfois d’utiliser chrome en navigation privé en dernier recours.
Noscript permets de ce rendre compte que les tracker sont des poupées gigogne, on en autorise un et 10 nouveaux apparaissent …
#2
J’utilise uMatrix (qui n’est plus maintenu) et je désactive le JS, les vidéos et le contenu tiers par défaut sur les sites que je ne connais pas. Ça protège de la majeure partie des failles de sécurité comme le CSRF, les bugs dans le JS, les mineurs de cryptomonnaie ou le tracking trop poussé (genre capturer tous les mouvements de souris). Sur bon nombre de site, quand je suis présenté une page blanche, je quitte tout simplement le site. Sur certains j’accepte d’activer le JS mais seulement en navigation privée. Sur les sites de confiance, j’active le JS.
Y a certains sites où j’en viens même à écrire des userscripts (donc du JS) pour faire fonctionner des parties de sites cassées sans JS (genre pour afficher des images, coucou le “lazy” loading).
Pour moi, y a que les applications avec chargement de contenu instantané (fil de contenu d’un réseau social, discussions instantanées) qui doivent utiliser activement le JS, pour le reste ça devrait être optionnel (par exemple pour améliorer l’expérience utilisateur).
Par exemple, on ne peut plus accéder à un profil sur Mastodon sans JS depuis la version 4 (page blanche). Sinon, sur Next INpact, on peut accéder à la partie non-abonnée de l’article en comparaison (et Next INpact utilise le local storage pour stocker le token de connexion donc le site ne peut pas fonctionner sans JS).
Concernant les technologies, le server-side rendering (SSR) est redevenu à la mode, donc des sites utilisant du JSX (qui correspond plus ou moins à React) peuvent être accessibles sans JS.
#3
Mes deux blogs (texte et photo) sont 100% javascript-free
Par contre je ne peux pas prétendre à intégrer le 512kb Club, mais je m’efforce de rester autant que possible sous la barre du 1MB pour mon blog texte (le photo, c’est mort mais la homepage est limitée à 4 albums pour réduire la casse).
Mais clairement, aujourd’hui naviguer sans Javascript est difficile. D’ailleurs il me semble qu’un élément de poids a été oublié : CloudFlare. Rien que ça fait qu’un pauvre site statique peut être difficile à accéder sans JS actif.
Je pense aussi qu’il y a un problème de culture. Dans l’esprit de beaucoup, le front doit être en JS. Spoiler alert : non, pas obligatoirement si la page ne présente pas de contenu dynamique, et HTML et CSS sont aujourd’hui capables de faire des interfaces interactives et adaptatives simples sans aucun JS. Je pense notamment aux sites web type “plaquette commerciale” de merde où faut scroller 50 000 fois pour faire défiler les “slides” … quelle horreur.
Pas plus tard que ce week end, j’ai publié sur GitHub un projet perso qui affiche une cartographie applicative avec des cartes pouvant être ouvertes et repliées. Pas un gramme de JS là dedans, que du HTML et du CSS, le tout propulsé par Flask pour faire le rendu du contenu qui est défini par un fichier YAML. Tout le calcul se fait côté serveur, le client affiche du HTML basique. Les cartes sont affichées avec la balise
detailsqui permet de ouvrir/fermer un pan de texte.Pourquoi ai-je fait ces choix ? Parce que je sais me débrouiller en Python, en HTML, CSS et prompt ChatGPT, là où je ne sais pas développer en JS (comme la plupart des devs web vous allez me dire
). J’y comprends rien à ces douze millions de frameworks qui pop par jour et ça m’intéresse pas, c’est pas mon métier en même temps. En dehors d’un autre projet de RPG texte produit avec la même couche logicielle qui intègre OSM pour les cartes du jeu (donc pour le coup du JS requis côté client), j’ai jamais ressenti le besoin. Peut-être parce que ça ne me dérange pas de faire changer de page le client pour enregistrer une action, probablement à cause de mes années PHP au début où je bricolais du Web.
Et si y’a un truc que je déteste avec les sites en JS (NXI y compris), ce sont les boutons “unresponsive” sur lesquels on va cliquer et qu’on a aucune idée de si cela a déclenché réellement un événement ou pas. Quand j’ai une barre de progression ou le bouton refresh du brouteur qui passe à “X”, je sais qu’il se passe un truc. Quand je clic un bouton et here goes nothing, ça me gave. Typiquement sur ce site, je suis régulièrement amené à cliquer trois ou quatre fois sur le bouton “Envoyer” d’un commentaire qui ne semble pas réagir du premier coup. C’est nul côté expérience utilisateur. Ca doit être aussi une raison pour laquelle le JS ne m’a jamais attiré.
Edit : bah suffisait de râler pour que la soumission du message soit immédiate cette fois XD
#3.1
Et oukilé ton blog ?
#3.2
Dans Ton Cloud évidemment !
Je n’ai pas mis le lien pour éviter que ça passe pour du spam, je peux te le faire suivre en MP si tu le souhaites.
#4
Plus trop d’actualité le CSRF de nos jours (same-origin policy, cookie SameSite…), tu ne parles pas plutôt du XSS ?
Techniquement on peut capturer les mouvements de souris via CSS, à voir si des sites s’embêtent à mettre ça en place juste pour tracer les quelques utilisateurs qui désactivent JS.
https://www.bleepingcomputer.com/news/security/researcher-finds-css-only-method-to-track-mouse-movements/
C’est pas un problème inhérent au JS, tu peux très bien faire en sorte que le clic ajoute un spinner voire disable le bouton le temps que l’action se fasse. Disable le bouton permet au passage d’éviter que l’action soit déclenchée plusieurs fois si l’utilisateur s’impatiente et bourre le bouton ou en cas de double clic (les fameux commentaires en double par ex).
Malheureusement il est vrai que souvent l’UX pêche sur les sites avec beaucoup de JS. Outre ton exemple, on peut aussi citer cette manie de ne pas utiliser l’API History du navigateur, ou pas “fidèlement”, donc tu navigues entre plusieurs “pages”, sous-rubriques, etc, et tu dois tout faire au clic gauche, pas possible :
#5
Bref, les chercheurs tentent d’expliquer que leur échantillon de site web n’est pas représentatif des usages des internautes.
Lies, damned lies, and statistics.
#6
uBlock Origin + uMatric aussi (je trouve le second bien plus facile à prendre en main), et ce n’est pas tellement le JS qui me bloque, mais les domaines tiers. Certains sites “statiques” n’affichent qu’une page blanche si on bloque tous les domaines tiers. J’aimerais bien discuter avec les chefs de projet qui valident ça, parce qu’il y a pas mal de questions qui me viennent à l’esprit (et aussi quelques noms d’oiseau).
#7
J’ai posé la question à Oracle-qui-sait-tout et il m’a donné une réponse qui me semble adaptée.
#7.1
Je parlais des domaines tiers, pas du JS.
#8
J’oubliais, c’est l’occasion de mentionner la vidéo Javascripto !
https://www.youtube.com/watch?v=4GDFeVhGBew
#8.1
Le classique!
“ジャーバー・スクリプト!!”(jâbâsukuriputo!!)
Je suis du même avis :
Mon petit grain de sel:
Pour ma part, j’utilise sur mes quelques projets web (je ne suis pas dév web pro), j’utilise un meta-framework JS bien précis: SvelteKit. Ca permet plusieurs choses:
A l’arrivée, je m’y retrouve, avec un code côté serveur organisé, et un code côté client petit et apportant des optimisations intéressantes -qui restent facultatives-.
#9
ça fait plus de 20 ans que les ESI (Edge Side Includes) ont été spécifiés (même si le W3C ne les a pas validés), et ça remplace avantageusement tellement de mécanismes de client side scripting… et les caches/CDN savent s’appuyer dessus.
#10
Gros +1 là dessus… Notamment l’action précédent via le bouton de la souris ou un gesture qui fait tourner en boucle (et je classe même pas là dedans la dark pattern des sites d’actualité qui en profitent pour pousser du contenu connexe parfois pas nexe du tout.).
Même les gros sites e-commerce me perdent parfois quand l’infinite scroll reprend “au début” après un clic sur précédent alors que t’avais déjà parcouru l’équivalent de 10 pages.
Bref, on a tout rendu plus fluide pour aller en avant dans le parcours avec le JS, mais sitôt qu’on veut changer quelque chose dans le parcours, y’a plus personne.
#11
“Ces résultats peuvent paraître étonnants pour quelqu’un qui navigue régulièrement sur le web en bloquant le JavaScript.”
En effet, l’écart entre les pages dépendantes et les utilisables est bien plus important chez moi.
#12
Les framework JS sont souvent parfaitement inutiles.
Je suis globalement d’accord avec ton message, mais je ne comprends pas une partie : en quoi une archi client / serveur (chaque action de l’internaute appelle le serveur pour rafraîchir le rendu) serait moins propice au tracking, c’est l’exact opposé en fait : un javascript bien écrit peut rendre dynamique certaines parties du site tout en améliorant la confidentialité : ce qui est fait en JS, (sauf code intentionnel) ne sort jamais de ton navigateur.
Prenons l’exemple du blog : une liste d’articles avec des contenus ou commentaires.
En client/server : le serveur saura quel article est lu, combien de temps, le pattern de navigation… (/var/log/apache2/access_log stocke adresse IP client + horodatage + URI du serveur accédé ) Y’a rien à coder, juste à analyser le log !
Le même site en JS propre va précharger une dizaine d’articles, et le serveur ne saura rien de plus : Est-ce que les articles ont été lus ? ou même simplement affichés dans le navigateur ?
Les JS sales et autres images de 1x1 px ont justement été inventés pour que le tracking qui était +/- natif auparavant puisse continuer à fonctionner avec des parties traitées localement en JS.
Avec les frameworks (jquery dès le milieu des années 2000) le JS est devenu très sale, car le tracking a pu être centralisé entre différents sites: une simple balise
script src="trackme"et plus personne, ni l’internaute, ni le propriétaire du site ne sait ce qui se passe.#12.1
Bonne remarque ! Mon propos ne portait aucunement sur le tracking, seulement “l’expérience utilisateur” mais c’est vrai, le server side est également propice à ce genre d’activité.
Dans mon cas : je ne fais rien. Je n’ai aucun outil d’analytique, pas de système de commentaires, rien, nada, que dalle.
La seule analyse de logs que je fais, c’est de temps en temps les erreurs pour voir les patterns d’attaque. En particulier quand OVH place le serveur en mitigation DDoS. Et les 3⁄4 du temps ce sont des échecs sur les URL Wordpress… autant dire que ça n’ira pas bien loin pour un site généré par GoHugo. Dans la mesure où j’estime qu’un blog est un outil d’expression, le parcours utilisateur et “l’intérêt” pour les conneries que j’écris ne m’importent pas. Cela permet d’avoir une pleine liberté éditoriale sans se soucier de ce “qu’attendent” les gens.
Pour l’aspect discussion sur un sujet, j’ai Mastodon pour ça
#13
No Script qui bloque tout autre que le site racine et cela passe presque partout, quand cela ne passe pas je change de site.
#14
De toute façon ça dépends du type de site.
Tout ce qui est webapp, sans JS ou Wasm c’est mort, trop lent.
Mais si c’est un site où l’on ne fait que de la consultation : blog, actu, wiki, etc. normal que ça puisse fonctionner sans JS. En plus, ça flinguerait le référencement. Je le vois très bien avec une web app que je fais, la faire référencer, c’est presque impossible de façon naturelle. Après, je m’en fous, l’objectif c’est pas de faire, et d’ailleurs en traking, je peux limite en faire moins qu’avec une application qui doit faire un appel de page à chaque clic si je mets pas en place un tracker spécifique. Rien rien empêche d’utiliser ublock pour bloquer le tracking.
#15
Bah même là je suis moyennement d’accord, navigue sur ton site “client / serveur” avec un accès satellite et ses 700ms de latence et on reparlera de l’expérience utilisateur :) Le javascript client a été inventé pour palier aux lenteurs des A-R client/serveur, bon ensuite on a un peu dévoyé le truc en faisant de l’Ajax (du client/serveur) qui reste quand même préférable car on n’envoie que les données et pas la page entière (dont les balises HTML, les CSS) à chaque action / contrôle.
Tu stoques des logs, qui pouraient parfaitement être utilisé après coup pour du marketing ou du tracking…
#16
Oui, les logs sont sur le serveur avec une rotation.
Et non, je ne fais pas de marketing ni de tracking.
Et oui, tu n’as que ma seule promesse et la déclaration de politique de vie privée (obligation légale) comme preuve de bonne foi.
Libre à toi ensuite de spéculer sur des potentielles activités de ma part, mais charge à toi de le démontrer.
#17
En dev interne, je me base fortement sur JS - ça me permet d’économiser des requêtes et d’être très fluide côté client.
#18
Merci pour cet article et aux chercheurs pour cette étude.
#19
quand un site parle si on pouvais ce passer de javascript et ce même site oblige le javascript , ça ne marche pas du tout!!!!!
#20
Je n’ai pas souvenir que nextinpact ai milité pour le non usage du JS. Ce qui n’aurai pas de sens