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

Artículo original ↗ Discusión en Hacker News ↗

Una demo del navegador que une varias ventanas superpuestas en un único lienzo interactivo está encantando a la gente como un uso creativo de las APIs web, al tiempo que plantea dudas sobre privacidad y seguridad. Los comentaristas exploran implementaciones alternativas usando localStorage, BroadcastChannel o postMessage en lugar de WebSockets, y señalan experimentos multi-ventana anteriores en juegos y proyectos artísticos. Muchos se inquietan de que APIs como `window.screenX/Y` y otras propiedades relacionadas con la pantalla o la batería existan siquiera, argumentando que permiten fingerprinting y clickjacking sin ofrecer mucho beneficio legítimo.

Concepto y comportamiento de la demo

  • Varias ventanas del navegador actúan como un único lienzo compartido.
  • Cada ventana informa de su tamaño/posición; el contenido se renderiza de modo que los objetos se extiendan e interactúen a través de ventanas superpuestas.
  • Varios comentaristas encontraron esto alucinante o visualmente impresionante; otros señalan que conceptualmente es similar a los juegos multijugador con múltiples vistas en un espacio de coordenadas compartido.

Implementación: sockets vs APIs del navegador

  • La inspiración original usaba eventos de localStorage para sincronización entre ventanas.
  • Esta versión usa WebSockets; algunos lo ven como “sobreingeniería”, mientras que otros señalan que permite compartirlo con amigos a través de la red.
  • Se sugirieron alternativas:
    • BroadcastChannel para mensajería entre pestañas/ventanas del mismo origen.
    • postMessage() / canales de mensajes cuando una ventana abre otra.
    • service workers o incluso loopback de WebRTC.
  • Algunos señalan que, para una demo local de un solo usuario, los sockets añaden una latencia evitable.

Retardo, rendimiento y comportamiento del navegador

  • Varios preguntan por qué la interacción tiene lag cuando parece “trivial”.
  • Posibles razones propuestas:
    • Retrasos de WebSocket o de red (aunque la red local debería ser rápida).
    • Las actualizaciones de la posición de la ventana no se sincronizan con el hilo de JS.
    • El navegador limita las pestañas/ventanas en segundo plano.
    • Consultar la posición de la ventana en sí mismo es una función lenta del navegador.
    • Limitaciones generales de GUI/compositor; sincronizar varias ventanas de forma fluida no es trivial ni siquiera de forma nativa.

Seguridad, privacidad y APIs web cuestionables

  • A muchos les preocupa que existan window.screenX/screenY y propiedades similares; exponen la ubicación de la ventana y las características de la pantalla.
  • Preocupaciones:
    • Fingerprinting del navegador mediante el tamaño/posición de la pantalla.
    • Clickjacking al predecir dónde aparecerán los diálogos del sistema.
    • El principio de que las páginas web no deberían saber nada del entorno fuera del viewport.
  • Algunas configuraciones de navegador/SO (por ejemplo, con ajustes de privacidad específicos o compositores Wayland) ya fijan estos valores en 0 o los ocultan.
  • Crítica más amplia a las APIs web “sobrecargadas” (por ejemplo, Battery Status) y referencias a abusos pasados y medidas defensivas (como las restricciones de tamaño de ventana de Tor).

Aplicaciones, arte previo y demos relacionadas

  • Usos sugeridos: interfaces en capas al estilo AR, gestión de capas en programas de dibujo, diagramas de mezcla de colores, efectos de “deslizamiento” entre varios monitores, navegación colaborativa.
  • Otros dicen que nada aquí es técnicamente nuevo; demos y juegos similares de múltiples ventanas existen desde hace años (por ejemplo, física o Pong a través de ventanas, experimentos de Chrome, implementaciones antiguas de ActiveX/NPAPI).
  • Varios enlaces a proyectos previos y paralelos (escenas 3D, herramientas de dibujo, juegos multi-ventana) refuerzan que se trata de un ejemplo divertido y pulido de un truco de larga data.