الخلاصة

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

تجيب الإحداثيات عن سؤال «أين؟» لكنها لا تكشف من جمعها، أو من تصف موقعه، أو من يحق له رؤيتها، أو درجة الدقة المسموح بها، أو ما إذا كان يحق للمتلقي حفظها أو إعادة إرسالها. أرادت GEOPRIV أن تجعل هذه الأفعال الغائبة مرئية.

صدرت RFC 3693 في فبراير 2004 بوصفها وثيقة Informational. وهي تقسم الخدمة إلى أدوار متمايزة. Target هو الشخص أو الكيان الذي يجري نقل موقعه. Rule Maker هو من يضع قواعد الوصول؛ وغالباً يكون الهدف نفسه، لكن ليس دائماً، إذ يذكر النص أيضاً الوالد أو صاحب العمل. Rule Holder يحفظ القواعد ويزود بها الخوادم. Location Generator يجمع الموقع وينشئ كائناً له؛ أما Location Server فيستقبل الكائن ويطبق القواعد ويوزع النتائج المسموح بها. Location Recipient يتلقى البيانات، وViewer يستهلكها من دون إعادة إرسالها. وهناك Data Transporter ينقل البيانات من دون معالجتها. وقد يجمع جهاز واحد عدة أدوار.

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

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

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

تُظهر الوثائق اللاحقة مواصلة العمل على المواصفات، لا انتشاراً عالمياً. عرّفت RFC 4119 تنسيقاً لكائن موقع مبنياً على PIDF، ووصفت RFC 4079 بنية الحضور. وفي 2011 حدّثت RFC 6280، المنشورة بوصفها BCP 160، RFC 3693 وRFC 3694 ووسعت المتطلبات إلى معمارية أشمل. ثم حددت HELD ونقل الموقع عبر SIP وإحالة URI الموقع طرقاً معينة للحصول على الموقع أو نقله أو استرجاعه.

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

المصادر