Codestream: La integración de Slack requiere demasiados permisos, y ni la política de privacidad ni los términos de servicio explican cómo o por qué CodeStream usa estos permisos, ni protege la información recopilada de Slack.

Agradezco totalmente su preocupación @BernsteinA . Lo más importante a tener en cuenta aquí es que, aparte de su nombre de usuario, correo electrónico y algunos campos de perfil, nuestros servidores no acceden ni almacenan la información de su espacio de trabajo de Slack.

Estamos trabajando activamente con el equipo de ingeniería de Slack para intentar reducir la cantidad de ámbitos al mínimo necesario para permitir la funcionalidad que proporciona CodeStream.

¿Quizás podría poner "aparte de su nombre de usuario, correo electrónico y algunos campos de perfil, no se accede a la información de su espacio de trabajo de Slack ni se almacena en nuestros servidores" en su política de privacidad?

Excelente sugerencia! Obviamente, nuestra política de privacidad actual se escribió antes de que agregáramos la integración de Slack.

Siguiendo con esto.

Los permisos actuales de Slack solicitan:

• Recibe todos los eventos de MadKudu en tiempo real
• Accede a todo el contenido en MadKudu

Esto parece mejor que lo que se describió originalmente en el problema, pero aún es demasiado. Habiendo creado una integración de Slack, sé lo molesto que puede ser. Pero por el momento, no puedo permitirme este nivel de permiso sin un acuerdo legal en Codestream.

A mi equipo le encantaría usar su producto, así que no dude en ponerse en contacto conmigo en [email protected]

@pcothenet - Me pondré en contacto contigo por correo electrónico.

@planteater ¿ algún movimiento sobre esto? Todavía estás solicitando acceso completo de lectura/escritura a todos los canales de Slack

@BernsteinA - No hay cambios todavía. Permítame resumir la situación aquí, ya que me encantaría conocer su opinión. En términos generales, tenemos dos opciones.

La primera opción es la que tenemos hoy, que por un lado requiere un amplio acceso, pero por otro lado permite un modelo en el que su mensajería no pasa en absoluto por el backend de CodeStream. Su cliente de VS Code se comunica directamente con Slack. Aunque los alcances que requerimos suenan onerosos, en realidad es para permitirle, a través de su editor, acceder a Slack, y no a los servidores de CodeStream.

La otra opción sería volver a implementar la integración de Slack de una manera que requeriría alcances más limitados, pero requeriría que agregue explícitamente un bot de CodeStream a cualquier conversación de Slack con la que desee interactuar a través de CodeStream. Es importante destacar que también significaría que sus mensajes hacia/desde Slack tendrían que pasar por el backend de CodeSteam.

¿Qué piensas de esas dos opciones?

Si es el caso de que los permisos son para permitir que mi cliente de VS Code acceda a Slack, entonces debería dar a los usuarios la posibilidad de configurar su propia integración en https://api.slack.com/apps

La otra opción, crear un usuario de bot o una integración por canal, sería más estándar y daría a los usuarios finales una imagen mucho más clara de qué mensajes/datos puede ver CodeStream (es decir, solo los mensajes enviados al bot o en un canal al que se ha agregado explícitamente el bot).

Debo decir que también me preocupé un poco cuando vi los alcances que CodeStream estaba preguntando... Seguramente agradeceré las mejoras en este tema 😉

¡Esto también es un factor decisivo para mi empresa! Estamos bien si CodeStream tiene acceso a las conversaciones sobre el código, pero todo es imposible para nosotros...

Aquí igual. La herramienta en sí se ve increíble, pero supongo que no se ajustará a las políticas de la empresa para muchas personas.
Creo que buscar bots en los canales elegidos es la forma (estándar) de implementar esto, sin tener que

¡Me encantaría saber de cualquier actualización sobre este tema!

Las integraciones personalizadas de Slack también suenan bien, pero la solución de bot propuesta parece más conveniente.

Secundando esto. Este fue un gran obstáculo, y si mi empresa detecta que puedo estar en problemas.

@BernsteinA - No hay cambios todavía. Permítame resumir la situación aquí, ya que me encantaría conocer su opinión. En términos generales, tenemos dos opciones.

La primera opción es la que tenemos hoy, que por un lado requiere un amplio acceso, pero por otro lado permite un modelo en el que su mensajería no pasa en absoluto por el backend de CodeStream. Su cliente de VS Code se comunica directamente con Slack. Aunque los alcances que requerimos suenan onerosos, en realidad es para permitirle, a través de su editor, acceder a Slack, y no a los servidores de CodeStream.

La otra opción sería volver a implementar la integración de Slack de una manera que requeriría alcances más limitados, pero requeriría que agregue explícitamente un bot de CodeStream a cualquier conversación de Slack con la que desee interactuar a través de CodeStream. Es importante destacar que también significaría que sus mensajes hacia/desde Slack tendrían que pasar por el backend de CodeSteam.

¿Qué piensas de esas dos opciones?

Para mi propia holgura o una holgura basada en un equipo, la primera sería aceptable; sin embargo, para mi empresa esto es un gran no-go.

Prefiero tener bots si eso es factible.

Quiere obtener algunas opiniones sobre posibles cambios aquí. Si la aplicación Slack de CodeStream...

• Estaba en el directorio de aplicaciones de Slack
• Ya no se requiere el alcance "Recibir todos los eventos de $workspace en tiempo real"
• Solo se requiere acceso a "todo el contenido" en sus canales públicos (tal vez con una opción para permitir el acceso a canales privados/DM también si desea compartir marcas de código en canales privados/DM)
• Solo escuché las respuestas a las marcas de código en esos canales, y ninguna otra publicación.

¿Eso le daría la tranquilidad que necesitaba para usar la integración de Slack?

@planteater eso suena razonable. ¿Hay alguna manera de agregar solo al oyente a ciertos canales?

Además, supongo que actualizará los TOS y la política de privacidad. No hay nada allí, que yo sepa, que cubra los datos recopilados a través de Slack, los comentarios del flujo de código o el código fuente en sí.

@planteater esto suena mejor, pero tengo los mismos comentarios que @BernsteinA

@planteater ¿ Algún movimiento sobre esto? Mi empresa no puede/no usará el flujo de código hasta que se resuelva este problema. Me imagino que es lo mismo para muchos otros. Es una pena porque Codestream se ve increíble, pero esos permisos simplemente no están bien para casi ninguna empresa.

@AndrewMorsillo : en este momento, puede tener un equipo que aproveche los mensajes de Slack o uno que use los propios mensajes de CodeStream. Simplemente no hay forma de hacer la integración actual de Slack sin esos amplios permisos, ya que es la única forma de que las respuestas publicadas desde Slack aparezcan en CodeStream.

Dicho esto, nuestro plan es agregar un tipo diferente de integración de Slack a los equipos que usan los mensajes de CodeStream. Básicamente, una forma de compartir cualquier marca de código con Slack como medio de notificación. Esta integración de Slack tendrá los permisos muy básicos a los que probablemente esté acostumbrado, por lo que resolverá ese problema, pero como resultado no podrá responder directamente desde Slack. Sin embargo, podría hacer clic desde Slack a una página web donde podría responder, o vincular directamente a su IDE donde podría responder a través de CodeStream. Y, por supuesto, habrá notificaciones por correo electrónico a las que también podrá responder.

Si desea comenzar a usar CodeStream ahora, le sugiero que se registre sin la opción de Slack, y luego podrá aprovechar estas nuevas funciones para compartir cuando estén listas en el próximo mes más o menos.

@planteater gracias! Intentaremos sin la integración de Slack por ahora. Creo que estaría perfectamente bien que CodeStream usara una integración de holgura más "normal" donde la aplicación CodeStream solo tiene acceso a los canales que podemos controlar. Al menos para mi equipo sería tan útil como el modelo actual y no habría problemas de permisos.

Para responder a su otro comentario https://github.com/TeamCodeStream/CodeStream/issues/14#issuecomment -493461174 No creo que ningún tipo de integración donde CodeStream solicite "todo el contenido" funcione para muchas personas. No funcionaría para mi equipo. Simplemente representa un riesgo de seguridad demasiado grande, ya que no hay forma de saber quién/quiero está accediendo a "todo el contenido". Incluso si le asegura a la comunidad (¡le creemos!) que es solo el cliente de Slack en el editor o que solo escucha ciertos mensajes, siempre se sentirá como demasiado riesgo: ¿qué pasa si su servicio se daña y ahora un ¿El actor infame controla una aplicación de Slack que tiene acceso completo a toneladas de instancias de Slack de personas?

La nueva integración de Slack ya no requiere muchos permisos para tu espacio de trabajo. Específicamente, ya no necesitamos acceso a su canal/historial de DM.