هوية ATProto: من يملك مفاتيح تحكمها حقًا؟

بعد أن تعمقت في استكشاف المخاطر المحتملة لمركزية منصة Bluesky، انفتحت عيناي على الآلية الحقيقية لعمل خوادم البيانات الشخصية (PDS) في بروتوكول ATProto. وما اكتشفته كان أكثر إثارة للقلق مما كنت أتوقعه. فبينما كان قلقي الأول ينصب على احتمال قيام Bluesky بحذف الحسابات أو تقييد المستخدمين، تبين أن هذا السيناريو هو الأقل سوءًا مقارنة بما يمكن لمشغل PDS فعله بهويتك الرقمية.

يمكن أن يكونوا أنت

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

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

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

أما في ATProto، فإن PDS الخاص بك لا يقتصر على تخزين منشوراتك على Bluesky فحسب، بل يضم كل ما يخصك: نشاطك على Git عبر Tangled (منصة تعاون مبنية على ATProto)، تفاعلاتك الاجتماعية على Grain، مقالاتك على Leaflet، وأي تطبيقات أخرى مستقبلية. كل تطبيق جديد ضمن ATProto يكتب إلى نفس المستودع، مُوقعًا بنفس المفتاح، وتحت سيطرة نفس المشغل. هذا يعني أن أي شخص يدير PDS الخاص بك يمكنه انتحال شخصيتك بالكامل عبر جميع التطبيقات في النظام البيئي.

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

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

إنها ليست البيانات، إنها المفاتيح

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

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

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

ما الذي يجب أن يتغير

من الممكن للمستخدمين تسجيل مفتاح تدوير ذاتي التحكم (self-controlled rotation key) يمتلك أولوية أعلى من مفتاح PDS. فإذا تم ذلك، سيظل بإمكان PDS التوقيع على الأنشطة باسمك، لكنه لن يتمكن على الأقل من حجبك عن هويتك الخاصة. حينها، يمكنك تدوير مفتاح التوقيع وتوجيه معرفك اللامركزي (DID) إلى PDS جديد والمضي قدمًا. إلا أن هذا ليس هو الوضع الافتراضي حاليًا، وبالتالي فإن الغالبية العظمى من المستخدمين لن تقوم بهذه الخطوة أبدًا.

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

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