صدمت أيضًا عندما اكتشفت أن المستخدمين المجهولين يمكنهم استخدام الوضع الآمن دون أي مشاكل.. مما يتجاوز الكثير من CSS المخصص والعناصر المخفية ويتجاوز أي تخصيصات إضافية.. 
ألا ينبغي أن تكون هذه ميزة للمسؤول فقط؟ لا أرى سببًا مشروعًا لتمكين المستخدم العادي من تعطيل الأشياء التي أعدها المسؤول لزواره.
يمكنك تعطيله للمستخدمين عن طريق إيقاف تشغيل تمكين الوضع الآمن، إذا كان ذلك يساعد؟
هذا هو الحل (ولكن أتوقع أن يكون هذا معطلاً افتراضيًا؟) - شكرًا!
تعطيله لجميع غير الموظفين يجعل التعامل مع مشكلة تحدث وتمنع تسجيل الدخول أكثر صعوبة. إنه رائع إذا كان للمسؤولين (أو الموظفين) فقط، ولكن ماذا يحدث عندما تسوء الأمور ولا تكون مسجلاً الدخول بالفعل؟
(مجرد التفكير بصوت عالٍ)
لقد خطرت هذه الحالة ببالي بالفعل، ثم بدأت أفكر: متى احتجت إلى الدخول إلى الوضع الآمن دون تسجيل الدخول؟
عادةً عندما أحتاج إلى الوضع الآمن يكون ذلك بسبب أنني قمت قبل ثانيتين بتعديل/تمكين بعض السمات/المكونات - لا أتذكر أنني احتجت إلى الوضع الآمن عندما لم أكن مسجلاً الدخول.
أليس هناك طريقة للتلاعب بأي إعداد في app.yml، بنفس الطريقة التي نمكّن بها الإعدادات المخفية؟
عندما يكون الموقع معطلاً حتى عندما لا تكون موظفًا، قد يكون من المفيد استخدام الوضع الآمن. بخلاف ذلك، لا يمكنك زيارة /about للاتصال بالمسؤول بشأن المشكلة.
لقد كنت سعيدًا جدًا في فبراير لوجود وضع آمن للمستخدمين لأنه كان الطريقة الوحيدة لاستخدامي للموقع. بينما لم يواجه المستخدمون الذين يستخدمون Safari أي مشاكل على الإطلاق. لذلك ربما لم يلاحظ المسؤولون المشكلة.
أنا مسؤول عن تعطيل الوضع الآمن للمجهولين. وأعتقد شخصيًا أنه يجب أن يكون متاحًا للموظفين فقط بشكل افتراضي.
هل يسبب هذا أي مشاكل من الناحية العملية؟ يمكنني القيام بمعظم الأشياء نفسها في وحدة تحكم المتصفح أيضًا
لست متأكدًا، أود أن أقول إن الوضع الآمن يمنح بالتأكيد خيارًا أسهل لتجاوز أشياء معينة؛
من الواضح أن هذا ليس شيئًا سأكون على دراية به، حيث لا أتوقع من المسيء الإبلاغ عن طريقة “التجاوز” الخاصة به.
ماذا عن إضافة إعداد بحيث لا يمكن للموظفين تسجيل الدخول إلا عندما يكون الموقع في الوضع الآمن؟ يجب أن يتمكن المستخدمون من الوصول إلى صفحات “حول” والمناطق العامة.