SharedArrayBuffer இப்போது உலாவிகளில் (browser) மீண்டும் வேலை செய்கிறது, ஆனால் ஒரு பக்கம் cross-origin isolated நிலையில் இருந்தால் மட்டுமே இது சாத்தியம் – இதற்கு இரண்டு response headers தேவைப்படுகின்றன. அந்தத் தலைப்புகளைச் சேர்த்ததால், எனது தளத்தில் இருந்த அனைத்து மூன்றாம் தரப்பு ஸ்கிரிப்ட்களையும் (third-party scripts) நீக்க வேண்டிய கட்டாயம் ஏற்பட்டது; இது எனது front end கட்டமைப்பையும், தரவு கசிவு (data leak) முறையையும் முற்றிலும் மாற்றியமைத்தது.

Why the headers matter

SharedArrayBuffer என்பது JavaScript-இல் உண்மையான multithreading-ஐ சாத்தியமாக்குகிறது, இது ஒரு tab-க்குள் ffmpeg-ஐ இயக்குவதற்கு அவசியமானது. Spectre-பாணி தணிப்பு நடவடிக்கைகளுக்குப் (Spectre-style mitigations) பிறகு நவீன உலாவிகள் இந்த அம்சத்தை மீண்டும் செயல்படுத்தின, ஆனால் அவற்றை cross-origin isolation உடன் இணைத்தன. அந்தத் தனிமைப்படுத்தலை (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) மூலம் பெறப்பட வேண்டும் என்று உலாவியிடம் கூறுகிறது. பெரும்பாலான மூன்றாம் தரப்பு சேவைகள் இந்தத் தலைப்புகளை அமைப்பதில்லை, எனவே அவற்றின் ஸ்கிரிப்ட்கள், எழுத்துருக்கள் (fonts) மற்றும் iframes ஆகியவை நேரடியாகத் தடுக்கப்படுகின்றன.

What fell away when isolation was turned on

Isolation செயல்பாட்டிற்கு வந்தவுடன், பல தோல்விகள் ஏற்பட்டன:

  • Analytics – பெரும்பாலான வழங்குநர்கள் தங்களது கண்காணிப்பு குறியீட்டை (tracking code) ஒரு எளிய <script> மூலம் ஏற்றுகிறார்கள், இது no-CORS கோரிக்கையைச் செய்கிறது. CORP தலைப்பு இல்லையென்றால், அந்தக் கோரிக்கை நிராகரிக்கப்படும், இதனால் tracker இயங்காது.
  • Google Fonts – stylesheet ஆனது fonts.googleapis.com-லிருந்து CORS இன்றி பெறப்படுகிறது. உலாவியானது அதைத் தவிர்த்துவிடுவதால், பக்கம் அதன் தனித்துவமான எழுத்துருக்களை (custom typography) இழக்கிறது.
  • Embedded media – YouTube iframes மற்றும் widget ஸ்கிரிப்ட்களில் CORP இல்லை, எனவே அவை திரையில் தெரிவதில்லை.
  • OAuth pop-ups – கடுமையான same-origin கொள்கையினால் window.opener தொடர்பு துண்டிக்கப்படுகிறது, இதனால் வழக்கமான popup-அடிப்படையிலான login செயல்முறை பாதிக்கப்படுகிறது.

சுருக்கமாகச் சொன்னால், அந்தத் தளம் புதிய header முறையை ஏற்றுக்கொண்டால் ஒழிய, மூன்றாம் தரப்பு டொமைனைச் சார்ந்திருந்த எந்தவொரு சொத்தும் காணாமல் போனது.

Rebuilding without the middlemen

தளத்தின் செயல்பாடுகள் முடங்கிய நிலையில், நான் self-hosted assets-களைச் சுற்றி front-end stack-ஐ மீண்டும் எழுதினேன்:

  • Fonts and images இப்போது எனது சொந்த origin-லிருந்து வழங்கப்படுகின்றன, இதனால் வெளிப்புற stylesheets-களின் தேவை நீங்கியது.
  • Data APIs நான் கட்டுப்படுத்தும் ஒரு தனிப்பட்ட backend-இல் கட்டமைக்கப்பட்டுள்ளன, எனவே ஒவ்வொரு கோரிக்கையும் எனது டொமைனுக்குள்ளேயே இருக்கும்.
  • Analytics என்பது POST நிகழ்வுகளை ஏற்றுக்கொண்டு அவற்றை ஒரு தனிப்பட்ட bucket-இல் சேமிக்கும் ஒரு சிறிய Cloudflare Worker ஆக மாற்றப்பட்டது. Client side-இல் வெறும் பன்னிரண்டு வரிகள் கொண்ட fetch code மட்டுமே உள்ளது.
  • Error reporting and session replay கருவிகளான Sentry போன்றவை முற்றிலும் நீக்கப்பட்டன; இப்போது எந்தவொரு crash-உம் எனது சொந்த endpoint-க்கு பதிவு செய்யப்படுகிறது.

ஒரு வெளிப்புற ஆதாரம் இன்னும் தேவைப்பட்டால், அதை நீங்கள் வைத்திருக்கும் ஒரு சர்வர் மூலம் proxy செய்வதே ஒரே வழி; உலாவியானது அதைப் பார்ப்பதற்கு முன்பே தேவையான CORP தலைப்பைச் சேர்க்க வேண்டும்.

Privacy gains versus operational cost

இதன் உடனடிப் பயன் தெளிவானது: தளம் இனி விளம்பர நெட்வொர்க்குகள், எழுத்துரு வழங்குநர்கள் அல்லது வீடியோ தளங்களுக்குப் பயன்பாட்டுத் தரவை (usage data) கசியவிடாது. அனைத்து telemetry-களும் எனது கட்டுப்பாட்டிலேயே இருக்கும், மேலும் நான் விரும்பும் போது அவற்றை நீக்க முடியும். வழக்கமான மூன்றாம் தரப்பு stack மூலம் இத்தகைய தனியுரிமையை (privacy) அடைவது கடினம்.

இதன் சவால் கூடுதல் பராமரிப்புச் சுமை (maintenance burden) ஆகும். எழுத்துருக்களை ஹோஸ்ட் செய்வது, analytics சேமிப்பைக் கையாளுவது மற்றும் ஒரு proxy-ஐப் புதுப்பித்த நிலையில் வைத்திருப்பது போன்றவை பெரும்பாலான டெவலப்பர்கள் சிறப்புச் சேவைகளுக்கு (specialized services) வழங்கும் பணிகளாகும். இந்த அணுகுமுறை அந்தச் சேவைகள் வழங்கும் அம்சங்களை இழப்பதையும் குறிக்கிறது – உதாரணமாக, நிகழ்நேர பிழைத் தொகுப்பு (real-time error aggregation) அல்லது விரிவான funnel visualisations.

Counter-point: will the ecosystem adapt?

மூன்றாம் தரப்பு விற்பனையாளர்கள் இறுதியில் தேவையான தலைப்புகளைச் சேர்த்துவிடுவார்கள், இதனால் cross-origin isolation-ஐப் பயன்படுத்துவது எளிதாகும் என்று சிலர் வாதிடுகின்றனர். ஒரு சிலர் ஏற்கனவே அவ்வாறு செய்கிறார்கள், ஆனால் பரவலாகப் பயன்படுத்தப்படும் பெரும்பாலான சேவைகள் இன்னும் அவ்வாறு செய்யவில்லை. இந்தச் சூழல் சீராகும் வரை, தனியுரிமை ஆதாரம் (privacy upside) self-host செய்வதற்குத் தேவைப்படும் பொறியியல் முயற்சியை விட மேலானதா என்பதை டெவலப்பர்கள் தீர்மானிக்க வேண்டும்.

How to verify you’re truly isolated

நீங்கள் மீண்டும் எழுதத் தொடங்குவதற்கு முன், உங்கள் பக்கம் isolation நிலையில் உள்ளதா என்பதை உலாவியில் உறுதிப்படுத்திக் கொள்ளுங்கள்:

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

ஏதேனும் ஒரு சரிபார்ப்பு தோல்வியடைந்தால், தலைப்புகள் சரியாகப் பயன்படுத்தப்படவில்லை என்று அர்த்தம், மேலும் SharedArrayBuffer கிடைக்காமல் போகும்.

What’s next for developers?

அதிகப்படியான web-apps, multithreaded JavaScript-இன் செயல்திறனைத் தேடும்போது, CORP-ஐ ஏற்றுக்கொள்வதற்கு மூன்றாம் தரப்பு வழங்குநர்கள் மீது அழுத்தம் அதிகரிக்கும். இதற்கிடையில், SharedArrayBuffer தேவைப்படும் எந்தவொரு திட்டமும் self-hosted asset strategy அல்லது ஒரு இலகுவான proxy layer-க்கான திட்டத்தைத் தீட்ட வேண்டும். Isolation தேவைகளில் ஏற்படும் மாற்றங்களுக்காக உலாவியின் release notes-களைக் கவனிப்பதும் அவசியமாகும்.

முக்கியக் கருத்து: SharedArrayBuffer-ஐப் பயன்படுத்துவதற்காக cross-origin isolation-ஐச் செயல்படுத்துவது ஒரு கடினமானத் தேர்வை ஏற்படுத்துகிறது – மூன்றாம் தரப்பு ஸ்கிரிப்ட்களின் வசதியைப் பராமரிப்பதா அல்லது அதைக் கைவிட்டு, மிகவும் பாதுகாப்பான மற்றும் சுயக்கட்டுப்பாட்டுடன் கூடிய தனியுரிமை மாதிரியைத் தேர்ந்தெடுப்பதா? இந்த முடிவு நவீன இணையதளங்களின் தொழில்நுட்பக் கட்டமைப்பு மற்றும் தரவுப் பரிமாற்றத் தடம் ஆகிய இரண்டையும் மறுசீரமைக்கிறது.