Bir kurum bilgisayarında çalışan tarayıcı eklentisi, bir sekmeye hata ayıklama bağlantısı kurduğunda yalnız sayfanın adresini görmez. `chrome.debugger` adlı API, eklentiye Chrome Geliştirici Araçları Protokolü'ne doğrudan erişim verir. Bu erişimle ağ trafiği izlenebilir, kod çalıştırılabilir ve ekran görüntüsü alınabilir. Chrome 155, yönetilen tarayıcılarda bu gücü daha sert bir sınırın içine alıyor: Kurumun engelli ana makine, ekran görüntüsü veya veri kaybını önleme kuralı varsa bağlantı daha başta reddedilecek.
Değişiklik 6 Ekim'de kararlı sürüme gelecek. Kişisel profiller ile bu üç kuralın tanımlanmadığı yönetilen ortamlar etkilenmiyor. Ama etkilenen eklenti için eski ara yol kalmıyor. Bir alan adına izin verilmiş olması, hata ayıklama bağlantısını açmaya yetmeyecek; Chrome, `chrome.debugger.attach()` çağrısını tüm hedefler için reddedecek. Ekran görüntüsü engeli ya da veri kaybını önleme kuralı bulunduğunda da aynı çağrı başarısız olacak.
Bu ayrım ilk bakışta kaba görünebilir. Çünkü sıradan uzantı izinleri sayfa sayfa, alan adı alan adı verilebilir. Fakat Chrome'un gerekçesi teknik olarak yerinde: Hata ayıklama protokolü, web sayfasının normal köken sınırının altında çalışıyor. Bir eklenti ağ isteğini yakalayabiliyor veya sayfada kod çalıştırabiliyorsa, yalnız izinli alanlara baktığını güvenle kanıtlayan daha dar bir filtre yok. Kurumun veri sızıntısı kuralı böyle bir erişimi güvenilir biçimde yarım açık bırakamaz.
Kullanıcının kazanacağı şey, kurum bilgisayarındaki "izin verildi" ifadesinin gerçekte neyi kapsadığının daha anlaşılır olmasıdır. Bir uzantı işini yapamıyorsa, bunu boş bir yüklenme göstergesiyle gizlememeli. Chrome'un önerdiği hata metinleri, engelin ana makine kuralından mı yoksa ekran görüntüsü ve veri kaybı önleminden mi geldiğini ayırıyor. Eklenti de bu bilgiyi kullanıcıya taşımalı: erişimin kurum politikasıyla kesildiğini, kişisel hesabındaki bir ayarla çözülemeyeceğini ve destek ekibinin hangi politikayı incelemesi gerektiğini söylemeli.
Yük geliştiriciye geçiyor. `attach()` çağrısını hata yakalamadan kullanan eklenti, Chrome 155'te yönetilen cihazda sessizce yarım kalabilir. Ürün ekibi önce hangi işlevin gerçekten doğrudan hata ayıklama protokolüne ihtiyaç duyduğunu ayırmalı. Sayfaya betik eklemek için `chrome.scripting`, ağ istekleri için bildirime dayalı `chrome.declarativeNetRequest`, çerezler içinse standart ana makine izinleri kullanılabiliyor. Bunlar yalnız daha dar yetki istemiyor; kurumun izinli ve engelli alan listeleriyle birlikte de çalışıyor.
Burada geliştiriciye düşen karar, güçlü aracı korumak ile her işi onunla çözmeye çalışmak arasında. Bir kurum içi destek eklentisi sadece belirli bir uygulamanın sayfasına yardım ediyorsa, doğrudan hata ayıklama erişimini varsayılan yol yapmamalı. Gerçekten gerekli olduğunda ise politika reddi için ayrı bir ekran, günlük kaydı ve destek akışı kurmalı. Chrome'un geçici geri alma bayrağını Chrome 160'ta kaldıracağını söylemesi, bu işin sürüm notuna bırakılacak kısa bir uyumsuzluk olmadığını da gösteriyor.
Bu değişiklik, kurumun daha fazla karar yetkisi alması demek. Fakat kullanıcı açısından önemli olan, bu yetkinin görünür bir istisna yoluyla uygulanması. Eklentinin neyi yapamadığı, neden yapamadığı ve daha dar izinli sürümünün ne sunabildiği aynı akışta gösterilmezse, kullanıcı güvenlik politikasının işini neden durdurduğunu anlayamaz.
— Ozan Doruk Karaca
