Résumé

  • Les applets HotJava remplaçaient certains composants installés à l’avance par du code Java transmis avec une page puis exécuté sur l’ordinateur du lecteur.
  • Cette souplesse reposait sur une politique locale ; la documentation Alpha2 de Sun précisait que le chiffrement à clé publique n’était pas encore implémenté, et une étude indépendante ultérieure a relevé des failles dans HotJava Alpha3.

En 1995, une page Web pouvait décrire un objet interactif, mais le navigateur classique devait connaître à l’avance la manière de l’interpréter. HotJava proposait une autre source pour cette capacité manquante. La page pouvait référencer une applet Java ; HotJava téléchargeait le programme et l’exécutait dans le navigateur. Le réseau transportait alors non seulement un document, mais aussi une partie du mécanisme nécessaire pour le comprendre.

Sun présentait cette approche comme un moyen de sortir d’une liste fixe de formats et de protocoles. Un nouveau format d’image pouvait être accompagné de son module d’affichage ; un protocole, de son gestionnaire. Le livre blanc de HotJava imaginait que l’utilisateur n’aurait plus à installer séparément chaque logiciel. C’étaient des objectifs de conception et des exemples, pas la preuve d’une adoption généralisée.

Cette architecture modifiait aussi le compromis de compatibilité. Le guide Alpha2 décrivait des applets intégrées au HTML. Un navigateur qui ne reconnaissait pas la nouvelle balise pouvait l’ignorer et continuer à afficher le texte environnant. La dégradation restait acceptable pour le contenu statique, mais seul HotJava exécutait le nouveau comportement. L’auteur pouvait enrichir une page sans attendre tous les éditeurs de navigateurs ; le lecteur devait disposer du bon environnement d’exécution et accepter du code local.

L’ordinateur du lecteur devenait donc la frontière décisive. Le document Sun d’octobre 1995 présentait les contrôles de types, la vérification du bytecode et l’environnement d’exécution comme des protections. Pourtant, les notes de version limitaient cette assurance. Alpha2 était un prototype pour Solaris/SPARC et son README précisait que le chiffrement à clé publique n’était pas implémenté. Le confinement et l’authenticité étaient deux problèmes distincts : limiter les actions d’un programme ne prouvait pas qui l’avait fourni.

La documentation Alpha3 rendait la politique visible. La boîte de sécurité proposait plusieurs niveaux, de l’interdiction des applets à l’accès limité à l’hôte d’origine ou au pare-feu, jusqu’au mode sans restriction. La lecture et l’écriture de fichiers dépendaient aussi de chemins autorisés ; le chemin d’écriture était vide par défaut, mais l’administrateur pouvait en configurer un. La frontière ne se résumait pas à « Java est sûr » : elle dépendait de règles, de valeurs initiales et de choix administratifs autour d’un programme venu d’ailleurs.

Le débat public de 1995 faisait déjà apparaître cette distinction. Sur la liste W3C www-talk, des participants se demandaient si un environnement confiné suffisait ou s’il fallait aussi garantir l’authenticité du code reçu. Cet échange montre un désaccord, pas un consensus. En 1996, une étude de Drew Dean, Edward Felten et Dan Wallach a examiné HotJava Alpha3 et signalé plusieurs failles, notamment des risques de déni de service. Cet audit ultérieur ne dit pas ce que chaque utilisateur savait en 1995 ; il montre plutôt qu’un bac à sable doit être vérifié et entretenu, et ne peut être tenu pour une garantie définitive.

L’apport historique de HotJava tient au déplacement du point d’extension. Les éditeurs pouvaient envoyer un comportement exécutable avec la page ; les lecteurs et leurs administrateurs héritaient du choix des ressources accessibles. Le coût de coordination pour ajouter une capacité baissait, tandis que la charge d’assurance augmentait sur le poste client. Les sources montrent un prototype et une architecture débattue, pas une adoption universelle, une sécurité parfaite ni un changement mesuré de l’usage du Web.

Sources et limites des preuves