Geçtiğimiz yıl boyunca, MV3 uzantıları platformunu geliştirme yollarıyla ilgili olarak çeşitli içerik engelleme uzantılarının arkasındaki tedarikçi firmalarla görüşmeler yaptık. Birçoğu WebExtensions Topluluk Grubu'nda (WECG) diğer tarayıcılarla ortak çalışarak gerçekleşen bu tartışmalar sonucunda önemli iyileştirmeler sağlayabildik.
Diğer statik kural kümeleri
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 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ümeleri") seçeneği sunmasına ve bunlardan 10 tanesinin aynı anda etkinleştirilmesine izin veriyorduk. Uzantı geliştiricileri, toplulukla yaptıkları görüşmelerde, belirli kullanım alanları için bunun çok düşük olduğunu gösteren ikna edici kanıtlar sundu. Bu tartışmalarla birlikte API'nin Chrome'daki performansını inceledikten sonra, artık aynı anda 50 API'nin etkinleştirilmesine izin veriyoruz. (Bu değer, WECG'de talep edilen 20 adetlik sınırdan önemli ölçüde yüksektir.) Toplamda 100 kural kümesine de izin verilir. Bu, Chrome 120'de kullanıma sunulmuştur ve sınırlar, bu teklifte erken giriş sağlayan Firefox ve Safari tarafından desteklenmektedir.
Daha dinamik kurallar
Çoğu kural "statik"tir ve her güncellemeyle bir uzantıya gönderilir. Ancak uzantılar, daha sık yapılan güncellemeleri ve kullanıcı tanımlı kuralları desteklemek için, geliştiricilerinin Chrome Web Mağazası'na uzantının yeni bir sürümünü yüklemek zorunda kalmadan kuralları dinamik olarak da ekleyebilir.
Bir uzantı, istekleri Chrome Web Mağazası incelemesi sırasında kontrol edilmeyen şekillerde dinamik olarak değiştirebiliyorsa bu durum kullanıcıları kimlik avı veya veri hırsızlığı risklerine maruz bırakır. Örneğin bir yönlendirme kuralı, izin alınmadan satış ortağı bağlantıları eklemek için kötüye kullanılabilir.
Sonuç olarak, uzantıların en fazla 5.000 kural eklemesine izin verdik. Bu kurallar,bu işlevin tutumlu bir şekilde kullanılmasını teşvik etti ve kötüye kullanımı tespit etmemizi kolaylaştırdı.
Bununla birlikte, AdGuard ve Adblock Plus gibi uzantıların geliştiricileri, kendi analizlerini gerçekleştirdi ve daha yüksek bir sınırın, daha güncel kurallara ve daha fazla özel listeye sahip kullanıcıların Manifest V3'e taşınmasına olanak tanıyacak şekilde verileri paylaştı. AdGuard, popüler listelerde her hafta 2600'den fazla değişiklik yapıldığını ve özel filtre listeleri kullanan kullanıcıların yüzde beşinin, bu kullanıcıların dörtte birinin toplamda 5.000'den fazla dinamik kurala sahip olduğunu bildirdi (kaynak). AdGuard, bunu uzantılarını Manifest V3'e taşıma konusunda önemli bir zorluk olarak görüyordu ve diğer içerik engelleyicilerden de benzer geri bildirimler aldık.
İşlemi block veya allow olan kurallar gibi bazı filtre kurallarının çok daha güvenli olduğunu ve kötüye kullanılma olasılıklarının daha düşük olduğunu belirledik. Ayrıca, reklam engelleme filtre kurallarının büyük çoğunluğunu da oluştururlar. Bu bilgiler doğrultusunda, daha düşük risk taşıdığını düşündüğümüz ve bunlardan 30.000 tanesine kadar izin vereceğimiz bir dizi kural tanımlamak üzere Web Uzantıları Topluluk Grubu'nda bir teklif taslağını hazırladım ve paylaştım. Performans gerilemelerini önlemek için üst sınırı uygulamaya devam ediyoruz.
Bu teklif Web Uzantıları Topluluk Grubu'nda desteklendiği için onu uyguladık. Chrome 121'den itibaren güvenli DNR kuralları için üst sınır olan 30.000, block, allow, allowAllRequests veya upgradeScheme ile tanımlanmıştır.
AdGuard tarafından paylaşılan verilere göre, kurallarının yüzde 98'i ile 99'u bu 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 mevcuttur. Diğer tüm dinamik net istek kurallarının kural sınırı 5.000 olarak kalır.
Küçültülmüş kural kümesi boyutu
Chrome 118'de, isUrlFilterCaseSensitive alanının varsayılan değerini topluluktan gelen geri bildirimler doğrultusunda false olarak değiştirdik. Bu alan, URL'ye göre filtre uygulayan bir kuralın büyük/küçük harfe duyarlı olup olmadığını kontrol eder. Çoğu geliştiricinin uzantılarında farklı bir varsayılan değer olduğunu öğrendik. Sonuç olarak, bu değerin birçok kez tekrarlanması gerekti. Geliştiriciler bu değişikliği yaparak kural kümelerinde boyutları önemli ölçüde küçültebilirler.
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. Ayrıca toplulukla birlikte çalışmaya devam etmek için sabırsızlanıyoruz. Bu işe yön veren önemli miktarda veriyi paylaştığı için AdGuard ve bu API'nin tasarlanmasında büyük rol oynayan tüm tarayıcı tedarikçilerine özellikle katılımları için WECG üyelerine teşekkür ederiz.
Gerektiğinde düzenlemeler yapmak için uyguladığımız sınırları 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ından gördüğümüz yaygın bir istek olan yanıt başlıklarıyla eşleştirme gibi ek özellikler eklemek için çalışıyoruz. Her koşulda, fikirlerimizi tartışmak ve gelecekte ele almak istediğimiz noktaları belirlemek için düzenli olarak Web Uzantıları Topluluk Grubu'nu kullanarak çalışmalarımızı paylaşmaya devam edeceğiz.