مطورو متصفح كروم وقف دعم وضع الحظر لتشغيل webRequest API، والذي يسمح لك بتغيير المحتوى المستلم بسرعة ويستخدم بشكل نشط في الوظائف الإضافية لمنع الإعلانات،
الحماية ضد البرامج الضارة والتصيد والتجسس على نشاط المستخدم والرقابة الأبوية والخصوصية.
دوافع جوجل:
- وضع حظر واجهة برمجة التطبيقات يؤدي إلى ارتفاع استهلاك الموارد.
عند استخدام واجهة برمجة التطبيقات هذه، يرسل المتصفح أولاً جميع البيانات الموجودة في طلب الشبكة إلى الوظيفة الإضافية، وتحللها الوظيفة الإضافية وتعيد نسخة معدلة لمزيد من المعالجة في المتصفح أو تصدر تعليمات الحظر. في هذه الحالة، لا تنشأ التأخيرات الرئيسية في مرحلة معالجة حركة المرور بواسطة الوظيفة الإضافية، ولكن بسبب التكاليف العامة لتنسيق تنفيذ الوظيفة الإضافية. على وجه الخصوص، تتطلب مثل هذه التلاعبات إطلاق عملية منفصلة لاستكمال، وكذلك استخدام IPC للتفاعل مع هذه العملية وآليات تسلسل البيانات؛ - تتحكم الوظيفة الإضافية بشكل كامل في كل حركة المرور عند مستوى منخفض، مما يفتح فرصًا كبيرة لإساءة الاستخدام وانتهاكات الخصوصية. وفقًا لإحصائيات Google، فإن 42% من جميع الوظائف الإضافية الضارة المكتشفة تستخدم واجهة برمجة التطبيقات webRequest. تجدر الإشارة إلى أنه يتم شهريًا حظر محاولات وضع ما متوسطه 1800 وظيفة إضافية ضارة في كتالوج سوق Chrome الإلكتروني. لسوء الحظ، لا تتيح لنا المراجعة اكتشاف جميع الوظائف الإضافية الضارة دون استثناء، لذا لتعزيز الحماية، تقرر تقييد الوظائف الإضافية على مستوى واجهة برمجة التطبيقات. الفكرة الرئيسية هي توفير الوظائف الإضافية مع إمكانية الوصول ليس إلى كل حركة المرور، ولكن فقط إلى البيانات الضرورية لتنفيذ الوظيفة المقصودة. على وجه الخصوص، لحظر المحتوى، ليس من الضروري منح الوظيفة الإضافية حق الوصول الكامل إلى جميع بيانات المستخدم السرية؛
- الاستبدال المقترح لواجهة برمجة التطبيقات التعريفية يعتني بجميع أعمال تصفية المحتوى عالي الأداء ويتطلب فقط الوظائف الإضافية لتحميل قواعد التصفية. لا يمكن للوظيفة الإضافية أن تتداخل مع حركة المرور وتظل بيانات المستخدم الخاصة مصونة؛
- أخذت Google في الاعتبار العديد من التعليقات المتعلقة بنقص وظائف واجهة برمجة التطبيقات DeclarativeNetRequest ووسعت الحد الأقصى لعدد قواعد التصفية من 30 ألفًا مقترحًا في البداية لكل ملحق إلى حد أقصى عالمي يبلغ 150 ألفًا، كما أضافت القدرة على التصفية ديناميكيًا تغيير القواعد وإضافتها، وإزالة واستبدال رؤوس HTTP (المُحيل، وملفات تعريف الارتباط، ومجموعة ملفات تعريف الارتباط) ومعلمات الطلب؛
- بالنسبة للمؤسسات، من الممكن استخدام وضع الحظر لتشغيل webRequest API، حيث يتم تحديد سياسة استخدام الوظائف الإضافية بواسطة مسؤول يفهم ميزات البنية التحتية ويدرك المخاطر. على سبيل المثال، يمكن استخدام واجهة برمجة التطبيقات المحددة في المؤسسات لتسجيل تدفقات حركة مرور الموظفين والتكامل مع الأنظمة الداخلية؛
- هدف Google ليس تقويض أو منع الوظائف الإضافية لحظر الإعلانات، ولكن تمكين إنشاء أدوات حظر إعلانات أكثر أمانًا وقوة؛
- يتم تفسير الإحجام عن ترك وضع الحظر لتشغيل webRequest API إلى جانب التصريح الجديد NetRequest بالرغبة في الحد من وصول الوظائف الإضافية إلى البيانات السرية. إذا تركت واجهة برمجة تطبيقات webRequest كما هي، فلن تستخدم معظم الإضافات واجهة NetRequest التعريفية الأكثر أمانًا، لأنه عند الاختيار بين الأمان والوظيفة، سيختار معظم المطورين عادةً الوظيفة.
:
- تم إجراؤها بواسطة مطوري الوظائف الإضافية يُظهر تأثيرًا إجماليًا ضئيلًا على أداء الوظائف الإضافية لحظر الإعلانات (أثناء الاختبار، تمت مقارنة أداء الوظائف الإضافية المختلفة، ولكن دون مراعاة الحمل الزائد للعملية الإضافية التي تنسق تنفيذ المعالجات في وضع الحظر واجهة برمجة التطبيقات لطلب الويب)؛
- ليس من العملي التوقف تمامًا عن دعم واجهة برمجة التطبيقات المستخدمة بشكل نشط في الوظائف الإضافية. بدلاً من إزالته، يمكنك إضافة إذن منفصل والتحكم الصارم في مدى كفاية استخدامه في الوظائف الإضافية، الأمر الذي من شأنه أن ينقذ مؤلفي العديد من الوظائف الإضافية الشائعة من إعادة صياغة منتجاتهم بالكامل وتجنب قطع الوظائف؛
- لتقليل التكاليف العامة، لا يمكنك حذف واجهة برمجة التطبيقات (API)، ولكن يمكنك إعادة إنشائها بناءً على آلية الوعد، على غرار تنفيذ webRequest في Firefox؛
- البديل المقترح، declarativeNetRequest، لا يغطي جميع احتياجات مطوري الوظائف الإضافية لحظر الإعلانات والأمان/الخصوصية، لأنه لا يوفر تحكمًا كاملاً في طلبات الشبكة، ولا يسمح باستخدام خوارزميات التصفية المخصصة، ولا يسمح استخدام القواعد المعقدة التي تتداخل مع بعضها البعض حسب الظروف؛
- مع الوضع الحالي لواجهة برمجة تطبيقات declarativeNetRequest، من المستحيل إعادة إنشاء الوظائف الحالية لإضافات uBlock Origin وuMatrix دون تغيير، كما يجعل التطوير الإضافي لمنفذ NoScript لمتصفح Chrome بلا جدوى؛
- تعتبر المخاوف المتعلقة بالخصوصية بعيدة المنال، حيث تم ترك وضع القراءة فقط وغير المحظور لواجهة برمجة تطبيقات webRequest في مكانه ولا يزال يسمح للوظائف الإضافية الضارة بالتحكم في كل حركة المرور، ولكنه لا يوفر القدرة على التدخل فيها على يطير (يمكن استخدام تغيير المحتوى ووضع إعلاناتك وتشغيل عمال المناجم وتحليل محتويات نماذج الإدخال بعد انتهاء تحميل الصفحة)؛
- مطوري المتصفح , и ، المبنية على محرك Chromium، تنوي ترك الدعم لوضع حظر webRequest في منتجاتها.
المصدر: opennet.ru