Hay cosas como Whatsapp y otras que no tienen esa función y ¿estás seguro de que pueden o presumes que pueden porque puedes en otras aplicaciones que usas?
Solo un amable recordatorio de tu amigable moderador del vecindario para mantener la discusión civil, y en general tranquila, serena y sosegada.
Las funciones de Debating Discourse no deberían ser una experiencia tensa. ![]()
Siendo totalmente honesto, no habría elegido Discourse como base de la comunidad que fundé en primer lugar si hubiera conocido este error/característica.
En mi humilde opinión, es inaceptable desde todos los puntos de vista tener eso habilitado por defecto Y a un solo clic o toque de distancia.
La libertad y la privacidad son lo único que realmente importa en Internet hoy en día. Y espero que el equipo principal pueda revisar el flujo de trabajo porque sé que no se habilitó para romper la confianza dentro de Discourse, ¡sino para buenos casos de uso!
El hilo, como dijo Jammy, apunta a una buena discusión, no a ser grosero o tomar opiniones diferentes como algo personal ![]()
No lo hago, y solo uso Mac para reproducir música o cosas triviales.
Por cierto, ¿conoces una plataforma LMS bastante grande llamada Moodle? Sí, la suplantación de identidad es una de las herramientas. Nadie se queja. Puedo actuar en nombre de mis clientes en WordPress.
Entonces… Si la suplantación de identidad es un obstáculo, no quedan demasiadas opciones.
¡Y ni siquiera has descubierto la función de “cambiar la propiedad de la publicación” todavía! ![]()
Dejando las bromas a un lado. Quieres prohibir los cuchillos en todos los hogares porque es posible matar gente con ellos. No se trata de la herramienta, sino de cómo se utiliza. Si formas parte de una comunidad, debes confiar en los administradores, por muchísimas razones. Si no puedes, entonces debes abandonar la comunidad. Es duro, pero es así de simple.
Cambiar una línea en el código fuente de Discourse permitiría a un administrador recopilar silenciosamente todas las contraseñas escritas, ¿qué te parece? Puedes eliminar funciones todo lo que quieras, pero no tienes forma de verificar el código que se está ejecutando en el servidor. La confianza es la única solución para esto.
Como alguien que realiza muchas tareas de solución de problemas en nombre de clientes y sus usuarios, puedo decirte que una “cuenta de prueba” no es suficiente. Hay tantas opciones y configuraciones que importan que la suplantación de identidad es a menudo la única manera. Dicho esto, tenemos un acuerdo de procesamiento de datos que nos prohíbe hacer un mal uso de estas funciones.
Entonces, como dijiste, esta función solo se sabe que está en uso y, al elegir usar la plataforma, estás de acuerdo con ella.
Realmente este tema tiene mucho mérito. Tener una forma de deshabilitar la función a través del acceso al servidor raíz de la línea de comandos tiene perfecto sentido. Aquellos que quieran usar la función la tienen disponible para su caso de uso. Aquellos que no quieran tener la función habilitada pueden desactivarla. Como a menudo solo un número muy limitado de administradores en un sitio tiene acceso de root, puede funcionar bien.
De manera similar a como tenemos que usar una línea de comandos para habilitar la creación de insignias personalizadas que usan scripts, si no me equivoco.
Es una solución muy simple que puede apaciguar el punto de vista de todos a favor y/o en contra de la función. Un gran compromiso para una plataforma de foro abierto. Por defecto, desactívala con instrucciones claras sobre cómo activarla o incluso haz que sea una pregunta durante la instalación para habilitarla o no, con detalles sobre cómo habilitar/deshabilitar a través de root.
![]()
![]()
![]()
Y si alguien cree que Google, Facebook, Apple y todos los demás no hacen estas cosas, entonces no sé qué decir… ![]()
Entonces, ¿se podría usar una clave de API en ese caso? Si mal no recuerdo, no estoy seguro de si mencionaste una solución para usar una API para que los diseñadores no tengan acceso completo de administrador. Pero hubo una buena discusión al respecto.
Cambiar la propiedad ciertamente podría usarse. Pero la función no funciona, digamos, en la función de Nuevo Chat.
Realmente no deberíamos usar comparaciones de manzanas y naranjas. Mientras que los cuchillos no tienen requisitos legales de almacenamiento, las armas de fuego y la munición sí. Las armas de fuego y los cuchillos no matan personas, es la persona quien los usa para ese propósito.
Cualquier herramienta puede ser mal utilizada y no hay daño en tener salvaguardas opcionales implementadas.
En cualquier sistema siempre hay un grupo de personas que tienen suficiente acceso y conocimiento para hacerse pasar por otros sin su conocimiento o consentimiento.
Todo se reduce a la confianza y la responsabilidad; tienes que confiar en que tu equipo de administradores o desarrolladores senior actúen de manera responsable.
En los sistemas bajo mi autoridad, si existe una función de ‘suplantar usuario’ (que estoy de acuerdo en que es muy útil), nuestros procedimientos operativos para el personal establecen que solo se puede utilizar después de informar al usuario de su uso y obtener el consentimiento de ese usuario. No hacerlo se consideraría motivo de despido. Dado que casi siempre se hace para resolver un problema, muy pocos usuarios se han negado a darnos ese consentimiento.
Vemos preguntas ocasionales de los usuarios sobre si los moderadores o los administradores del sistema pueden leer sus mensajes ‘personales’. Nuestro consejo es que cualquier sistema puede ser violado o hackeado, así que no pongas nada en los mensajes personales que no quieras que se haga público.
Por cierto, nuestros asesores legales nos dicen que en caso de procedimientos de descubrimiento legal, SE PUEDE solicitar TODO.
Claro, bien podrían hacerlo, al igual que WhatsApp, que afirma lo contrario. Este es un problema claro del software de código cerrado; se espera que confíes en su palabra. Sin forma de verificarlo como podrías hacerlo con código abierto.
El padre de Linus criticó a Microsoft por no permitir que nadie audite el código para asegurarse de que no haya puertas traseras.
Como ya expliqué, incluso si algo es de código abierto, no tienes forma de verificar qué código se está ejecutando en el servidor.
¿Cómo te imaginas eso? No entiendo cómo una clave de API puede ayudarme a solucionar problemas de algo que un usuario ve o no ve.
¿Sabes lo que sucede cuando no hay una función de “suplantar usuario” o cuando es difícil acceder a ella? El personal de soporte comenzará a pedir a los usuarios sus contraseñas nuevamente. Simplemente tiraste al bebé con el agua del baño.
No, lo siento, pero eso no es lo que estoy pidiendo (y no quiero nada).
Por favor, discutan.
No estaba ridiculizando nada. Estaba buscando una comparación y encontré un ejemplo en los cuchillos, que son muy útiles y también muy fáciles de usar mal, pero todo el mundo acepta que están en todas partes.
Es cierto, ya que se puede alterar antes de usarlo.
Nunca dije una eliminación completa. Se podría usar una clave API para otorgar temporalmente la opción cuando sea necesario para aquellos que la necesiten.
Como se indicó, tener una opción para deshabilitarla a través del acceso raíz de la línea de comandos es una solución fácil para aquellos que preferirían no tenerla como una función abierta. Incluso se podría hacer que la función de suplantación se configure a través de la línea de comandos como una opción para restringir su uso a 1 administrador, por ejemplo.
Me sorprende la resistencia que se presenta a simplemente tener opciones para limitar o deshabilitar la función como una opción. Por ejemplo, con su uso de proporcionar servicios de alojamiento, obviamente no deshabilitaría ni siquiera limitaría su uso por elección de sus necesidades.
Ahora, si también queremos una opción directa, el sistema simplemente podría enviar un correo electrónico al usuario informándole que ha sido suplantado por el administrador x. Al igual que la 2fa, crearía una capa de apertura sobre el uso de la función. A lo que el usuario suplantado ya estaba al tanto de que se usaría para resolver un problema.
Mi “resistencia” es doble:
- eliminar la función o dificultar su acceso proporciona una falsa sensación de seguridad
- cuando dicha funcionalidad es difícil (o más difícil) de acceder, el personal de soporte encuentra la manera de evitarla, y compartir contraseñas es mucho peor, ya que eso no se registra, las contraseñas pueden permanecer y las contraseñas pueden ser válidas para otros servicios.
Alguien con suficiente acceso también podría evitar que se envíe ese correo electrónico.
Y cada correo electrónico también puede ser un vector de ataque (conozco un ejemplo específico de un foro de Discourse que fue comprometido por una notificación falsa de “copia de seguridad creada” enviada a un administrador).
Así que quieres usar una clave API para desbloquear esto. Ahora los administradores pueden crear claves API que les dan acceso completo y, cuando otros administradores les preguntan por qué crearon/usaron una clave API, pueden afirmar que fue para solucionar problemas.
No estamos hablando de Google, Facebook o Apple. Estamos hablando de Discourse, que es de código abierto y permite el autoalojamiento.
Se supone que es lo contrario.
Lo entiendo totalmente.
Pero la pregunta es por qué está a solo un clic de distancia cuando cambiar el título de los niveles de confianza implica el uso del explorador de consultas o la gestión manual de la base de datos.
EDITADO: dos publicaciones unificadas.
Eso se aplica a cualquier cosa, incluso a los dispositivos de protección de seguridad como las protecciones anticaídas. Entonces, ¿deberíamos abandonar el EPP porque crea una falsa sensación de seguridad total si se usa?
Las opciones no son absolutas. Simplemente configuraciones opcionales para la tranquilidad, incluso si todo se puede eludir. Sam reveló que, aunque no es fácil de hacer, incluso el plugin de cifrado puede, como cualquier esquema de cifrado, ser descifrado.
Bueno, ese no es el punto del hilo, pero puedes abrir uno nuevo si quieres ![]()
En mi opinión, ese es el propósito del tema: ¿puede y debe confiar en los administradores de las comunidades en las que participa?
No creo que haya muchas novedades en la conversación a estas alturas… un administrador malintencionado no necesita hacerse pasar por alguien para hacer esto, también podría crear una publicación y cambiar su propiedad. Podría editar tus publicaciones existentes y cambiar tu configuración sin hacerse pasar por ti. También puede eliminar el historial de edición para ocultar este hecho a otros usuarios que no sean administradores. Un administrador tampoco necesita hacerse pasar por un usuario para ver todo lo que hace su cuenta, y tampoco necesita acceso a la consola para ello.
Eliminar el botón de suplantación no hace que su cuenta sea más segura. Todo lo que permite la suplantación puede ser realizado por un administrador sin la función de suplantación.
Si no puedes confiar en un administrador por miedo a que lea tus mensajes personales o altere lo que publicas para hacerte daño, no deberías usar el sitio.
