SharedArrayBuffer ಅಂತಿಮವಾಗಿ ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಮತ್ತೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅದು ಪೇಜ್ cross-origin isolated ಆಗಿದ್ದಾಗ ಮಾತ್ರ ಸಾಧ್ಯ – ಈ ಸ್ಥಿತಿಗೆ ಎರಡು response headers ಅಗತ್ಯವಿರುತ್ತದೆ. ಆ ಹೆಡರ್‌ಗಳನ್ನು ಸೇರಿಸುವುದರಿಂದ ನನ್ನ ಸೈಟ್‌ನಲ್ಲಿನ ಪ್ರತಿಯೊಂದು third-party script ಅನ್ನು ಕೈಬಿಡಬೇಕಾಯಿತು, ಇದು ಇಡೀ front end ಹೇಗೆ ನಿರ್ಮಿಸಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಅದು ಯಾವ ಡೇಟಾವನ್ನು ಸೋರಿಕೆ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಮರುರೂಪಿಸಿತು.

ಹೆಡರ್‌ಗಳು ಏಕೆ ಮುಖ್ಯ

SharedArrayBuffer ಎಂಬುದು JavaScript ನಲ್ಲಿ ನಿಜವಾದ multithreading ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ, ಇದು ಒಂದು ಟ್ಯಾಬ್ ಒಳಗೆ ffmpeg ಅನ್ನು ರನ್ ಮಾಡಲು ಅಗತ್ಯವಾದ ಪೂರ್ವಭಾವಿ ಅಗತ್ಯವಾಗಿದೆ. Spectre-ಶೈಲಿಯ ತಡೆಗಟ್ಟುವಿಕೆಗಳ ನಂತರ ಆಧುನಿಕ ಬ್ರೌಸರ್‌ಗಳು ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಮತ್ತೆ ಸಕ್ರಿಯಗೊಳಿಸಿವೆ, ಆದರೆ ಅವು ಇದನ್ನು 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) ಮೂಲಕ ಪಡೆಯಲ್ಪಟ್ಟಿರಬೇಕು ಎಂದು ಬ್ರೌಸರ್‌ಗೆ ತಿಳಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ third-party ಸೇವೆಗಳು ಈ ಹೆಡರ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವುಗಳ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು, ಫಾಂಟ್‌ಗಳು ಮತ್ತು iframes ನೇರವಾಗಿ ಬ್ಲಾಕ್ ಆಗುತ್ತವೆ.

isolation ಅನ್ನು ಆನ್ ಮಾಡಿದಾಗ ಏನವು ಕೈತಪ್ಪಿತು

ಹೆಡರ್‌ಗಳು ಲೈವ್ ಆದ ಕ್ಷಣದಲ್ಲೇ, ವೈಫಲ್ಯಗಳ ಸರಮಾಲೆ ಕಾಣಿಸಿಕೊಂಡಿತು:

  • Analytics – ಹೆಚ್ಚಿನ ಪೂರೈಕೆದಾರರು ತಮ್ಮ ಟ್ರ್ಯಾಕಿಂಗ್ ಕೋಡ್ ಅನ್ನು ಸರಳ <script> ಮೂಲಕ ಲೋಡ್ ಮಾಡುತ್ತಾರೆ, ಇದು no-CORS ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತದೆ. CORP ಹೆಡರ್ ಇಲ್ಲದಿದ್ದರೆ ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಟ್ರ್ಯಾಕರ್ ಎಂದಿಗೂ ರನ್ ಆಗುವುದಿಲ್ಲ.
  • Google Fonts – ಸ್ಟೈಲ್‌ಶೀಟ್ ಅನ್ನು CORS ಇಲ್ಲದೆ fonts.googleapis.com ನಿಂದ ಪಡೆಯಲಾಗುತ್ತದೆ. ಬ್ರೌಸರ್ ಅದನ್ನು ಕೈಬಿಡುತ್ತದೆ, ಇದರಿಂದ ಪೇಜ್ ತನ್ನ ಕಸ್ಟಮ್ ಟೈಪೋಗ್ರಫಿಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.
  • Embedded media – YouTube iframes ಮತ್ತು ವಿಜೆಟ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಲ್ಲಿ CORP ಇರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವುים ರೆಂಡರ್ ಆಗುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ.
  • OAuth pop-ups – ಕಟ್ಟುನಿಟ್ಟಾದ same-origin ಪಾಲಿಸಿಯಿಂದಾಗಿ window.opener ಸಂಬಂಧವು ಮುರಿದುಹೋಗುತ್ತದೆ, ಇದು ಸಾಮಾನ್ಯ ಪಾಪ್-ಅಪ್ ಆಧಾರಿತ ಲಾಗಿನ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ.

ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ಆ ಡೊಮೇನ್ ಹೊಸ ಹೆಡರ್ ನಿಯಮಕ್ಕೆ ಒಪ್ಪಿಕೊಳ್ಳದ ಹೊರತು, ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಡೊಮೇನ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಯಾವುದೇ ಅಸೆಟ್ ಮಾಯವಾಗುತ್ತದೆ.

ಮಧ್ಯವರ್ತಿಗಳಿಲ್ಲದೆ ಮರುನಿರ್ಮಾಣ ಮಾಡುವುದು

ಹಾಳಾದ ಸೈಟ್ ಎದುರಾದಾಗ, ನಾನು ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿದ (self-hosted) ಅಸೆಟ್‌ಗಳ ಸುತ್ತ ಫ್ರಂಟ್-ಎಂಡ್ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಮರುಬರೆಯ್ದೆ:

  • Fonts ಮತ್ತು images ಈಗ ನನ್ನದೇ ಆದ origin ನಿಂದ ನೀಡಲ್ಪಡುತ್ತವೆ, ಇದರಿಂದ ಬಾಹ್ಯ ಸ್ಟೈಲ್‌ಶೀಟ್‌ಗಳ ಅಗತ್ಯವಿಲ್ಲದಂತಾಯಿತು.
  • Data APIs ಅನ್ನು ನಾನು ನಿಯಂತ್ರಿಸುವ ಖಾಸಗಿ ಬ್ಯಾಕೆಂಡ್ ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯು ನನ್ನ ಡೊಮೇನ್‌ನ ಒಳಗೇ ಇರುತ್ತದೆ.
  • Analytics ಅನ್ನು ಒಂದು ಸಣ್ಣ Cloudflare Worker ಆಗಿ ಬದಲಾಯಿಸಲಾಯಿತು, ಇದು POST ಇವೆಂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಖಾಸಗಿ ಬಕೆಟ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಸೈಡ್ ಕೇವಲ ಒಂದು ಡಜನ್ fetch ಕೋಡ್ ಸಾಲುಗಳನ್ನು ಹೊಂದಿದೆ.
  • Sentry ನಂತಹ Error reporting ಮತ್ತು session replay ಪರಿಕರಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕೈಬಿಡಲಾಯಿತು; ಯಾವುದೇ ಕ್ರ್ಯಾಶ್ ಈಗ ನನ್ನ ಸ್ವಂತ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಲಾಗ್ ಮಾಡಲಾಗುತ್ತದೆ.

ಒಂದು ವೇಳೆ ಬಾಹ್ಯ ಸಂಪನ್ಮೂಲದ ಅಗತ್ಯವಿದ್ದರೆ, ಏಕೈಕ ಕಾರ್ಯಸಾಧ್ಯವಾದ ಮಾರ್ಗವೆಂದರೆ ಅದನ್ನು ನೀವು ಹೊಂದಿರುವ ಸರ್ವರ್ ಮೂಲಕ ಪ್ರೊಕ್ಸಿ (proxy) ಮಾಡುವುದು ಮತ್ತು ಬ್ರೌಸರ್ ಅದನ್ನು ನೋಡುವ ಮೊದಲು ಅಗತ್ಯವಾದ CORP ಹೆಡರ್ ಅನ್ನು ಸೇರಿಸುವುದು.

ಗೌಪ್ಯತೆಯ ಲಾಭಗಳು ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚ

ತಕ್ಷಣದ ಪ್ರಯೋಜನ ಸ್ಪಷ್ಟವಾಗಿದೆ: ಸೈಟ್ ಈಗ ಜಾಹೀರಾತು ನೆಟ್‌ವರ್ಕ್‌ಗಳು, ಫಾಂಟ್ ಪೂರೈಕೆದಾರರು ಅಥವಾ ವಿಡಿಯೋ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗೆ ಬಳಕೆ ಡೇಟಾವನ್ನು ಸೋರಿಕೆ ಮಾಡುವುದಿಲ್ಲ. ಎಲ್ಲಾ ಟೆಲಿಮೆಟ್ರಿ (telemetry) ನನ್ನ ನಿಯಂತ್ರಣದಲ್ಲಿರುತ್ತದೆ ಮತ್ತು ನಾನು ಬಯಸಿದಾಗ ಅದನ್ನು ಅಳಿಸಬಹುದು. ಸಾಮಾನ್ಯ third-party ಸ್ಟ್ಯಾಕ್‌ನೊಂದಿಗೆ ಅಂತಹ ಮಟ್ಟದ ಗೌಪ್ಯತೆಯನ್ನು ಸಾಧಿಸುವುದು ಕಷ್ಟ.

ಇದರ ಬದಲಾಗಿ ಹೆಚ್ಚಿನ ನಿರ್ವಹಣಾ ಹೊರೆ (maintenance burden) ಇದೆ. ಫಾಂಟ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವುದು, ಅನಾಲಿಟಿಕ್ಸ್ ಸಂಗ್ರಹಣೆಯನ್ನು ನಿರ್ವಹಿಸುವುದು ಮತ್ತು ಪ್ರೊಕ್ಸಿಯನ್ನು ಅಪ್‌ಡೇಟ್ ಆಗಿ ಇಡುವುದು ಎಂಬ ಕಾರ್ಯಗಳನ್ನು ಹೆಚ್ಚಿನ ಡೆವಲಪರ್‌ಗಳು ವಿಶೇಷ ಸೇವೆಗಳಿಗೆ ಹೊರಗುತ್ತಿಂಗ್ ಮಾಡುತ್ತಾರೆ. ಈ ವಿಧಾನವು ಆ ಸೇವೆಗಳು ಒದಗಿಸುವ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದನ್ನೂ ಅರ್ಥೈಸುತ್ತದೆ - ಉದಾಹರಣೆಗೆ, ರಿಯಲ್-ಟೈಮ್ ಎರರ್ ಅಗ್ರಿಗೇಶನ್ ಅಥವಾ ವಿವರವಾದ ಫನಲ್ ವಿಶುವಲೈಸೇಶನ್‌ಗಳು.

ವಿರೋಧಾತ್ಮಕ ಅಂಶ: ಪರಿಸರ ವ್ಯವಸ್ಥೆಯು (ecosystem) ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆಯೇ?

ಕೆಲವರು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಮಾರಾಟಗಾರರು ಅಂತಿಮವಾಗಿ ಅಗತ್ಯವಿರುವ ಹೆಡರ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತಾರೆ ಮತ್ತು cross-origin isolation ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತಾರೆ ಎಂದು ವಾದಿಸುತ್ತಾರೆ. ಕೆಲವರು ಈಗಾಗಲೇ ಮಾಡುತ್ತಿದ್ದಾರೆ, ಆದರೆ ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುವ ಹೆಚ್ಚಿನ ಸೇವೆಗಳು ಇನ್ನೂ ಮಾಡಿಲ್ಲ. ಪರಿಸರ ವ್ಯವಸ್ಥೆಯು ಬೆಂಬಲ ನೀಡುವವರೆಗೆ, ಡೆವಲಪರ್‌ಗಳು ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಲು ಬೇಕಾದ ಎಂಜಿನಿಯರಿಂಗ್ ಪ್ರಯತ್ನಕ್ಕಿಂತ ಗೌಪ್ಯತೆಯ ಲಾಭವು ಹೆಚ್ಚಿದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬೇಕಾಗುತ್ತದೆ.

ನೀವು ನಿಜವಾಗಿಯೂ isolation ಆಗಿದ್ದೀರಾ ಎಂದು ಪರಿಶೀಲಿಸುವುದು ಹೇಗೆ

ನೀವು ಮರುಬರೆಯಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ಬ್ರೌಸರ್ ನಿಮ್ಮ ಪೇಜ್ ಅನ್ನು isolation ಆಗಿ ನೋಡುತ್ತಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ:

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

ಯಾವುದೇ ಒಂದು ಪರಿಶೀಲನೆ ವಿಫಲವಾದರೆ, ಹೆಡರ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಅನ್ವಯಿಸಲಾಗಿಲ್ಲ ಎಂದರ್ಥ ಮತ್ತು SharedArrayBuffer ಲಭ್ಯವಿರುವುದಿಲ್ಲ.

ಡೆವಲಪರ್‌ಗಳಿಗೆ ಮುಂದೆ ಏನು?

ಹೆಚ್ಚಿನ ವೆಬ್-ಆಪ್‌ಗಳು ಮಲ್ಟಿಥ್ರೆಡೆಡ್ JavaScript ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಬಯಸುತ್ತಿದ್ದಂತೆ, CORP ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಲು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಪೂರೈಕೆದಾರರ ಮೇಲಿನ ಒತ್ತಡ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಅಲ್ಲಿಯವರೆಗೆ, SharedArrayBuffer ಅಗತ್ಯವಿರುವ ಯಾವುದೇ ಪ್ರಾಜೆಕ್ಟ್ ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿದ ಅಸೆಟ್ ಸ್ಟ್ರಾಟಜಿ ಅಥವಾ ಲೈಟ್‌ವೇಯ್ಟ್ ಪ್ರೊಕ್ಸಿ ಲೇಯರ್ ಅನ್ನು ಯೋಜಿಸಬೇಕು. isolation ಅಗತ್ಯತೆಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳಿಗಾಗಿ ಬ್ರೌಸರ್ ರಿಲೀಸ್ ನೋಟ್ಸ್‌ಗಳನ್ನು ಗಮನಿಸುವುದು ಕೂಡ ಅತ್ಯಗತ್ಯ.

ಸಾರಾಂಶ: SharedArrayBuffer ಅನ್ನು ಅನ್ಲಾಕ್ ಮಾಡಲು cross-origin isolation ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಒಂದು ಕಠಿಣ ಆಯ್ಕೆಯನ್ನು ಎದುರಿಸುವಂತೆ ಮಾಡುತ್ತದೆ – ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಅನುಕೂಲತೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದು ಅಥವಾ ಅದನ್ನು ಹೆಚ್ಚು ಬಿಗಿಯಾದ, ಸ್ವಯಂ-ನಿಯಂತ್ರಿತ ಗೌಪ್ಯತಾ ಮಾದರಿಗಾಗಿ ಬದಲಾಯಿಸುವುದು. ಈ ನಿರ್ಧಾರವು ಆಧುನಿಕ ವೆಬ್‌ಸೈಟ್‌ಗಳ ತಾಂತ್ರಿಕ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಡೇಟಾ-ಫ್ಲೋ ಫುಟ್‌ಪ್ರಿಂಟ್ ಎರಡನ್ನೂ ಮರುರೂಪಿಸುತ್ತದೆ.