Resumen

  • Los applets de HotJava sustituían algunos componentes instalados de antemano por código Java enviado con una página y ejecutado en el ordenador del lector.
  • Esa flexibilidad dependía de una política local; la documentación Alpha2 de Sun decía que el cifrado de clave pública aún no estaba implementado, y una revisión independiente posterior encontró fallos en HotJava Alpha3.

En 1995 una página podía describir un objeto interactivo, pero el navegador convencional tenía que saber de antemano cómo interpretarlo. HotJava propuso otra fuente para esa capacidad. La página podía incluir una referencia a un applet Java; HotJava descargaba el programa y lo ejecutaba dentro del navegador. La red transportaba así no solo un documento, sino parte del mecanismo necesario para interpretarlo.

Sun presentó el enfoque como una salida del catálogo fijo de formatos y protocolos. Un formato de imagen nuevo podía llegar con su propio componente; un protocolo, con su controlador. El documento de HotJava imaginaba que el lector ya no tendría que instalar cada pieza de software por separado. Eran metas de diseño y ejemplos, no pruebas de adopción generalizada.

El cambio también alteraba el pacto de compatibilidad. La guía Alpha2 describía applets integrados en HTML. Un navegador que no entendiera la nueva etiqueta podía ignorarla y seguir leyendo el resto de la página. El texto se degradaba bien, pero solo HotJava ejecutaba el nuevo comportamiento. El autor podía ofrecer algo más sin esperar a que todos los fabricantes actualizaran sus navegadores; el lector necesitaba un entorno compatible y aceptaba código en su propio equipo.

Por eso el ordenador del lector se convirtió en el límite decisivo. El documento de Sun de octubre de 1995 presentaba la comprobación de tipos, la verificación del bytecode y los controles del entorno de ejecución como protecciones. Sin embargo, las notas de versión acotaban esa promesa. Alpha2 era un prototipo para Solaris/SPARC y su README advertía que el cifrado de clave pública no estaba implementado. Contener un programa y comprobar quién lo creó eran problemas distintos: limitar sus acciones no demostraba su procedencia.

La documentación de Alpha3 hacía visible la política. El cuadro de seguridad ofrecía niveles desde bloquear applets hasta permitir el acceso solo al host de origen o a la red detrás del cortafuegos, además de un modo sin restricciones. La lectura y escritura de archivos también dependían de rutas autorizadas. La ruta de escritura estaba vacía por defecto, aunque el administrador podía configurarla. La frontera no era simplemente «Java es seguro», sino un conjunto de reglas, valores iniciales y decisiones administrativas aplicadas a un programa llegado desde otro lugar.

El debate público de 1995 ya distinguía ambos asuntos. En la lista www-talk del W3C, varios participantes discutieron si un entorno aislado bastaba o si también había que asegurar que el código descargado era auténtico. El intercambio documenta una discrepancia, no un consenso. En 1996, Drew Dean, Edward Felten y Dan Wallach examinaron HotJava Alpha3 y describieron fallos, incluidos riesgos de denegación de servicio. Esa auditoría posterior no prueba qué sabía cada usuario en 1995; sí demuestra que un sandbox debía someterse a pruebas y mantenimiento, no aceptarse como garantía permanente.

La aportación histórica de HotJava fue mover el punto de extensión. Los editores podían enviar comportamiento ejecutable junto con la página; los lectores y sus administradores asumían la decisión sobre los recursos disponibles. El diseño reducía el coste de coordinación para incorporar una nueva función al navegador y aumentaba la carga de seguridad en el equipo final. Las fuentes acreditan un prototipo y una arquitectura debatida, no un despliegue universal, una seguridad infalible ni un cambio medido en el uso de la Web.

Fuentes y límites de la evidencia