SharedArrayBuffer akhirnya berfungsi kembali di browser, tetapi hanya jika halaman tersebut terisolasi secara cross-origin – sebuah status yang memerlukan dua header respons. Menambahkan header tersebut memaksa saya untuk menghapus setiap skrip pihak ketiga di situs saya, sebuah langkah yang mengubah cara seluruh front end dibangun dan data apa saja yang bocor.

Mengapa header tersebut penting

SharedArrayBuffer memungkinkan multithreading sejati dalam JavaScript, sebuah prasyarat untuk menjalankan ffmpeg di dalam tab. Browser modern mengaktifkan kembali fitur ini setelah mitigasi gaya Spectre, tetapi mereka mengaitkannya dengan cross-origin isolation. Untuk mencapai isolasi tersebut, server harus mengirimkan:

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

Header kedua, require-corp, memberi tahu browser bahwa setiap sumber daya eksternal harus menyertakan header Cross-Origin-Resource-Policy atau diambil menggunakan CORS (Cross-Origin Resource Sharing). Sebagian besar layanan pihak ketiga tidak menyetel header tersebut, sehingga skrip, font, dan iframe mereka langsung diblokir.

Apa saja yang hilang saat isolasi diaktifkan

Saat header tersebut diterapkan, serangkaian kegagalan muncul:

  • Analitik – sebagian besar penyedia memuat kode pelacakan mereka dengan <script> sederhana yang melakukan permintaan no-CORS. Tanpa header CORP, permintaan tersebut ditolak, sehingga pelacak tidak pernah berjalan.
  • Google Fonts – stylesheet diambil dari fonts.googleapis.com tanpa CORS. Browser membuangnya, membuat halaman kehilangan tipografi kustomnya.
  • Media tertanam – iframe YouTube dan skrip widget tidak memiliki CORP, sehingga berhenti merender.
  • Pop-up OAuth – hubungan window.opener terputus oleh kebijakan same-origin yang ketat, merusak alur login berbasis popup yang biasa digunakan.

Singkatnya, aset apa pun yang mengandalkan domain pihak ketiga akan hilang kecuali domain tersebut mengadopsi rezim header baru.

Membangun kembali tanpa perantara

Menghadapi situs yang rusak, saya menulis ulang stack front-end dengan aset yang di-host sendiri (self-hosted):

  • Font dan gambar kini disajikan dari origin saya sendiri, menghilangkan kebutuhan akan stylesheet eksternal.
  • API Data dibangun di atas backend privat yang saya kendalikan, sehingga setiap permintaan tetap berada di dalam domain saya.
  • Analitik berubah menjadi Cloudflare Worker kecil yang menerima peristiwa POST dan menyimpannya di bucket privat. Sisi klien hanyalah belasan baris kode fetch.
  • Pelaporan error dan pemutaran ulang sesi seperti Sentry dihapus sepenuhnya; setiap crash kini dicatat ke endpoint saya sendiri.

Jika sumber daya eksternal masih diperlukan, satu-satunya jalan yang layak adalah mem-proxy-nya melalui server milik Anda sendiri, dengan menambahkan header CORP yang diperlukan sebelum dilihat oleh browser.

Keuntungan privasi versus biaya operasional

Manfaat langsungnya jelas: situs tidak lagi membocorkan data penggunaan ke jaringan iklan, penyedia font, atau platform video. Semua telemetri tetap di bawah kendali saya, dan saya dapat menghapusnya kapan pun saya mau. Tingkat privasi seperti itu sulit dicapai dengan stack pihak ketiga yang umum.

Pertukaran (trade-off) yang terjadi adalah beban pemeliharaan tambahan. Menghosting font, menangani penyimpanan analitik, dan menjaga proxy tetap mutakhir adalah tugas yang biasanya didelegasikan pengembang ke layanan khusus. Pendekatan ini juga berarti kehilangan fitur yang disediakan layanan tersebut – misalnya, agregasi error real-time atau visualisasi funnel yang mendetail.

Argumen sebaliknya: akankah ekosistem beradaptasi?

Beberapa orang berpendapat bahwa vendor pihak ketiga pada akhirnya akan menambahkan header yang diperlukan, membuat adopsi cross-origin isolation menjadi mudah. Beberapa sudah melakukannya, tetapi mayoritas layanan yang digunakan secara luas masih belum. Sampai ekosistem mengejar ketertinggalan, pengembang harus memutuskan apakah keuntungan privasi lebih besar daripada upaya teknik yang diperlukan untuk melakukan self-host.

Cara memverifikasi bahwa Anda benar-benar terisolasi

Sebelum Anda mulai menulis ulang, konfirmasikan bahwa browser melihat halaman Anda sebagai terisolasi:

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

Jika salah satu pemeriksaan gagal, header tidak diterapkan dengan benar, dan SharedArrayBuffer akan tetap tidak tersedia.

Apa langkah selanjutnya bagi pengembang?

Seiring semakin banyak aplikasi web mencari peningkatan performa dari JavaScript multithreaded, tekanan pada penyedia pihak ketiga untuk mengadopsi CORP akan meningkat. Sementara itu, proyek apa pun yang membutuhkan SharedArrayBuffer harus merencanakan strategi aset self-hosted atau lapisan proxy yang ringan. Memantau catatan rilis browser untuk perubahan pada persyaratan isolasi juga akan sangat penting.

Kesimpulan: Mengaktifkan isolasi lintas-asal (cross-origin isolation) untuk membuka akses SharedArrayBuffer memaksa sebuah pilihan sulit – mempertahankan kenyamanan skrip pihak ketiga atau menukarnya dengan model privasi yang lebih ketat dan terkendali secara mandiri. Keputusan ini membentuk kembali arsitektur teknis maupun jejak aliran data pada situs web modern.