إقرار الوصول الموقّع لا يثبت ما سيفعله الروبوت لاحقاً

الخلاصة

• تصف النسخة 00 من terms.txt فحوصاً ينفذها موقع الأصل قبل التسليم: توقيع الطلب، والغرض المعلن، وتفويض المستخدم، وقسيمة الدفع عند اشتراطها.
• ينسب التوقيع الإقرار إلى مفتاح، ويسجل Access-Receipt عملية تسليم محددة؛ لكن أياً منهما لا يثبت صدق الغرض أو يفرض طريقة استعمال المحتوى لاحقاً.
• يقترح Daniel Kade سجل التزامات وصول يفصل بين الإنفاذ قبل التسليم، والتدقيق بعده، والواجب التعاقدي. هذا اقتراح تحريري وليس مطلباً من IETF.

ما يمكن لجهة الأصل أن تمنعه فعلاً

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

تضع النسخة 00 من terms.txt القرار عند الأصل. تنشر الجهة ملفاً في /.well-known/terms.txt وفق نمط المعرّفات المعروفة، وتحدد لكل مسار وغرض ما إذا كان الوصول مسموحاً أو مدفوعاً أو مرفوضاً. ويمكنها وضع سقف لإعادة إنتاج المادة أو اشتراط تفويض من المستخدم.

يستخدم العميل الآلي مسودة منفصلة صادرة عن مجموعة عمل Web Bot Auth وآلية تواقيع رسائل HTTP. يضع غرضه ومستوى الاستخدام في Access-Intent ويغطيهما بالتوقيع مع معرّف الهدف الكامل. وإذا نصت الشروط على ذلك، يغطي التوقيع أيضاً تفويض المستخدم وقسيمة دفع أحادية الاستعمال.

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

وعند الرفض، تستخدم المسودة الرمز 403 مع Problem Details لتحديد السبب: توقيع غير صالح، أو إعادة إرسال، أو غرض مرفوض، أو استعمال يتجاوز السقف، أو تفويض ناقص، أو دفع مطلوب. لا تعيد تعريف 402 المحجوز في دلالات HTTP، ولا تستخدم 401 من دون WWW-Authenticate. قرار الرفض قرار لهذا الأصل، لا حكماً عاماً على الروبوت في الويب كله.

إثبات حامل المفتاح ليس إثبات الشركة

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

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

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

ثلاث طبقات من الدليل

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

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

تظهر دقة هذا الحد في التخزين المؤقت. إذا أعاد وسيط تقديم استجابة مخزنة لطالب ثانٍ، سيظل الإيصال مربوطاً بتوقيع الطلب الأول، ولن يكون الأصل قد سجل التسليم الثاني. لذلك تفرض المسودة Cache-Control: no-store على الاستجابات ذات الإيصال، مستندة إلى قواعد التخزين المؤقت في HTTP. تنخفض الكفاءة مقابل إسناد كل طلب؛ ولا يجوز الادعاء بكليهما من دون تصميم جديد.

وجودها في Datatracker لا يعني اعتمادها

يعرّف سجل Datatracker الوثيقة كمسودة إنترنت فردية بلا مسار محدد وبلا مكانة رسمية في عملية المعايير. ويسجل التاريخ نشر النسخة 00 يدوياً في 11 سبتمبر/أيلول 2026. لا توجد موافقة مجموعة عمل، ولا مدير منطقة مسؤول، ولا اعتماد من IESG، ولا RFC.

تقول ترويسة الوثيقة إن الهدف Standards Track، بينما يظل حقل حالة RFC المقصودة في Datatracker فارغاً. هدف المؤلف ليس قرار المؤسسة. كما أن مسودتي مجموعة العمل الخاصتين بـمفردات تفضيلات استخدام الذكاء الاصطناعي وربطها بمحتوى HTTP عملان منفصلان، ولا تنتقل مكانتهما الإجرائية إلى terms.txt.

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

سجل للالتزام لا شهادة للمستقبل

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

تساعد The Policy Mirror لهينغ لو على إظهار النقطة التي يتحول عندها الدليل إلى قرار. وتحافظ Minimum Initial Specification على طبقة مشتركة صغيرة فلا تبتلع القرار المحلي. أما Why BTW Media Exists فتضع قاعدة التغطية: الجديد الحقيقي يُنشر مع حدوده، لا مع مستقبل متخيل على أنه واقع.

المصادر

1. سجل terms.txt في Datatracker
2. تاريخ وثيقة terms.txt
3. النسخة 00 من terms.txt
4. مسودة Web Bot Auth
5. مسودة مفردات تفضيلات استخدام الذكاء الاصطناعي
6. مسودة ربط تفضيلات الذكاء الاصطناعي بـHTTP
7. RFC 9309 — Robots Exclusion Protocol
8. RFC 9421 — HTTP Message Signatures
9. RFC 9457 — Problem Details
10. RFC 9110 — دلالات HTTP
11. RFC 9111 — التخزين المؤقت في HTTP
12. RFC 8615 — المعرّفات المعروفة
13. RFC 8126 — إرشادات سجلات IANA
14. The Policy Mirror
15. Minimum Initial Specification
16. Why BTW Media Exists