SharedArrayBuffer अखेर ब्राउझरमध्ये पुन्हा काम करू लागले आहे, परंतु ते तेव्हाच शक्य आहे जेव्हा पेज 'cross-origin isolated' असते – ही अशी स्थिती आहे ज्यासाठी दोन रिस्पॉन्स हेडर्सची आवश्यकता असते. हे हेडर्स जोडल्यामुळे मला माझ्या साइटवरील प्रत्येक थर्ड-पार्टी स्क्रिप्ट काढून टाकावी लागली, ज्यामुळे संपूर्ण फ्रंट एंडची रचना आणि डेटा लीक होण्याच्या पद्धतीत मोठा बदल झाला.

हे हेडर्स का महत्त्वाचे आहेत

SharedArrayBuffer JavaScript मध्ये खऱ्या अर्थाने मल्टिथ्रेडिंग सक्षम करते, जे टॅबमध्ये ffmpeg चालवण्यासाठी आवश्यक आहे. आधुनिक ब्राउझरनी Spectre-शैलीच्या प्रतिबंधांनंतर (mitigations) ही सुविधा पुन्हा सुरू केली आहे, परंतु त्यांनी ती cross-origin isolation शी जोडली आहे. ते आयसोलेशन मिळवण्यासाठी सर्व्हरने खालील गोष्टी पाठवणे आवश्यक आहे:

  • Cross-Origin-Opener-Policy: same-origin
  • Cross-Origin-Embedder-Policy: require-corp

दुसरे हेडर, require-corp, ब्राउझरला सांगते की कोणत्याही बाह्य संसाधनामध्ये (external resource) Cross-Origin-Resource-Policy हेडर असणे आवश्यक आहे किंवा ते CORS (Cross-Origin Resource Sharing) द्वारे मिळवले जाणे आवश्यक आहे. बहुतेक थर्ड-पार्टी सेवांमध्ये हे हेडर्स नसतात, त्यामुळे त्यांच्या स्क्रिप्ट्स, फॉन्ट्स आणि iframes थेट ब्लॉक केले जातात.

आयसोलेशन सुरू केल्यावर काय काय बंद पडले

ज्या क्षणी हे हेडर्स लागू झाले, तेव्हा समस्यांची साखळी सुरू झाली:

  • Analytics – बहुतेक प्रदाते (providers) त्यांचा ट्रॅकिंग कोड एका साध्या <script> द्वारे लोड करतात जो no-CORS विनंती करतो. CORP हेडरशिवाय ही विनंती नाकारली जाते, त्यामुळे ट्रॅकर कधीच चालत नाही.
  • Google Fonts – स्टाईलशीट fonts.googleapis.com मधून CORS शिवाय मिळवली जाते. ब्राउझर ती काढून टाकतो, ज्यामुळे पेजवरील कस्टम टायपोग्राफी निघून जाते.
  • Embedded media – YouTube iframes आणि विजेट स्क्रिप्ट्समध्ये CORP नसते, त्यामुळे ते रेंडर होणे थांबते.
  • OAuth pop-ups – कडक 'same-origin policy' मुळे window.opener संबंध तुटतो, ज्यामुळे नेहमीचा पॉपअप-आधारित लॉगिन फ्लो खंडित होतो.

थोडक्यात सांगायचे तर, कोणतेही असे अ‍ॅसेट जे थर्ड-पार्टी डोमेनवर अवलंबून होते, ते नाहीसे झाले, जोपर्यंत त्या डोमेनने नवीन हेडर नियमांचा स्वीकार केला नाही.

मध्यस्थांशिवाय पुनर्बांधणी

साइट खराब झाल्यामुळे, मी सेल्फ-होस्टेड अ‍ॅसेट्सच्या आधारे फ्रंट-एंड स्टॅक पुन्हा लिहिला:

  • Fonts and images आता माझ्या स्वतःच्या ओरिजिनमधून सर्व्ह केले जातात, ज्यामुळे बाह्य स्टाईलशीट्सची गरज उरली नाही.
  • Data APIs मी नियंत्रित करतो त्या खाजगी बॅकएंडवर आधारित आहेत, जेणेकरून प्रत्येक विनंती माझ्या डोमेनच्या आतच राहील.
  • Analytics एका लहान Cloudflare Worker मध्ये रूपांतरित केले गेले जे POST इव्हेंट्स स्वीकारते आणि त्यांना खाजगी बकेटमध्ये साठवते. क्लायंट साईडवर फक्त काही ओळींचा fetch कोड आहे.
  • Error reporting and session replay सारखी साधने जसे की Sentry पूर्णपणे काढून टाकली गेली; आता कोणताही क्रॅश माझ्या स्वतःच्या एंडपॉइंटवर लॉग केला जातो.

जर बाह्य संसाधनाची गरज असेल, तर एकमेव व्यवहार्य मार्ग म्हणजे ते तुमच्या मालकीच्या सर्व्हरद्वारे प्रॉक्सी करणे, जेणेकरून ब्राउझरला दिसण्यापूर्वी आवश्यक CORP हेडर जोडता येईल.

गोपनीयतेचा फायदा विरुद्ध कार्यात्मक खर्च

तात्काळ फायदा स्पष्ट आहे: साइट आता जाहिरात नेटवर्क, फॉन्ट प्रदाते किंवा व्हिडिओ प्लॅटफॉर्म्सना वापरण्याचा डेटा (usage data) लीक करत नाही. सर्व टेलिमेट्री माझ्या नियंत्रणाखाली राहते आणि मला हवी तेव्हा मी ती हटवू शकतो. सामान्य थर्ड-पार्टी स्टॅकसह इतकी गोपनीयता मिळवणे कठीण आहे.

याचा तोटा म्हणजे देखभालीचा अतिरिक्त भार. फॉन्ट्स होस्ट करणे, ॲनालिटिक्स स्टोरेज हाताळणे आणि प्रॉक्सी अपडेट ठेवणे ही अशी कामे आहेत जी बहुतेक डेव्हलपर्स विशेष सेवांना (specialized services) आउटसोर्स करतात. या दृष्टिकोनाचा अर्थ असा देखील आहे की त्या सेवांद्वारे मिळणाऱ्या वैशिष्ट्यांचा (features) त्याग करणे – उदाहरणार्थ, रिअल-टाइम एरर अ‍ॅग्रिगेशन किंवा तपशीलवार फनेल व्हिज्युअलायझेशन.

प्रतिवाद: इकोसिस्टम जुळवून घेईल का?

काही लोकांचा असा युक्तिवाद आहे की थर्ड-पार्टी विक्रेते अखेरीस आवश्यक हेडर्स जोडतील, ज्यामुळे क्रॉस-ओरिजिन आयसोलेशन स्वीकारणे सोपे होईल. काही आधीच तसे करत आहेत, परंतु मोठ्या प्रमाणावर वापरल्या जाणाऱ्या सेवांमध्ये अजूनही तसे केलेले नाही. जोपर्यंत इकोसिस्टम या पातळीवर येत नाही, तोपर्यंत डेव्हलपर्सना हे ठरवावे लागेल की गोपनीयतेचा फायदा सेल्फ-होस्टिंगसाठी आवश्यक असलेल्या इंजिनिअरिंग प्रयत्नांपेक्षा जास्त आहे की नाही.

तुम्ही खरोखर आयसोलेटेड आहात की नाही हे कसे तपासायचे

पुन्हा लिहिण्यास सुरुवात करण्यापूर्वी, ब्राउझर तुमच्या पेजला आयसोलेटेड म्हणून पाहत आहे याची खात्री करा:

crossOriginIsolated   // should be true
typeof SharedArrayBuffer   // should be "function"

जर दोन्हीपैकी एक तपासणी (check) अयशस्वी झाली, तर हेडर्स योग्यरित्या लागू केले जात नाहीत आणि SharedArrayBuffer उपलब्ध राहणार नाही.

डेव्हलपर्ससाठी पुढे काय?

जसजसे अधिक वेब-अ‍ॅप्स मल्टिथ्रेडेड JavaScript च्या परफॉर्मन्स वाढीचा शोध घेत आहेत, तसतसे CORP स्वीकारण्यासाठी थर्ड-पार्टी प्रदात्यांवरचा दबाव वाढेल. दरम्यान, ज्या प्रोजेक्टला SharedArrayBuffer ची आवश्यकता आहे त्यांनी सेल्फ-होस्टेड अ‍ॅसेट स्ट्रॅटेजी किंवा हलक्या वजनाच्या प्रॉक्सी लेअरची योजना आखली पाहिजे. आयसोलेशनच्या गरजांमधील बदलांसाठी ब्राउझरच्या रिलीज नोट्सवर लक्ष ठेवणे देखील आवश्यक असेल.

निष्कर्ष: SharedArrayBuffer अनलॉक करण्यासाठी cross-origin isolation सक्षम करणे ही एक कठीण निवड ठरते – एकतर थर्ड-पार्टी स्क्रिप्ट्सची सोय कायम ठेवणे किंवा अधिक कडक आणि स्वतःच्या नियंत्रणाखालील प्रायव्हसी मॉडेलसाठी ती सोय त्यागणे. हा निर्णय आधुनिक वेबसाइट्सचे तांत्रिक आर्किटेक्चर आणि डेटा-फ्लो फूटप्रिंट या दोन्ही गोष्टींना नवीन आकार देतो.