SharedArrayBuffer બ્રાઉઝરમાં ફરીથી કામ કરવા લાગ્યું છે, પરંતુ તે ત્યારે જ કામ કરે છે જ્યારે પેજ cross-origin isolated હોય – એક એવી સ્થિતિ જે માટે બે response headers જરૂરી છે. આ headers ઉમેરવાને કારણે મારે મારી સાઇટ પરથી દરેક third-party script હટાવવી પડી, જેના કારણે આખું front end કેવી રીતે બનાવવું અને તે કયો ડેટા લીક કરે છે તેમાં મોટો ફેરફાર આવ્યો.

આ headers શા માટે મહત્વના છે

SharedArrayBuffer JavaScript માં સાચું multithreading સક્ષમ કરે છે, જે ટેબની અંદર ffmpeg ચલાવવા માટે એક પૂર્વશરત છે. Spectre-style mitigations પછી આધુનિક બ્રાઉઝરોએ આ ફીચર ફરીથી સક્રિય કર્યું છે, પરંતુ તેઓ તેને cross-origin isolation સાથે જોડી દીધું છે. તે isolation મેળવવા માટે સર્વરે આ મોકલવું આવશ્યક છે:

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

બીજું header, require-corp, બ્રાઉઝરને જણાવે છે કે કોઈપણ બાહ્ય રિસોર્સ (external resource) કાં તો Cross-Origin-Resource-Policy header ધરાવતું હોવું જોઈએ અથવા CORS (Cross-Origin Resource Sharing) સાથે ફેચ (fetch) કરવામાં આવ્યું હોવું જોઈએ. મોટાભાગની third-party સેવાઓ આ headers સેટ કરતી નથી, તેથી તેમના scripts, fonts અને iframes સીધા જ બ્લોક થઈ જાય છે.

જ્યારે isolation ચાલુ કરવામાં આવ્યું ત્યારે શું નુકસાન થયું

જે ક્ષણે headers અમલમાં આવ્યા, તરત જ અનેક સમસ્યાઓ દેખાવા લાગી:

  • Analytics – મોટાભાગના પ્રદાતાઓ તેમનો tracking code એક સાદા <script> દ્વારા લોડ કરે છે જે no-CORS request કરે છે. CORP header વગર આ request રિજેક્ટ થઈ જાય છે, તેથી tracker ક્યારેય રન થતું નથી.
  • Google Fonts – stylesheet fonts.googleapis.com પરથી CORS વગર ફેચ કરવામાં આવે છે. બ્રાઉઝર તેને નકારી દે છે, જેના કારણે પેજ તેની કસ્ટમ ટાઇપોગ્રાફી વગર રહી જાય છે.
  • Embedded media – YouTube iframes અને widget scripts માં CORP હોતું નથી, તેથી તેઓ રેન્ડર થતા નથી.
  • OAuth pop-ups – સખત same-origin policy ને કારણે window.opener સંબંધ તૂટી જાય છે, જેનાથી સામાન્ય popup-આધારિત લોગિન ફ્લો બગડી જાય છે.

ટૂંકમાં, કોઈપણ એસેટ (asset) જે third-party domain પર આધારિત હતું તે અદૃશ્ય થઈ ગયું, સિવાય કે તે domain એ નવા header નિયમોનો સ્વીકાર કર્યો હોય.

વચેટિયાઓ વગર ફરીથી નિર્માણ કરવું

સાઇટ બગડી જવાથી, મેં self-hosted assets ની આસપાસ front-end stack ફરીથી લખ્યું:

  • Fonts and images હવે મારા પોતાના origin પરથી સર્વ કરવામાં આવે છે, જેનાથી બાહ્ય stylesheets ની જરૂરિયાત દૂર થઈ ગઈ છે.
  • Data APIs એક ખાનગી (private) backend પર બનાવવામાં આવ્યા છે જેનું નિયંત્રણ મારી પાસે છે, જેથી દરેક request મારા domain ની અંદર જ રહે છે.
  • Analytics એક નાના Cloudflare Worker માં ફેરવાઈ ગયા જે POST events સ્વીકારે છે અને તેને એક private bucket માં સ્ટોર કરે છે. Client side માં માત્ર fetch code ની થોડી લાઈનો જ છે.
  • Error reporting and session replay જેવા સાધનો જેમ કે Sentry ને સંપૂર્ણપણે હટાવી દેવામાં આવ્યા; હવે કોઈપણ crash મારા પોતાના endpoint પર લોગ થાય છે.

જો કોઈ બાહ્ય રિસોર્સની હજુ પણ જરૂર હોય, તો એકમાત્ર વ્યવહારુ રસ્તો તેને તમારા પોતાના સર્વર દ્વારા proxy કરવાનો છે, જેથી બ્રાઉઝર તેને જોતા પહેલા જરૂરી CORP header ઉમેરી શકાય.

પ્રાઇવસીના ફાયદા વિરુદ્ધ ઓપરેશનલ ખર્ચ

તાત્કાલિક ફાયદો સ્પષ્ટ છે: સાઇટ હવે એડ નેટવર્ક્સ, ફોન્ટ પ્રદાતાઓ અથવા વિડિયો પ્લેટફોર્મ્સને વપરાશનો ડેટા (usage data) લીક કરતી નથી. તમામ ટેલિમેટ્રી (telemetry) મારા નિયંત્રણ હેઠળ રહે છે, અને હું ઈચ્છું ત્યારે તેને ડિલીટ કરી શકું છું. સામાન્ય third-party stack સાથે આ સ્તરની પ્રાઇવસી મેળવવી મુશ્કેલ છે.

તેનો બદલો વધારાના મેન્ટેનન્સના બોજ તરીકે મળે છે. Fonts હોસ્ટ કરવા, analytics સ્ટોરેજ સંભાળવું અને proxy ને અપ-ટુ-ડેટ રાખવા એ એવા કાર્યો છે જે મોટાભાગના ડેવલપર્સ સ્પેશિયલાઇઝ્ડ સેવાઓને આઉટસોર્સ કરે છે. આ અભિગમનો અર્થ એ પણ છે કે તે સેવાઓ જે સુવિધાઓ આપે છે તે ગુમાવવી – ઉદાહરણ તરીકે, real-time error aggregation અથવા વિગતવાર funnel visualisations.

વિરોધ પક્ષ: શું ઇકોસિસ્ટમ અનુકૂલન સાધશે?

કેટલાક દલીલ કરે છે કે third-party વેન્ડર્સ આખરે જરૂરી headers ઉમેરશે, જેનાથી cross-origin isolation અપનાવવું સરળ બનશે. કેટલાક તો પહેલેથી જ કરી રહ્યા છે, પરંતુ મોટાભાગની વ્યાપક રીતે વપરાતી સેવાઓ હજુ પણ આવું કરતી નથી. જ્યાં સુધી ઇકોસિસ્ટમ આ સ્તર સુધી ન પહોંચે ત્યાં સુધી, ડેવલપર્સ એ નક્કી કરવું પડશે કે પ્રાઇવસીનો ફાયદો self-host કરવા માટે જરૂરી એન્જિનિયરિંગ પ્રયત્નો કરતા વધારે છે કે નહીં.

તમે ખરેખર isolated છો તેની ચકાસણી કેવી રીતે કરવી

તમે ફરીથી લખવાનું શરૂ કરો તે પહેલાં, ખાતરી કરો કે બ્રાઉઝર તમારા પેજને isolated તરીકે જુએ છે:

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

જો બંનેમાંથી કોઈ પણ ચેક નિષ્ફળ જાય, તો headers યોગ્ય રીતે લાગુ કરવામાં આવ્યા નથી, અને SharedArrayBuffer ઉપલબ્ધ રહેશે નહીં.

ડેવલપર્સ માટે આગળ શું છે?

જેમ જેમ વધુ વેબ-એપ્સ multithreaded JavaScript ના પર્ફોર્મન્સ બૂસ્ટની શોધમાં છે, તેમ તેમ CORP અપનાવવા માટે third-party પ્રદાતાઓ પરનું દબાણ વધશે. તે દરમિયાન, જે કોઈપણ પ્રોજેક્ટને SharedArrayBuffer ની જરૂર હોય તેમણે self-hosted asset strategy અથવા લાઇટવેઇટ proxy layer માટે આયોજન કરવું જોઈએ. isolation જરૂરિયાતોમાં ફેરફાર માટે બ્રાઉઝર રિલીઝ નોટ્સ પર નજર રાખવી પણ આવશ્યક રહેશે.

મુખ્ય તારણ: SharedArrayBuffer ને અનલોક કરવા માટે cross-origin isolation સક્ષમ કરવાથી એક કઠિન પસંદગી કરવાની ફરજ પડે છે – કાં તો થર્ડ-પાર્ટી સ્ક્રિપ્ટ્સની સુવિધા જાળવી રાખવી અથવા તેને વધુ સખત અને સ્વ-નિયંત્રિત પ્રાઈવસી મોડલ સાથે બદલી નાખવી. આ નિર્ણય આધુનિક વેબસાઇટ્સના ટેકનિકલ આર્કિટેક્ચર અને ડેટા-ફ્લો ફૂટપ્રિન્ટ બંનેને નવો આકાર આપે છે.