در طول سال گذشته، ما به طور فعال در بحث با فروشندگان پشت چندین افزونه مسدودکننده محتوا پیرامون راه‌های بهبود پلتفرم افزونه‌های MV3 شرکت کرده‌ایم. بر اساس این بحث ها، که بسیاری از آنها در گروه انجمن WebExtensions ( WECG ) با همکاری سایر مرورگرها انجام شد، ما توانسته ایم پیشرفت های قابل توجهی را ارائه دهیم.
قوانین ایستا بیشتر
مجموعه ای از قوانین فیلتر معمولاً در لیست ها گروه بندی می شوند. به عنوان مثال، یک لیست عمومی تر می تواند حاوی قوانین قابل اجرا برای همه کاربران باشد، در حالی که یک لیست خاص تر ممکن است محتوای خاص مکان را پنهان کند که فقط برخی از کاربران مایل به مسدود کردن آن هستند. تا همین اواخر، ما به هر برنامه افزودنی اجازه می دادیم تا انتخابی از بین 50 لیست (یا "مجموعه قوانین ثابت") را به کاربران ارائه دهد و 10 مورد از آنها را به طور همزمان فعال کنند. در بحث با جامعه، توسعه‌دهندگان برنامه‌های افزودنی شواهد قانع‌کننده‌ای ارائه کردند که نشان می‌دهد این برای موارد استفاده خاص بسیار کم است. پس از بررسی عملکرد API در کروم با در نظر گرفتن این بحث ها، اکنون اجازه می دهیم تا حداکثر 50 به طور همزمان فعال شوند. (به طور قابل توجهی، این به طور قابل توجهی بالاتر از حد 20 درخواست شده در WECG است.) ما همچنین در مجموع به 100 مجموعه قانون اجازه می دهیم. این در Chrome 120 ارسال می‌شود و افزایش محدودیت‌ها توسط فایرفاکس و سافاری پشتیبانی می‌شود که هر دو ورودی اولیه را در مورد این پیشنهاد ارائه کردند.
قوانین پویا تر
اکثر قوانین "ایستا" هستند و با هر به روز رسانی به یک برنامه افزودنی ارسال می شوند. با این حال، برای پشتیبانی از به‌روزرسانی‌های مکرر و قوانین تعریف‌شده توسط کاربر، برنامه‌های افزودنی می‌توانند قوانین را نیز به صورت پویا اضافه کنند، بدون اینکه برنامه‌نویسان مجبور باشند نسخه جدیدی از برنامه افزودنی را در فروشگاه وب Chrome آپلود کنند.
وقتی یک برنامه افزودنی می‌تواند به‌طور پویا درخواست‌ها را به روش‌هایی تغییر دهد که در بررسی فروشگاه وب Chrome بررسی نشده‌اند، این کار کاربران را در معرض خطرات فیشینگ یا سرقت داده‌ها قرار می‌دهد. به عنوان مثال، یک قانون تغییر مسیر ممکن است برای تزریق پیوندهای وابسته بدون رضایت مورد سوء استفاده قرار گیرد.
در نتیجه، ما فقط به برنامه‌های افزودنی اجازه دادیم تا حداکثر 5000 قانون را اضافه کنند که استفاده کم از این عملکرد را تشویق می‌کند و تشخیص سوءاستفاده را برای ما آسان‌تر می‌کند.
با این حال، توسعه‌دهندگان برنامه‌های افزودنی از جمله AdGuard و Adblock Plus تجزیه و تحلیل خود را انجام دادند و داده‌هایی را به اشتراک گذاشتند که محدودیت‌های بالاتر باعث می‌شود قوانین به‌روزتر و کاربرانی که تعداد فهرست‌های سفارشی بیشتری دارند به Manifest V3 مهاجرت کنند. در واقع، AdGuard گزارش داد که هر هفته بیش از 2600 تغییر در لیست‌های محبوب ایجاد می‌شود و از پنج درصد کاربرانی که از لیست‌های فیلتر سفارشی استفاده می‌کنند، از هر چهار کاربر یک نفر مجموعاً بیش از 5000 قانون پویا در سراسر آنها دارد ( منبع ). AdGuard این را به عنوان یک چالش مهم برای انتقال برنامه افزودنی خود به Manifest V3 ذکر کرد و ما بازخوردهای مشابهی را از سایر مسدود کننده های محتوا شنیدیم.
ما تشخیص دادیم که برخی از قوانین فیلتر، مانند مواردی که دارای عملکرد block یا allow هستند، بسیار ایمن‌تر هستند و کمتر مورد سوء استفاده قرار می‌گیرند. آنها همچنین اکثریت بزرگی از قوانین فیلتر بلوک تبلیغات را تشکیل می دهند. بر این اساس، من پیش‌نویسی را برای تعریف مجموعه‌ای از قوانین که ریسک کمتری در نظر می‌گیریم و حداکثر 30000 مورد از این موارد را مجاز می‌دانیم، در گروه جامعه برنامه‌های افزودنی وب به اشتراک گذاشتم . ما همچنان یک حد بالایی را برای جلوگیری از رگرسیون عملکرد حفظ می کنیم.
این پیشنهاد در گروه انجمن برنامه های افزودنی وب پشتیبانی شد، بنابراین ما آن را اجرا کردیم. با شروع Chrome 121، محدودیت بالاتر 30000 قانون برای قوانین DNR ایمن اعمال می‌شود، که ما آنها را به‌عنوان قوانینی با عملکرد block ، allow ، allowAllRequests یا upgradeScheme تعریف می‌کنیم.
بر اساس داده های به اشتراک گذاشته شده توسط AdGuard، بین 98 تا 99 درصد از قوانین آنها باید از این حد بالاتر بهره مند شوند. قوانین باقی مانده همچنان پشتیبانی می شوند و می توانند در محدوده موجود اضافه شوند.
این در Chrome به عنوان ثابت MAX_NUMBER_OF_DYNAMIC_RULES در دسترس است. محدودیت قانون برای سایر قوانین درخواست خالص پویا 5000 باقی می ماند.
کاهش اندازه مجموعه قوانین
در Chrome 118، مقدار پیش‌فرض فیلد isUrlFilterCaseSensitive را بر اساس بازخورد انجمن به false تغییر دادیم. این فیلد کنترل می‌کند که آیا قاعده‌ای که بر اساس URL فیلتر می‌شود به حروف کوچک و بزرگ حساس است یا خیر، و ما متوجه شدیم که اکثر توسعه‌دهندگان پیش‌فرض متفاوتی در پسوند خود دارند. در نتیجه، مقدار باید چندین بار تنظیم شود. با ایجاد این تغییر، توسعه دهندگان قادر به کاهش اندازه قابل توجهی در مجموعه قوانین خود هستند.
بعدش چی؟
ما متعهد هستیم که به سرمایه گذاری در DeclarativeNetRequest API ادامه دهیم تا بتوانیم تا حد امکان از موارد استفاده پشتیبانی کنیم و مشتاقانه منتظر ادامه همکاری با جامعه هستیم. به طور خاص، مایلیم از اعضای WECG به خاطر مشارکتشان، از جمله AdGuard برای به اشتراک گذاشتن مقدار قابل توجهی از داده‌هایی که این کار را به انجام رساندند، و همه فروشندگان مرورگر که همگی بخش عمده‌ای در طراحی این API بوده‌اند، تشکر کنیم.
ما به بررسی محدودیت‌هایی که داریم ادامه می‌دهیم تا در صورت نیاز تنظیمات را انجام دهیم. برای حمایت از این امر، قصد داریم در آینده نزدیک برخی از داده هایی را که به عنوان بخشی از این کار جمع آوری کرده ایم به اشتراک بگذاریم. علاوه بر این، ما در حال کار بر روی افزودن قابلیت‌های اضافی مانند توانایی تطبیق با سرصفحه‌های پاسخ هستیم، که درخواست رایجی است که از پسوندهای نمایشگر PDF دیده‌ایم. در همه موارد، ما به برقراری ارتباط با کار خود ادامه می‌دهیم و از گروه انجمن افزونه‌های وب به‌عنوان مکانی برای بحث در مورد ایده‌ها و هماهنگی با آنچه که می‌خواهیم در آینده به آن نگاه کنیم، استفاده می‌کنیم.