SharedArrayBuffer చివరకు బ్రౌజర్‌లో మళ్ళీ పనిచేస్తోంది, కానీ అది పేజీ cross-origin isolated అయినప్పుడు మాత్రమే పనిచేస్తుంది – ఈ స్థితిని సాధించడానికి రెండు response headers అవసరం. ఆ హెడర్లను జోడించడం వల్ల నా సైట్‌లోని ప్రతి third-party స్క్రిప్ట్‌ను తొలగించాల్సి వచ్చింది, ఇది నా ఫ్రంట్ ఎండ్ నిర్మాణాన్ని మరియు డేటా లీకేజీని పూర్తిగా మార్చివేసింది.

హెడర్లు ఎందుకు ముఖ్యమో ఇక్కడ ఉంది

SharedArrayBuffer జావాస్క్రిప్ట్‌లో నిజమైన multithreadingని సాధ్యం చేస్తుంది, ఇది ఒక ట్యాబ్ లోపల ffmpegని రన్ చేయడానికి ఒక ముందస్తు అవసరం. Spectre-style 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) ద్వారా పొందాలని బ్రౌజర్‌కు చెబుతుంది. చాలా third-party సర్వీసులు ఈ హెడర్లను సెట్ చేయవు, కాబట్టి వాటి స్క్రిప్ట్‌లు, ఫాంట్లు మరియు iframes నేరుగా బ్లాక్ చేయబడతాయి.

ఐసోలేషన్ ఆన్ చేసినప్పుడు ఏవి నిలిచిపోయాయి

హెడర్లు అమలులోకి రాగానే, వరుసగా అనేక వైఫల్యాలు కనిపించాయి:

  • Analytics – చాలా ప్రొవైడర్లు తమ ట్రాకింగ్ కోడ్‌ను సాధారణ <script> ద్వారా లోడ్ చేస్తారు, ఇది no-CORS రిక్వెస్ట్‌ను చేస్తుంది. CORP హెడర్ లేకపోతే ఆ రిక్వెస్ట్ తిరస్కరించబడుతుంది, తద్వారా ట్రాకర్ ఎప్పటికీ రన్ అవ్వదు.
  • Google Fonts – స్టైల్‌షీట్ fonts.googleapis.com నుండి CORS లేకుండా పొందబడుతుంది. బ్రౌజర్ దానిని పక్కన పెడుతుంది, దీనివల్ల పేజీ దాని కస్టమ్ టైపోగ్రఫీని కోల్పోతుంది.
  • Embedded media – YouTube iframes మరియు విడ్జెట్ స్క్రిప్ట్‌లకు CORP ఉండదు, కాబట్టి అవి రెండర్ అవ్వవు.
  • OAuth pop-ups – కఠినమైన same-origin పాలసీ వల్ల window.opener సంబంధం తెగిపోతుంది, దీనివల్ల సాధారణ పాపప్ ఆధారిత లాగిన్ ఫ్లో దెబ్బతింటుంది.

క్లుప్తంగా చెప్పాలంటే, ఆ డొమైన్ కొత్త హెడర్ విధానాన్ని స్వీకరించనంత వరకు, third-party డొమైన్‌పై ఆధారపడిన ఏ అసెట్ అయినా కనిపించకుండా పోయింది.

మధ్యవర్తులు లేకుండా మళ్ళీ నిర్మించడం

సైట్ పనిచేయకపోవడంతో, నేను సెల్ఫ్-హోస్టెడ్ అసెట్‌ల చుట్టూ ఫ్రంట్-ఎండ్ స్టాక్‌ను మళ్ళీ రాశాను:

  • Fonts and images ఇప్పుడు నా స్వంత ఒరిజిన్ నుండి సర్వ్ చేయబడతాయి, దీనివల్ల బాహ్య స్టైల్‌షీట్‌ల అవసరం ఉండదు.
  • Data APIs నేను నియంత్రించే ప్రైవేట్ బ్యాకెండ్‌పై నిర్మించబడ్డాయి, కాబట్టి ప్రతి రిక్వెస్ట్ నా డొమైన్ లోపలే ఉంటుంది.
  • Analytics అనేది POST ఈవెంట్‌లను స్వీకరించి, వాటిని ప్రైవేట్ బకెట్‌లో నిల్వ చేసే ఒక చిన్న Cloudflare Worker గా మారింది. క్లయింట్ సైడ్ కేవలం డజన్ కొద్దీ fetch కోడ్ లైన్ల మాత్రమే ఉంటుంది.
  • Error reporting and session replay టూల్స్ అయిన Sentry వంటి వాటిని పూర్తిగా తొలగించాను; ఇప్పుడు ఏదైనా క్రాష్ జరిగితే నా స్వంత ఎండ్‌పాయింట్‌కు లాగ్ చేయబడుతుంది.

ఒకవేళ బాహ్య వనరు అవసరమైతే, దాన్ని మీరు స్వంతం చేసుకున్న సర్వర్ ద్వారా ప్రాక్సీ చేయడం మాత్రమే ఏకైక మార్గం, బ్రౌజర్ చూడకముందే దానికి అవసరమైన CORP హెడర్‌ను జోడించాలి.

గోప్యత ప్రయోజనాలు వర్సెస్ నిర్వహణ ఖర్చు

తక్షణ ప్రయోజనం స్పష్టంగా ఉంది: సైట్ ఇకపై అడ్వర్టైజింగ్ నెట్‌వర్క్‌లకు, ఫాంట్ ప్రొవైడర్‌లకు లేదా వీడియో ప్లాట్‌ఫారమ్‌లకు వినియోగ డేటాను లీక్ చేయదు. మొత్తం టెలిమెట్రీ నా నియంత్రణలో ఉంటుంది మరియు నేను కోరుకున్నప్పుడు దానిని తొలగించగలను. సాధారణ third-party స్టాక్‌తో ఆ స్థాయి గోప్యతను సాధించడం కష్టం.

దీనికి ప్రతిఫలంగా అదనపు నిర్వహణ భారం పెరుగుతుంది. ఫాంట్‌లను హోస్ట్ చేయడం, అనలిటిక్స్ స్టోరేజ్‌ని నిర్వహించడం మరియు ప్రాక్సీని అప్‌డేట్‌గా ఉంచడం వంటి పనులను చాలా మంది డెవలపర్లు ప్రత్యేక సేవల ద్వారా outsource చేస్తారు. ఈ విధానం వల్ల ఆ సర్వీసులు అందించే ఫీచర్లు కూడా కోల్పోవాల్సి వస్తుంది – ఉదాహరణకు, రియల్-టైమ్ ఎర్రర్ అగ్రిగేషన్ లేదా వివరణాత్మక ఫన్నెల్ విజువలైజేషన్లు.

ప్రతివాదం: ఈ ఎకోసిస్టమ్ మారుతుందా?

third-party వెండర్లు చివరికి అవసరమైన హెడర్లను జోడిస్తారని, తద్వారా cross-origin isolationని సులభంగా స్వీకరించవచ్చని కొందరు వాదిస్తారు. కొందరు ఇప్పటికే చేస్తున్నప్పటికీ, విస్తృతంగా ఉపయోగించే మెజారిటీ సర్వీసులు ఇంకా చేయలేదు. ఎకోసిస్టమ్ దీనికి అనుగుణంగా మారే వరకు, సెల్ఫ్-హోస్ట్ చేయడానికి అవసరమైన ఇంజనీరింగ్ ప్రయత్నం కంటే గోప్యత వల్ల కలిగే ప్రయోజనం ఎక్కువగా ఉంటుందా లేదా అనేది డెవలపర్లు నిర్ణయించుకోవాలి.

మీరు నిజంగా ఐసోలేట్ అయ్యారో లేదో ఎలా ధృవీకరించాలి

మీరు మళ్ళీ రాయడం ప్రారంభించే ముందు, బ్రౌజర్ మీ పేజీని ఐసోలేటెడ్‌గా చూస్తుందో లేదో నిర్ధారించుకోండి:

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

ఏదైనా చెక్ విఫలమైతే, హెడర్లు సరిగ్గా వర్తించబడటం లేదు, మరియు SharedArrayBuffer అందుబాటులో ఉండదు.

డెవలపర్ల కోసం తదుపరి ఏమిటి?

మరిన్ని వెబ్-యాప్‌లు మల్టీథ్రెడెడ్ జావాస్క్రిప్ట్ యొక్క పనితీరును కోరుకుంటున్న కొద్దీ, CORPని స్వీకరించడానికి third-party ప్రొవైడర్లపై ఒత్తిడి పెరుగుతుంది. ప్రస్తుతానికి, SharedArrayBuffer అవసరమైన ఏ ప్రాజెక్ట్ అయినా సెల్ఫ్-హోస్టెడ్ అసెట్ వ్యూహాన్ని లేదా తేలికపాటి ప్రాక్సీ లేయర్‌ను ప్లాన్ చేసుకోవాలి. ఐసోలేషన్ అవసరాలలో మార్పుల కోసం బ్రౌజర్ రిలీజ్ నోట్స్‌ను గమనిస్తూ ఉండటం కూడా చాలా అవసరం.

ముఖ్య సారాంశం: SharedArrayBufferని అన్‌లాక్ చేయడానికి cross-origin isolationని ఎనేబుల్ చేయడం వల్ల ఒక కఠినమైన ఎంపిక ఎదురవుతుంది – థర్డ్-పార్టీ స్క్రిప్ట్‌ల సౌలభ్యాన్ని కొనసాగించాలా లేదా మరింత కఠినమైన, స్వయం-నియంత్రిత గోప్యతా నమూనా కోసం దానిని వదులుకోవాలా అనేది. ఈ నిర్ణయం ఆధునిక వెబ్‌సైట్‌ల సాంకేతిక నిర్మాణం (technical architecture) మరియు డేటా-ఫ్లో ఫుట్‌ప్రింట్‌ను (data-flow footprint) మారుస్తుంది.