سيغير الإصدار Manifest V3 القادم لإضافات Google Chrome كيفية عمل أدوات حظر الإعلانات على Chrome. هل هذا هو الطريق الصحيح للمضي قدمًا لأدوات حظر الإعلانات وGoogle؟
جوجل كروم هو متصفح الويب الأكثر شيوعًا عبر الأنظمة الأساسية والمتوفر في السوق حاليًا، يستحوذ على 62.7% من حصة استخدام المتصفح عالميًا حتى مايو 2019، حيث جاء Safari من Apple في المرتبة الثانية بنسبة 15.89%، وMozilla’s Firefox بنسبة 5.07%. نظرًا لنصيب الأسد الذي يحظى به، فإن أصغر التغييرات التي يجريها Google Chrome على نظامه الأساسي تنتهي في النهاية بالتأثير على ملايين المستخدمين حول العالم. لذلك عندما أعلنت Google عن إصدار بيان الإضافات التالي في شكل Manifest V3 لملحقات Google Chrome، علمنا أننا كانت هناك بعض التغييرات الكبيرة، خاصة عندما تبين أن Google كانت تبني واجهة برمجة تطبيقات لحظر المحتوى داخل Chrome بحد ذاتها.
ما هو البيان V3؟
إذا كنت أحد مستخدمي Chrome النشطين، فلا شك أنك تستخدم بعض الإضافات. الملحقات عبارة عن برامج صغيرة تعمل على تخصيص تجربة التصفح باستخدام واجهات برمجة التطبيقات التي يوفرها المتصفحمما يسمح للمستخدمين بتخصيص الوظائف والسلوك بما يتناسب مع احتياجاتهم وتفضيلاتهم الفردية. يتم توزيع هذه الامتدادات بشكل رئيسي من خلال
منذ في أواخر العام الماضي، تعمل Google على "Manifest V3"، وهي مجموعة من التغييرات المقترحة على النظام الأساسي لإضافات Chrome والتي يمكن تصنيفها على أنها "تغييرات عاجلة". كما وثيقة المناقشة العامة للمانيفست V3 ينص إصدار بيان الامتداد على آلية لتقييد إمكانيات معينة لفئة معينة من الامتدادات. يمكن أن تكون هذه القيود في شكل إصدار الحد الأدنى أو الحد الأقصى للإصدار. يسمح التقييد بالحد الأدنى من الإصدار بأن تكون واجهات برمجة التطبيقات أو الإمكانات الأحدث متاحة فقط للإضافات الأحدث بينما يسمح التقييد بالإصدار الأقصى للبيان بواجهات برمجة التطبيقات أو الإمكانات الأقدم بشكل تدريجي إهمال.
بعبارات أبسط، يسمح إصدار البيان الجديد لمتصفح Chrome بتقييد واجهات برمجة التطبيقات والميزات على إصدار البيان الجديد هذا من أجل إجبار مطوري الإضافات على الابتعاد عن بعض واجهات برمجة التطبيقات الأقدم بسبب تأثيرها السلبي على المستخدم خبرة. من المفترض أن يوفر تطبيق الامتداد في Manifest V3 نظريًا ضمانات أقوى من منظور الأمان والخصوصية والأداء.
على الرغم من وجود مجموعة واسعة من التغييرات الموضحة في Manifest V3، فإن التغيير الأكثر إثارة للجدل يتعلق بقرار Google بالحد من قدرات الحظر الموجودة في الإصدار الحالي. chrome.webRequest واجهة برمجة التطبيقات (وتركيز واجهة برمجة التطبيقات حول المراقبة بدلاً من الحظر) ثم تقديم قدرات الحظر هذه من خلال واجهة برمجة تطبيقات جديدة chrome.declarativeNetRequest واجهة برمجة التطبيقات. هذا التغيير بالذات أثارت المجتمع حيث ينتهي الأمر باستهداف آلية حظر الإعلانات الخاصة بامتداد حظر الإعلانات الشهير، أصل uBlock، ويؤثر بشكل مباشر على أكثر من 10 مليون مستخدم.
قبل أن نتناول هذه المشكلة، دعونا نلقي نظرة على كيفية webRequest مقارنة API بـ DeclarativeNetRequest واجهة برمجة التطبيقات.
واجهة برمجة تطبيقات طلب الويب وواجهة برمجة تطبيقات طلب Net التعريفية
الحاضر
يصف الوصف الرسمي لطلب الويب واجهة برمجة التطبيقات (API) على النحو التالي:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
باستخدام طلب الويب، يرسل Chrome الجميع البيانات الموجودة في طلب الشبكة إلى الامتداد الذي يستمع إليها. تتاح للامتداد بعد ذلك فرصة لتقييم الطلب وإرشاد Chrome بشأن ما يجب فعله بالطلب: السماح به أو حظره أو إرساله مع بعض التعديلات.
تابع تسلسل الأحداث لفهم ما يحدث عندما تستخدم الملحقات Web Request API. عندما ينقر مستخدم لديه ملحق طلب ويب مثبت على رابط ما، يقوم Chrome بإبلاغ الامتداد بأنه قد تم إجراء طلب بيانات قبل أن يصل الطلب إلى الخادم. يمكن للامتداد اختيار تعديل الطلب في هذه المرحلة. يستجيب الخادم بعد ذلك، لكن الاستجابة تمر مرة أخرى عبر الامتداد، ويمكن للامتداد تحديد ما إذا كانت الاستجابة بحاجة إلى تعديل أم لا. يقوم Chrome بعد ذلك بعرض الصفحة في النهاية ويتمكن المستخدم من عرض نتيجة إجراء النقر الخاص به.
كما يسلم كروم كافة البيانات في طلب الشبكة، تتمتع الإضافات التي تستخدم Web Request API بإمكانية الوصول لقراءة وتعديل كل ما يفعله المستخدم على الويب. لذلك، بينما تستخدم أدوات حظر المحتوى مثل uBlock Origin بحكمة إمكانات واجهة برمجة التطبيقات هذه، فإن Google تدعي ذلك لقد أساءت الملحقات الأخرى ذات النوايا الخبيثة استخدام نفس الشيء للوصول إلى بيانات المستخدمين الشخصية معلومة. وفقًا لشركة Google، استخدمت 42% من الإضافات الضارة واجهة برمجة تطبيقات طلب الويب منذ يناير 2018. تدعي Google أيضًا أن هناك "تكاليف أداء كبيرة" مرتبطة بواجهة برمجة التطبيقات باعتبارها إصدار الحظر منه يتطلب عملية مستمرة وطويلة الأمد في كثير من الأحيان والتي لا تتوافق بشكل أساسي مع "الكسل". العمليات.
مع Manifest V3، تقترح Google تقييد واجهة برمجة التطبيقات هذه في نموذج الحظر الخاص بها. وكبديل، توفر Google واجهة برمجة تطبيقات Declarative Net Request.
المستقبل
يصف الوصف الرسمي لـ Declarative Net Request واجهة برمجة التطبيقات (API) على النحو التالي:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
باستخدام Declarative Net Request، لا يحتاج Chrome إلى إرسال جميع المعلومات المتعلقة بالطلب إلى ملحق الاستماع. وبدلاً من ذلك، تسجل الإضافة قواعد في Chrome تخبر المتصفح مسبقًا بما يجب فعله إذا تمت رؤية أنواع معينة من الطلبات.
يحدد الامتداد قواعده مسبقًا. تتم بعد ذلك مطابقة طلب المستخدمين مع هذه القاعدة بواسطة المتصفح (وليس الامتداد)، ويتم تنفيذ الإجراء أيضًا بواسطة المتصفح، ويتم عرض الصفحة لاحقًا. تذكر Google أن هذا يسمح لهم بضمان الكفاءة حيث يمكنهم التحكم في الخوارزمية التي تحدد النتيجة ويمكنهم منع أو تعطيل القواعد غير الفعالة. كما أنه يقدم ضمانات خصوصية أفضل للمستخدم النهائي حيث لا يتم عرض تفاصيل طلب الشبكة للامتداد. نظرًا لأن العمليات المستمرة وطويلة الأمد لم تعد ضرورية (نظرًا لأن القواعد مسجلة مسبقًا)، فإن Google تدعي ذلك يجلب هذا النهج أيضًا تحسينات في الأداء من شأنها أن تجعل الامتدادات أكثر قابلية للتطبيق بشكل ملحوظ في ظل الموارد المحدودة المنصات.
سيكون طلب Net Declarative متاحًا لكل من Manifest V2 (الحالي) وManifest V3، ولكنه سيكون الطريقة الأساسية التي ستسمح بها Google بتعديل طلبات الشبكة في Manifest V3.
الجدال
تبدو التغييرات التي أجرتها جوجل منطقية حتى تسمع الجانب الآخر من القصة، خاصة فيما يتعلق بأدوات حظر الإعلانات. يُنظر إلى عملية ترحيل واجهة برمجة التطبيقات هذه على أنها طريقة Google للتخلص من أدوات حظر الإعلانات لأنها تغير بشكل أساسي الطريقة التي يعمل بها أحد أدوات حظر الإعلانات الأكثر شيوعًا. يرتبط هذا بـ "النظرية" القائلة بأن Google لديها الدافع نحو هذا التغيير من منظور الأعمال أكثر من منظور أمان المستخدم. بعد كل شيء، تعتمد جوجل بشكل كبير على الإعلانات لتحقيق إيراداتها، ويُنظر إلى أدوات حظر الإعلانات على أنها تهديد مباشر لعملاء جوجل على هذه الجبهة، كما تم الكشف عنه من خلال نموذج 10-K الخاص بشركة Alphabet لعام 2018 SEC (عبر السجل):
يمكن أن تؤثر التقنيات الجديدة والحالية على قدرتنا على تخصيص الإعلانات و/أو قد تمنع الإعلانات عبر الإنترنت، مما قد يضر بأعمالنا.
لقد تم تطوير التقنيات لجعل الإعلانات القابلة للتخصيص أكثر صعوبة أو لمنع عرض الإعلانات تمامًا وبعض مقدمي الخدمة من الخدمات عبر الإنترنت تحتوي على تقنيات متكاملة قد تؤدي إلى إضعاف الوظائف الأساسية للخدمات الرقمية التابعة لجهات خارجية دعاية. معظم إيراداتنا من Google مستمدة من الرسوم المدفوعة لنا فيما يتعلق بعرض الإعلانات عبر الإنترنت. ونتيجة لذلك، فإن مثل هذه التقنيات والأدوات يمكن أن تؤثر سلبًا على نتائجنا التشغيلية.
كان على جوجل أن تفعل ذلك الافراج عن بيان لمعالجة هذه المشكلة، تكرر موقفها بأن التغيير يصب في مصلحة خصوصية المستخدم وليس هجومًا مباشرًا على أدوات حظر الإعلانات:
نحن لا نمنع تطوير أدوات حظر الإعلانات أو نمنع المستخدمين من حظر الإعلانات. وبدلاً من ذلك، نريد مساعدة المطورين، بما في ذلك أدوات حظر المحتوى، على كتابة الملحقات بطريقة تحمي خصوصية المستخدمين.
يجب الإشارة إلى اثنين من أكثر أدوات حظر الإعلانات شيوعًا المتوفرة على Google Chrome: أصل uBlock و Adblock زائدوكلاهما يتخذان أساليب مختلفة لتحقيق نفس النتيجة المتمثلة في حظر المحتوى. يعتمد uBlock Origin بشكل كبير على Web Request API، وقد فضل المجتمع هذا الامتداد على مر السنين. يعتمد Adblock Plus وغيره من ملحقات حظر المحتوى أيضًا على جزء الحظر من Web Request، لذا فإن التغييرات التي يتم إجراؤها على واجهة برمجة التطبيقات هذه ستؤثر في النهاية على معظم أدوات حظر المحتوى في بعض السعات على الأقل.
إن دفع Google لإيقاف طلب الويب سيؤدي بشكل أساسي إلى القضاء على uBlock Origin بتنسيقه الحالي، وهو الأمر الذي سيؤثر بالفعل على الكثير من المستخدمين. في حين أن المستخدمين الذين ليس لديهم ولاء (وليس لديهم أي نية لإزعاج أنفسهم بكيفية تحقيق الحظر الإعلاني) سيجدون حلولًا بديلة تأتي مع عيوبهم الخاصة، فسوف يصبح الأمر مستحيلًا للموالين والمتحمسين للتوصل إلى تصميمات جديدة لمحركات التصفية للتحايل على التقنيات المختلفة التي ستبتكرها مواقع الويب في النهاية لمكافحة أدوات حظر الإعلانات على واجهة برمجة التطبيقات المحددة هذه.
تم أيضًا اقتراح أن يكون Declarative Net Request بمثابة محرك تصفية محدود نوعًا ما المخطط لها في البداية أن يكون لديك حد أقصى يبلغ 30000 قاعدة لقواعد التصفية الثابتة لكل ملحق (القواعد التي تم الإعلان عنها أثناء التثبيت)؛ والحد الأقصى للقاعدة هو 5000 قاعدة لقواعد التصفية الديناميكية لكل ملحق (القواعد التي يمكن إضافتها بعد التثبيت). سيتم تجاهل أي قواعد زائدة، وهو ما يمثل مشكلة صغيرة لأن EasyList for Adblock Plus نفسه يحتوي على 70.000 قاعدة، بينما يمكن تكوين uBlock Origin ليعمل مع أكثر من 100.000 قاعدة. بعد ردود الفعل العنيفة في البداية من المجتمع، استجابت جوجل من خلال الوعد بتغيير حد القاعدة الثابتة من 30000 قاعدة لكل امتداد إلى الحد الأقصى العالمي البالغ 150000 قاعدة. وهذا له تأثير جانبي يتمثل في منع المستخدمين من استخدام نصوص برمجية أخرى ذات قواعد ثقيلة جنبًا إلى جنب مع أداة حظر الإعلانات، لذلك سيتعين على المستخدمين التوفيق بين تفضيلاتهم.
بخلاف حد التصفية المحدود، طلب صافي التعريفي يمكن فقط إعادة التوجيه إلى عناوين URL الثابتة، لذلك لا يوجد دعم متضمن لمطابقة الأنماط. يعتمد uBlock Origin بشكل كبير على مطابقة الأنماط ومطور الامتدادات وذكر أنه ليس من الممكن التحديثية خوارزمية مطابقة امتداده لتلبية متطلبات واجهات برمجة التطبيقات. ستتطلب واجهة برمجة التطبيقات (API) أيضًا تحديثًا كاملاً للامتداد لتحديث قائمة التصفية ببساطة، وهو ما قد يكون نشاطًا متكررًا جدًا بالنظر إلى التردد الذي يتم به تحديث قوائم التصفية هذه. وبطبيعة الحال، ستتوقف هذه التحديثات أيضًا على معايير وعمليات مراجعة الإضافات في Google.
من ناحية أخرى، حافظت Google دائمًا على موقفها المتمثل في أن نيتها الابتعاد عن طلب الويب هي من منظور أمني، نظرًا لأن واجهة برمجة تطبيقات طلب الويب قوية جدًا في شكلها الحالي وتترك مجالًا واسعًا جدًا لـ إساءة. إن إساءة الاستخدام هذه ليست نظرية فقط، حيث ذكرت Google أن 42% من الإضافات الضارة أساءت استخدام واجهة برمجة التطبيقات هذه. أبل سفاري واجهة برمجة تطبيقات حظر المحتوى تم تصميمه مثل Declarative Net Request لأسباب مماثلة، حيث أن هناك مساحة أقل يمكن للمطورين المارقين استغلالها. في طلب الويب الذي تم إنقاصه، ستظل طلبات الشبكة قابلة للملاحظة، ولكنها ستحتاج إلى أذونات من المضيفين ذوي الصلة. مع Manifest V3، تتغير أيضًا أذونات المضيف بشكل ملحوظ ولم يعد من الممكن منحها بطريقة شاملة في وقت التثبيت.
استخدمت Google أيضًا النفقات العامة للأداء كمحفز للتبديل. يتم تقييم طلبات الشبكة في سلسلة JavaScript الخاصة بالامتداد، الأمر الذي قد يكون مكلفًا على الأداء. كدحض، ذكر مطور uBlock Origin أن امتداده لا يتحمل أي عقوبة أداء كبيرة حتى عند وجود ما يصل إلى 140.000 مرشح ثابت للتنفيذ. يُزعم أنه يمكن استرداد التكاليف المتكبدة بسهولة من خلال الموارد التي تم منع تنزيلها من الخوادم البعيدة وبالتالي لا تتم معالجتها بواسطة المتصفح.
على الرغم من أن جوجل لا تستخدم هذا المنطق، إلا أنه يمكن أيضًا تقديم حجة واحدة ضد طلب الويب من أجل الكفاءة في حظر الإعلانات. باستخدام طلب الويب، إذا لم يستجب أحد الإضافات في الوقت المناسب (بسبب تأخر أو تعطل)، فسيتم السماح بطلب معالجة الشبكة بوضوح، مما يسمح للإعلانات بالمرور عبر أداة حظر الإعلانات. من ناحية أخرى، لن يعاني برنامج Declarative Net Request من هذا العيب. وبدلاً من ذلك، سيتم تمرير الإعلانات إذا لم يتم ضبطها ضمن القواعد الثابتة، وسيحدث هذا في أغلب الأحيان.
خاتمة
من التوضيحات أعلاه، من الواضح أن Declarative Net Request ليس نسخة وظيفية بنسبة 1:1 للحظر قدرات واجهة برمجة تطبيقات طلب الويب، ولا بد أن يشعر مطورو الإضافات بالانزعاج عندما يتعطل عملهم الشاق بسبب مثل هذه التغييرات. لكن منطق Google يحمل وزنًا أيضًا - فطلب الويب قوي جدًا، ويجب أن تكون صلاحياته كذلك تم تقليصها من أجل المصلحة الأكبر لمجتمع المستخدمين (الذي يتألف من المستخدمين العاديين بالإضافة إلى المتحمسين).
كان من الممكن أن يكون التحرك نحو Declarative Net Request خطوة إيجابية في العلاقات العامة أيضًا - فبعد كل شيء، تضيف Google واجهة برمجة تطبيقات مدمجة لحظر المحتوى إلى Chrome! ولكن نظرًا لأن واجهة برمجة التطبيقات الجديدة تأتي مع قيودها الثقيلة، فإن المجتمع يرى ذلك على أنه قصاصة من أجنحته. في عالم مثالي، كان ينبغي لشركة Google أن تستكشف طريقة عمل أدوات حظر الإعلانات مثل uBlock Origin قبل طرح واجهة برمجة التطبيقات الجديدة. في الوضع الحالي، يمكن لواجهة برمجة التطبيقات الجديدة استخدام مزيد من التخفيفات في حدود القواعد الخاصة بها لاستيعاب السيناريوهات التي قد يرغب فيها المستخدمون في استخدام امتدادين كثيفي المرشحات.
وفق السجل، ستكون الإصدارات الأولى مع تغييرات Manifest V3 متاحة اعتبارًا من يوليو 2019 فصاعدًا. نأمل أن تستوعب Google التعليقات الواردة من مجتمع مطوري الإضافات من خلال هذه الإصدارات.
شكر خاص لرئيس تحرير XDA مشعل الرحمن على مدخلاته ومساعدته!
تحرير: قامت المقالة بمساواة عمل Adblock Plus بشكل غير صحيح مع واجهة برمجة تطبيقات Declarative Net Request API. تم تعديل المادة وفقا لذلك. سيتأثر Adblock Plus أيضًا بإزالة إمكانيات الحظر الخاصة بـ Web Request API.