على مدار العام الماضي، شاركنا بشكل نشط في مناقشات مع المورّدين الذين قدّموا العديد من إضافات حظر المحتوى حول طرق تحسين منصة إضافات الفيديوهات MV3. استنادًا إلى هذه المناقشات، التي تم عقد الكثير منها في مجموعة منتدى WebExtensions (WECG) بالتعاون مع المتصفّحات الأخرى، تمكّنا من إدخال تحسينات مهمة.
المزيد من مجموعات القواعد الثابتة
عادةً ما يتم تجميع مجموعات قواعد الفلاتر في قوائم. على سبيل المثال، يمكن أن تحتوي القائمة الأكثر عمومية على قواعد تنطبق على جميع المستخدمين، بينما قد تخفي القائمة الأكثر تحديدًا المحتوى الخاص بالموقع الجغرافي الذي يريد بعض المستخدمين فقط حظره. حتى وقت قريب، سمحنا لكل إضافة بتزويد المستخدمين بالاختيار من بين 50 قائمة (أو "مجموعات قواعد ثابتة")، وتفعيل 10 منها في وقت واحد. خلال المناقشات مع المنتدى، قدَّم مطوّرو الإضافات أدلة مقنعة على أنّ هذه النسبة كانت منخفضة جدًا بالنسبة إلى حالات استخدام معيّنة. وبعد النظر في أداء واجهة برمجة التطبيقات في Chrome مع وضع هذه المناقشات في الاعتبار، نسمح الآن بتفعيل ما يصل إلى 50 واجهة برمجة تطبيقات في آنٍ واحد. (ويزيد ذلك بشكل ملحوظ عن الحد البالغ 20 طلب في WECG). نسمح أيضًا بإجمالي 100 مجموعة قواعد. ستتم عملية الشحن في الإصدار Chrome 120، ويمكن زيادة الحدود من خلال كلّ من Firefox وSafari اللذان قدّما معلومات أولية بشأن هذا الاقتراح.
قواعد أكثر ديناميكية
تكون معظم القواعد "ثابتة" ويتم شحنها مع كل تحديث إلى إضافة. ومع ذلك، لإتاحة المزيد من التحديثات والقواعد التي يحددها المستخدم، يمكن للإضافات إدراج قواعد ديناميكيًا أيضًا، بدون أن يضطر المطوّرون إلى تحميل إصدار جديد من الإضافة إلى "سوق Chrome الإلكتروني".
عندما تتمكّن الإضافة من تعديل الطلبات ديناميكيًا بطرق لم يتم التحقّق منها أثناء مراجعة "سوق Chrome الإلكتروني"، يعرِّض ذلك المستخدمين لخطر التصيّد الاحتيالي أو سرقة البيانات. على سبيل المثال، يمكن إساءة استخدام قاعدة إعادة توجيه لإدخال روابط مؤدية إلى شركاء تابعين بدون الحصول على موافقة.
وبالتالي، لم نسمح للإضافات إلا بإضافة ما يصل إلى 5,000 قاعدة، ما شجّع على استخدام هذه الوظيفة باعتدال وسهّل علينا رصد حالات إساءة الاستخدام.
في المقابل، أجرى مطوّرو الإضافات من الإضافات، بما في ذلك AdGuard وAdblock Plus تحليلاً خاصًا ومشاركة بيانات تتيح لهم حدّ أقصى أعلى حداثة القواعد وانتقال المستخدمين الذين لديهم عدد أكبر من القوائم المخصّصة إلى إصدار Manifest V3. وفي الواقع، أفاد AdGuard أنّه يتم إجراء أكثر من 2600 تغيير على القوائم الشائعة كل أسبوع، ومن بين خمسة بالمئة من المستخدمين الذين يستخدمون قوائم الفلاتر المخصّصة، يحتوي واحد من كل أربعة من هؤلاء المستخدمين على إجمالي أكثر من 5,000 قاعدة ديناميكية في جميع هذه القوائم (المصدر). لاحظ فريق AdGuard أنّ هذا الأمر يشكّل تحديًا كبيرًا لنقل إضافة التطبيق إلى الإصدار Manifest V3، وقد تلقّينا ملاحظات مشابهة من أدوات حظر المحتوى الأخرى.
لقد تبيّن لنا أنّ بعض قواعد الفلاتر، مثل القواعد التي يتم فيها تطبيق الإجراء block أو allow، أكثر أمانًا وأقل عرضةً لإساءة الاستخدام. وتشكّل أيضًا الغالبية العظمى من قواعد فلترة حظر الإعلانات. وبناءً على ذلك، أعددتُ مسودة وشاركت اقتراحًا في مجموعة منتدى إضافات الويب لتحديد مجموعة من القواعد التي نعتبرها أقل خطورة ويمكننا تضمين ما يصل إلى 30,000 منها. ولا نزال نحتفظ بحد أقصى لتجنب أي تراجع في الأداء.
كان هذا الاقتراح متاحًا في مجموعة منتدى إضافات الويب، ولذلك تم تنفيذه. بدءًا من إصدار Chrome 121، يسري الحدّ الأقصى البالغ 30,000 قاعدة على قواعد DNR الآمنة التي نعرّفها كقواعد بإجراء block أو allow أو allowAllRequests أو upgradeScheme.
استنادًا إلى البيانات التي يشاركها AdGuard، من المفترض أن يستفيد ما بين 98 إلى 99 في المائة من قواعده من هذا الحد الأعلى. لا تزال أي قواعد متبقية متاحة ويمكن إضافتها ضمن الحدّ الحالي.
ويتوفر هذا في Chrome في صورة ثابتة MAX_NUMBER_OF_DYNAMIC_RULES بالقاعدة. ويظل حد القاعدة لجميع قواعد طلبات الشبكة الديناميكية الأخرى عند 5000.
تقليل حجم مجموعة القواعد
في الإصدار 118 من Chrome، غيّرنا القيمة التلقائية للحقل isUrlFilterCaseSensitive إلى false استنادًا إلى الملاحظات الواردة من المنتدى. يتحكم هذا الحقل في ما إذا كانت القاعدة التي تتم فلترتها حسب عنوان URL حساسة لحالة الأحرف، وتعرّفنا على أن معظم مطوّري البرامج لديهم إعداد تلقائي مختلف في الإضافة. وبالتالي، كان يجب تعيين القيمة عدة مرات. من خلال إجراء هذا التغيير، يتمكن المطورون من خفض حجم مجموعات قواعدهم بشكل ملحوظ.
الخطوات التالية
نحن ملتزمون بمواصلة الاستثمار في واجهة برمجة التطبيقات declarativeNetRequest API لنتمكن من دعم أكبر عدد ممكن من حالات الاستخدام، ونتطلّع إلى مواصلة العمل مع المنتدى. على وجه الخصوص، نود أن نشكر أعضاء فريق WECG على تفاعلهم، بما في ذلك AdGuard على مشاركة كمية كبيرة من البيانات التي أدت إلى تنفيذ هذا العمل، وجميع مورّدي المتصفحات الذين كانوا جزءًا كبيرًا من تصميم واجهة برمجة التطبيقات هذه.
سنواصل مراجعة الحدود التي وضعناها لإجراء التعديلات اللازمة حسب الحاجة. ولدعم ذلك، نخطط لمشاركة بعض البيانات التي جمعناها كجزء من هذا العمل في المستقبل القريب. بالإضافة إلى ذلك، نعمل على إضافة إمكانات إضافية مثل إمكانية المطابقة مع عناوين الاستجابة، وهو طلب شائع وصلنا إليه في إضافات عارض ملفات PDF. في جميع الحالات، سنواصل نشر عملنا، وسنستخدم مجموعة منتدى إضافات الويب بانتظام كمكان لمناقشة الأفكار والتأكّد من توافقه مع ما نريد أن نتناوله في المستقبل.