Tras una marca de tema no relacionado en el hilo de Discobot, me pregunto si la comunidad de Discourse quiere debatir si permitir la suplantación de identidad de usuarios con un solo clic está bien o podría ser algo reservado para escenarios específicos.
Desde mi perspectiva, es como usar la IP o la identificación de otra persona. Son comportamientos que no se alinean con la ética o la moral (antes que lo legal o ilegal).
Creo que lo mismo se aplica a la suplantación de identidad como solución de un solo clic, donde los administradores podrían publicar como otros usuarios con un solo clic.
Quiero decir, cambiar algunas cosas en Discourse requiere entrar manualmente en la aplicación, usar Postgres y trabajar con los datos de muchas consultas.
¿Por qué la suplantación de identidad es tan fácil, cuando implica un hilo con múltiples perspectivas e intereses legales diferentes?
Eso probablemente no lo sabe la mayoría de los usuarios y todos sabemos que los administradores pueden acceder a la base de datos y cambiar cosas, pero eso es totalmente diferente a hacer clic en un botón y publicar como otro usuario.
Los administradores pueden suspender y prohibir a los usuarios si algo malo está sucediendo en el foro y son legalmente responsables del sitio web.
Yo no. Así que, en algún lugar eso es cierto, en algún lugar no lo es. Lo mismo que el límite de edad de 13 años. O grabar las propias llamadas telefónicas.
Porque es una herramienta poderosa para resolver problemas, tanto técnicos como de otro tipo.
Para mí, el acto en sí no es ilegal. Lo que hago al pretender ser otra persona puede serlo, sin embargo. Depende.
Como desarrollador, Impersonate es una función brillantemente útil que ayuda en el proceso de desarrollo, de modo que puedo salir rápidamente de un rol de administrador y asumir el rol de un nuevo usuario para comprobar lo que vería…
Creo que el punto que se está planteando es que la suplantación de identidad fácil (y silenciosa) podría violar las expectativas, al menos en algunas comunidades.
No deberíamos ver esto como una cuestión de derecho, sino como una cuestión de política y cultura, y quizás sea el tipo de política en la que un administrador del sitio podría elegir un enfoque u otro.
A veces es útil suplantar la identidad, pero quizás la persona en cuestión debería recibir una notificación. Quizás en muchos casos, la persona en cuestión podría aprobar una solicitud para suplantar la identidad.
La verdad es que, en mi opinión, la función no es necesaria y debería eliminarse. Pero estoy seguro de que el equipo tendrá razones para que esté ahí. Por ejemplo, cambiar a una cuenta de usuario de prueba.
En cuanto a la función utilizada para suplantar y publicar como otro usuario, al menos públicamente, uno podría simplemente usar 3 clics para cambiar la propiedad.
En resumen, solo tened administradores bien elegidos.
Esto podría ser problemático ya que algunos administradores solo mantienen la interfaz, como en el caso de @pfaffman con los clientes. Como todos los administradores tienen permisos completos pero no usan cosas fuera de su trabajo. Como se mencionó, uno necesita verificar las leyes de su región; sin embargo, podría ser necesario tener cuidado con los viajes.
Crear la API propuesta para otorgar a un usuario funciones de administrador parciales que un diseñador/mantenedor requiere.
Cierto, pero esto podría hacerse usando específicamente cuentas de prueba. Aquí es donde entra en juego la integridad del usuario final. Esto podría ser, como sugiere el OP, un uso abusivo y corrupto.
Me recuerda a la advertencia en Linux cuando se usa el comando sudo por primera vez:
Confiamos en que haya recibido la conferencia habitual del Administrador del Sistema local.
Generalmente se reduce a estas tres cosas:
#1) Respeta la privacidad de los demás.
#2) Piensa antes de escribir.
#3) Un gran poder conlleva una gran responsabilidad.
Es decir, al usar Impersonate por primera vez, o cada vez, se le podría presentar al administrador una ventana emergente, con algún mensaje sobre respetar la privacidad y actuar con integridad.
La función impersonate es algo bueno si lo piensas un momento, pero no solo por las razones ya mencionadas.
Impersonate registra su uso en el registro de administración. Claro, un administrador podría eliminar la entrada con la consola de rails o mediante una consulta SQL directa en Postgres, pero eso deja su propio rastro (un hueco en los IDs del registro que otros miembros del personal verán si lo buscan).
La falta de impersonate alentaría activamente a los administradores a abusar de la alternativa mucho más siniestra que no se registrará, y sospecho que cualquier desarrollador que lea lo que acabo de escribir ya habrá deducido lo que estoy a punto de decir.
¿Quieres tener una única entrada de registro fácilmente oculta e incluso hecha con meses de antelación para que el resto del personal del foro no asocie las dos cosas? Creas una Clave de API para Todos los Usuarios. 1 entrada de registro, y haces lo que quieras como quien quieras cuando quieras, y a menos que sea algo que normalmente se registraría para el usuario que estás actuando, no dejaría ningún rastro.
A menudo son cuentas de prueba en un entorno de desarrollo, pero configurar cuentas de prueba en desarrollo es trabajo adicional. Esto evita tener que cerrar sesión y volver a iniciarla, lo que ralentiza tu flujo de trabajo y es especialmente molesto tener que configurar varias contraseñas, lo que no es una experiencia agradable, te ralentiza y no añade nada de valor en desarrollo. Con “Suplantar” solo tienes que recordar la contraseña de administrador.
Simplemente estoy ilustrando un beneficio adicional de esta funcionalidad para este caso de uso específico.
Las cuentas de prueba realmente no tardan nada en crearse y, en esta idea, serían una parte estándar de la instalación de Discourse, al igual que Discobot y el sistema. La función “Suplantar” se mantendría, solo que funcionaría con, por ejemplo, 3 o 4 cuentas de prueba nulas que podrían modificarse para simular usuarios de varios niveles.
Como se ha dicho, las personas con altos valores e integridad pueden no usar “Suplantar” para fines nefastos. Aunque el uso sea tentador. Además, si los miembros de un sitio supieran que el administrador podría usar su cuenta para suplantarlos, podrían perder la confianza en la plataforma. Actualmente, “Suplantar” se basa únicamente en la integridad y no tiene una solución opcional, a diferencia de cómo el “Plugin de Cifrado” soluciona los problemas de los usuarios de un Foro Discourse para hacer que los PM/DM sean privados, como esperan los usuarios de un foro, a menos que se indique claramente que los DM/PM no son seguros y privados como la funcionalidad esperada por una comunidad. Por otro lado, pregunté específicamente si “Suplantar” podría usarse para eludir el “Plugin de Cifrado”, a lo que Sam explicó y confirmó que no podría eludir la protección, ya que es cifrado de extremo a extremo.
No es cierto. Crear usuarios de prueba cada vez es un fastidio. A menudo creo instalaciones de desarrollador nuevas y ejecuto los fixtures de desarrollo por conveniencia. (Esos usuarios con fixtures no tienen contraseñas conocidas, hasta donde sé) Luego, solo tengo que agregar una cuenta de administrador y la suplantación me permite cambiar entre ellas desde la interfaz de usuario de forma agradable. Trabajo hecho.
Estoy un poco perplejo por tu negatividad aquí… Simplemente estaba elogiando la plataforma por tener una utilidad útil que uso regularmente en mi trabajo, ahora estás atacando esta funcionalidad y mi enfoque con el objetivo de ¿qué? ¿Hacernos la vida más difícil? ¡No estoy seguro de apreciar eso mucho!
¿Cuál es realmente el problema con la función de “suplantar”? ¿Por qué la gente está haciendo un problema de la nada? De todos modos, esta es bastante útil e incluso las grandes tecnológicas usan estas funciones si hablas de privacidad, entonces el administrador puede ver todo y puede hacer cualquier cosa con las cosas del sitio, Google, Facebook y todas las grandes tecnológicas lo hacen. eso no es nada nuevo de todos modos.
Y, ¿por qué algún desarrollador crearía una cuenta si el problema es del lado del usuario? En esos casos, esta función es bastante útil. Si tienes un problema, entonces no la uses.
No lo estoy atacando en absoluto. Simplemente señalo que es una función que se puede abusar fácilmente y que puede crear una plétora de problemas. Integrar cuentas de prueba para uso directo soluciona el posible mal uso al no estar disponible. En cuanto a la creación de una cuenta de prueba. He abierto una segunda pestaña, he creado una cuenta con una dirección de correo electrónico falsa y he vuelto a mi cuenta de administrador iniciada y la he validado.
Impersonate es definitivamente una herramienta útil que, si las cuentas de prueba predeterminadas o una opción de administrador dentro del panel de administración pudieran crear cuentas nulas que se puedan usar con Impersonate. Cerraría el posible mal uso.
Como se mencionó, si se hace saber a una comunidad que las cuentas del personal pueden suplantarlas, es posible que no confíen en la plataforma comunitaria.
Por lo que he leído de ti y de un montón de gente genial aquí, es poco probable que abusen de la función. Pero tener la funcionalidad abierta de esta característica podría hacer que las comunidades confíen menos en Discourse como plataforma de foros.
Tener una discusión abierta no debe verse como algo negativo, sopesando pros y contras.
El plugin Sam’s Encrypt evita que los administradores y moderadores vean mensajes directos/privados, de manera similar a como aplicaciones como WhatsApp anuncian que no pueden ver conversaciones a menos que sean invitados. Por lo tanto, eso cierra la función de ver mensajes directos/privados que podría considerarse una violación de la privacidad esperada que no se indica claramente que no son realmente privados.
Esto es totalmente irrelevante. Si realmente quieres leer las comunicaciones privadas de los usuarios, como administrador puedes echar un vistazo en la base de datos (a menos que habilites el cifrado).
Como propietario de un sitio web, en cualquier caso tienes acceso a todo, puedes aplicar las modificaciones que desees, activar y desactivar el cifrado, lo que sea.
Cuando utilizas un sistema de terceros como usuario, no tienes ningún control directo sobre lo que la gente puede hacer con tus datos.
En cualquier caso, no estoy discutiendo sobre Producción, mi punto era solo decir que esta funcionalidad también tiene sus beneficios en Desarrollo y son fáciles de demostrar.
Así que desde mi perspectiva, +1 a esto. Ahora estoy demasiado ocupado para discutir esto más a fondo. Que tengas un buen día.
Entonces no uses Google, Facebook, Microsoft y todos los demás, ya que todos lo hacen. No dicen abiertamente que pueden “hacerse pasar por ti”. Pueden hacer todo lo que puedas imaginar, pero aun así confías en ellos y los sigues usando sabiendo que pueden hacer cualquier cosa, así que no sé cuál es realmente el problema, hombre. Quizás te preocupan tus moderadores y administradores de foros, pero aun así, todas las acciones se registran si algún administrador usa la función de “hacerse pasar por”. Así que no puedo entender dónde está el problema. Si esta función fuera problemática, el equipo de Discourse no la habría implementado en primer lugar.
Lo cual, por supuesto, tiene mérito. Pero tener esto disponible en un entorno de producción es arriesgado.
Así que lo que podría ser genial sería, como otras características, tener esta función modificada para que sea necesario activarla en el servidor Root.
Veo cómo puede tener valor en un entorno de Desarrollo, ya que es probable que los usuarios allí sean conscientes de que es un entorno de pruebas.
Ya mencioné usar Encrypt para cerrar esa función abierta.
