SharedArrayBuffer akhirnya berfungsi semula dalam pelayar, tetapi ia hanya berfungsi apabila halaman diasingkan secara rentas-asal (cross-origin isolated) – satu keadaan yang memerlukan dua pengepala respons. Menambah pengepala tersebut memaksa saya membuang setiap skrip pihak ketiga pada laman saya, satu langkah yang membentuk semula cara keseluruhan bahagian hadapan (front end) dibina dan data yang dibocorkannya.

Mengapa pengepala tersebut penting

SharedArrayBuffer membolehkan multithreading yang sebenar dalam JavaScript, satu prasyarat untuk menjalankan ffmpeg di dalam tab. Pelayar moden telah mengaktifkan semula ciri ini selepas mitigasi gaya Spectre, tetapi mereka mengikatnya kepada pengasingan rentas-asal (cross-origin isolation). Untuk mencapai pengasingan tersebut, pelayan mesti menghantar:

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

Pengepala kedua, require-corp, memberitahu pelayar bahawa sebarang sumber luaran mesti membawa pengepala Cross-Origin-Resource-Policy atau diambil menggunakan CORS (Cross-Origin Resource Sharing). Kebanyakan perkhidmatan pihak ketiga tidak menetapkan pengepala tersebut, jadi skrip, fon, dan iframe mereka disekat sepenuhnya.

Apa yang hilang apabila pengasingan diaktifkan

Sebaik sahaja pengepala tersebut dilaksanakan, rantaian kegagalan mula muncul:

  • Analytics – kebanyakan penyedia memuatkan kod penjejakan mereka dengan <script> ringkas yang membuat permintaan tanpa CORS. Tanpa pengepala CORP, permintaan tersebut ditolak, jadi penjejak tidak akan berjalan.
  • Google Fonts – helaian gaya (stylesheet) diambil dari fonts.googleapis.com tanpa CORS. Pelayar membuangnya, menyebabkan halaman kehilangan tipografi tersuai.
  • Embedded media – iframe YouTube dan skrip widget kekurangan CORP, jadi ia berhenti dipaparkan.
  • OAuth pop-ups – hubungan window.opener terputus disebabkan polisi same-origin yang ketat, sekali gus merosakkan aliran log masuk berasaskan pop-up yang biasa.

Ringkasnya, sebarang aset yang bergantung pada domain pihak ketiga akan hilang melainkan domain tersebut memilih untuk menyertai rejim pengepala baharu ini.

Membina semula tanpa orang tengah

Berhadapan dengan laman yang rosak, saya menulis semula timbunan (stack) bahagian hadapan berdasarkan aset yang dihoskan sendiri:

  • Fon dan imej kini disajikan dari origin saya sendiri, menghapuskan keperluan untuk helaian gaya luaran.
  • API Data dibina pada bahagian belakang (backend) peribadi yang saya kawal, supaya setiap permintaan kekal di dalam domain saya.
  • Analytics bertukar menjadi Cloudflare Worker kecil yang menerima acara POST dan menyimpannya dalam bucket peribadi. Bahagian klien hanyalah baris kod fetch yang ringkas.
  • Alatan pelaporan ralat dan rakaman sesi seperti Sentry dibuang sepenuhnya; sebarang kegagalan kini direkodkan ke endpoint saya sendiri.

Jika sumber luaran masih diperlukan, satu-satunya jalan yang berkesan adalah dengan melaluinya (proxy) melalui pelayan yang anda miliki, dengan menambah pengepala CORP yang diperlukan sebelum ia dilihat oleh pelayar.

Keuntungan privasi berbanding kos operasi

Manfaat serta-merta adalah jelas: laman tersebut tidak lagi membocorkan data penggunaan kepada rangkaian iklan, penyedia fon, atau platform video. Semua telemetri kekal di bawah kawalan saya, dan saya boleh memadamkannya pada bila-bila masa saya mahu. Tahap privasi sedemikian sukar dicapai dengan timbunan pihak ketiga yang tipikal.

Pertukaran (trade-off) yang berlaku adalah beban penyelenggaraan tambahan. Menghoskan fon, mengendalikan penyimpanan analitik, dan memastikan proksi sentiasa dikemas kini adalah tugas yang biasanya diserahkan oleh kebanyakan pembangun kepada perkhidmatan khusus. Pendekatan ini juga bermakna kehilangan ciri-ciri yang disediakan oleh perkhidmatan tersebut – contohnya, agregasi ralat masa nyata atau visualisasi corong (funnel) yang terperinci.

Hujah balas: adakah ekosistem akan menyesuaikan diri?

Sesetengah pihak berpendapat bahawa vendor pihak ketiga akhirnya akan menambah pengepala yang diperlukan, menjadikan pengasingan rentas-asal mudah untuk diterima. Beberapa daripadanya sudah melakukannya, tetapi majoriti perkhidmatan yang digunakan secara meluas masih belum. Sehingga ekosistem mengejar, pembangun mesti memutuskan sama ada kelebihan privasi mengatasi usaha kejuruteraan yang diperlukan untuk menghoskan sendiri.

Cara mengesahkan anda benar-benar diasingkan

Sebelum anda mula menulis semula, sahkan bahawa pelayar melihat halaman anda sebagai terasing:

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

Jika mana-mana semakan gagal, pengepala tersebut tidak dilaksanakan dengan betul, dan SharedArrayBuffer akan kekal tidak tersedia.

Apa seterusnya untuk pembangun?

Memandangkan lebih banyak aplikasi web mencari peningkatan prestasi daripada JavaScript berbilang thread, tekanan terhadap penyedia pihak ketiga untuk menerima CORP akan meningkat. Sementara itu, sebarang projek yang memerlukan SharedArrayBuffer harus merancang strategi aset yang dihoskan sendiri atau lapisan proksi yang ringan. Memantau nota keluaran pelayar untuk perubahan pada keperluan pengasingan juga akan menjadi sangat penting.

Rumusan: Mengaktifkan pengasingan rentas-asal untuk membolehkan SharedArrayBuffer menuntut satu pilihan yang sukar – mengekalkan kemudahan skrip pihak ketiga atau mengorbankannya demi model privasi yang lebih ketat dan terkawal sendiri. Keputusan ini membentuk semula seni bina teknikal dan jejak aliran data laman web moden.