الخلاصة

  • يطلب RFC 8890 إعطاء المستخدمين النهائيين البشر الأولوية عندما تتعارض مصالحهم مع مصالح أطراف أخرى، لكنه لا يمنح IETF أو المشاركين الحكوميين أو خبراء المجتمع المدني أو الجماعات المستشارة حقاً تلقائياً في تمثيل الجميع.
  • وكيل المستخدم في RFC 9110 هو برنامج العميل الذي يبدأ طلب HTTP، وقد يقيّد قدرات الخدمة ويحمل إعداداً من دون حضور إنسان. ولا يثبت بذلك الهوية أو الموافقة الواعية أو التفويض الجماعي.
  • ينبغي تفكيك كلمة «يمثل» إلى إيصالات مستقلة: الفئة المتأثرة، وآلية المنفعة أو الضرر، وحدود التشاور، والاختيار والوضع الافتراضي، ونطاق الوسيط، والبدائل العملية، وكلفة الخروج، والنتيجة المرصودة.

قد يخرج طلب HTTP من الجهاز بينما صاحبه نائم. مهمة خلفية تزامن البيانات، أو زاحف يزور صفحة، أو تطبيق يحدث محتواه، أو جهاز منزلي يتصل بالخدمة. يسمي RFC 9110 البرنامج الذي يبدأ الطلب user agent، أي وكيل المستخدم، ويقول بوضوح إن الإنسان ليس مضطراً إلى التفاعل لحظة الإرسال.

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

يضع RFC 8890، الذي كتبه Mark Nottingham، حداً لهذا الانتقال. فالإنترنت ينبغي أن يكون للمستخدمين النهائيين وأن تعطى مصالحهم الأولوية، لكن الأولوية لا تعيّن متحدثاً عاماً باسمهم. إنها تكلف صاحب القرار بالبحث عن الأثر، ولا تسمح له بأن ينصب نفسه أصيلاً عن المتأثرين.

قد يكون الإنسان خارج الطلب تماماً

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

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

لذلك تبقى عبارة «المستخدمون يريدون» بلا مضمون حتى تحدد الفئة والدور والسياق. ويعترف RFC 8890 بقيود المؤسسة نفسها: لا تملك IETF معرفة فريدة بما ينفع الناس، ولا يصح أن تعمم تجربة المشاركين فيها. ولا يمثل المشارك المدعوم من حكومة تلقائياً كل سكان ولايته، ولا يحمل خبير المجتمع المدني بالضرورة تفويض المجتمع الأوسع. حتى التشاور الموجه يحسن الأدلة ولا يضمن التمثيل رسمياً.

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

قيمة الحاجز في ضيق سلطته

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

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

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

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

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

لا يسقط الضرر بخروج صاحبه من القاعة

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

يشرح RFC 7282 أن rough consensus يعالج المسائل لا أعداد الأشخاص. قد يكشف الهمهم عن حال القاعة ويفتح التحقيق، لكنه ليس اقتراعاً ينهي الاعتراض التقني. تبقى المسألة بعد ذهاب أول من طرحها.

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

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

التشاور يثبت السماع ولا يثبت التوكيل

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

يوثق RFC 8752 ورشة ESCAPE المتعلقة بالناشرين وتجميع المحتوى والويب المفتوح. يثبت التقرير أن عملية حدثت وأن آراء ومسائل عُرضت. ولا يثبت أن الحاضرين مثلوا كل ناشر أو معلن أو قارئ أو شخص تصفه الأنظمة.

يسجل إيصال التشاور الجهة المنظمة، والجماعة المقصودة، وطريقة الدعوة، واللغات وإتاحة المشاركة، وتركيبة المستجيبين، والفئات الغائبة، والمسائل، والردود، والتغييرات وأسباب عدم التغيير. ويحتفظ بما لم يُعرف بدلاً من تحويل الصمت إلى قبول.

الفصل بين «استمعنا إليه» و«فوضناه» يحفظ قيمة الخبير من دون تحميله وكالة جماعية خيالية، ويحفظ الغائب كأصيل لم يصدر موافقة.

لا يصبح البديل مخرجاً إلا بعد نجاح الانتقال

يرى RFC 8890 أن تعدد تطبيقات وكيل المستخدم يمكن أن يخفض كلفة التبديل ويخلق حافزاً لمراعاة الناس. ويحلل RFC 9518 switching بوصفه قيداً على المركزية. لكن ذلك يتطلب بدائل موجودة بالفعل وكلفة استبدال مقبولة من حيث الوقت والموارد والخبرة والتنسيق والوظائف المفقودة.

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

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

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

سلطة الوسيط تحتاج إلى فعل إيجابي ونهاية واضحة

يقترح RFC 9518 أن تأتي مشاركة الطرف الثالث بعد فعل إيجابي من طرف أصيل واحد على الأقل، وأن يقتصر الرصد أو التحكم على ما تحتاجه الوظيفة. وهو RFC معلوماتي من المسار المستقل يمثل آراء Nottingham، لا توافق IETF ولا قانوناً عاماً.

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

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

اسم Nottingham يقع تحت ثلاث عبارات سلطة مختلفة

يسمي RFC 8890 Mark Nottingham مؤلفاً. وهو RFC معلوماتي في مسار IAB يمثل توافق IAB عند النشر، وليس Internet Standard ولا توافق IETF. ويصف شرح Nottingham في 2020 الوثيقة بأنها إرشاد للإقناع لا أمراً ملزماً.

أما RFC 9110 فهو في مسار معايير IETF، وحرره Roy Fielding وMark Nottingham وJulian Reschke. تعريف وكيل المستخدم فيه جزء من عمل جماعي طويل على HTTP، ولا تمنح صفة المحرر سيطرة على التطبيقات.

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

يوثق ملف IETF Datatracker مساهمات Nottingham في HTTP وURL وRSS/Atom وQUIC وأدواره في وقت المراجعة. ولا يثبت ملكية HTTP أو الويب، ولا السيطرة على سياسة المتصفح أو نتائج IETF، ولا تفويض المستخدمين.

استبدال كلمة مريحة بسلسلة أدلة

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

لا يرث إيصال سلطة الإيصال المجاور. الإعداد الفاعل لا يثبت تفضيلاً واعياً. والتشاور لا يثبت تفويضاً. واسم منتج بديل لا يثبت خروجاً عملياً. والمنفعة لفئة لا تثبت رفاه الجميع.

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

المصادر