Zusammenfassung

  • HotJava-Applets ersetzten manche vorinstallierten Komponenten durch Java-Code, der mit einer Seite ankam und auf dem Rechner des Lesers ausgeführt wurde.
  • Diese Flexibilität hing von einer lokalen Richtlinie ab. Suns Alpha2-Dokumentation hielt fest, dass Public-Key-Verschlüsselung noch nicht implementiert war; eine spätere unabhängige Prüfung fand zudem Fehler in HotJava Alpha3.

1995 konnte eine Webseite ein interaktives Objekt beschreiben, doch ein herkömmlicher Browser musste bereits wissen, wie es zu deuten war. HotJava bot eine andere Quelle für diese Fähigkeit. Eine Seite konnte ein Java-Applet einbinden; HotJava lud das Programm und führte es im Browser aus. Das Netz übertrug damit nicht nur ein Dokument, sondern auch einen Teil des Mechanismus, der es interpretierte.

Sun stellte dies als Ausweg aus einer fest verdrahteten Liste von Datenformaten und Protokollen dar. Ein neues Bildformat konnte mit seinem Anzeigeprogramm kommen, ein Protokoll mit seinem Handler. Das HotJava-Whitepaper stellte sich vor, dass Nutzer Software nicht mehr einzeln installieren müssten. Das waren Entwurfsziele und Beispiele, kein Beleg für eine flächendeckende Einführung.

Auch der Kompromiss bei der Kompatibilität änderte sich. Der Alpha2-Applet-Leitfaden beschrieb Applets, die in HTML eingebettet waren. Ein Browser ohne Unterstützung konnte das neue Tag übergehen und den übrigen Text anzeigen. Statische Inhalte blieben lesbar, aber nur HotJava führte das neue Verhalten aus. Autoren konnten Funktionen anbieten, ohne auf jeden Browserhersteller zu warten; Leser brauchten eine kompatible Laufzeitumgebung und mussten Code auf dem eigenen Rechner zulassen.

Damit wurde der Rechner des Lesers zur entscheidenden Grenze. Suns Whitepaper vom Oktober 1995 nannte Typprüfungen, Bytecode-Verifikation und Laufzeitkontrollen als Schutz. Die Versionshinweise begrenzten dieses Versprechen jedoch: Alpha2 war ein Prototyp für Solaris/SPARC, und die README erklärte ausdrücklich, dass Public-Key-Verschlüsselung nicht implementiert war. Ein Programm einzuschränken und seine Herkunft zu bestätigen waren zwei verschiedene Aufgaben.

Die Alpha3-Dokumentation machte die Richtlinie sichtbar. Der Sicherheitsdialog bot Optionen vom vollständigen Ausschluss über den Zugriff nur auf den Quellhost oder das Firewall-Netz bis hin zu uneingeschränktem Zugriff. Auch Datei-Lese- und Schreibzugriffe hingen von Pfadlisten ab; der Schreibpfad war standardmäßig leer, konnte aber administrativ gesetzt werden. Die Grenze lautete also nicht schlicht „Java ist sicher“, sondern bestand aus Regeln, Standardwerten und administrativen Entscheidungen für Code von außen.

Die öffentliche Debatte von 1995 unterschied diese Fragen bereits. Auf der W3C-Mailingliste www-talk diskutierten Teilnehmer, ob eine abgeschottete Laufzeit genügte oder ob auch die Echtheit des geladenen Codes feststehen musste. Der Austausch belegt Uneinigkeit, keinen Konsens. 1996 untersuchten Drew Dean, Edward Felten und Dan Wallach HotJava Alpha3 und dokumentierten mehrere Fehler, darunter Risiken von Dienstverweigerung. Diese spätere Prüfung zeigt nicht, was jeder Nutzer 1995 wusste; sie zeigt, dass eine Sandbox getestet und gepflegt werden muss und keine dauerhafte Garantie ist.

HotJavas historische Bedeutung lag in der Verlagerung des Erweiterungspunkts. Anbieter konnten ausführbares Verhalten zusammen mit einer Seite senden; Leser und Administratoren mussten entscheiden, auf welche lokalen Ressourcen es zugreifen durfte. Das Design senkte die Abstimmungskosten für neue Browserfunktionen und erhöhte zugleich den Sicherheitsaufwand am Endgerät. Die Quellen belegen einen Prototyp und eine umstrittene Architektur, aber weder universelle Verbreitung noch Unverwundbarkeit oder eine gemessene Veränderung der Web-Nutzung.

Quellen und Grenzen der Belege