على مدار العام الماضي، شاركنا بشكل نشط في مناقشات مع مورّدي العديد من إضافات حظر المحتوى حول طرق تحسين منصة إضافات MV3. استنادًا إلى هذه المناقشات، والتي تم إجراء الكثير منها في مجموعة منتدى إضافات WebExtensions (WECG) بالتعاون مع متصفحات أخرى، تم توفير تحسينات مهمة.
المزيد من مجموعات القواعد الثابتة
يتم عادةً تجميع مجموعات قواعد الفلاتر في قوائم. على سبيل المثال، يمكن أن تحتوي القائمة الأكثر عمومية على قواعد تنطبق على جميع المستخدمين، في حين قد تخفي قائمة أكثر تحديدًا المحتوى المرتبط بموقع جغرافي والذي يريد بعض المستخدمين حظره فقط. حتى وقت قريب، سمحنا لكل إضافة بأن توفّر للمستخدمين إمكانية الاختيار من بين 50 قائمة (أو "مجموعة قواعد ثابتة")، وأن يتم تفعيل 10 من هذه القوائم في الوقت نفسه. خلال المناقشات مع المنتدى، قدَّم مطوّرو الإضافات أدلة مقنعة تشير إلى أنّ هذه القيمة منخفضة جدًا في حالات استخدام معيّنة. بعد النظر في أداء واجهة برمجة التطبيقات في Chrome مع وضع هذه المناقشات في الاعتبار، نسمح الآن بتفعيل ما يصل إلى 50 في الوقت نفسه. (وتجدر الإشارة إلى أنّ هذا العدد أعلى بكثير من الحدّ الأقصى المسموح به البالغ 20 في WECG). ونسمح أيضًا بمجموع 100 مجموعة قواعد. يتم تنفيذ ذلك في Chrome 120، ويمكن زيادة الحدود من خلال كل من Firefox وSafari اللذان قدّما ملاحظات مبكرة حول هذا الاقتراح.
المزيد من القواعد الديناميكية
تكون معظم القواعد "ثابتة" ويتم تطبيقها مع كل تحديث لإحدى الإضافات. لإتاحة المزيد من التحديثات المتكررة والقواعد التي يحددها المستخدم، يمكن للإضافات إضافة قواعد ديناميكيًا أيضًا بدون أن يضطر مطوّروها إلى تحميل إصدار جديد من الإضافة إلى "سوق Chrome الإلكتروني".
عندما تعدِّل إحدى الإضافات الطلبات ديناميكيًا بطرق لم يتم التحقّق منها أثناء مراجعة "سوق Chrome الإلكتروني"، يعرّض ذلك المستخدمين لمخاطر التصيّد الاحتيالي أو سرقة البيانات. على سبيل المثال، يمكن إساءة استخدام قاعدة إعادة توجيه لإدخال روابط مؤدية إلى شركاء تابعين بدون الحصول على موافقة.
وبالتالي، لم نسمح للإضافات بإضافة ما يصل إلى 5,000 قاعدة إلا إذا شجعت هذه الإضافات على استخدام هذه الوظيفة باعتدال وسهّل علينا رصد إساءة الاستخدام.
ومع ذلك، أجرى المطوّرون الذين يستخدمون إضافات، بما في ذلك AdGuard وAdblock Plus تحليلهم الخاص وشاركوا بيانات تسمح لهم باستخدام حد أعلى باستخدام أحدث القواعد، وللمستخدمين الذين لديهم عدد أكبر من القوائم المخصَّصة نقل البيانات إلى الإصدار 3 من البيان. في الواقع، أفادت AdGuard بأنّه يتم إجراء أكثر من 2600 تغيير على القوائم الرائجة كل أسبوع، ومن بين خمسة بالمائة من المستخدمين الذين يستخدمون قوائم الفلاتر المخصّصة، يمتلك واحد من كل أربعة من هؤلاء المستخدمين إجمالي أكثر من 5,000 قاعدة ديناميكية في تلك القوائم (المصدر). أشار AdGuard إلى أنّ هذا الأمر يشكّل تحديًا كبيرًا لنقل إضافة الشركة إلى الإصدار Manifest V3، وتلقّينا ملاحظات مشابهة من أدوات حظر محتوى أخرى.
لقد تبيّن لنا أنّ بعض قواعد الفلاتر، مثل القواعد التي تتضمّن إجراء block أو allow، أكثر أمانًا وأقل احتمالاً أن تتم إساءة استخدامها. كما أنّها تشكِّل الغالبية العظمى من قواعد فلاتر حظر الإعلانات. وبناءً على ذلك، أعددت اقتراحًا وشاركته في مجموعة منتدى إضافات الويب من أجل تحديد مجموعة من القواعد التي نعتبرها أقل خطورة، وأن تسمح بما يصل إلى 30,000 من هذه القواعد. ما زلنا نحتفظ بحد أقصى لتجنب أي تراجع في الأداء.
كان هذا الاقتراح متاحًا في مجموعة منتدى إضافات الويب، ولذلك نفّذناه. بدءًا من الإصدار 121 من Chrome، ينطبق الحدّ الأقصى البالغ 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. في جميع الحالات، سنواصل العمل على إبلاغنا بالعمل، واستخدام مجموعة منتدى إضافات الويب بانتظام كمكان لمناقشة الأفكار وتوضيح ما نود أن نطّلع عليه لاحقًا.