Show HN: I saw this mind-blowing experiment, so I made a simple version of it

Original Article ↗ Hacker News Discussion ↗

A browser demo that stitches multiple overlapping windows into a single interactive canvas is delighting people as a creative use of web APIs, while also raising questions about privacy and security. Commenters explore alternative implementations using localStorage, BroadcastChannel, or postMessage instead of WebSockets, and point to earlier multi-window experiments in games and art projects. Many are unsettled that APIs like `window.screenX/Y` and other screen- or battery-related properties exist at all, arguing they enable fingerprinting and clickjacking without offering much legitimate benefit.

Demo concept & behavior

  • Multiple browser windows act as a single shared canvas.
  • Each window reports its size/position; content is rendered so objects span and interact across overlapping windows.
  • Several commenters found this mind‑bending or visually impressive; others note it’s conceptually similar to multiplayer games with multiple viewports in a shared coordinate space.

Implementation: sockets vs browser APIs

  • Original inspiration used localStorage events for cross‑window sync.
  • This version uses WebSockets; some see that as “over‑engineering,” others note it enables sharing with friends over the network.
  • Alternatives suggested:
    • BroadcastChannel for same‑origin, multi‑tab/window messaging.
    • postMessage() / message channels when one window opens another.
    • Service workers or even WebRTC loopback.
  • Some point out that for a local, single‑user demo, sockets add avoidable latency.

Lag, performance, and browser behavior

  • Several ask why the interaction lags when it seems “trivial.”
  • Proposed reasons:
    • WebSocket or network delays (though local network should be fast).
    • Window position updates not synchronized with the JS thread.
    • Browser throttling of background tabs/windows.
    • Querying window position itself being a laggy browser feature.
    • General GUI/compositor limitations; smooth multi‑window synchronization is non‑trivial even natively.

Security, privacy, and questionable web APIs

  • Many are disturbed that window.screenX/screenY and similar properties exist; they expose window location and screen characteristics.
  • Concerns:
    • Browser fingerprinting via screen size/position.
    • Clickjacking by predicting where system dialogs will appear.
    • Principle that web pages shouldn’t know about the environment outside the viewport.
  • Some browsers/OS setups (e.g., with specific privacy settings or Wayland compositors) already clamp these values to 0 or hide them.
  • Broader criticism of “overpowered” web APIs (e.g., Battery Status) and references to past abuses and defensive measures (like Tor’s window‑size restrictions).

Applications, prior art, and related demos

  • Suggested uses: AR‑style layered interfaces, paint program layer management, color‑mixing diagrams, multi‑monitor “swipe” effects, collaborative browsing.
  • Others say nothing here is technically new; similar multi‑window demos and games have existed for years (e.g., physics or Pong across windows, Chrome experiments, older ActiveX/NPAPI implementations).
  • Multiple links to prior and parallel projects (3D scenes, drawing tools, multi‑window games) reinforce that this is a fun, polished example of a long‑standing trick.