SharedArrayBuffer tarayıcıda nihayet tekrar çalışıyor, ancak yalnızca bir sayfa cross-origin isolated (çapraz köken izole edilmiş) olduğunda çalışıyor – bu durum iki yanıt başlığı gerektiren bir durumdur. Bu başlıkları eklemek, sitemdeki her üçüncü taraf betiği bırakmamı zorunlu kıldı; bu hamle, tüm ön yüzün nasıl inşa edildiğini ve hangi verilerin sızdırıldığını yeniden şekillendirdi.

Başlıklar neden önemli

SharedArrayBuffer, JavaScript'te gerçek çoklu iş parçacığı (multithreading) kullanımına olanak tanır; bu, ffmpeg'in bir sekme içinde çalıştırılması için bir ön koşuldur. Modern tarayıcılar, Spectre tarzı önlemlerden sonra bu özelliği yeniden etkinleştirdi ancak bunu cross-origin isolation (çapraz köken izolasyonu) ile ilişkilendirdi. Bu izolasyonu sağlamak için bir sunucunun şunları göndermesi gerekir:

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

İkinci başlık olan require-corp, tarayıcıya herhangi bir harici kaynağın ya bir Cross-Origin-Resource-Policy başlığı taşıması gerektiğini ya da CORS (Cross-Origin Resource Sharing) ile getirilmesi gerektiğini söyler. Çoğu üçüncü taraf hizmet bu başlıkları ayarlamaz, bu nedenle betikleri, yazı tipleri ve iframe'leri doğrudan engellenir.

İzolasyon açıldığında neler ortadan kalktı

Başlıklar yayına girdiği anda bir dizi hata ortaya çıktı:

  • Analizler (Analytics) – çoğu sağlayıcı, takip kodlarını no-CORS isteği yapan basit bir <script> ile yükler. Bir CORP başlığı olmadan istek reddedilir, bu nedenle takipçi asla çalışmaz.
  • Google Fonts – stil sayfası, fonts.googleapis.com adresinden CORS olmadan getirilir. Tarayıcı bunu atar ve sayfa özel tipografisinden mahrum kalır.
  • Gömülü medya – YouTube iframe'leri ve widget betikleri CORP'tan yoksundur, bu nedenle işlenmeyi durdururlar.
  • OAuth açılır pencereleri – window.opener ilişkisi katı same-origin politikası tarafından bozulur ve alışılagelmiş popup tabanlı giriş akışını engeller.

Kısacası, o alan adı yeni başlık rejimine geçmediği sürece, üçüncü taraf bir alana dayanan her türlü varlık ortadan kalktı.

Aracılar olmadan yeniden inşa etmek

Bozulan bir siteyle karşı karşıya kaldığımda, ön uç yığınını (stack) kendi sunucumda barındırılan (self-hosted) varlıklar etrafında yeniden yazdım:

  • Yazı tipleri ve görseller artık kendi kökenimden (origin) sunuluyor, bu da harici stil sayfalarına olan ihtiyacı ortadan kaldırıyor.
  • Veri API'leri, kontrol ettiğim özel bir arka uç (backend) üzerine inşa edildi, böylece her istek benim alanımın içinde kalıyor.
  • Analizler, POST etkinliklerini kabul eden ve bunları özel bir kovada (bucket) saklayan küçük bir Cloudflare Worker'a dönüştü. İstemci tarafı sadece bir düzine satırlık fetch kodundan ibaret.
  • Hata raporlama ve oturum yeniden oynatma (session replay) gibi Sentry araçları tamamen bırakıldı; artık herhangi bir çökme benim kendi uç noktama (endpoint) kaydediliyor.

Eğer harici bir kaynağa hala ihtiyaç duyuluyorsa, tek uygulanabilir yol, tarayıcı görmeden önce gerekli CORP başlığını ekleyerek bunu sahip olduğunuz bir sunucu üzerinden proxy'lemektir.

Gizlilik kazanımları ile operasyonel maliyet karşılaştırması

Anında fayda açıktır: Site artık kullanım verilerini reklam ağlarına, yazı tipi sağlayıcılarına veya video platformlarına sızdırmıyor. Tüm telemetri benim kontrolümde kalıyor ve istediğim zaman silebiliyorum. Bu düzeyde bir gizliliğe tipik bir üçüncü taraf yığını ile ulaşmak zordur.

Takas (trade-off) ise ekstra bakım yüküdür. Yazı tiplerini barındırmak, analiz depolamasını yönetmek ve bir proxy'yi güncel tutmak, çoğu geliştiricinin uzmanlaşmış hizmetlere devrettiği görevlerdir. Bu yaklaşım aynı zamanda bu hizmetlerin sunduğu özelliklerden mahrum kalmak anlamına da gelir; örneğin gerçek zamanlı hata toplama veya ayrıntılı huni (funnel) görselleştirmeleri.

Karşı görüş: Ekosistem uyum sağlayacak mı?

Bazıları, üçüncü taraf satıcıların sonunda gerekli başlıkları ekleyeceğini ve böylece cross-origin izolasyonunun benimsenmesini zahmetsiz hale getireceğini savunuyor. Birkaçı bunu zaten yapıyor ancak yaygın olarak kullanılan hizmetlerin çoğunluğu hala yapmıyor. Ekosistem yetişene kadar, geliştiriciler gizlilik avantajının, kendi sunucusunda barındırmak için gereken mühendislik çabasına değip değmeyeceğine karar vermelidir.

Gerçekten izole edildiğinizi nasıl doğrularsınız

Yeniden yazmaya başlamadan önce, tarayıcının sayfanızı izole edilmiş olarak gördüğünden emin olun:

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

Eğer kontrollerden herhangi biri başarısız olursa, başlıklar doğru şekilde uygulanmıyor demektir ve SharedArrayBuffer kullanılamaz kalacaktır.

Geliştiriciler için sırada ne var?

Daha fazla web uygulaması çok iş parçacıklı JavaScript'in performans artışını aradıkça, üçüncü taraf sağlayıcılar üzerindeki CORP'u benimseme baskısı artacaktır. Bu süre zarfında, SharedArrayBuffer'a ihtiyaç duyan her proje, kendi sunucusunda barındırılan bir varlık stratejisi veya hafif bir proxy katmanı planlamalıdır. İzolasyon gereksinimlerindeki değişiklikler için tarayıcı sürüm notlarını takip etmek de elzem olacaktır.

Özetle: SharedArrayBuffer'ın kilidini açmak için cross-origin izolasyonunu etkinleştirmek, zor bir seçim yapmaya zorlar: ya üçüncü taraf betiklerin sağladığı kolaylığı korumak ya da bunu daha sıkı, kendi kontrolünüzde olan bir gizlilik modeliyle takas etmek. Bu karar, hem modern web sitelerinin teknik mimarisini hem de veri akışı ayak izini yeniden şekillendirir.