Codestream: L'intégration de Slack nécessite trop d'autorisations, et ni la politique de confidentialité ni l'adresse des conditions de service n'expliquent comment ou pourquoi CodeStream utilise ces autorisations, ni ne protège les informations recueillies auprès de Slack

J'apprécie totalement votre inquiétude @BernsteinA . L'essentiel à noter ici est que, à part votre nom d'utilisateur, votre adresse e-mail et quelques champs de profil, aucune des informations de votre espace de travail Slack n'est accessible ou stockée sur nos serveurs.

Nous travaillons activement avec l'équipe d'ingénierie de Slack pour essayer de réduire le nombre de champs d'application au strict minimum requis pour permettre la fonctionnalité fournie par CodeStream.

Peut-être pourriez-vous mettre "à part votre nom d'utilisateur, votre adresse e-mail et quelques champs de profil, aucune des informations de votre espace de travail Slack n'est accessible ou stockée sur nos serveurs" dans votre politique de confidentialité ?

Excellente proposition ! Notre politique de confidentialité actuelle a évidemment été rédigée avant l'intégration de Slack.

Suite à cela.

Les autorisations Slack actuelles demandent :

• Recevez tous les événements de MadKudu en temps réel
• Accéder à tout le contenu de MadKudu

Cela semble mieux que ce qui a été décrit à l'origine dans le problème, mais c'est toujours trop loin. Ayant construit une intégration Slack, je sais à quel point cela peut être ennuyeux. Mais pour le moment, je ne peux pas me permettre ce niveau de permission sans un accord légal dans Codestream.

Mon équipe aimerait utiliser votre produit, alors n'hésitez pas à me contacter à [email protected]

@pcothenet - Je vous contacterai par e-mail.

@planteater un mouvement à ce sujet ? Vous demandez toujours un accès complet en lecture/écriture à chaque chaîne Slack

@BernsteinA - Pas encore de changements. Permettez-moi de décrire la situation ici, car j'aimerais avoir votre avis. D'une manière générale, nous avons deux options.

La première option est celle que nous avons aujourd'hui, qui d'une part nécessite un large accès, mais d'autre part permet un modèle où votre messagerie ne passe pas du tout par le backend CodeStream. Votre client VS Code communique directement avec Slack. Bien que les portées que nous exigeons semblent onéreuses, c'est vraiment pour vous permettre, via votre éditeur, d'accéder à Slack, et non aux serveurs de CodeStream.

L'autre option serait de réimplémenter l'intégration Slack d'une manière qui nécessiterait des portées plus limitées, mais vous obligerait à ajouter explicitement un bot CodeStream à toute conversation Slack avec laquelle vous souhaitez interagir via CodeStream. Surtout, cela signifierait également que vos messages vers / depuis Slack devraient passer par le backend de CodeSteam.

Que pensez-vous de ces deux options ?

Si les autorisations permettent à mon client VS Code d'accéder à Slack, vous devez donner aux utilisateurs la possibilité de configurer leur propre intégration sur https://api.slack.com/apps

L'autre option, créer un utilisateur de bot ou une intégration par canal, serait plus standard et donnerait aux utilisateurs finaux une image beaucoup plus claire des messages/données pouvant être vus par CodeStream (c'est-à-dire uniquement les messages envoyés au bot ou dans un canal auquel le bot a été explicitement ajouté).

Je dois dire que je me suis un peu inquiété aussi quand j'ai vu les portées demandées par CodeStream... des améliorations sur ce sujet seront sûrement appréciées 😉

C'est aussi une rupture pour mon entreprise ! Nous allons bien si CodeStream a accès aux conversations autour du code, mais tout est interdit pour nous...

Pareil ici. L'outil lui-même a l'air génial, mais il n'ira pas avec les politiques de l'entreprise pour beaucoup de gens, je suppose.
Je pense qu'opter pour des bots dans des canaux choisis est le moyen (standard) de mettre cela en œuvre, sans avoir à

J'aimerais avoir des nouvelles sur ce problème !

Les intégrations Slack personnalisées sonnent bien également, mais la solution de bot proposée semble plus pratique.

Secondant ceci. C'était un gros obstacle, et si mon entreprise le détecte, je peux avoir des ennuis.

@BernsteinA - Pas encore de changements. Permettez-moi de décrire la situation ici, car j'aimerais avoir votre avis. D'une manière générale, nous avons deux options.

La première option est celle que nous avons aujourd'hui, qui d'une part nécessite un large accès, mais d'autre part permet un modèle où votre messagerie ne passe pas du tout par le backend CodeStream. Votre client VS Code communique directement avec Slack. Bien que les portées que nous exigeons semblent onéreuses, c'est vraiment pour vous permettre, via votre éditeur, d'accéder à Slack, et non aux serveurs de CodeStream.

L'autre option serait de réimplémenter l'intégration Slack d'une manière qui nécessiterait des portées plus limitées, mais vous obligerait à ajouter explicitement un bot CodeStream à toute conversation Slack avec laquelle vous souhaitez interagir via CodeStream. Surtout, cela signifierait également que vos messages vers / depuis Slack devraient passer par le backend de CodeSteam.

Que pensez-vous de ces deux options ?

Pour mon propre slack ou un slack basé sur une équipe, le premier serait acceptable ; cependant, pour mon entreprise, c'est un grand interdit.

Je préfère avoir des bots si c'est faisable.

Vous voulez obtenir des avis sur les changements possibles ici. Si l'application Slack de CodeStream…

• Était dans le répertoire des applications Slack
• La portée "Recevoir tous les événements de $workspace en temps réel" n'est plus nécessaire
• Uniquement l'accès requis à "tout le contenu" dans vos chaînes publiques (peut-être avec une option pour vous permettre d'autoriser l'accès aux chaînes privées/DM également si vous vouliez partager des marques de code dans les chaînes privées/DM)
• N'a écouté que les réponses aux marques de code dans ces canaux, et pas d'autres messages.

Cela vous apporterait-il la tranquillité d'esprit dont vous aviez besoin pour utiliser l'intégration Slack ?

@planteater cela semble raisonnable. Existe-t-il un moyen de n'ajouter l'auditeur qu'à certaines chaînes ?

De plus, je suppose que vous mettrez à jour les conditions d'utilisation et la politique de confidentialité ? Il n'y a rien là-dedans, pour autant que je sache, qui couvre soit les données recueillies via Slack, les commentaires du flux codé ou le code source lui-même.

@planteater ça sonne mieux, mais j'ai les mêmes commentaires que @BernsteinA

@planteater Tout mouvement à ce sujet ? Ma société ne peut pas/ne veut pas utiliser le flux codé tant que ce problème n'est pas résolu. J'imagine que c'est pareil pour beaucoup d'autres. C'est dommage car le flux codé a l'air génial, mais ces autorisations ne conviennent tout simplement pas à presque toutes les entreprises.

@AndrewMorsillo - À l'heure actuelle, vous pouvez soit avoir une équipe qui exploite la messagerie de Slack, soit une équipe qui utilise la propre messagerie de CodeStream. Il n'y a tout simplement aucun moyen de faire l'intégration actuelle de Slack sans ces larges autorisations, car c'est le seul moyen de faire apparaître les réponses publiées à partir de Slack dans CodeStream.

Cela dit, notre plan est d'ajouter un autre type d'intégration Slack aux équipes qui utilisent les messages de CodeStream. Fondamentalement, un moyen de partager n'importe quel codemark avec Slack comme moyen de notification. Cette intégration Slack aura les autorisations très basiques auxquelles vous êtes probablement habitué, elle résoudra donc ce problème, mais par conséquent, vous ne pourrez pas répondre directement depuis Slack. Cependant, vous pourrez cliquer depuis Slack vers une page Web où vous pourrez répondre, ou un lien profond directement dans votre IDE où vous pourrez répondre via CodeStream. Et bien sûr, il y aura des notifications par e-mail auxquelles vous pourrez également répondre.

Si vous voulez commencer à botter les pneus sur CodeStream maintenant, je suggérerais de vous inscrire sans l'option Slack, et vous pourrez alors tirer parti de ces nouvelles fonctionnalités de partage lorsqu'elles seront prêtes dans le mois prochain.

@planteater merci ! Nous allons essayer sans l'intégration lâche pour l'instant. Je pense qu'il serait parfaitement bien que CodeStream utilise une intégration lâche plus "normale" où l'application CodeStream n'a accès qu'aux canaux que nous pouvons contrôler. Au moins pour mon équipe, ce serait tout aussi utile que le modèle actuel et il n'y aurait pas de problèmes d'autorisation.

Pour répondre à votre autre commentaire https://github.com/TeamCodeStream/CodeStream/issues/14#issuecomment -493461174 Je ne pense pas que tout type d'intégration où CodeStream demande "tout le contenu" fonctionnera pour beaucoup de gens. Cela ne fonctionnerait pas pour mon équipe. Cela pose simplement un risque de sécurité trop important car il n'y a aucun moyen de savoir qui/veut accéder à "tout le contenu". Même si vous donnez à la communauté l'assurance (nous vous croyons !) qu'il ne s'agit que du client mou de l'éditeur ou qu'il n'écoute que certains messages, cela donnera toujours l'impression d'être trop risqué ; que se passe-t-il si votre service est bloqué et maintenant un acteur infâme contrôle une application slack qui a un accès complet à des tonnes d'instances slack de personnes ?

La nouvelle intégration Slack ne nécessite plus d'autorisations étendues pour votre espace de travail. Plus précisément, nous n'avons plus besoin d'accéder à vos historiques de chaîne/DM.