Show HN: Vi este este experimento alucinante, así que hice una versión simple de él

Artigo original ↗ Discussão no Hacker News ↗

Uma demo de navegador que costura múltiplas janelas sobrepostas em uma única tela interativa está encantando as pessoas como um uso criativo das APIs da web, ao mesmo tempo em que levanta questões sobre privacidade e segurança. Comentadores exploram implementações alternativas usando localStorage, BroadcastChannel ou postMessage em vez de WebSockets, e apontam experimentos multiwindow anteriores em jogos e projetos de arte. Muitos ficam incomodados com o fato de APIs como `window.screenX/Y` e outras propriedades relacionadas à tela ou à bateria existirem, argumentando que elas permitem fingerprinting e clickjacking sem oferecer muito benefício legítimo.

Conceito e comportamento da demo

  • Múltiplas janelas do navegador atuam como uma única tela compartilhada.
  • Cada janela informa seu tamanho/posição; o conteúdo é renderizado de modo que os objetos se estendam e interajam entre janelas sobrepostas.
  • Vários comentaristas acharam isso alucinante ou visualmente impressionante; outros observam que, conceitualmente, é semelhante a jogos multiplayer com múltiplas visões em um espaço de coordenadas compartilhado.

Implementação: sockets vs APIs do navegador

  • A inspiração original usava eventos de localStorage para sincronização entre janelas.
  • Esta versão usa WebSockets; alguns veem isso como “sobreengenharia”, enquanto outros observam que isso permite compartilhar com amigos pela rede.
  • Alternativas sugeridas:
    • BroadcastChannel para mensagens entre abas/janelas no mesmo origin.
    • postMessage() / canais de mensagem quando uma janela abre outra.
    • service workers ou até loopback via WebRTC.
  • Alguns apontam que, para uma demo local de usuário único, sockets adicionam latência evitável.

Lag, desempenho e comportamento do navegador

  • Vários perguntam por que a interação fica lenta quando parece “trivial”.
  • Razões propostas:
    • Atrasos de WebSocket ou de rede (embora a rede local devesse ser rápida).
    • Atualizações de posição da janela não sincronizadas com a thread de JS.
    • Limitação de abas/janelas em segundo plano pelo navegador.
    • A própria consulta da posição da janela sendo um recurso lento do navegador.
    • Limitações gerais de GUI/compositor; sincronização suave entre múltiplas janelas não é trivial nem mesmo nativamente.

Segurança, privacidade e APIs web questionáveis

  • Muitos ficam incomodados com o fato de window.screenX/screenY e propriedades semelhantes existirem; elas expõem a localização da janela e características da tela.
  • Preocupações:
    • Fingerprinting do navegador por meio do tamanho/posição da tela.
    • Clickjacking ao prever onde os diálogos do sistema aparecerão.
    • O princípio de que páginas web não deveriam saber sobre o ambiente fora da viewport.
  • Algumas configurações de navegador/SO (por exemplo, com ajustes específicos de privacidade ou compositores Wayland) já limitam esses valores a 0 ou os ocultam.
  • Crítica mais ampla a APIs web “superpoderosas” (por exemplo, Battery Status) e referências a abusos passados e medidas defensivas (como as restrições de tamanho de janela do Tor).

Aplicações, trabalhos anteriores e demos relacionadas

  • Usos sugeridos: interfaces em camadas no estilo AR, gerenciamento de camadas em programas de desenho, diagramas de mistura de cores, efeitos de “deslizar” em múltiplos monitores, navegação colaborativa.
  • Outros dizem que nada aqui é tecnicamente novo; demos e jogos semelhantes com múltiplas janelas existem há anos (por exemplo, física ou Pong entre janelas, experimentos do Chrome, implementações antigas com ActiveX/NPAPI).
  • Vários links para projetos anteriores e paralelos (cenas 3D, ferramentas de desenho, jogos multiwindow) reforçam que esta é uma exemplo divertido e polido de uma técnica de longa data.