توسعه دهندگان مرورگر کروم توقف پشتیبانی از حالت مسدود کردن عملکرد webRequest API، که به شما امکان می دهد محتوای دریافتی را در لحظه تغییر دهید و به طور فعال در افزونه ها برای مسدود کردن تبلیغات استفاده می شود.
محافظت در برابر بدافزار، فیشینگ، جاسوسی از فعالیت کاربر، کنترل‌های والدین و حریم خصوصی.
انگیزه های گوگل:
- حالت مسدود کردن API منجر به مصرف بالای منابع می شود.
هنگام استفاده از این API، مرورگر ابتدا تمام داده‌های موجود در درخواست شبکه را برای افزونه ارسال می‌کند، افزونه آن را تجزیه و تحلیل می‌کند و یک نسخه اصلاح‌شده را برای پردازش بیشتر در مرورگر برمی‌گرداند یا دستورالعمل‌های مسدود کردن را صادر می‌کند. در این حالت، تاخیرهای اصلی نه در مرحله پردازش ترافیک توسط افزونه، بلکه به دلیل هزینه های سربار هماهنگی اجرای افزونه ایجاد می شود. به طور خاص، چنین دستکاری هایی نیاز به راه اندازی یک فرآیند جداگانه برای تکمیل، و همچنین استفاده از IPC برای تعامل با این فرآیند و مکانیسم های سریال سازی داده ها دارد. - این افزونه به طور کامل تمام ترافیک را در سطح پایین کنترل می کند، که فرصت های گسترده ای را برای سوء استفاده و نقض حریم خصوصی باز می کند. طبق آمار گوگل، 42 درصد از افزونه های مخرب شناسایی شده از webRequest API استفاده می کردند. اشاره شده است که هر ماه، تلاش برای قرار دادن به طور متوسط 1800 افزونه مخرب در کاتالوگ فروشگاه وب کروم مسدود می شود. متأسفانه، بررسی به ما اجازه نمی‌دهد بدون استثنا همه افزونه‌های مخرب را بگیریم، بنابراین برای افزایش حفاظت، تصمیم گرفته شد افزونه‌ها را در سطح API محدود کنیم. ایده اصلی این است که افزونه‌ها را با دسترسی نه به تمام ترافیک، بلکه فقط به داده‌هایی که برای اجرای عملکرد مورد نظر ضروری هستند، ارائه دهیم. به ویژه، برای مسدود کردن محتوا، دسترسی کامل افزونه به تمام اطلاعات محرمانه کاربر ضروری نیست.
- جایگزین پیشنهادی API اعلامی تمام کارهای مربوط به فیلتر کردن محتوای با کارایی بالا را انجام می دهد و فقط برای بارگذاری قوانین فیلترینگ به افزونه هایی نیاز دارد. این افزونه نمی تواند با ترافیک تداخل داشته باشد و داده های خصوصی کاربر غیرقابل تعرض باقی می ماند.
- گوگل بسیاری از نظرات مربوط به عدم عملکرد DeclarativeNetRequest API را در نظر گرفت و محدودیت تعداد قوانین فیلتر را از 30 هزار مورد پیشنهادی اولیه برای هر افزونه به حداکثر جهانی 150 هزار افزایش داد و همچنین قابلیت پویا را اضافه کرد. تغییر و اضافه کردن قوانین، حذف و جایگزینی هدرهای HTTP (مرجع، کوکی، تنظیم کوکی) و پارامترهای درخواست.
- برای شرکت ها، امکان استفاده از حالت مسدود کردن عملکرد webRequest API وجود دارد، زیرا خط مشی استفاده از افزونه ها توسط مدیری تعیین می شود که ویژگی های زیرساخت را درک کرده و از خطرات آن آگاه است. به عنوان مثال، API مشخص شده را می توان در شرکت ها برای ثبت جریان ترافیک کارکنان و ادغام با سیستم های داخلی استفاده کرد.
- هدف گوگل تضعیف یا سرکوب افزونه های مسدودکننده تبلیغات نیست، بلکه ایجاد مسدود کننده های تبلیغاتی ایمن تر و قدرتمندتر است.
- عدم تمایل به ترک حالت مسدود کردن عملکرد webRequest API به همراه NetRequest جدید اعلامی با تمایل به محدود کردن دسترسی افزونه ها به داده های محرمانه توضیح داده شده است. اگر webRequest API را همانطور که هست رها کنید، اکثر افزونه‌ها از NetRequest ایمن‌تر استفاده نمی‌کنند، زیرا هنگام انتخاب بین امنیت و عملکرد، اکثر توسعه‌دهندگان معمولاً عملکرد را انتخاب می‌کنند.
:
- توسط توسعه دهندگان افزونه انجام شده است تأثیر کلی ناچیز را بر عملکرد افزونه‌های مسدودکننده تبلیغات نشان می‌دهد (در طول آزمایش، عملکرد افزونه‌های مختلف مقایسه شد، اما بدون در نظر گرفتن سربار یک فرآیند اضافی که اجرای کنترل‌کننده‌ها را در حالت مسدود کردن هماهنگ می‌کند. webRequest API)؛
- متوقف کردن کامل پشتیبانی از API که به طور فعال در افزونه ها استفاده می شود عملی نیست. به جای حذف آن، می توانید یک مجوز جداگانه اضافه کنید و به شدت کفایت استفاده از آن را در افزونه ها کنترل کنید، که نویسندگان بسیاری از افزونه های محبوب را از بازسازی کامل محصولات خود نجات می دهد و از کاهش عملکرد جلوگیری می کند.
- برای کاهش هزینه های سربار، نمی توانید API را حذف کنید، اما آن را بر اساس مکانیسم Promise، شبیه به اجرای webRequest در فایرفاکس، بازسازی کنید.
- جایگزین پیشنهادی، DeclarativeNetRequest، تمام نیازهای توسعه‌دهندگان افزونه برای مسدود کردن تبلیغات و امنیت/حریم خصوصی را پوشش نمی‌دهد، زیرا کنترل کاملی بر درخواست‌های شبکه ارائه نمی‌کند، اجازه استفاده از الگوریتم‌های فیلتر سفارشی را نمی‌دهد و اجازه نمی‌دهد. استفاده از قوانین پیچیده که بسته به شرایط با یکدیگر همپوشانی دارند.
- با وضعیت فعلی DeclarativeNetRequest API، غیرممکن است که عملکرد موجود افزونه‌های uBlock Origin و uMatrix را بدون تغییر ایجاد کنیم، و همچنین توسعه بیشتر یک پورت NoScript برای Chrome را بی‌معنی می‌سازد.
- نگرانی در مورد حریم خصوصی دور از ذهن است، زیرا حالت فقط خواندنی و غیر مسدود کننده webRequest API در جای خود باقی مانده است و همچنان به افزونه های مخرب اجازه می دهد تا تمام ترافیک را کنترل کنند، اما امکان تداخل با آن را در fly (تغییر محتوا، قرار دادن تبلیغات خود، اجرای ماینرها و تجزیه و تحلیل محتویات فرم های ورودی می تواند پس از اتمام بارگیری صفحه استفاده شود).
- توسعه دهندگان مرورگر , и ، ساخته شده بر روی موتور Chromium، قصد دارند از حالت مسدود کردن webRequest در محصولات خود پشتیبانی کنند.
منبع: opennet.ru