Podría ser social y/o cultural y trato de compartir mis pensamientos, sin juzgar a nadie, por eso.
Algunas personas viven en países que son resistentes a los cambios y están completamente censurados (por lo que podrían normalizar cosas que atacan directamente la libertad desde diferentes perspectivas o culturas).
Pero Discourse quiere ser la plataforma principal de foros en todo el mundo y creo que discutir sobre este tipo de temas siempre es algo bueno para todos.
Gracias por el espacio. Espero que se pueda revisar para no dañar los casos de uso, pero tampoco la confianza en Discourse por parte de los usuarios y las comunidades
Estamos hablando de prevenir usos muy malos en comunidades grandes y no dañar la confianza que los usuarios dan a Discourse.
No estamos hablando de foros ciegos o de evitar que los administradores tengan los datos porque eso es imposible desde la base centralizada que utiliza una única base de datos.
Creo que esa pregunta encaja muy bien en un debate de ‘SÍ, PERO’ y no en un debate de ‘SÍ O NO’.
Lo siento, pero ese no es el punto de mi tema. Puedes abrir otro y preguntar lo que quieras.
Eliminar la suplantación de identidad no previene esto, es igual de fácil sin ella. El efecto principal de eliminar la suplantación de identidad sería dificultar la solución de problemas específicos de la cuenta.
No lo hago. Gestionar la base de datos manualmente es totalmente diferente a hacer clic y publicar como otro tipo.
Eso está habilitado en la instancia predeterminada de Discourse sin declaraciones claras o casos de uso universales más allá de las pruebas de desarrollador.
Ese es el punto de mi hilo. Y lo siento de nuevo, pero puedes abrir otro hilo o pensar lo que quieras.
Deberías iniciar una demostración y probar algunas de las funciones de administración, no necesitas acceso a la base de datos ni suplantar para cambiar las palabras de alguien o leer sus mensajes.
Ya sea que se trate de un clic o de una docena de clics, la diferencia es poca, todavía es posible. Conozco a alguien que trabaja desde casa con frecuencia y tiene que pasar por media docena de contraseñas, identificaciones de dos factores y otras formalidades para acceder a los sistemas internos de su empresa, pero solo le lleva unos minutos hacerlo.
O usted y sus usuarios confían en los desarrolladores y administradores, o no lo hacen. Y si no confía en el sistema, es probable que cambie la forma en que lo usa.
Desde mi perspectiva, eso probablemente valida que Discourse tiene en cuenta la privacidad y la libertad.
Gestionar manualmente una base de datos está bien para un desarrollador. Un solo botón para que todos los administradores suplanten es innecesario y no está bien.
En medio, puede haber un sistema simple que muestre de manera transparente que se usó la suplantación o algo similar.
Quiero decir, puedes pensar en opciones o reducir todo a tu propia perspectiva.
Debes volver a leer mis últimas publicaciones antes de volver a responder, los administradores todavía pueden hacer todo esto sin suplantación o acceso a la base de datos. La suplantación y la mayoría de las acciones de administración ya se registran en caso de que otro administrador necesite un rastro para encontrar a un administrador malintencionado.
O simplemente cierra esa función abierta con el plugin Encrypt. Al final del día, tener opciones sobre funciones que la gente pueda encontrar problemáticas es algo bueno. Falsa sensación de seguridad, protección, etc. El único sistema seguro, para citar a Adama, es una terminal sin conexión que no esté conectada a otros sistemas.
Todos los pros y contras tienen un punto de vista válido. El compromiso es la mejor solución para todas las partes. Me imagino que el plugin Encrypt se desarrolló para apaciguar el deseo y, en algunos lugares, posiblemente el requisito de tener una capa de privacidad para el subsistema de PM/DM.
Quizás si no se incluye en el Core como una opción, podría ser un plugin que logre el efecto deseado para aquellos sistemas autoalojados que desean tranquilidad.
Se podría decir que el script para crear insignias personalizadas no necesita ser deshabilitado, ya que solo el Administrador tiene acceso directo para crearlas. Sin embargo, esto debe ser habilitado desde Root, a menos que eso haya cambiado.
Estoy de acuerdo en que en circunstancias ideales perfectas, la gente debería poder confiar en las personas en posiciones de autoridad. Desafortunadamente, la confianza a veces se deposita en el lugar equivocado y solo se descubre al final.
Esa es una medida de rendimiento, para asegurarse de que los clientes alojados en un entorno compartido no puedan arruinar el sitio de los demás. Permite distinguir entre el administrador del servidor y el administrador del foro.
Hacer clic una o doce veces parece similar pero no es lo mismo y por eso muchas corporaciones pierden mucho dinero por no habilitar un simple botón que diga ‘Darse de baja’.
Probablemente estamos hablando de lo opuesto pero desde el punto de vista moral y ético.
He estado usando Discourse como administrador desde hace 4 años y sé de lo que hablas (casos totalmente diferentes a suplantar a usuarios).
Lo que dijiste no habilita la posibilidad de publicar como otro con un solo clic. Eso es como usar una IP o ID de terceros y es diferente a editar sus publicaciones para moderación.
Por cierto, espero que el cifrado se detenga y rompa la posibilidad de leer los mensajes privados de los usuarios, pero eso es para otro hilo y estoy esperando actualizaciones para probar
Volveré a citar esto ya que parece que has agregado el modo lento…
He estado jugando con la idea de algunos ejemplos prácticos de ‘cambiar propiedad’ y/o ‘editar tu publicación y ocultar la revisión’ para demostrar que este es principalmente un argumento inútil sobre el método utilizado para hacer que parezca que dijiste algo que no dijiste sin tocar el botón de suplantación, pero he decidido no hacerlo.
Pero ciertamente hay más de unas pocas formas en que podría ser un completo imbécil con todos los botones mágicos que tengo solo en la interfaz de usuario, y mucho menos jugando con la consola de rails. Creo que mucho depende de la confianza de la comunidad, no solo del administrador, ya que muchas de estas funciones también están disponibles en el nivel TL4/catmod/mod. Creo que, en general, el grupo ‘staff’ generalmente no se esfuerza por ser destructivo con ninguna de las herramientas, ya que sería un acto de autodestrucción en su propia comunidad.
Como tal, ¿no sé por qué la función de suplantación en sí misma está siendo señalada como poco ética?
En serio, todos estos comentarios que afirman un mal uso y otras cosas no tienen sentido para mí, no tiene sentido deshabilitar esta característica en particular. Un administrador todavía puede hacer todo como otros señalaron.
Pero aun así, no quieres escuchar a los demás y quieres hacer un problema de la nada. Todavía no entiendo cuál es realmente el problema. ¿Perderás a tus usuarios? ¿O tienes miedo de que tu otro administrador use esta función en tu contra? Si es así, entonces no deberías tener administradores en los que no confíes, así de simple.
Seré perfectamente honesto, Richard, tú y @merefield tenéis escenarios de uso positivos muy válidos. Pero siento que ambos solo veis cómo los elementos cambiantes con configuraciones opcionales impedirían vuestros flujos de trabajo. Lo cual realmente no lo haría, ya que si proporcionáis alojamiento, la función no cambiaría para ninguno de los dos.
Excepto, por ejemplo, si publicara un problema con el que necesitara ayuda, con acuerdos de compensación monetaria o pro bono. Tú, Robert o cualquiera que ofrezca ayuda podéis exponer las herramientas necesarias desde un Discourse autoalojado.
es decir, “Dan, puedo ayudarte por X $ a resolver tu problema. Necesitaré lo siguiente. Crear una cuenta en tu sitio y concederme acceso de administrador. También necesitaré acceso a Suplantar (con una lista de usuarios autorizados para usar la función para que pueda diagnosticar y solucionar el problema de manera adecuada y eficiente). Si tienes Suplantar deshabilitado, necesitarás que tu administrador raíz lo habilite. Si aceptas mis términos, podemos comenzar este proceso.”
Lo automatizaría, así que no me preocupa en absoluto (de hecho, tengo un script de shell que toma el nombre del host y el nombre de usuario de una instalación de Discourse alojada por nosotros como argumento, y me da un enlace de inicio de sesión (incluyendo 2FA y registro).
Ya he explicado mis objeciones hace más de dos horas (pero con gusto las repetiré para evitar mayor confusión sobre mis motivos)
En mi mejor intento de resumir manualmente lo que estoy leyendo con GPT-4:
Algunos quieren mayor fricción para suplantar la identidad.
Algunos quieren el nivel actual de baja fricción para suplantar la identidad.
Para aquellos que quieren un poco más de fricción (yo estoy en ese grupo, porque personalmente no quiero ser tentado a hacer clic en el botón, similar a Tiempo de Uso y otros trucos en iOS para ayudarme a evitar la tentación):
Añade un componente de tema muy simple a tu sitio con el siguiente CSS:
.btn-impersonate {
display: none;
}
Quizás quieras aún más fricción que eso, y tal vez alguien podría crear un plugin o un componente de tema más avanzado para hacerlo, pero quiero probar esto y ver si me proporciona suficiente fricción para evitar cualquier tentación no deseada.
Para mí, este es el punto principal. Los administradores aún pueden “hacerse pasar” por usuarios con las otras herramientas disponibles, literalmente a unos pocos clics de distancia.
Pero al final del día, Discourse es un proyecto de código abierto con un sistema de complementos, siempre puedes hacer que las cosas funcionen de la manera que creas que es correcta para tu propia comunidad.
Si quieres un complemento, comenzaría con uno que anule Guardian.can_impersonate?, es utilizado por el serializador que determina la presencia del botón “Hacerse pasar” así como por las verificaciones del backend. Al menos por una prueba rápida en mi instancia de desarrollo, funcionó:
# plugin.rb
after_initialize do
class ::Guardian
def can_impersonate?(target)
false
end
end
end
