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