Кратко

  • Апплеты HotJava заменяли часть заранее установленных обработчиков кодом Java, который передавался вместе со страницей и запускался на компьютере читателя.
  • Такая гибкость зависела от локальной политики. В документации Sun для Alpha2 сказано, что шифрование с открытым ключом ещё не было реализовано; позднее независимая проверка обнаружила уязвимости в HotJava Alpha3.

В 1995 году веб-страница могла описать интерактивный объект, но обычный браузер должен был заранее знать, как его интерпретировать. HotJava предложила другой источник такой возможности: страница ссылалась на Java-апплет, браузер загружал программу и запускал её внутри себя. По сети передавался уже не только документ, но и часть механизма для его интерпретации.

Sun представляла этот подход как выход за пределы фиксированного набора форматов и протоколов. Новый формат изображения мог приходить вместе с обработчиком; новый протокол — со своим программным модулем. В описании HotJava предполагалось, что пользователю больше не придётся устанавливать каждую программу отдельно. Это были цели проектирования и примеры, а не свидетельство массового внедрения.

Изменилась и модель совместимости. В руководстве Alpha2 описаны апплеты, встроенные в HTML. Браузер без поддержки нового тега мог его проигнорировать и продолжить показывать остальную страницу. Статический текст сохранял доступность, но новое поведение исполнял только HotJava. Автор мог предлагать новые возможности, не ожидая изменений у всех производителей браузеров; читателю требовалась совместимая среда и согласие на локальный запуск кода.

Поэтому компьютер читателя стал решающей границей. В октябрьском документе Sun за 1995 год проверка типов, верификация байткода и контроль среды выполнения описаны как защитные меры. Однако примечания к выпуску ограничивали эти обещания: Alpha2 была прототипом для Solaris/SPARC, а README прямо сообщал, что шифрование с открытым ключом не реализовано. Ограничить действия программы и подтвердить её происхождение — разные задачи.

Документация Alpha3 показывала пользователю настройки политики. Диалог безопасности предлагал режимы от полного запрета апплетов до доступа только с исходного узла или из-за межсетевого экрана, а также неограниченный режим. Чтение и запись файлов зависели от списков путей; путь записи по умолчанию был пустым, хотя администратор мог его настроить. Граница безопасности состояла не из лозунга «Java безопасна», а из правил, значений по умолчанию и административных решений для кода из внешней сети.

Публичная дискуссия 1995 года уже разделяла эти вопросы. В списке рассылки W3C www-talk участники спорили, достаточно ли изолированной среды исполнения или требуется также удостоверять подлинность загруженного кода. Переписка фиксирует разногласие, а не консенсус. В 1996 году Drew Dean, Edward Felten и Dan Wallach исследовали HotJava Alpha3 и описали ряд ошибок, включая риски отказа в обслуживании. Этот более поздний аудит не показывает, что знал каждый пользователь в 1995 году; он показывает, что песочницу необходимо проверять и поддерживать, а не считать постоянной гарантией.

Исторический вклад HotJava заключался в переносе точки расширения. Издатель мог передать исполняемое поведение вместе со страницей, а читатель и системный администратор должны были определить, к каким локальным ресурсам оно получит доступ. Проект снижал затраты на согласование новых возможностей браузера, но повышал нагрузку по обеспечению безопасности на конечном устройстве. Источники подтверждают наличие прототипа и обсуждавшейся архитектуры, но не всеобщую популярность, абсолютную защищённость или измеренное изменение использования Веба.

Источники и ограничения доказательств