جوجل كروم
لعدة أشهر حتى الآن أعلنت Google عن نواياها لإزالة أدوات حظر الإعلانات من متصفح الويب Chrome الخاص بها.، هذا مع المبدأ التوجيهي أن الحاصرات ستواجه مشاكل في التغييرات التي تم إدخالها في Manifest V3.
حتى لو جوجل جادل أيضا أن بعض مقدمي الخدمات على الإنترنت تقنيات مدمجة يمكن أن تعرض للخطر الميزات الأساسية للإعلان الرقمي من أطراف ثالثة.
حاول مطورو Chrome تبرير إيقاف دعم وضع الحظر من واجهة برمجة تطبيقات webRequest ، يسمح لك بتغيير المحتوى المستلم بسرعة ويستخدم بنشاط في الوظائف الإضافية لحظر الإعلانات والحماية من البرامج الضارة والتصيد الاحتيالي والتجسس على المستخدمين والرقابة الأبوية والخصوصية.
يؤدي وضع الحظر الخاص بواجهة برمجة تطبيقات webRequest إلى زيادة استهلاك الموارد.
عند استخدام واجهة برمجة التطبيقات هذه ، يرسل المستعرض أولاً جميع البيانات الواردة في طلب الشبكة إلى المكون الإضافي ، ويقوم المكون الإضافي بتوزيعها وإرجاع نسخة معدلة لمزيد من المعالجة في المتصفح أو مشاكل تتعلق بإرشادات الحظر.
في هذه الحالة ، لا تنشأ التأخيرات الرئيسية في مرحلة معالجة حركة المرور باستخدام مكون إضافي ، ولكن بسبب الحمل الزائد لتنسيق تنفيذ المكون الإضافي.
على وجه الخصوص ، تتطلب مثل هذه التلاعبات إطلاقًا لاستكمال عملية منفصلة ، فضلاً عن استخدام IPC للتفاعل مع هذه العملية وآليات تسلسل البيانات.
تتحكم الوظيفة الإضافية بشكل كامل في كل حركة المرور على مستوى منخفض ، مما يفتح فرصًا كبيرة لإساءة الاستخدام وانتهاكات الخصوصية.
لا تزال Google تؤيد إزالة API
وفقًا لإحصاءات Google ، في 42٪ من جميع المكونات الإضافية الضارة التي تم اكتشافها ، تم استخدام webRequest API.
لسوء الحظ، لا يسمح التصحيح باعتراض أي من المكونات الإضافية الضارة ، لتحسين الحماية ، تقرر تقييد المكونات الإضافية على مستوى واجهة برمجة التطبيقات.
الفكرة الأساسية هي توفير المكونات الإضافية ذات الوصول المحدود إلى كل حركة المرور، إن لم يكن فقط للبيانات الضرورية لتنفيذ الوظيفة المتصورة.
على وجه الخصوص ، لحظر المحتوى ، ليس من الضروري تزويد المكون الإضافي بالوصول الكامل إلى جميع بيانات المستخدم السرية.
التصريحي المقترح لاستبدال واجهة برمجة التطبيقات التابعة لـ DisplayativeNetRequest تهتم بكل العمل نظام تصفية المحتوى عالي الأداء ولا يتطلب سوى تنزيل المكونات الإضافية لقواعد التصفية. علاوة على ذلك ، لا يمكن أن تتداخل الإضافة مع حركة المرور وتظل بيانات المستخدم الخاصة مصونة.
أخذت Google في الاعتبار العديد من التعليقات المتعلقة بنقص وظائف واجهة برمجة التطبيقات ، وطبقاً لطلبات الشبكة ومدد الحد الأقصى لعدد قواعد التصفية من 30,000 المقترحة أصلاً لكل امتداد إلى حد أقصى عالمي يبلغ 150,000 وإضافة أيضًا القدرة على تعديل القواعد وإضافتها ديناميكيًا وإزالة واستبدال رؤوس HTTP (الإحالة ، ملف تعريف الارتباط ، مجموعة ملفات تعريف الارتباط) وطلب المعلمات.
المطورون ليسوا مقتنعين تمامًا
يُظهر الاختبار من قبل مطوري الإضافات أن أداء الوظائف الإضافية لحظر الإعلانات ضئيل مقارنة بالخلفية العامة (عند الاختبار ، مقارنة أداء الوظائف الإضافية المختلفة ، ولكن دون مراعاة النفقات العامة لعملية إضافية تنسق تنفيذ المعالجات في وضع الحظر لواجهة برمجة تطبيقات webRequest).
ليس من العملي التوقف تمامًا عن دعم واجهة برمجة التطبيقات ، تستخدم بنشاط في المكونات الإضافية. بدلاً من إزالته ، يجادل المطورون بأنه يمكن إضافة قرار منفصل والتحكم فيه بإحكام من أجل مدى كفاية استخدامه في الإضافات ، مما سيوفر مؤلفي العديد من المكونات الإضافية الشائعة من المعالجة الكاملة لمنتجاتهم ويمنع التخفيضات في الوظائف.
لا يغطي البديل المُقترَح لـ AdvertisativeNetRequest جميع احتياجات مطوري المكونات الإضافية لحظر الإعلانات وضمان الأمان / الخصوصية ، حيث إنه لا يوفر تحكمًا كاملاً في طلبات الشبكة ، ولا يسمح باستخدام خوارزميات التصفية الخاصة ولا يسمح باستخدام قواعد معقدة تتداخل مع بعضها البعض حسب الظروف.
مصدر: https://security.googleblog.com/