Show HN: मैंने यह दिमाग़ घुमा देने वाला प्रयोग देखा, इसलिए मैंने इसका एक साधारण संस्करण बनाया

मूल लेख ↗ Hacker News चर्चा ↗

एक ब्राउज़र डेमो जो कई ओवरलैप होती विंडोज़ को एक इंटरैक्टिव कैनवास में जोड़ देता है, रचनात्मक वेब API उपयोग के रूप में लोगों को प्रभावित कर रहा है, लेकिन साथ ही गोपनीयता और सुरक्षा पर सवाल भी उठा रहा है। टिप्पणीकार localStorage, BroadcastChannel, या postMessage का उपयोग करके WebSockets के बजाय वैकल्पिक इंप्लीमेंटेशन पर चर्चा करते हैं, और खेलों तथा कला परियोजनाओं में पहले हुए multi-window प्रयोगों की ओर इशारा करते हैं। कई लोगों को इस बात से असहजता है कि `window.screenX/Y` और battery से जुड़ी अन्य प्रॉपर्टीज़ जैसी APIs मौजूद ही क्यों हैं; उनका तर्क है कि ये fingerprinting और clickjacking को सक्षम करती हैं, जबकि इनका वैध लाभ बहुत कम है।

डेमो का विचार और व्यवहार

  • कई ब्राउज़र विंडो एक ही साझा कैनवास की तरह काम करती हैं।
  • हर विंडो अपना आकार/स्थिति रिपोर्ट करती है; कंटेंट इस तरह रेंडर होता है कि ऑब्जेक्ट्स ओवरलैप होती विंडोज़ के बीच फैलते और आपस में इंटरैक्ट करते हैं।
  • कई टिप्पणीकारों को यह मन को झकझोर देने वाला या दृश्य रूप से प्रभावशाली लगा; अन्य लोगों ने बताया कि वैचारिक रूप से यह साझा कोऑर्डिनेट स्पेस में कई व्यूपोर्ट वाले मल्टीप्लेयर गेम्स जैसा है।

इंप्लीमेंटेशन: सॉकेट्स बनाम ब्राउज़र API

  • मूल प्रेरणा ने क्रॉस-विंडो सिंक के लिए localStorage इवेंट्स का उपयोग किया था।
  • इस संस्करण में WebSockets का उपयोग किया गया है; कुछ लोगों को यह “ओवर-इंजीनियरिंग” लगा, जबकि अन्य ने कहा कि इससे नेटवर्क पर दोस्तों के साथ साझा करना संभव हो जाता है।
  • सुझाए गए विकल्प:
    • समान-origin, मल्टी-टैब/विंडो मैसेजिंग के लिए BroadcastChannel।
    • जब एक विंडो दूसरी खोलती है, तब postMessage() / message channels।
    • Service workers या यहाँ तक कि WebRTC loopback।
  • कुछ लोगों ने बताया कि स्थानीय, एकल-उपयोगकर्ता डेमो के लिए सॉकेट्स अनावश्यक latency जोड़ते हैं।

लैग, परफ़ॉर्मेंस, और ब्राउज़र व्यवहार

  • कई लोगों ने पूछा कि जब यह “trivial” लगता है, तब इंटरैक्शन में लैग क्यों है।
  • सुझाए गए कारण:
    • WebSocket या नेटवर्क देरी (हालाँकि लोकल नेटवर्क तेज़ होना चाहिए)।
    • विंडो की स्थिति के अपडेट्स का JS thread के साथ synchronized न होना।
    • background tabs/windows को ब्राउज़र द्वारा throttle करना।
    • स्वयं विंडो की position क्वेरी करना एक laggy ब्राउज़र फीचर होना।
    • सामान्य GUI/compositor सीमाएँ; स्मूद multi-window synchronization मूल रूप से भी गैर-तुच्छ है।

सुरक्षा, गोपनीयता, और संदिग्ध वेब API

  • कई लोग इस बात से परेशान थे कि window.screenX/screenY जैसी प्रॉपर्टीज़ मौजूद हैं; ये विंडो की लोकेशन और स्क्रीन की विशेषताओं को उजागर करती हैं।
  • चिंताएँ:
    • स्क्रीन के आकार/स्थिति के माध्यम से ब्राउज़र fingerprinting।
    • सिस्टम डायलॉग कहाँ दिखाई देंगे, इसका अनुमान लगाकर clickjacking।
    • यह सिद्धांत कि वेब पेजों को viewport के बाहर के वातावरण के बारे में नहीं जानना चाहिए।
  • कुछ ब्राउज़र/OS सेटअप्स (जैसे विशिष्ट privacy settings या Wayland compositors के साथ) पहले से ही इन मानों को 0 पर clamp कर देते हैं या छिपा देते हैं।
  • “ओवरपावर्ड” वेब APIs (जैसे Battery Status) की व्यापक आलोचना और पिछले दुरुपयोगों तथा रक्षात्मक उपायों (जैसे Tor की window-size restrictions) के संदर्भ भी दिए गए।

उपयोग, पूर्व कला, और संबंधित डेमो

  • सुझाए गए उपयोग: AR-शैली layered interfaces, paint program layer management, color-mixing diagrams, multi-monitor “swipe” effects, collaborative browsing।
  • अन्य लोगों का कहना है कि यहाँ तकनीकी रूप से कुछ नया नहीं है; वर्षों से इसी तरह के multi-window demos और games मौजूद रहे हैं (जैसे विंडोज़ के बीच physics या Pong, Chrome experiments, पुराने ActiveX/NPAPI implementations)।
  • 3D scenes, drawing tools, multi-window games जैसी पूर्व और समानांतर परियोजनाओं के कई लिंक यह पुष्ट करते हैं कि यह एक लंबे समय से मौजूद trick का मज़ेदार, polished उदाहरण है।