Geçtiğimiz yıl boyunca, MV3 uzantıları platformunu iyileştirme yollarına yönelik çeşitli içerik engelleme uzantılarının arkasındaki tedarikçilerle etkin bir şekilde görüşmeler yaptık. Çoğu, diğer tarayıcılarla işbirliğiyle WebExtensions Topluluk Grubu'nda (WECG) gerçekleştirilen bu tartışmalara dayanarak önemli iyileştirmeler yapmayı başardık.
Daha fazla statik kural kümesi
Filtre kuralı grupları genellikle listeler halinde gruplandırılır. Örneğin, daha genel bir liste tüm kullanıcılar için geçerli olan kuralları içerebilirken, daha spesifik bir liste yalnızca bazı kullanıcıların engellemek istediği konuma özgü içeriği gizleyebilir. Yakın zamana kadar, her bir uzantının kullanıcılara 50 liste (veya "statik kural grupları") seçeneği sunmasına ve bunlardan 10 tanesinin aynı anda etkinleştirilmesine izin veriyorduk. Uzantı geliştiricileri, toplulukla yaptıkları görüşmelerde bunun belirli kullanım alanları için çok düşük olduğuna dair ikna edici kanıtlar sundu. API'nin Chrome'daki performansını inceledikten sonra bu noktaları göz önünde bulundurarak, aynı anda en fazla 50 API'nin etkinleştirilmesine izin veriyoruz. (Bu değer, özellikle WECG'de istenen 20 sınırın önemli ölçüde üzerindedir.) Ayrıca toplamda 100 kural kümesine izin verilir. Bu özellik Chrome 120'de kullanıma sunulmaktadır ve sınırların artırılması, bu teklife erken giriş sağlayan Firefox ve Safari tarafından desteklenmektedir.
Diğer dinamik kurallar
Çoğu kural "statik"tir ve her güncellemeyle birlikte bir uzantıya gönderilir. Bununla birlikte, uzantılar, daha sık güncelleme yapılmasını ve kullanıcı tanımlı kuralları desteklemek için, geliştiricilerin Chrome Web Mağazası'na uzantının yeni sürümünü yüklemek zorunda kalmadan kuralları dinamik bir şekilde de ekleyebilir.
Bir uzantı, istekleri Chrome Web Mağazası incelemesi sırasında kontrol edilmeyen şekillerde dinamik olarak değiştirebildiğinde kullanıcılar için kimlik avı veya veri hırsızlığı riski ortaya çıkar. Örneğin bir yönlendirme kuralı, izinsiz olarak satış ortağı bağlantıları eklemek için kötüye kullanılabilir.
Sonuç olarak, uzantıların yalnızca 5.000'e kadar kural eklemesine izin verildi. Böylece,bu işlevin ölçülü kullanımı teşvik edildi ve kötüye kullanımın tespit edilmesi kolaylaştı.
Bununla birlikte, AdGuard ve Adblock Plus gibi uzantıların geliştiricileri, daha yüksek bir sınırın daha güncel kurallara ve daha yüksek sayıda özel listeye sahip kullanıcıların Manifest V3'e taşınmasına olanak tanıyacağı şekilde kendi analizlerini gerçekleştirmiş ve paylaşmıştır. Aslında AdGuard, popüler listelerde her hafta 2.600'den fazla değişiklik yapıldığını ve özel filtre listelerini kullanan kullanıcıların yüzde beşini, bu kullanıcıların dörtte birinin toplamda 5.000'den fazla dinamik kurala sahip olduğunu bildirmiştir (kaynak). AdGuard'da bunun, uzantılarını Manifest V3'e taşımaları açısından önemli bir zorluk olarak belirttiği ve diğer içerik engelleyicilerden de benzer geri bildirimler aldık.
block veya allow işlemi olanlar gibi bazı filtre kurallarının çok daha güvenli olduğunu ve kötüye kullanılma olasılığının daha düşük olduğunu belirledik. Ayrıca, reklam engelleme filtresi kurallarının büyük çoğunluğunu oluştururlar. Buna dayanarak, daha düşük riskli olarak değerlendirdiğimiz bir dizi kural tanımlamak ve bunlardan 30.000 kadarına izin vermek üzere bir teklif taslağı hazırladım ve Web Uzantıları Topluluk Grubu'nda bir teklif paylaştım. Performans gerilemelerini önlemek için bir üst sınırı tutmaya devam ederiz.
Bu teklif, Web Uzantıları Topluluk Grubu tarafından desteklendiğinden uyguladık. Chrome 121 sürümünden itibaren geçerli olmak üzere, güvenli DNR kuralları için üst sınır olan 30.000 kural geçerlidir. Bu kuralları block, allow, allowAllRequests veya upgradeScheme işlemiyle kural olarak tanımlıyoruz.
AdGuard tarafından paylaşılan verilere göre, kurallarının yüzde 98 ile 99'u bu yüksek sınırdan yararlanmalıdır. Kalan kurallar hâlâ desteklenmektedir ve mevcut sınır dahilinde eklenebilir.
Bu değer, Chrome'da MAX_NUMBER_OF_DYNAMIC_RULES sabiti olarak kullanılabilir. Diğer tüm dinamik net istek kurallarının kural sınırı 5.000'de kalır.
Küçültülmüş kural grubu boyutu
Chrome 118'de, topluluktan gelen geri bildirimler doğrultusunda isUrlFilterCaseSensitive alanının varsayılan değerini false olarak değiştirdik. Bu alan, URL'ye göre filtreleme yapan bir kuralın büyük/küçük harfe duyarlı olup olmadığını kontrol eder. Ayrıca, çoğu geliştiricinin uzantılarında farklı bir varsayılana sahip olduğunu öğrendik. Bu nedenle, değerin birçok kez ayarlanması gerekti. Geliştiriciler bu değişikliği yaparak kural kümelerinde önemli ölçüde boyut küçültmeyi başarabilirler.
Sırada ne var?
Mümkün olduğunca fazla kullanım alanını destekleyebilmek için declarativeNetRequest API'ye yatırım yapmaya devam etme konusunda kararlıyız ve toplulukla çalışmaya devam etmeyi umuyoruz. Özellikle WECG üyelerine, bu çalışmaya olanak tanıyan önemli miktarda veri paylaştığı için AdGuard'a ve bu API'nin tasarımında büyük rol oynayan tüm tarayıcı tedarikçilerine kadar tüm WECG üyelerine teşekkür ediyoruz.
Gerektiğinde düzenlemeler yapmak için mevcut sınırlarımızı incelemeye devam edeceğiz. Bunu desteklemek için bu çalışma kapsamında topladığımız verilerin bir kısmını yakın gelecekte paylaşmayı planlıyoruz. Buna ek olarak, PDF görüntüleyici uzantılarında yaygın olarak gördüğümüz bir istek olan yanıt başlıklarıyla eşleştirme özelliği gibi ek özellikler eklemek için çalışıyoruz. Her durumda, çalışmalarımızı duyurmaya devam edeceğiz ve fikirlerimizi tartışmak ve gelecekte ele almak istediklerimiz üzerinde fikir birliğine varmak için düzenli olarak Web Uzantıları Topluluk Grubu'nu kullanacağız.