SharedArrayBuffer ബ്രൗസറിൽ വീണ്ടും പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും, ഒരു പേജ് cross-origin isolated ആണെങ്കിൽ മാത്രമേ അത് സാധ്യമാകൂ – ഇതിനായി രണ്ട് response headers ആവശ്യമാണ്. ഈ headers ചേർക്കേണ്ടി വന്നതോടെ എന്റെ സൈറ്റിലെ എല്ലാ third-party സ്ക്രിപ്റ്റുകളും ഒഴിവാക്കേണ്ടി വന്നു, ഇത് എന്റെ ഫ്രണ്ട് എൻഡ് നിർമ്മാണ രീതിയെയും ഡാറ്റാ ചോർച്ചയെയും (data leaks) പാടെ മാറ്റിമറിച്ചു.

Why the headers matter

JavaScript-ൽ യഥാർത്ഥ മൾട്ടിത്രെഡിംഗ് (multithreading) സാധ്യമാക്കുന്നത് SharedArrayBuffer ആണ്, ഒരു ടാബിനുള്ളിൽ ffmpeg പ്രവർത്തിപ്പിക്കാൻ ഇത് അത്യാവശ്യമാണ്. Spectre-style സുരക്ഷാ ക്രമീകരണങ്ങൾക്ക് ശേഷം ആധുനിക ബ്രൗസറുകൾ ഈ ഫീച്ചർ വീണ്ടും സജീവമാക്കിയിട്ടുണ്ടെങ്കിലും, അവ ഇതിനെ 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) വഴി ഫെച്ച് ചെയ്യണം എന്ന് ബ്രൗസറിനോട് പറയുന്നു. മിക്ക third-party സേവനങ്ങളും ഈ ഹെഡറുകൾ നൽകുന്നില്ല, അതിനാൽ അവയുടെ സ്ക്രിപ്റ്റുകളും ഫോണ്ടുകളും iframe-കളും നേരിട്ട് ബ്ലോക്ക് ചെയ്യപ്പെടുന്നു.

What fell away when isolation was turned on

ഈ ഹെഡറുകൾ നടപ്പിലാക്കിയ നിമിഷം തന്നെ നിരവധി പ്രശ്നങ്ങൾ ഉടലെടുത്തു:

  • Analytics – മിക്ക സേവനദാതാക്കളും അവരുടെ ട്രാക്കിംഗ് കോഡ് ഒരു ലളിതമായ <script> ഉപയോഗിച്ചാണ് ലോഡ് ചെയ്യുന്നത്, ഇത് no-CORS റിക്വസ്റ്റ് ആണ്. CORP ഹെഡർ ഇല്ലാതെ ഈ റിക്വസ്റ്റ് നിരസിക്കപ്പെടും, അതിനാൽ ട്രാക്കർ പ്രവർത്തിക്കില്ല.
  • Google Fonts – സ്റ്റൈൽഷീറ്റ് fonts.googleapis.com-ൽ നിന്ന് CORS ഇല്ലാതെയാണ് ഫെച്ച് ചെയ്യുന്നത്. ബ്രൗസർ ഇത് ഒഴിവാക്കുന്നതിനാൽ പേജിന് അതിന്റെ കസ്റ്റം ടൈപ്പോഗ്രാഫി നഷ്ടപ്പെടുന്നു.
  • Embedded media – YouTube iframe-കൾക്കും വിഡ്ജറ്റ് സ്ക്രിപ്റ്റുകൾക്കും CORP ഇല്ലാത്തതിനാൽ അവ റെൻഡർ ചെയ്യപ്പെടാറില്ല.
  • OAuth pop-ups – കർശനമായ same-origin പോളിസി കാരണം window.opener ബന്ധം തകരുന്നു, ഇത് സാധാരണ പോപ്പ്അപ്പ് അധിഷ്ഠിത ലോഗിൻ പ്രക്രിയയെ തടസ്സപ്പെടുത്തുന്നു.

ചുരുക്കത്തിൽ, ആ ഡൊമെയ്ൻ പുതിയ ഹെഡർ നിയമങ്ങൾ സ്വീകരിക്കുന്നില്ലെങ്കിൽ, മൂന്നാം കക്ഷി ഡൊമെയ്‌നുകളെ ആശ്രയിക്കുന്ന ഏതൊരു അസറ്റും അപ്രത്യക്ഷമാകും.

Rebuilding without the middlemen

തകരാറിലായ സൈറ്റ് പരിഹരിക്കാനായി, ഞാൻ സെൽഫ്-ഹോസ്റ്റ് ചെയ്ത അസറ്റുകളെ (self-hosted assets) അടിസ്ഥാനമാക്കി ഫ്രണ്ട്-എൻഡ് സ്റ്റാക്ക് വീണ്ടും എഴുതി:

  • Fonts and images ഇപ്പോൾ എന്റെ സ്വന്തം ഒറിജിനിൽ നിന്ന് തന്നെയാണ് നൽകുന്നത്, ഇത് ബാഹ്യ സ്റ്റൈൽഷീറ്റുകളുടെ ആവശ്യം ഇല്ലാതാക്കുന്നു.
  • Data APIs ഞാൻ നിയന്ത്രിക്കുന്ന ഒരു സ്വകാര്യ ബാക്കെൻഡിലാണ് നിർമ്മിച്ചിരിക്കുന്നത്, അതിനാൽ എല്ലാ റിക്വസ്റ്റുകളും എന്റെ ഡൊമെയ്നുള്ളിൽ തന്നെ നിൽക്കുന്നു.
  • Analytics എന്നത് POST ഇവന്റുകൾ സ്വീകരിക്കുകയും അവ ഒരു സ്വകാര്യ ബക്കറ്റിൽ സൂക്ഷിക്കുകയും ചെയ്യുന്ന ചെറിയൊരു Cloudflare Worker ആയി മാറി. ക്ലയന്റ് സൈഡിൽ വെറും പന്ത്രണ്ട് വരി fetch കോഡ് മാത്രമാണുള്ളത്.
  • Sentry പോലുള്ള Error reporting and session replay ടൂളുകൾ പൂർണ്ണമായും ഒഴിവാക്കി; ഇപ്പോൾ ഏതൊരു ക്രാഷും എന്റെ സ്വന്തം എൻഡ്പോയിന്റിലേക്ക് ലോഗ് ചെയ്യപ്പെടുന്നു.

ഒരു ബാഹ്യ റിസോഴ്സ് ആവശ്യമാണെങ്കിൽ, അത് നിങ്ങൾ ഉടമസ്ഥതയിലുള്ള ഒരു സെർവർ വഴി പ്രോക്സി (proxy) ചെയ്യുക എന്നതാണ് ഏക മാർഗ്ഗം. ബ്രൗസർ അത് കാണുന്നതിന് മുമ്പ് ആവശ്യമായ CORP ഹെഡർ ഇതിലൂടെ ചേർക്കാം.

Privacy gains versus operational cost

ഇതിന്റെ ഉടനടിയുള്ള ഗുണം വ്യക്തമാണ്: സൈറ്റ് ഇനി പരസ്യ ശൃംഖലകൾക്കോ (ad networks), ഫോണ്ട് പ്രൊവൈഡർമാർക്കോ, വീഡിയോ പ്ലാറ്റ്‌ഫോമുകൾക്കോ ഉപയോഗ വിവരങ്ങൾ ചോർത്തുന്നില്ല. എല്ലാ ടെലിമെട്രിയും (telemetry) എന്റെ നിയന്ത്രണത്തിലാണ്, എനിക്ക് എപ്പോൾ വേണമെങ്കിലും അത് ഡിലീറ്റ് ചെയ്യാം. സാധാരണ third-party സ്റ്റാക്കുകൾ ഉപയോഗിച്ച് ഇത്രയും ഉയർന്ന നിലവാരത്തിലുള്ള സ്വകാര്യത കൈവരിക്കുക പ്രയാസമാണ്.

എന്നാൽ ഇതിന് പകരമായി കൂടുതൽ മെയിന്റനൻസ് ഭാരം കൂടി വരുന്നു. ഫോണ്ടുകൾ ഹോസ്റ്റ് ചെയ്യുക, അനലിറ്റിക്സ് സ്റ്റോറേജ് കൈകാര്യം ചെയ്യുക, ഒരു പ്രോക്സി അപ്‌ഡേറ്റ് ആയി സൂക്ഷിക്കുക എന്നിവ മിക്ക ഡെവലപ്പർമാരും പ്രത്യേക സേവനങ്ങൾക്കായി ഏൽപ്പിക്കാറുള്ള കാര്യങ്ങളാണ്. കൂടാതെ, ആ സേവനങ്ങൾ നൽകുന്ന ഫീച്ചറുകൾ (ഉദാഹരണത്തിന്, real-time error aggregation അല്ലെങ്കിൽ വിശദമായ funnel visualisations) നഷ്ടപ്പെടാനും ഇത് കാരണമാകുന്നു.

Counter-point: will the ecosystem adapt?

മൂന്നാം കക്ഷി വെണ്ടർമാർ ആവശ്യമായ ഹെഡറുകൾ eventually ചേർക്കുമെന്നും, അതുവഴി cross-origin isolation നടപ്പിലാക്കുന്നത് എളുപ്പമാകുമെന്നും ചിലർ വാദിക്കുന്നു. കുറച്ചുപേർ ഇപ്പോൾ തന്നെ അത് ചെയ്യുന്നുണ്ടെങ്കിലും, വ്യാപകമായി ഉപയോഗിക്കുന്ന ഭൂരിഭാഗം സേവനങ്ങളും ഇപ്പോഴും അത് ചെയ്യുന്നില്ല. ഈ മാറ്റം വരുന്നത് വരെ, സ്വയം ഹോസ്റ്റ് ചെയ്യുന്നതിനായുള്ള എഞ്ചിനീയറിംഗ് പരിശ്രമത്തേക്കാൾ സ്വകാര്യത നൽകുന്ന ഗുണം വലുതാണോ എന്ന് ഡെവലപ്പർമാർ തീരുമാനിക്കേണ്ടതുണ്ട്.

How to verify you’re truly isolated

പുനർനിർമ്മാണം തുടങ്ങുന്നതിന് മുമ്പ്, ബ്രൗസർ നിങ്ങളുടെ പേജിനെ ഐസൊലേറ്റഡ് ആയി കാണുന്നുണ്ടോ എന്ന് ഉറപ്പുവരുത്തുക:

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

ഏതെങ്കിലും പരിശോധന പരാജയപ്പെട്ടാൽ, ഹെഡറുകൾ ശരിയായി നടപ്പിലാക്കുന്നില്ല എന്നാണ് അർത്ഥം, അപ്പോൾ SharedArrayBuffer ലഭ്യമാകില്ല.

What’s next for developers?

കൂടുതൽ വെബ് ആപ്പുകൾ മൾട്ടിത്രെഡഡ് JavaScript-ന്റെ പെർഫോമൻസ് ആഗ്രഹിക്കുമ്പോൾ, CORP സ്വീകരിക്കാൻ third-party പ്രൊവൈഡർമാരുടെ മേലുള്ള സമ്മർദ്ദം വർദ്ധിക്കും. അതുവരെ, SharedArrayBuffer ആവശ്യമായ ഏതൊരു പ്രോജക്റ്റും സെൽഫ്-ഹോസ്റ്റ് അസറ്റ് സ്ട്രാറ്റജി അല്ലെങ്കിൽ ഒരു ലൈറ്റ്വെയ്റ്റ് പ്രോക്സി ലെയർ എന്നിവയ്ക്കായി തയ്യാറെടുക്കണം. ഐസൊലേഷൻ ആവശ്യകതകളിലെ മാറ്റങ്ങൾ അറിയാൻ ബ്രൗസർ റിലീസ് നോട്ടുകൾ ശ്രദ്ധിക്കുന്നത് അത്യാവശ്യമാണ്.

ചുരുക്കം: SharedArrayBuffer ലഭ്യമാക്കുന്നതിനായി cross-origin isolation പ്രവർത്തനക്ഷമമാക്കുന്നത് ഒരു കഠിനമായ തിരഞ്ഞെടുപ്പിന് നിർബന്ധിതമാക്കുന്നു – തേർഡ് പാർട്ടി സ്ക്രിപ്റ്റുകളുടെ സൗകര്യം നിലനിർത്തണോ അതോ കൂടുതൽ കർശനവും സ്വയം നിയന്ത്രിതവുമായ ഒരു പ്രൈവസി മോഡലിന് വേണ്ടി അത് ഉപേക്ഷിക്കണോ എന്നത്. ഈ തീരുമാനം ആധുനിക വെബ്സൈറ്റുകളുടെ സാങ്കേതിക ഘടനയെയും ഡാറ്റാ-ഫ്ലോ ഫൂട്ട്പ്രിന്റിനെയും പുനർനിർമ്മിക്കുന്നു.