Google, reklam engelleyiciler tarafından kullanılan webRequest API'sinin kısıtlanmasını haklı çıkarıyor

Chrome tarayıcı geliştiricileri denedim kanıtlamak Alınan içeriği anında değiştirmenize olanak tanıyan ve reklamları engellemek için eklentilerde aktif olarak kullanılan webRequest API'nin engelleme çalışma moduna yönelik desteğin sona ermesi,
Kötü amaçlı yazılımlara, kimlik avına, kullanıcı etkinliklerine ilişkin casusluğa, ebeveyn denetimlerine ve gizliliğe karşı koruma.

Google'ın nedenleri:

• API engelleme modu webTalebi yüksek kaynak tüketimine yol açar.
  Bu API kullanıldığında, tarayıcı ilk önce ağ isteğinde bulunan tüm verileri eklentiye gönderir, eklenti bunları analiz eder ve tarayıcıda daha fazla işlenmek üzere değiştirilmiş bir sürüm döndürür veya engelleme talimatları verir. Bu durumda, ana gecikmeler, trafiğin eklenti tarafından işlenmesi aşamasında değil, eklentinin yürütülmesini koordine etmenin genel giderleri nedeniyle ortaya çıkar. Özellikle, bu tür manipülasyonlar, tamamlayıcı olarak ayrı bir sürecin başlatılmasının yanı sıra, bu süreçle ve veri serileştirme mekanizmalarıyla etkileşimde bulunmak için IPC'nin kullanılmasını gerektirir;

• Eklenti, tüm trafiği düşük düzeyde tamamen kontrol eder ve bu da kötüye kullanım ve gizlilik ihlalleri için geniş fırsatlar yaratır. Google istatistiklerine göre, tespit edilen tüm kötü amaçlı eklentilerin %42'si webRequest API'sini kullanıyor. Chrome Web Mağazası kataloğuna her ay ortalama 1800 kötü amaçlı eklenti yerleştirme girişiminin engellendiği belirtiliyor. Maalesef inceleme, istisnasız tüm kötü amaçlı eklentileri yakalamamıza izin vermiyor, bu nedenle korumayı artırmak için eklentilerin API düzeyinde sınırlandırılmasına karar verildi. Ana fikir, eklentilere tüm trafiğe değil, yalnızca amaçlanan işlevselliği uygulamak için gerekli olan verilere erişim sağlamaktır. Özellikle içeriği engellemek için eklentiye tüm gizli kullanıcı verilerine tam erişim izni vermek gerekli değildir;
• Önerilen yedek bildirim API'si bildirimselNetRequest yüksek performanslı içerik filtrelemenin tüm işlerini üstlenir ve yalnızca filtreleme kurallarını yüklemek için eklentilere ihtiyaç duyar. Eklenti trafiğe müdahale edemez ve kullanıcının özel verileri dokunulmaz kalır;
• Google, declarativeNetRequest API'sinin işlevsellik eksikliğine ilişkin yorumların çoğunu dikkate aldı ve filtreleme kuralı sayısı sınırını başlangıçta uzantı başına önerilen 30 binden küresel maksimum 150 bine kadar genişletti ve ayrıca dinamik olarak filtreleme yeteneğini de ekledi. kuralları değiştirin ve ekleyin, HTTP başlıklarını (Referer, Cookie, Set-Cookie) kaldırın ve değiştirin ve parametreleri talep edin;
• İşletmeler için webRequest API'nin engelleme çalışma modunu kullanmak mümkündür, çünkü eklentilerin kullanımına ilişkin politika, altyapının özelliklerini anlayan ve risklerin farkında olan bir yönetici tarafından belirlenir. Örneğin belirtilen API, işletmelerde çalışan trafik akışlarını kaydetmek ve iç sistemlere entegre etmek için kullanılabilir;
• Google'ın amacı, reklam engelleme eklentilerini baltalamak veya bastırmak değil, daha güvenli ve daha güçlü reklam engelleyicilerin oluşturulmasını sağlamaktır;
• Yeni declarativeNetRequest ile birlikte webRequest API'sinin engelleme çalışma modundan ayrılma konusundaki isteksizlik, eklentilerin gizli verilere erişimini sınırlama arzusuyla açıklanmaktadır. webRequest API'sini olduğu gibi bırakırsanız çoğu geliştirici, güvenlik ve işlevsellik arasında seçim yaparken genellikle işlevselliği seçeceğinden, çoğu eklenti daha güvenli olan bildirimselNetRequest'i kullanmayacaktır.

İtirazlar geliştiriciler eklemeler:

• Eklenti geliştiricileri tarafından yürütülür testleri reklam engelleme eklentilerinin performansı üzerinde önemsiz bir genel etki gösterir (test sırasında çeşitli eklentilerin performansı karşılaştırıldı, ancak işleyicilerin engelleme modunda yürütülmesini koordine eden ek bir sürecin ek yükü dikkate alınmadan) webRequest API'si);
• Eklentilerde aktif olarak kullanılan bir API'yi desteklemeyi tamamen bırakmak pratik değildir. Bunu kaldırmak yerine, ayrı bir izin ekleyebilir ve bunun eklentilerde kullanımının yeterliliğini sıkı bir şekilde kontrol edebilirsiniz; bu, birçok popüler eklentinin yazarlarını, ürünlerini tamamen yeniden çalışmaktan ve işlevselliği kesmekten kurtaracaktır;
• Genel maliyetleri azaltmak için API'yi silemezsiniz, ancak Firefox'taki webRequest uygulamasına benzer şekilde Promise mekanizmasına dayalı olarak yeniden oluşturabilirsiniz;
• Önerilen alternatif, declarativeNetRequest, ağ istekleri üzerinde tam kontrol sağlamadığı, özel filtreleme algoritmalarının kullanımına izin vermediği ve izin vermediği için eklenti geliştiricilerinin reklam engelleme ve güvenlik/gizlilik konusundaki tüm ihtiyaçlarını karşılamamaktadır. koşullara bağlı olarak birbiriyle örtüşen karmaşık kuralların kullanılması;
• DeclarativeNetRequest API'nin mevcut durumuyla, uBlock Origin ve uMatrix eklentilerinin mevcut işlevselliğini değiştirmeden yeniden oluşturmak imkansızdır ve ayrıca Chrome için bir NoScript bağlantı noktasının daha fazla geliştirilmesini anlamsız hale getirir;
• webRequest API'sinin salt okunur, engellemesiz modu yerinde bırakıldığından ve kötü niyetli eklentilerin tüm trafiği kontrol etmesine izin verdiğinden, ancak buna web üzerinde müdahale etme yeteneği sağlamadığından, gizlilikle ilgili endişeler abartılıdır. uçmak (içeriği değiştirin, reklamlarınızı yerleştirin, madencileri çalıştırın ve giriş formlarının içeriğini analiz edin, sayfanın yüklenmesi tamamlandıktan sonra kullanılabilir);
• Tarayıcı geliştiricileri Cesur, Opera и VivaldiChromium motoru üzerine kurulu olan şirket, ürünlerinde webRequest engelleme modunu desteklemeyi amaçlıyor.

Kaynak: opennet.ru