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

وكيل متصفح على حاسوب محمول ينتظر التأكيد خلف حدود أمان مرئية

يستحق WebBrain الاختبار الآن لأن أحدث إصداراته، 42.4.3، صدر في 25 أكتوبر مع مجموعة تغييرات توضّح اتجاه المشروع بدرجة لافتة. حدّث الإصدار حزمة MCP SDK وتبعية Hono، وجعل نموذج Compass VLD Tiny v5 الصغير هو النموذج الافتراضي داخل المتصفح، وأضاف مؤشر نشاط مرئيًا في اللوحة الجانبية، وأصلح رفع الملفات في نافذة إنشاء المنشورات على X، وواصل العمل على الاختيار التلقائي بين أوضاع Ask وAct وDev. إنه ليس مجرد روبوت دردشة آخر للمتصفح. فالمشروع المثير للاهتمام هو نموذج الصلاحيات المحيط بوكيل متصفح يستطيع العمل داخل علامات التبويب المفتوحة للمستخدم.

النصيحة العملية هي تجربة WebBrain أولًا بوصفه اختبارًا لحدود الصلاحيات: ثبّته في ملف تعريف متصفح مخصّص للتجربة، وابدأ بوضع Ask مع نموذج محلي، ثم اختبر وضع Act فقط على حسابات ومواقع لا تترتب على النقرة الخاطئة فيها أي تكلفة. يجعل تصميمه مفتوح المصدر سطح التحكم قابلًا للفحص، لكن صلاحيات الامتداد تظل حقيقية حتى عندما يكون النموذج محليًا.

ما الذي تغيّر في WebBrain 42.4.3

صدر الإصدار 42.4.3 في 25 أكتوبر. وسجل التغييرات فيه مزيج من أعمال الصيانة وتطوير المنتج، وليس ميزة رئيسية واحدة.

حدّث المشروع Hono إلى الإصدار 4.13.13 وModel Context Protocol SDK إلى الإصدار 1.32.0. وتهم هذه التحديثات لأن وكيل المتصفح ليس امتداد واجهة أمامية فحسب؛ فهو يضم أيضًا محوّلات لمزوّدي الخدمة، وخادم MCP اختياريًا، وجسورًا محلية، ومجموعة متنامية من عمليات التكامل. لا تثبت تحديثات التبعيات أن النظام بأكمله آمن، لكنها تقلّل مصدرًا واضحًا من مصادر الشيفرة القديمة في مشروع يتعامل مع بيانات المتصفح واستدعاءات الأدوات.

أعاد الإصدار أيضًا تسمية واجهة مزوّد الخدمة المُدار إلى Compass وCompass Light، وفعّل رفع الوسائط في الرسائل المباشرة على Instagram، وأضاف مؤشر نشاط عصبيًا إلى اللوحة الجانبية، وغيّر النموذج الافتراضي داخل المتصفح إلى Compass VLD Tiny v5. ويكتسب تغيير النموذج أهمية في قصة المشروع التي تضع التشغيل المحلي أولًا. يستطيع WebBrain استخدام خادم محلي مثل llama.cpp، أو Ollama، أو vLLM، أو LM Studio، أو Jan، أو LocalAI، أو نقطة نهاية أخرى متوافقة مع OpenAI. كما يستطيع استخدام مزوّدي الخدمات السحابية، ومنهم OpenAI وAnthropic وOpenRouter.

تغيّر هذه المرونة سؤال التقييم. فالسؤال «هل يعمل الوكيل؟» واسع أكثر من اللازم. الاختبار الأفضل هو: أي محتوى يذهب إلى أي نموذج، وما إجراءات المتصفح المتاحة في كل وضع، وما التأكيد المطلوب قبل أن يغيّر أي إجراء حالةً ما؟

الأوضاع الثلاثة هي أهم ميزة في المنتج

يصف مستودع WebBrain ثلاثة أوضاع للتشغيل:

  • Ask للقراءة فقط. يستطيع الوكيل قراءة الصفحة الحالية، والإجابة عن الأسئلة، واستخراج المعلومات، وجلب عناوين URL، لكنه لا يستطيع النقر أو الكتابة أو التنقل بوصفها إجراءات.
  • Act يتيح التفاعل مع المتصفح، بما في ذلك النقر والكتابة والتنقل ورفع الملفات وتنزيلها وملء النماذج.
  • Dev يضيف إمكانات لتصحيح الصفحات، مثل فحص المصدر والأنماط ووحدة التحكم والشبكة، إلى جانب تعديلات قابلة للعكس على الصفحة.

يمكن للامتداد اختيار الوضع تلقائيًا، لكنه يدعم أيضًا الأوامر الصريحة /ask و/act و/dev. وهذا التفريق أكثر فائدة من تسمية عامة مثل «الوضع الآمن»، لأنه يربط قدرات النموذج بنيّة المستخدم. فطلب تلخيص لا ينبغي أن يمنح بصمت الأدوات نفسها التي يمنحها طلب إرسال نموذج.

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

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

تذكر وثائق WebBrain الأمنية أنه يغلّف النتائج المستمدة من الصفحة باعتبارها محتوى غير موثوق، ويفرض التحقق من الصلاحيات والمصدر قبل تشغيل الأدوات ذات العواقب، كما يُبقي وضع Ask للقراءة فقط. وتصف الوثائق أيضاً طبقات للتأكيد والتحقق تخص بيانات الاعتماد، والتنزيلات، وتعديلات واجهات API، والإرسال المكرر، ومربعات الحوار، وادعاءات إتمام المهمة. هذه مؤشرات مهمة على أن المشروع يفكر في أنماط الفشل، لا في عرض النقرات الناجحة فحسب.

لماذا يكون المتصفح المسجّل الدخول مفيداً وخطيراً في آن واحد

تحتاج خدمة الأتمتة عادةً، عندما تعمل دون واجهة، إلى ملف متصفح خاص بها، وإعداد جلسة، والتعامل مع ملفات تعريف الارتباط، أو تكامل مع واجهة API. يتخذ WebBrain مساراً مختلفاً: فهو يعمل إلى جانب المتصفح الذي تستخدمه أصلاً. وهذا يعني أن المهمة يمكنها الوصول إلى صفحات محمية بتسجيل الدخول من دون مطالبتك بتصدير ملفات تعريف الارتباط أو بناء تكامل منفصل.

الفائدة واضحة. يستطيع الوكيل قراءة لوحة معلومات خاصة، ومقارنة العناصر داخل حساب مسجّل الدخول، ونقل المعلومات بين تطبيقات الويب، أو ملء نموذج داخلي متكرر. كما يمكنه التعامل مع مواقع لا توفر واجهة API عامة، ومع واجهات تعتمد بكثافة على JavaScript ولا تتصرف مثل مستندات HTTP العادية.

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

يوثّق النموذج الأمني للمستودع صلاحيات متصفح واسعة في إصدار Chrome، بما في ذلك <all_urls> وdebugger، إلى جانب التنزيلات، والوصول إلى علامات التبويب، والبرمجة النصية، وإمكانات أخرى توفرها الإضافات. ويقول المشروع إن الوصول إلى أداة التصحيح debugger مقيّد بالتشغيل النشط، وإن أدوات الإجراءات لا تزال تمر عبر فحوص الصلاحيات والمصدر. تقلل هذه الإجراءات الوقائية احتمال تنفيذ إجراء من دون مراجعة، لكنها لا تجعل الإضافة مكافئة لأداة تلخيص صفحات للقراءة فقط.

لهذا السبب، لا ينبغي التعامل مع عبارة «نموذج محلي» باعتبارها جواباً كاملاً عن الخصوصية. قد يُبقي النموذج المحلي نصوص الصفحات ولقطات الشاشة داخل الجهاز، وهذه فائدة كبيرة. لكنه لا يستطيع منع الوكيل المحلي من إجراء نقرة خاطئة داخل المتصفح. فخصوصية الاستدلال وسلامة الإجراء خاصيتان منفصلتان.

المسار المحلي أولاً عملي، لكنه يتطلب بعض الإعداد

يسرد الملف التمهيدي للمشروع عدة طرق لربط نموذج. ويمكن استخدام خادم محلي متوافق مع OpenAI عبر أمر مثل:

llama-server -m your-model.gguf --port 8080

أو يمكن إتاحة نقطة نهاية Ollama عبر عنوانها المتوافق مع OpenAI. ويوفر WebBrain Companion، وهو تطبيق سطح المكتب المنفصل التابع للمشروع، مساراً محلياً آخر. نُشر الإصدار 0.1.2 منه في 24 أكتوبر لأنظمة Windows وmacOS وLinux. ويقدّم التطبيق المصاحب نقطة نهاية متوافقة مع OpenAI على http://127.0.0.1:8327/v1، كما يمكنه تشغيل نموذج Bonsai المحلي الاختياري.

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

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

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

لذلك يُفضَّل أن تبدأ باستخدام نموذج نصي محلي على موقع غير حساس. اختبر قدرة الوكيل على الإجابة عن أسئلة الصفحة في وضع Ask قبل تفعيل أي وضع ينفّذ إجراءات. ثم تحقّق من نقطة النهاية التي تستقبل الطلبات، وما إذا كانت لقطات الشاشة تُرسل إلى مزود منفصل.

حقن التعليمات ليس احتمالًا نظريًا هامشيًا

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

يصف نموذج WebBrain الأمني عدة وسائل دفاع، منها تغليف المحتوى غير الموثوق، وبوابة للقدرات بحسب أصل الموقع، وفرض حدود على نتائج الأدوات، وفصل أوضاع Ask وAct وDev، وطلب التأكيد على الأدوات المسجّلة في الصفحة، واكتشاف الحلقات، والتعامل مع الأسرار، والحماية من عمليات الإرسال المكررة. وتوضح الوثائق أيضًا ما لا توفر له حماية، ومن ذلك مزود نموذج اللغة نفسه، وبعض المخاوف المتعلقة ببصمة المتصفح وقنوات التوقيت.

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

الاختبار العملي الأفضل ليس: «هل يستطيع مقاومة اختبار معياري للتعليمات؟» بل: هل يستطيع المستخدم رؤية الانتقال من القراءة إلى التنفيذ وفهمه؟ جرّب صفحة مؤقتة تتضمن نصًا يطلب من الوكيل تجاهل مهمته الأصلية. تحقّق من أن وضع Ask يظل عاجزًا عن النقر. ثم استخدم وضع Act، وتأكد من أن الإضافة تحدد أصل الموقع المستهدف، وتعرض خطة أو خطوة موافقة حيثما كان ذلك مهيأً، وتتوقف عندما تتغير الصفحة على نحو غير متوقع.

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

ما الذي أصبح جاهزًا للتجربة

يصلح WebBrain لأربعة أنواع من التجارب.

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

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

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

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

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

أسئلة الترخيص وسلسلة التوريد

يُرخَّص WebBrain بموجب GPL-3.0-or-later. ويوضح المستودع أن هذا الاختيار مرتبط بكون الإضافة الموزعة تجمع وتدمج بيئة تشغيل Xapian/libzim WebAssembly المرخَّصة بموجب GPL.

بالنسبة إلى المستخدمين، النتيجة الأساسية واضحة: المشروع مفتوح للدراسة والتعديل وإعادة التوزيع وفق شروط GPL. أما المؤسسات التي تخطط لدمج أجزاء منه أو إعادة توزيعها، فعليها مراجعة الترخيص الكامل والمكوّنات المضمّنة قبل الإطلاق. فعبارة «مفتوح المصدر» لا تغني عن التحقق من الالتزامات المرتبطة بنموذج توزيع محدد.

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

تنص سياسة WebBrain الأمنية على عدم وجود تحذيرات أمنية منشورة، وتوجّه الباحثين إلى الإبلاغ الخاص عن الثغرات. هذه معلومة مفيدة عن آلية الإفصاح، لكن لا ينبغي تفسيرها على أنها شهادة أمان شاملة. فالإضافة التي تتغير بنشاط وتمتلك قدرات واسعة داخل المتصفح لا تزال تحتاج إلى التحديثات المعتادة، وعزل الملفات الشخصية، والنسخ الاحتياطية، وممارسات الحد الأدنى من الصلاحيات.

خطة اختبار أكثر أمانًا

يمكن تقييم المشروع عبر سلسلة قصيرة من الخطوات:

  1. أنشئ ملفًا شخصيًا منفصلًا للمتصفح، من دون حساباتك الأساسية أو وسائل الدفع المحفوظة أو الجلسات طويلة الأمد.
  2. ثبّت الإصدار الحالي أو ابنِ الإضافة من المستودع. سجّل النسخة وراجع أذونات الإضافة.
  3. اضبط وضع Ask باستخدام نموذج محلي إذا كانت الخصوصية هي الأولوية. اطلب الاستخراج والتلخيص قبل اختبار تنفيذ الأفعال.
  4. اختبر نموذجًا غير ضار عمدًا على موقع مخصّص للتجارب. تأكد من أن وضع Act يتطلب تفعيلًا صريحًا، وأن زر الإيقاف يقطع التنفيذ.
  5. أضف مزودًا سحابيًا واحدًا فقط بعد التحقق من نوع نصوص الصفحات ولقطات الشاشة وآثار التنفيذ ونتائج الأدوات التي تصله.
  6. اختبر صفحة تتضمن تعليمات مضللة، وتحقق من أن الوكيل يتعامل معها باعتبارها محتوى الصفحة لا تفويضًا من المستخدم.
  7. جرّب رفع الملفات وتنزيلها والتنقل بشكل منفصل. فهذه قدرات مختلفة، ولكل منها تبعات مختلفة.
  8. أبقِ ملف الاختبار معزولًا إلى أن تصبح مطالبات الوكيل وإشعارات الأذونات وسلوكه عند الفشل مألوفة لديك.

النتيجة المفيدة ليست بالضرورة إكمال سير العمل. فإذا توقف الوكيل لأنه لم يتمكن من إثبات تحقق حالة لاحقة آمنة، فقد تكون تلك نتيجة أفضل من إرسال واثق لم يُتحقق منه.

الزاوية الحقيقية لمصدره المفتوح

لا تكمن أهمية WebBrain في أنه يجعل أتمتة المتصفح ممكنة؛ فأتمتة المتصفح موجودة منذ سنوات. تكمن الزاوية المفتوحة المصدر في أنه يكشف الحد الفاصل بين استدلال النموذج وسلطة المتصفح باعتباره شيئًا يمكن للمستخدمين والمطورين فحصه.

يضع المشروع عدة قرارات تصميمية أمام العامة: وضع القراءة فقط افتراضيًا، وأوضاع تنفيذ صريحة، والاختيار بين مزود محلي وسحابي، والاختزال الدلالي للصفحات، وأذونات تراعي المصدر، وترخيص GPL المرتبط بإضافة متصفح موزعة. يمكن مناقشة هذه القرارات وتدقيقها وتحسينها. كما أنها تجعل القيود أسهل رؤية.

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

ابدأ بوضع Ask. استخدم نموذجًا محليًا إذا كانت الصفحة خاصة. أبقِ وضعي Act وDev داخل ملف شخصي مخصّص للتجارب إلى أن يصبح مسار الأذونات مفهومًا. وتعامل مع كل نقرة ناجحة بوصفها دليلًا على الموقع الحالي والإصدار الحالي، لا برهانًا على حل جميع مشكلات فئة وكلاء المتصفح.