SharedArrayBuffer ਹੁਣ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਫਿਰ ਤੋਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਪਰ ਇਹ ਉਦੋਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਪੇਜ cross-origin isolated ਹੋਵੇ – ਇੱਕ ਅਜਿਹੀ ਸਥਿਤੀ ਜਿਸ ਲਈ ਦੋ response headers ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹਨਾਂ headers ਨੂੰ ਜੋੜਨ ਕਾਰਨ ਮੈਨੂੰ ਆਪਣੀ ਸਾਈਟ ਤੋਂ ਹਰ third-party ਸਕ੍ਰਿਪਟ ਹਟਾਉਣੀ ਪਈ, ਇੱਕ ਅਜਿਹਾ ਕਦਮ ਜਿਸ ਨੇ ਪੂਰੇ 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 ਸੈੱਟ ਨਹੀਂ ਕਰਦੀਆਂ, ਇਸ ਲਈ ਉਹਨਾਂ ਦੀਆਂ ਸਕ੍ਰਿਪਟਾਂ, ਫੌਂਟਸ ਅਤੇ iframes ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਬਲੌਕ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਜਦੋਂ isolation ਚਾਲੂ ਕੀਤਾ ਗਿਆ ਤਾਂ ਕੀ-ਕੀ ਖਤਮ ਹੋ ਗਿਆ

ਜਿਵੇਂ ਹੀ headers ਲਾਗੂ ਹੋਏ, ਕਈਆਂ ਅਸਫਲਤਾਵਾਂ ਸਾਹਮਣੇ ਆਈਆਂ:

  • Analytics – ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਵਾਈਡਰ ਆਪਣਾ tracking code ਇੱਕ ਸਧਾਰਨ <script> ਨਾਲ ਲੋਡ ਕਰਦੇ ਹਨ ਜੋ ਇੱਕ no-CORS ਰਿਕੁਐਸ ਕਰਦਾ ਹੈ। CORP header ਤੋਂ ਬਿਨਾਂ ਰਿਕੁਐਸ ਰੱਦ ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ tracker ਕਦੇ ਚੱਲਦਾ ਹੀ ਨਹੀਂ।
  • Google Fonts – stylesheet ਨੂੰ fonts.googleapis.com ਤੋਂ ਬਿਨਾਂ CORS ਦੇ ਫੈਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਇਸਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਪੇਜ ਆਪਣੀ ਕਸਟਮ ਟਾਈਪੋਗ੍ਰਾਫੀ ਤੋਂ ਬਿਨਾਂ ਰਹਿ ਜਾਂਦਾ ਹੈ।
  • Embedded media – YouTube iframes ਅਤੇ widget scripts ਵਿੱਚ CORP ਦੀ ਕਮੀ ਹੈ, ਇਸ ਲਈ ਉਹ ਰੈਂਡਰ ਹੋਣਾ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ।
  • OAuth pop-ups – ਸਖ਼ਤ same-origin policy ਦੁਆਰਾ window.opener ਰਿਸ਼ਤਾ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਆਮ popup-ਅਧਾਰਤ login flow ਵਿਗੜ ਜਾਂਦਾ ਹੈ।

ਸੰਖੇਪ ਵਿੱਚ, ਕੋਈ ਵੀ asset ਜੋ third-party domain 'ਤੇ ਨਿਰਭਰ ਸੀ, ਉਹ ਗਾਇਬ ਹੋ ਗਿਆ ਜਦੋਂ ਤੱਕ ਉਸ domain ਨੇ ਨਵੇਂ header ਨਿਯਮਾਂ ਨੂੰ ਨਹੀਂ ਅਪਣਾਇਆ।

ਵਿਚੋਲਿਆਂ ਤੋਂ ਬਿਨਾਂ ਮੁੜ ਨਿਰਮਾਣ ਕਰਨਾ

ਇੱਕ ਟੁੱਟੀ ਹੋਈ ਸਾਈਟ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹੋਏ, ਮੈਂ self-hosted assets ਦੇ ਆਲੇ-ਦੁਆਲੇ front-end stack ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ:

  • Fonts and images ਹੁਣ ਮੇਰੇ ਆਪਣੇ origin ਤੋਂ ਸਰਵ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਬਾਹਰੀ stylesheets ਦੀ ਲੋੜ ਖਤਮ ਹੋ ਗਈ ਹੈ।
  • Data APIs ਇੱਕ ਨਿੱਜੀ backend 'ਤੇ ਬਣਾਈਆਂ ਗਈਆਂ ਹਨ ਜਿਸ ਨੂੰ ਮੈਂ ਕੰਟਰੋਲ ਕਰਦਾ ਹਾਂ, ਤਾਂ ਜੋ ਹਰ ਰਿਕੁਐਸ ਮੇਰੇ domain ਦੇ ਅੰਦਰ ਹੀ ਰਹੇ।
  • Analytics ਇੱਕ ਛੋਟੇ Cloudflare Worker ਵਿੱਚ ਬਦਲ ਗਿਆ ਜੋ POST events ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਨਿੱਜੀ bucket ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ। Client side ਸਿਰਫ਼ fetch code ਦੀਆਂ ਦਰਜਨ ਲਾਈਨਾਂ ਹੈ।
  • Error reporting and session replay ਟੂਲ ਜਿਵੇਂ ਕਿ Sentry ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ; ਹੁਣ ਕੋਈ ਵੀ crash ਮੇਰੇ ਆਪਣੇ endpoint 'ਤੇ log ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਜੇਕਰ ਕਿਸੇ ਬਾਹਰੀ ਸਰੋਤ ਦੀ ਅਜੇ ਵੀ ਲੋੜ ਹੈ, ਤਾਂ ਇੱਕੋ ਇੱਕ ਵਿਹਾਰਕ ਰਸਤਾ ਇਸਨੂੰ ਆਪਣੇ ਸਰਵਰ ਰਾਹੀਂ proxy ਕਰਨਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜੀਂਦਾ CORP header ਜੋੜਿਆ ਜਾਵੇ।

Privacy ਦੇ ਫਾਇਦੇ ਬਨਾਮ ਕੰਮਕਾਜੀ ਲਾਗਤ (operational cost)

ਤੁਰੰਤ ਫਾਇਦਾ ਸਪੱਸ਼ਟ ਹੈ: ਸਾਈਟ ਹੁਣ ad networks, font providers, ਜਾਂ video platforms ਨੂੰ ਵਰਤੋਂ ਦਾ ਡੇਟਾ ਲੀਕ ਨਹੀਂ ਕਰਦੀ। ਸਾਰੀ telemetry ਮੇਰੇ ਕੰਟਰੋਲ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਮੈਂ ਜਦੋਂ ਚਾਹਵਾਂ ਇਸਨੂੰ ਡਿਲੀਟ ਕਰ ਸਕਦਾ ਹਾਂ। ਆਮ third-party stack ਨਾਲ ਇਸ ਪੱਧਰ ਦੀ privacy ਪ੍ਰਾਪਤ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ।

ਇਸਦਾ ਨੁਕਸਾਨ ਵਾਧੂ ਰੱਖ-ਰਖਾਅ (maintenance) ਦਾ ਬੋਝ ਹੈ। Fonts ਨੂੰ ਹੋਸਟ ਕਰਨਾ, analytics storage ਨੂੰ ਸੰਭਾਲਣਾ, ਅਤੇ ਇੱਕ proxy ਨੂੰ ਅਪ-ਟੂ-ਡੇਟ ਰੱਖਣਾ ਅਜਿਹੇ ਕੰਮ ਹਨ ਜੋ ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰ ਵਿਸ਼ੇਸ਼ ਸੇਵਾਵਾਂ ਨੂੰ ਆਊਟਸੋਰਸ ਕਰ ਦਿੰਦੇ ਹਨ। ਇਸ ਪਹੁੰਚ ਦਾ ਮਤਲਬ ਉਹਨਾਂ ਫੀਚਰਾਂ ਨੂੰ ਗੁਆਉਣਾ ਵੀ ਹੈ ਜੋ ਉਹ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ - ਉਦਾਹਰਨ ਲਈ, real-time error aggregation ਜਾਂ ਵਿਸਤ੍ਰਿਤ funnel visualisations।

ਵਿਰੋਧੀ ਵਿਚਾਰ: ਕੀ ecosystem ਅਨੁਕੂਲ ਹੋਵੇਗਾ?

ਕੁਝ ਲੋਕਾਂ ਦਾ ਤਰਕ ਹੈ ਕਿ third-party ਵੈਂਡਰ ਅੰਤ ਵਿੱਚ ਲੋੜੀਂਦੇ headers ਜੋੜ ਦੇਣਗੇ, ਜਿਸ ਨਾਲ cross-origin isolation ਨੂੰ ਅਪਣਾਉਣਾ ਆਸਾਨ ਹੋ ਜਾਵੇਗਾ। ਕੁਝ ਪਹਿਲਾਂ ਹੀ ਕਰ ਰਹੇ ਹਨ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਵੱਧ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਅਜੇ ਵੀ ਨਹੀਂ ਕਰਦੀਆਂ। ਜਦੋਂ ਤੱਕ ecosystem ਇਸ ਪੱਧਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਹੋਵੇਗਾ ਕਿ ਕੀ privacy ਦਾ ਫਾਇਦਾ self-host ਕਰਨ ਲਈ ਲੋੜੀਂਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਕੋਸ਼ਿਸ਼ ਨਾਲੋਂ ਵੱਧ ਹੈ।

ਇਹ ਕਿਵੇਂ ਪੁਸ਼ਟੀ ਕਰੀਏ ਕਿ ਤੁਸੀਂ ਸੱਚਮੁੱਚ isolated ਹੋ

ਦੁਬਾਰਾ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਤੁਹਾਡੇ ਪੇਜ ਨੂੰ isolated ਦੇ ਰੂਪ ਵਿੱਚ ਦੇਖ ਰਿਹਾ ਹੈ:

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

ਜੇਕਰ ਕੋਈ ਵੀ ਚੈੱਕ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ headers ਸਹੀ ਤਰ੍ਹਾਂ ਲਾਗੂ ਨਹੀਂ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ, ਅਤੇ SharedArrayBuffer ਉਪਲਬਧ ਨਹੀਂ ਰਹੇਗਾ।

ਡਿਵੈਲਪਰਾਂ ਲਈ ਅੱਗੇ ਕੀ ਹੈ?

ਜਿਵੇਂ-ਜਿਵੇਂ ਵਧੇਰੇ web-apps multithreaded JavaScript ਦੀ ਪ੍ਰਦਰਸ਼ਨ ਵਧਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ, CORP ਅਪਣਾਉਣ ਲਈ third-party ਪ੍ਰੋਵਾਈਡਰਾਂ 'ਤੇ ਦਬਾਅ ਵਧੇਗਾ। ਇਸ ਦੌਰਾਨ, ਕਿਸੇ ਵੀ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਜਿਸ ਨੂੰ SharedArrayBuffer ਦੀ ਲੋੜ ਹੈ, ਉਸ ਨੂੰ self-hosted asset strategy ਜਾਂ ਇੱਕ ਹਲਕੇ (lightweight) proxy layer ਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ। Isolation ਦੀਆਂ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲਾਅ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਰਿਲੀਜ਼ ਨੋਟਸ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣਾ ਵੀ ਜ਼ਰੂਰੀ ਹੋਵੇਗਾ।

ਮੁੱਖ ਨੁਕਤਾ: SharedArrayBuffer ਨੂੰ ਅਨਲੌਕ ਕਰਨ ਲਈ cross-origin isolation ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣਾ ਇੱਕ ਮੁਸ਼ਕਲ ਚੋਣ ਸਾਹਮਣੇ ਰੱਖਦਾ ਹੈ – ਜਾਂ ਤਾਂ third-party scripts ਦੀ ਸਹੂਲਤ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖੋ ਜਾਂ ਇਸ ਦੇ ਬਦਲੇ ਇੱਕ ਸਖ਼ਤ, ਸਵੈ-ਨਿਯੰਤਰਿਤ privacy model ਨੂੰ ਅਪਣਾਓ। ਇਹ ਫੈਸਲਾ ਆਧੁਨਿਕ ਵੈੱਬ ਸਾਈਟਾਂ ਦੇ ਤਕਨੀਕੀ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਡੇਟਾ-ਫਲੋ ਫੁੱਟਪ੍ਰਿੰਟ ਦੋਵਾਂ ਨੂੰ ਮੁੜ ਰੂਪ ਦਿੰਦਾ ਹੈ।