Geçtiğimiz yıl, çeşitli içerik engelleme uzantılarının arkasındaki tedarikçi firmalarla MV3 uzantıları platformunu iyileştirmenin yolları hakkında aktif olarak görüştük. Çoğu WebExtensions Topluluk Grubu'nda (WECG) diğer tarayıcılarla birlikte yapılan bu görüşmeler sonucunda önemli iyileştirmeler yapabildik.
Daha fazla statik kural kümesi
Filtre kuralı kümeleri genellikle listeler halinde gruplandırılır. Örneğin, daha genel bir liste tüm kullanıcılar için geçerli 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 uzantının kullanıcılara 50 liste (veya "statik kural kümesi") seçeneği sunmasına ve bunların 10'unun aynı anda etkinleştirilmesine izin veriyorduk. Toplulukla yaptığımız görüşmelerde, uzantı geliştiricileri bu sınırın belirli kullanım alanları için çok düşük olduğunu gösteren ikna edici kanıtlar sundu. Bu tartışmaları göz önünde bulundurarak Chrome'daki API'nin performansını inceledikten sonra, artık aynı anda 50'ye kadar etkinleştirmeye izin veriyoruz. (Bu, WECG'de istenen 20 sınırından önemli ölçüde daha yüksektir.) Ayrıca toplamda 100 kural kümesine izin verilir. Bu özellik Chrome 120'de kullanıma sunulacaktır. Sınırların artırılması, bu teklifle ilgili erkenden geri bildirimde bulunan hem Firefox hem de Safari tarafından desteklenmektedir.
Daha fazla dinamik kural
Çoğu kural "statik"tir ve uzantı her güncellendiğinde gönderilir. Ancak daha sık güncellemeleri ve kullanıcı tanımlı kuralları desteklemek için uzantılar, geliştiricilerin uzantının yeni bir sürümünü Chrome Web Mağazası'na yüklemesi gerekmeden dinamik olarak da kural ekleyebilir.
Bir uzantı, istekleri Chrome Web Mağazası incelemesi sırasında kontrol edilmeyen şekillerde dinamik olarak değiştirebiliyorsa kullanıcılar kimlik avı veya veri hırsızlığı risklerine maruz kalır. Ö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 kural eklemesine izin verdik. Bu,bu işlevin dikkatli bir şekilde kullanılmasını teşvik etti ve kötüye kullanımı tespit etmemizi kolaylaştırdı.
Ancak AdGuard ve Adblock Plus gibi uzantıların geliştiricileri kendi analizlerini yaptı ve daha yüksek bir sınırın daha güncel kurallara ve daha fazla sayıda özel listeye sahip kullanıcıların Manifest V3'e geçmesine olanak tanıyacağıyla ilgili veriler paylaştı. AdGuard, popüler listelerde her hafta 2.600'den fazla değişiklik yapıldığını ve özel filtre listeleri kullanan kullanıcıların yüzde beşinde, bu kullanıcıların dörtte birinin toplamda 5.000'den fazla dinamik kurala sahip olduğunu bildirmiştir (kaynak). AdGuard, uzantılarını Manifest V3'e taşıma konusunda bu sorunun önemli bir zorluk olduğunu belirtti. Diğer içerik engelleyicilerden de benzer geri bildirimler aldık.
block veya allow işlemine sahip olanlar gibi bazı filtre kurallarının çok daha güvenli olduğunu ve kötüye kullanım 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. Bu doğrultuda, riski düşük olarak değerlendirdiğimiz ve 30.000'e kadarına izin vereceğimiz bir dizi kural tanımlamak için Web Uzantıları Topluluk Grubu'nda bir öneri hazırlayıp paylaştım. Performans gerilemelerini önlemek için üst sınırı korumaya devam ediyoruz.
Bu öneri, Web Uzantıları Topluluk Grubu tarafından desteklendiğinde uygulandı. Chrome 121'den itibaren, block, allow, allowAllRequests veya upgradeScheme işlemine sahip kurallar olarak tanımladığımız güvenli DNR kuralları için 30.000 kurallık daha yüksek sınır geçerlidir.
AdGuard tarafından paylaşılan verilere göre, kurallarının yüzde 98 ila 99'u bu daha yüksek sınırdan yararlanacaktır. Kalan kurallar desteklenmeye devam eder ve mevcut sınır dahilinde eklenebilir.
Bu değer, Chrome'da MAX_NUMBER_OF_DYNAMIC_RULES sabit değeri olarak kullanılabilir. Diğer tüm dinamik net istek kuralları için kural sınırı 5.000 olarak kalır.
Azaltı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 filtreleyen bir kuralın büyük/küçük harf duyarlı olup olmadığını kontrol eder. Çoğu geliştiricinin uzantısında farklı bir varsayılan değer olduğunu öğrendik. Sonuç olarak, değerin birçok kez ayarlanması gerekiyordu. Geliştiriciler bu değişikliği yaparak kural kümelerinde önemli ölçüde boyut azaltma elde edebilir.
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 etmeye kararlıyız ve toplulukla çalışmaya devam etmeyi umuyoruz. Özellikle, bu çalışmayı yönlendiren verilerin önemli bir kısmını paylaşan AdGuard ve bu API'nin tasarımında önemli bir rol oynayan tüm tarayıcı tedarikçileri de dahil olmak üzere WECG üyelerine katılımları için teşekkür ederiz.
Gerekli durumlarda düzenlemeler yapmak için mevcut sınırlarımızı incelemeye devam edeceğiz. Bu çalışma kapsamında topladığımız verilerin bir kısmını yakın gelecekte paylaşmayı planlıyoruz. Ayrıca, PDF görüntüleyici uzantılarından sıklıkla aldığımız yanıt başlıklarıyla eşleme yapma özelliği gibi ek özellikler eklemek için çalışıyoruz. Her durumda, çalışmalarımızı paylaşmaya devam edeceğiz ve Web Uzantıları Topluluk Grubu'nu, fikirleri tartışmak ve bir sonraki çalışma alanımızı belirlemek için düzenli olarak kullanacağız.