Resumo

  • Os applets do HotJava substituíam alguns componentes pré-instalados por código Java enviado junto com a página e executado no computador do leitor.
  • Essa flexibilidade dependia de uma política local; a documentação Alpha2 da Sun dizia que a criptografia de chave pública ainda não havia sido implementada, e uma análise independente posterior encontrou falhas no HotJava Alpha3.

Em 1995, uma página podia descrever um objeto interativo, mas o navegador convencional precisava saber de antemão como interpretá-lo. O HotJava propôs outra origem para essa capacidade. A página podia apontar para um applet Java; o navegador baixava o programa e o executava dentro de si. A rede passava a transportar não apenas um documento, mas parte do mecanismo necessário para interpretá-lo.

A Sun apresentou a ideia como uma saída do catálogo fixo de formatos e protocolos. Um novo formato de imagem poderia vir acompanhado de seu componente de exibição; um protocolo, de seu controlador. O documento do HotJava imaginava que o usuário deixaria de instalar cada software separadamente. Eram objetivos de projeto e exemplos, não prova de adoção ampla.

A proposta também alterava o acordo de compatibilidade. O guia Alpha2 descrevia applets inseridos em HTML. Um navegador que não reconhecesse a nova tag podia ignorá-la e continuar exibindo o restante da página. O conteúdo estático continuava legível, mas só o HotJava executava o novo comportamento. O autor podia oferecer algo mais sem aguardar todos os fabricantes de navegadores; o leitor precisava de um ambiente compatível e aceitava código rodando localmente.

Por isso, a máquina do leitor tornou-se a fronteira decisiva. O documento da Sun de outubro de 1995 apresentava verificação de tipos, validação de bytecode e controles de execução como proteções. As notas de versão, porém, delimitavam essa promessa. O Alpha2 era um protótipo para Solaris/SPARC, e seu README dizia explicitamente que a criptografia de chave pública ainda não estava implementada. Conter o que um programa pode fazer e confirmar quem o forneceu eram problemas distintos.

A documentação Alpha3 tornava a política visível. A janela de segurança oferecia modos que iam de bloquear applets a permitir apenas o host de origem ou a rede atrás do firewall, além do modo irrestrito. A leitura e a gravação de arquivos dependiam de caminhos autorizados; o caminho de gravação começava vazio, embora pudesse ser configurado pelo administrador. A fronteira não era simplesmente “Java é seguro”, mas um conjunto de regras, padrões iniciais e escolhas administrativas para o código recebido de fora.

A discussão pública de 1995 já separava essas questões. Na lista www-talk da W3C, participantes debateram se um ambiente isolado bastava ou se também era necessário confirmar a autenticidade do código baixado. A troca registra divergência, não consenso. Em 1996, Drew Dean, Edward Felten e Dan Wallach examinaram o HotJava Alpha3 e documentaram falhas, incluindo riscos de negação de serviço. Essa auditoria posterior não permite afirmar o que cada usuário sabia em 1995; mostra que um sandbox exige testes e manutenção contínuos, não pode ser tratado como garantia permanente.

A contribuição histórica do HotJava foi deslocar o ponto de extensão. Os editores podiam enviar comportamento executável junto com a página; leitores e administradores assumiam a decisão sobre os recursos locais disponíveis. O desenho reduzia o custo de coordenação para acrescentar uma capacidade ao navegador e aumentava a carga de segurança no dispositivo final. As fontes comprovam um protótipo e uma arquitetura debatida, não adoção universal, segurança invulnerável ou mudança mensurada no uso da Web.

Fontes e limites das evidências