هذا موضوع رائع، ويبدو أنه ناتج في الغالب عن سوء فهم.
هذه ليست مشكلة في الخطاب، بل هذه المشكلة تتخلل أي نظام عبر الإنترنت لا يوجد فيه تشفير من طرف إلى طرف وتوقيعات رقمية / تحقق من الرسائل. لا يمتلك الخطاب أياً من هذين الأمرين بشكل افتراضي.
أنت لا تناقش حقًا أيًا من هذين الأمرين هنا، ولا يتعلق هذا حقًا بأي قرارات اتخذها الخطاب كمنتج أو فريق CDCK. هناك الكثير من المفاهيم الخاطئة، أنت تتعلم فقط أن البرامج لا يمكنها فرض المستوى النهائي من السلطة على نظام - وهو شيء يعرفه الكثير منا بدرجات متفاوتة منذ عقود.
لا تعتمد سمعة المجتمع على ميزات الخطاب، بل تعتمد بشكل شبه كامل على من تسلمه المفاتيح. إذا قام مسؤول سيء التصرف بشيء يثير غضب المجتمع، فلن يهتم أحد بمدى سهولة قيامه بهذه الأفعال لأنه في النهاية كنت أنت وليس زرًا معينًا هو الذي مكنه من القيام بذلك.
يبدو الأمر أشبه بأن الناس أصبحوا غافلين عن القوة التي يمتلكها المسؤول. الانتحال هو قمة جبل الجليد.
أنا أقدر الطريقة التي طرحت بها هذا الأمر، لأنه بالنسبة لي، لقد صُدمت (وخفت كثيرًا في كثير من الأحيان) عندما علمت مقدار القوة التي أمتلكها بصفتي مسؤولاً.
لهذا السبب رغبت كثيرًا في الحصول على تشفير من طرف إلى طرف، وذلك تحديدًا: لتقليل القوة التي أمتلكها بصفتي مسؤولاً وتقليل الخوف مما قد يحدث بهذه القوة (على سبيل المثال، القدرة على قراءة/تغيير الرسائل، والمسؤولية القانونية عن الاضطرار إلى الإبلاغ عما يقوله الناس في المحادثات الخاصة، وما إلى ذلك).
ما يكفي لأعرف أن لدي احترامًا كبيرًا لمهندسي Signal والكثير من الخوف من بناء تشفير خاص بي لقد قمت ببناء تطبيق يوميات مشفر في عام 2012/13 وكان ذلك لمستخدم واحد يتحدث مع نفسه على جهاز واحد فقط… وكان لا يزال الأمر مؤلمًا، وربما لم يكن سهل الاستخدام، ولست متأكدًا من مدى أمانه.
لذا، نعم، أتفق معك، فإن تكنولوجيا الاتصالات البسيطة وسهلة الاستخدام والآمنة متعددة المستخدمين يمكن أن تكون صعبة للغاية في الإنشاء والصيانة. ربما لهذا السبب كنت متفاجئًا بشكل مبهج بوجود إضافة Discourse Encrypt.
بغض النظر، تذكرني تعليقاتك بأن هذه المنصة مجانية ومفتوحة المصدر، مما يعني أنه إذا قرر الفريق الأساسي عدم القيام بشيء ما (على سبيل المثال، تشفير الدردشة أو حظر انتحال الشخصية) لأي سبب من الأسباب، فيمكنني بناء إضافة بنفسي أو دفع شخص ما لبنائها - وهذه الحرية في القيام بذلك إذا أردت هي إحدى الأشياء التي أحبها كثيرًا في Discourse.
برأيي المتواضع، حتى المشرفين لديهم الكثير من السلطة في المنتديات، لكنني قادم من بيئة phpbb3 حيث كان للمشرفين صلاحيات أقل بكثير. (لقد قمت أيضًا بإدارة موقع Mailman لأكثر من 20 عامًا، والذي أنقله إلى Discourse بمجرد أن أتمكن من معرفة كيفية نقل 20 عامًا من الرسائل إلى Discourse.)
لقد كنت المسؤول الوحيد عن نظام موقع phpbb3 هذا لأكثر من 15 عامًا، على الرغم من أنني تقاعدت قبل عدة سنوات؛ أتطلع بالفعل إلى انتقال هذا النظام الأساسي إلى Discourse لأنني أفترض أن شخصًا آخر سيكون المسؤول ولست أرغب حقًا في أن أكون مشرفًا هناك، مجرد مشارك. لقد كنت أقدم المشورة لقائد المشروع بشأن قضايا إدارة المنتدى التي تعاملنا معها على مر السنين، وقد يؤثر بعضها على الإعدادات التي يختار استخدامها، وقد يؤثر البعض الآخر على السياسات التي تضعها المنظمة للمستخدمين وكذلك للموظفين.
ومع ذلك، فإن وجود قيود على من يمكنه استخدام زر انتحال الشخصية لا يبدو لي فكرة سيئة، بل هو مجرد فكرة رمزية إلى حد كبير بمجرد أن تكون مسؤول نظام خبير. وبالطبع، يمكن لفريق التطوير أو مسؤول النظام (في نظام مستضاف ذاتيًا) القيام بأي شيء إذا أرادوا بذل ما يكفي من الجهد.
انتحال الشخصية هو أداة أساسية واسعة الانتشار للمسؤولين. أنا في مجال استضافة الويب، وأقوم بانتحال شخصية (“تسجيل الدخول كـ”) العملاء كثيرًا في لوحة الفوترة الخاصة بي. هناك ما يكفي من الحالات التي تكون فيها ميزة كهذه ضرورية، والآن في هذه الحالة قد تحدث السيناريوهات التالية:
أنت تساعد المستخدم وتحتاج إلى رؤية ما يحدث من جانبه
أنت تقوم باستكشاف أخطاء مشكلة، لا تحدث لجميع المستخدمين لديك
تحتاج إلى رؤية الواجهة الأمامية من منظور المستخدم
أنت تختبر تجربة المستخدم/التدفق
الآن Discourse ليست لوحة فوترة، ولكن حالات الاستخدام متشابهة إلى حد ما. قد يحتاج المسؤولون إلى استكشاف أخطاء مشكلة أو رؤية كيف يبدو المنتدى من مجموعة معينة أو مستخدم معين. عادةً ما أقوم بانتحال شخصية حساباتي البديلة التي تنتمي إلى مجموعات معينة أو لديها حالة TL/mod/category mod محددة، لرؤية كيف يبدو كل شيء من جانبهم وما إذا كنت لم أغفل أي إعدادات واضحة.
أو ببساطة مساعدة المستخدم في أي شيء غير ممكن دون انتحال الشخصية - لست متأكدًا مما إذا كانت هناك إعدادات مستخدم لا يمكن الوصول إليها دون انتحال الشخصية؟
إلى جانب حقيقة أن أي مسؤول جذري يمكنه بالفعل الوصول إلى أي معلومات في قاعدة البيانات. هذا هو أحد حقوق الوصول التي يمتلكها المسؤول بحكم طبيعته. ميزة انتحال الشخصية موجودة لتسهيل حياة المسؤول، تمامًا مثل أي إعداد آخر، فهي موجودة لتسهيل المهام الإدارية: من واجهة /admin/.
الإعدادات الوحيدة التي أعرف أنها تمثل مشكلة أعتقد أنه يمكنك تغييرها كمسؤول، ولكنها تعرض إعداداتك بدلاً من إعداداتهم في بعض الأماكن. في علامة التبويب “الواجهة”، تعرض إعدادات السمة والمخطط اللوني الخاص بك بدلاً من إعدادات المستخدم، لذا يتعين عليك انتحال شخصيتهم للتأكد من أنك ترى القيم الصحيحة.
أردت فقط التذكير:\nهل من الممكن أن يكون الكثير من الناس قد نسوا بالفعل إمكانية تعطيل انتحال شخصية المسؤول بالكامل عن طريق تثبيت مكون إضافي صغير بأقل من عشرة أسطر من التعليمات البرمجية؟\n\n[quote="Renato Atilio, post:64, topic:258795, username:renato"]\nإذا كنت تريد مكونًا إضافيًا، فسأبدأ بواحد يتجاوز Guardian.can_impersonate؟، فهو يستخدم بواسطة المحول الذي يحدد وجود زر انتحال الشخصية وكذلك بواسطة فحوصات الواجهة الخلفية. على الأقل من اختبار سريع على مثيل التطوير الخاص بي، نجح الأمر:\n\n\n# plugin.rb\nafter_initialize do\n class ::Guardian\n def can_impersonate?(target)\n false\n end\n end\nend\n\n[/quote]\n\nربما أعتقد أن وظيفة انتحال الشخصية يمكن أن تحتوي على مفتاح في إعدادات الموقع مثل جميع الوظائف الأخرى، تمامًا مثل الهمس، ووضع العلامات، وصفحة المستخدم، وسجل الوصول إلى الرسائل الخاصة، وما إلى ذلك.
إذا كان مفتاح التبديل هذا موجودًا في إعدادات الموقع، فيمكن لأي مسؤول إعادة تشغيله، وبذلك يصبح النقر الواحد بضع نقرات. لست متأكدًا من أن هذا يحل المشكلة في أذهان أولئك الذين يعتبرون هذا مشكلة. لكنه قد يقلل من إغراء استخدامه للتجسس.
أعتقد أنه سيكون من الرائع أن نتمكن من تكوين أي مسؤول (مسؤولين) على الموقع عبر سطر الأوامر للوصول إلى هذه الميزة. حيث قد يكون لديك مسؤولون يحتاجون إلى الوصول المرتفع. على الرغم من أن فكرة @jimkleiber البسيطة المتمثلة في استخدام CSS لإخفاء الزر عن الجميع باستثناء X+ ستكون كافية لمعظم الناس، حيث إنها مجرد إزالة إغراء رؤيتها. على الرغم من أن مُسلسل المكون الإضافي بنفس الفكرة سيكون أفضل على الأرجح، تخيل أنه يمكنك الضغط على الزر غير المرئي (؟)
بالتأكيد، في هذه الحالة، خيار سطر الأوامر الجذر. على الرغم من أن معظم الناس سيتركونه إذا كان مجرد مسألة “إغراء”.
إليك طلب سحب (PR) لإعداد عالمي لتعطيله. أعتقد أن هذا هو الإخلاص الصحيح. إنه شيء يرغب الشخص الذي يقوم بتثبيت وتشغيل المجموعة في تعيينه على مستوى المجموعة بأكملها.
عمل رائع! ومع ذلك، أجد أن القدرة على تشغيل وإيقاف إعداد انتحال الشخصية سهلة للغاية مع هذه الميزة الجديدة. أعتقد أن معظم المستخدمين سيكونون غير مرتاحين لمعرفة أنه يمكن إيقاف تشغيل انتحال الشخصية وتشغيله حسب رغبة المسؤول!
ربما يجب أن نفكر في إعداد إضافي يسمح بتشغيل أو إيقاف تشغيل هذا الإعداد الجديد allow_impersonation. بهذه الطريقة لن أكون مغريًا جدًا لتعيين إعداد allow_impersonation على “تشغيل”. شيء مثل إعداد allow_allow_impersonation. ما رأيك؟
عندما ندعم العملاء، نقوم أحيانًا بانتحال شخصية مسؤول في مواقف غريبة للتأكد من أن المشكلة لا تتعلق بالمتصفح/نظام التشغيل/مانع الإعلانات. في تلك الحالات، يكون الأمر مفيدًا جدًا وغير مزعج - فهم لا ينشرون نيابة عنهم ولا يمكنهم الوصول إلى أي شيء لم يتمكنوا من رؤيته على أي حال.
أرى الكثير من الارتباك بين الجانب التقني والاجتماعي. الرؤية التقنية هي أن الانتحال مفيد وأن إيقافه لا يمنع ما يكفي. الرؤية الاجتماعية هي أن الانتحال سهل الاستخدام للغاية وفي ثقافة بعض المنتديات ينتهك العقد الاجتماعي.
الإشارة إلى أن الانتحال مفيد، أو حتى ضروري، لا تقول شيئًا عن الفائدة الاجتماعية أو الرسائل. وهكذا لدينا أشخاص يتحدثون عن بعضهم البعض - خاصة ربما من أولئك الذين لم يعتادوا على التفكير من حيث التوقعات الاجتماعية في ثقافات مختلفة.
شكراً على المفتاح العالمي. (ما زلت أعتقد أن تحذيرًا فاصلاً سيكون تحسينًا!)
أو يجب أن يكون في وحدة التحكم للسماح بهذا الإعداد. أو يجب أن يكون في الكود المصدري للسماح به. أو بعض التحذيرات؟ على أي حال، الإغراء لا يزال قائماً، ماذا أفعل
لقد قمت ببناء تطبيق يوميات مشفر في عام 2012/13 وكان ذلك لمستخدم واحد يتحدث مع نفسه على جهاز واحد فقط… وكان لا يزال الأمر مؤلمًا، وربما لم يكن سهل الاستخدام، ولست متأكدًا من مدى أمانه.
)