要約

  • HotJavaのアプレットは、事前に組み込まれた処理機能の一部を、ページとともに届いて閲覧者のコンピューターで動くJavaコードに置き換えた。
  • この柔軟性はローカルの権限ポリシーに依存した。SunのAlpha2文書は公開鍵暗号が未実装だと明記し、後年の独立調査はHotJava Alpha3の欠陥を報告した。

1995年、Webページはインタラクティブな対象を記述できても、従来型ブラウザーはその解釈方法をあらかじめ備えている必要があった。HotJavaは、その能力を別の場所から持ち込む方法を示した。ページにJavaアプレットを含めると、HotJavaはプログラムを取得し、ブラウザー内で実行した。ネットワークが運ぶのは文書だけでなく、文書の解釈に必要な仕組みの一部にもなった。

Sunは、固定されたデータ形式やプロトコルの一覧から抜け出す設計としてこれを説明した。新しい画像形式は表示用コードとともに、新しいプロトコルは処理コードとともに届く。HotJavaの白書は、利用者がソフトウェアを一つずつ手作業で導入しなくてよい未来を描いた。これは設計目標と例であり、Web全体で採用された証拠ではない。

互換性の前提も変わった。Alpha2のアプレットガイドによれば、アプレットはHTMLに埋め込めた。新しいタグに対応しないブラウザーはそのタグを無視し、周囲のページを読み続けられた。静的な内容は残るが、新しい動作を実行できるのはHotJavaだけだった。作者は各ブラウザーベンダーの実装を待たずに機能を届けられる。閲覧者には対応ランタイムと、自分の端末でコードを実行する判断が必要になる。

そのため、閲覧者のマシンが決定的な境界になった。Sunの1995年10月の白書は、型検査、バイトコード検証、ランタイム制御を保護策として示した。しかし、リリース資料はその主張に条件を付けている。Alpha2はSolaris/SPARC向けの試作版で、READMEは公開鍵暗号が未実装だと明記した。プログラムの行為を制限することと、誰がそのコードを提供したかを確かめることは別問題だった。

Alpha3の文書は権限設定を利用者に示した。セキュリティ画面には、アプレットを許可しない設定から、配信元ホストのみ、ファイアウォール内、無制限までの選択肢があった。ファイルの読み書きもパス設定に左右され、書き込み先は既定で空だが管理者が設定できた。境界とは「Javaは安全」という標語ではなく、遠隔コードに適用する規則、初期値、管理上の選択だった。

1995年の公開議論もこの違いを捉えていた。W3Cのwww-talkでは、安全な実行環境だけで十分か、受け取ったコードの真正性も必要かが議論された。これは意見の一致ではなく、対立を含む記録だ。1996年にはDrew Dean、Edward Felten、Dan WallachがHotJava Alpha3を調査し、サービス妨害の危険を含む複数の欠陥を報告した。後年の監査から1995年の全利用者の認識を推測することはできない。ただし、サンドボックスは一度作れば保証されるものではなく、検査と保守を要することを示している。

HotJavaの歴史的な動きは、拡張点の移動にある。発信者はページとともに実行コードを送れるようになり、閲覧者と管理者はそのコードがローカルで何に触れられるかを決めることになった。新機能を追加するための調整負担は減る一方、端末側の安全性を保証する負担は増えた。史料が示すのは試作と議論された設計であり、普及規模、完全な安全性、Web利用の変化を測った結果ではない。

出典と証拠の限界