سيغيّر بيان Google V3 كيفية عمل ملحقات Chrome التي تمنع الإعلانات: هل هو شلها أم أنها متعلقة بالأمان؟

يعد Google Chrome أكثر مستعرضات الويب الشائعة انتشارًا المتوفرة في السوق حاليًا ، حيث حصل على 62.7٪ من حصة استخدام المستعرض العالمي حتى مايو 2019 ، في حين احتل Safari من Apple المرتبة الثانية بنسبة 15.89٪ وموزيلا Firefox بنسبة 5.07٪. نظرًا لحصة الأسد ، فإن أصغر التغييرات التي يجريها Google Chrome لنظامه الأساسي ستؤثر في ملايين المستخدمين حول العالم. لذلك عندما أعلنت Google عن إصدار بيان الإضافات التالي في شكل Manifest V3 لـ Google Chrome Extensions ، عرفنا أننا كنا في بعض التغييرات الكبيرة ، خاصة عندما ظهر أن Google تقوم ببناء واجهة برمجة تطبيقات لحظر المحتوى داخل Chrome نفسه.

ما هو البيان V3؟

إذا كنت من مستخدمي Chrome النشطين ، فأنت بلا شك تستخدم بعض الإضافات. الإضافات عبارة عن برامج صغيرة مخصصة لتخصيص تجربة التصفح باستخدام واجهات برمجة التطبيقات التي يوفرها المتصفح ، مما يسمح للمستخدمين بتخصيص وظائف وسلوك يناسب احتياجاتهم وتفضيلاتهم الفردية. يتم توزيع هذه الملحقات بشكل رئيسي من خلال سوق Chrome الإلكتروني ، والذي يضم أكثر من 180،000 امتداد.

منذ أواخر العام الماضي ، تعمل Google على "Manifest V3" ، وهي مجموعة من التغييرات المقترحة على نظام ملحقات Chrome والتي يمكن تصنيفها على أنها "كسر التغييرات". كما تنص وثيقة المناقشة العامة لـ Manifest V3 ، فإن إصدار بيان الامتداد هو آلية لتقييد بعض القدرات على فئة معينة من الامتدادات. يمكن أن تكون هذه القيود في شكل إصدار الحد الأدنى أو إصدار الحد الأقصى. يسمح التقييد إلى أدنى إصدار بإتاحة واجهات برمجة التطبيقات أو الإمكانيات الأحدث للإضافات الأحدث فقط بينما يسمح التقييد على أقصى إصدار واضح بإلغاء واجهات برمجة التطبيقات أو الإمكانات القديمة تدريجيًا.

بعبارات أبسط ، يسمح إصدار البيان الجديد لـ Chrome بتقييد واجهات برمجة التطبيقات والميزات في هذا الإصدار الجديد من البيان ، من أجل إجبار مطوري الإضافات على الانتقال بعيدًا عن بعض واجهات برمجة التطبيقات القديمة بسبب تأثيرهم السلبي على تجربة المستخدم. من الناحية النظرية ، يجب أن يوفر تطبيق ملحق في Manifest V3 ضمانات أقوى من منظور الأمان والخصوصية والأداء.

على الرغم من وجود مجموعة واسعة من التغييرات الموضحة في البيان V3 ، إلا أن التغيير الأكثر إثارة للجدل يتعلق بقرار Google بالحد من قدرات الحظر الموجودة في واجهة برمجة تطبيقات chrome.webRequest الحالية (وتركيز واجهة برمجة التطبيقات على الملاحظة بدلاً من الحظر) ثم تقديم هذه الحجب قدرات من خلال chrome.declarativeNetRequest API جديدة. ألهم هذا التغيير بالذات المجتمع لأنه انتهى به الأمر إلى استهداف آلية حظر الإعلانات في ملحق حظر الإعلانات الشهير ، uBlock Origin ، ويؤثر بشكل مباشر على مستخدميه البالغ عددهم 10 ملايين +.

قبل أن نعالج هذه المشكلة ، دعنا نلقي نظرة على كيفية مقارنة واجهة برمجة تطبيقات webRequest بواجهة برمجة تطبيقاتاكتيفيتريكست .

واجهة برمجة تطبيقات طلب الويب وواجهة برمجة تطبيقات الطلب الصافي

الحاضر

يصف الوصف الرسمي لطلب الويب واجهة برمجة التطبيقات كما يلي:

 استخدم chrome.webRequest API لمراقبة وتحليل حركة المرور ولاعتراض أو حظر أو تعديل الطلبات أثناء الطيران. 

من خلال طلب الويب ، يرسل Chrome جميع البيانات الموجودة في طلب الشبكة إلى الملحق الذي يستمع إليها. لدى الإضافة فرصة لتقييم الطلب وإرشاد Chrome بشأن ما يجب القيام به مع الطلب: السماح به أو حظره أو إرساله مع بعض التعديلات.

تابع تسلسل الأحداث لفهم ما يحدث عندما تستخدم الإضافات واجهة برمجة تطبيقات طلب الويب. عندما ينقر مستخدم لديه ملحق "طلب ويب" على رابط ، يبلغ Chrome الامتداد بأنه تم تقديم طلب بيانات قبل أن يصل الطلب إلى الخادم. يمكن للإضافة اختيار تعديل الطلب في هذه المرحلة. يستجيب الخادم بعد ذلك ، لكن الاستجابة مرة أخرى تمر عبر الامتداد ، ويمكن أن يحدد الامتداد ما إذا كانت الاستجابة تحتاج إلى تعديل. أخيرًا ، يعرض Chrome الصفحة ويستطيع المستخدم عرض نتيجة إجراء النقرات الخاص به.

أثناء قيام Chrome بتسليم جميع البيانات الموجودة في طلب الشبكة ، يكون للإضافات التي تستخدم واجهة برمجة تطبيقات طلب الويب حق الوصول لقراءة وتعديل كل ما يفعله المستخدم على الويب. لذا ، بينما تستخدم حاصرات المحتوى مثل uBlock Origin بحكمة إمكانات واجهة برمجة التطبيقات هذه ، تدعي Google أن الإضافات الأخرى ذات النوايا الخبيثة قد أساءت استخدامها للوصول إلى المعلومات الشخصية للمستخدمين. وفقًا لـ Google ، استخدم 42٪ من الإضافات الضارة واجهة برمجة تطبيقات طلب الويب منذ كانون الثاني (يناير) 2018. تدعي Google أيضًا أن هناك "تكاليف أداء كبيرة" مرتبطة بواجهة برمجة التطبيقات لأن إصدار الحظر منه يتطلب عملية مستمرة وغالباً ما تكون طويلة غير متوافق بشكل أساسي مع العمليات "الكسولة".

باستخدام Manifest V3 ، تقترح Google تقييد واجهة برمجة التطبيقات هذه في نموذج الحظر الخاص بها. كبديل ، توفر Google واجهة برمجة التطبيقات للطلب الصافي التعريفي.

المستقبل

يصف الوصف الرسمي التعريفي للطلب الصافي واجهة برمجة التطبيقات كما يلي:

 يتم استخدام chrome.declarativeNetRequest API لحظر أو تعديل طلبات الشبكة عن طريق تحديد قواعد التعريف. 

مع الطلب الصافي التعريفي ، لا يحتاج Chrome إلى إرسال جميع المعلومات حول طلب إلى امتداد الاستماع. بدلاً من ذلك ، يسجّل الملحق القواعد باستخدام Chrome التي تخبر المتصفح مسبقًا بما يجب فعله في حالة مشاهدة أنواع معينة من الطلبات.

التمديد يحدد قواعده مسبقا. ثم يتم مطابقة طلب المستخدمين مع هذه القاعدة بواسطة المستعرض (وليس الملحق) ، ويتم تنفيذ الإجراء أيضًا بواسطة المستعرض ، ويتم تقديم الصفحة لاحقًا. تشير Google إلى أن هذا يسمح لهم بضمان الكفاءة حيث يمكنهم التحكم في الخوارزمية التي تحدد النتيجة ويمكنهم منع أو تعطيل القواعد غير الفعالة. كما يقدم ضمانات خصوصية أفضل للمستخدم النهائي حيث لا يتم عرض تفاصيل طلب الشبكة على الامتداد. نظرًا لأن العمليات المستمرة وطويلة الأمد لم تعد ضرورية (نظرًا لأن القواعد مسجلة مسبقًا) ، تدعي Google أن هذا النهج يجلب أيضًا تحسينات في الأداء ستجعل الإضافات أكثر قابلية للتطبيق على الأنظمة الأساسية المحدودة الموارد.

سيكون الطلب الصافي التعريفي متاحًا لكل من Manifest V2 (الحالي) و Manifest V3 ، ولكنه سيكون الطريقة الأساسية التي تسمح بها Google بتعديل طلبات الشبكة في Manifest V3.

الجدال

يبدو أن تغييرات Google تبدو منطقية حتى تسمع الجانب الآخر من القصة ، وخاصةً حاصرات الإعلانات. يُنظر إلى عملية ترحيل واجهة برمجة التطبيقات هذه على أنها طريقة Google لقتل حاصرات الإعلانات لأنها تغيّر بشكل أساسي الطريقة التي يعمل بها أحد حاصرات الإعلانات الأكثر شعبية. يرتبط هذا بـ "النظرية" التي مفادها أن غوغل مدفوعة تجاه هذا التغيير أكثر من منظور الأعمال التجارية أكثر من منظور أمان المستخدم. بعد كل شيء ، تعتمد Google اعتمادًا كبيرًا على الإعلان عن إيراداتها ، ويُنظر إلى حاصرات الإعلانات على أنها تهديد مباشر لعملاء Google على هذه الجبهة ، كما تم الكشف عنها من خلال ملف Alphabet's 2018 SEC Form 10-K (عبر The Register ):

قد تؤثر التقنيات الجديدة والحالية على قدرتنا على تخصيص الإعلانات و / أو يمكن أن تمنع الإعلانات عبر الإنترنت ، مما قد يضر أعمالنا.

تم تطوير التقنيات لجعل الإعلانات القابلة للتخصيص أكثر صعوبة أو منع عرض الإعلانات تمامًا ، كما أن بعض مزودي الخدمات عبر الإنترنت لديهم تقنيات متكاملة يمكن أن تضعف الوظائف الأساسية للإعلانات الرقمية الخارجية. تستمد معظم إيرادات Google من الرسوم المدفوعة لنا فيما يتعلق بعرض الإعلانات عبر الإنترنت. نتيجة لذلك ، يمكن أن تؤثر هذه التقنيات والأدوات سلبًا على نتائج التشغيل الخاصة بنا.

كان على Google أن تصدر بيانًا لمعالجة هذا الأمر ، مكررة موقفها من أن التغيير في مصلحة خصوصية المستخدم وليس هجومًا مباشرًا على مانع الإعلانات:

نحن لا نمنع تطوير برامج منع الإعلانات أو منع المستخدمين من حظر الإعلانات. بدلاً من ذلك ، نريد مساعدة المطورين ، بما في ذلك برامج حظر المحتوى ، على كتابة الإضافات بطريقة تحمي خصوصية المستخدمين.

يجب الإشارة إلى اثنين من أكثر أدوات منع الإعلانات شيوعًا المتوفرة على Google Chrome: uBlock Origin و Adblock Plus ، وكلاهما يتبعان طرقًا مختلفة لتحقيق نفس نتيجة حظر المحتوى. يعتمد uBlock Origin اعتمادًا كبيرًا على واجهة برمجة تطبيقات طلب الويب ، وقد فضل المجتمع هذا الامتداد على مر السنين. تعتمد Adblock Plus وغيرها من ملحقات حظر المحتوى أيضًا على جزء الحظر من "طلب الويب" ، وبالتالي فإن التغييرات في واجهة برمجة التطبيقات هذه ستؤثر في معظم حاصرات المحتوى على الأقل ببعض السعة.

دفع Google لإلغاء طلب الويب سيقتل أساسًا uBlock Origin بتنسيقه الحالي ، وهو أمر سيؤثر في الواقع على الكثير من المستخدمين. على الرغم من أن المستخدمين الذين لا يتمتعون بالولاء (وليس لديهم أي نية لإزعاج أنفسهم بشأن كيفية تحقيق كتلة الإعلانات) سيجدون حلولًا بديلة تأتي مع عيوبهم الخاصة ، سيكون من المستحيل على الموالين والمتحمسين التوصل إلى تصاميم جديدة لمحركات التصفية للتحايل على العديد من التقنيات التي ستظهرها مواقع الويب في نهاية المطاف لمحاربة حاصرات الإعلانات على واجهة برمجة التطبيقات هذه المحددة.

تم اقتراح "الطلب الصافي التعريفي" أيضًا ليكون محرك تصفية محدودًا إلى حد ما ، حيث كان من المخطط في البداية أن يكون هناك حد 30000 لقواعد التصفية الثابتة لكل ملحق (القواعد التي تم الإعلان عنها أثناء التثبيت) ؛ و 5000 قاعدة الحد على قواعد التصفية الحيوية لكل ملحق (القواعد التي يمكن إضافتها بعد التثبيت). سيتم تجاهل أي قواعد فائضة ، والتي تعد مشكلة صغيرة لأن EasyList لـ Adblock Plus بحد ذاته يحتوي على 70000 قاعدة ، في حين يمكن تكوين uBlock Origin للعمل مع أكثر من 100000 قاعدة. بعد رد الفعل المبدئي من المجتمع ، استجابت Google من خلال الوعد بتغيير حد القاعدة الثابتة من 30000 قاعدة لكل ملحق إلى الحد الأقصى العالمي البالغ 150.000 قاعدة. ولهذا الأمر تأثير جانبي يمنع المستخدمين من استخدام نصوص برمجية ثقيلة أخرى مع مانع الإعلانات ، لذلك سيتعين على المستخدمين التوفيق بين تفضيلاتهم.

بخلاف حد التصفية المحدود ، يمكن لـ صافي الطلب التعريفي إعادة التوجيه فقط إلى عناوين URL الثابتة ، لذلك لا يوجد دعم لمطابقة الأنماط. يعتمد uBlock Origin اعتمادًا كبيرًا على مطابقة الأنماط ، وقد ذكر مطور الامتداد أنه لا يمكن تعديل خوارزمية مطابقة الإضافة الخاصة به لتلبية متطلبات واجهات برمجة التطبيقات. قد تتطلب واجهة برمجة التطبيقات أيضًا تحديثًا كاملاً للامتداد لتحديث قائمة عوامل التصفية ببساطة ، والذي سيكون نشاطًا متكررًا للغاية بالنظر إلى التردد الذي يتم به تحديث قوائم التصفية هذه. بالطبع ، ستتوقف هذه التحديثات أيضًا على معايير وعمليات مراجعة امتداد Google.

من ناحية أخرى ، حافظت Google دائمًا على موقفها من أن هدفها الابتعاد عن طلب الويب هو من منظور الأمان ، لأن واجهة برمجة تطبيقات طلب الويب قوية للغاية في شكلها الحالي وتترك مجالًا واسعًا للغاية لسوء الاستخدام. ليس هذا الاعتداء نظريًا فحسب ، حيث ذكرت Google أن 42٪ من الإضافات الضارة قد أساءت استخدام واجهة برمجة التطبيقات هذه. لقد تم تصميم API Blocker الخاص بـ Apple Safari مثل "الطلب الصافي التعريفي" لأسباب مماثلة ، حيث توجد مساحة أقل لاستغلال مطور مارق. على طلب ويب nerfed ، ستظل طلبات الشبكة قابلة للملاحظة ، ولكنها ستحتاج إلى أذونات على المضيفين ذوي الصلة. مع Manifest V3 ، تتغير أذونات المضيف أيضًا بشكل كبير ولم يعد بالإمكان منحها بطريقة شاملة وقت التثبيت.

استخدمت Google أيضًا النفقات العامة للأداء كحافز للمحول. يحدث تقييم طلبات الشبكة في مؤشر ترابط جافا سكريبت الخاص بالملحق ، والذي قد يكون مكلفًا على الأداء. كدحض ، يشير مطور uBlock Origin إلى أن امتداده لا يتحمل أي عقوبة أداء كبيرة حتى عند وجود ما يصل إلى 140،000 مرشح ثابت لفرضه. تتم المطالبة بالتكاليف التي يتم استردادها بسهولة من خلال الموارد التي يتم منع تنزيلها من الخوادم البعيدة وبالتالي لا يتم معالجتها بواسطة المستعرض.

على الرغم من أن Google لا تستخدم هذا المنطق ، إلا أن هناك حجة واحدة ضد طلب الويب يمكن إجراؤها أيضًا من أجل الكفاءة في حظر الإعلانات. باستخدام "طلب الويب" ، إذا لم تستجب إحدى الإضافات في الوقت المناسب (بسبب التأخر أو الانهيار) ، فإن طلب معالجة الشبكة مسموح به بوضوح ، مما يتيح للإعلانات التسلل عبر مانع الإعلانات. الطلب الصافي التعريفي ، من ناحية أخرى ، لن يعاني من هذا العيب. بدلاً من ذلك ، ستنقل الإعلانات إذا لم يتم اكتشافها ضمن القواعد الثابتة ، وسيحدث ذلك كثيرًا.

خاتمة

من التوضيحات المذكورة أعلاه ، من الواضح أن "الطلب الصافي التعريفي" ليس استنساخًا لوظيفة 1: 1 لإمكانيات الحجب في واجهة برمجة تطبيقات طلب الويب ، ولا بد أن يكون مطورو الإضافات قد انزعجوا عندما يتعرقل عملهم الشاق بسبب هذه التغييرات. لكن منطق غوغل يحمل أهمية كبيرة أيضًا - طلب الويب قوي للغاية ، ويجب تقليص صلاحياتها في مصلحة مجتمع المستخدمين (التي تضم مستخدمين متوسطين إلى جانب المتحمسين).

كان يمكن أن يكون التحرك نحو الطلب الصافي التعريفي خطوة إيجابية للغاية في العلاقات العامة - بعد كل شيء ، تضيف Google واجهة برمجة التطبيقات (API) لحظر المحتوى المضمنة إلى Chrome! ولكن نظرًا لأن واجهة برمجة التطبيقات الجديدة تأتي مع قيودها الثقيلة ، يرى المجتمع بحق هذا قصاصة في الأجنحة. في عالم مثالي ، كان يتعين على Google استكشاف عمل حاصرات الإعلانات مثل uBlock Origin قبل دفع واجهة برمجة التطبيقات الجديدة. كما هو الآن ، يمكن أن تستخدم واجهة برمجة التطبيقات الجديدة مزيدًا من الاسترخاء على حدود قواعدها لاستيعاب السيناريوهات التي قد يرغب المستخدمون في استخدام ملحقين كثيف التصفية.

وفقًا لـ The Register ، سيتم توفير أول تصميمات مع تغييرات Manifest V3 اعتبارًا من يوليو 2019 وما بعده. نأمل أن تستوعب Google التعليقات التي تم تلقيها من مجتمع مطوري الإضافات بهذه البنيات.


شكر خاص لمحرر رئيس التحرير مشعل الرحمن لمساهماته ومساعدته!

تحرير: مقال غير صحيح عمل Adblock Plus إلى ذلك من API Net Net Netative. تم تعديل المقال وفقًا لذلك. سيتأثر Adblock Plus أيضًا بإزالة إمكانات حظر واجهة برمجة تطبيقات طلب الويب.