Codestream: Slack統合には必要なアクセス許可が多すぎます。プライバシーポリシーも利用規約アドレスも、CodeStreamがこれらのアクセス許可を使用する方法や理由を説明したり、Slackから収集した情報を保護したりすることはありません。

@BernsteinAの懸念に心から感謝します。 ここで注意すべき重要な点は、ユーザー名、電子メール、およびいくつかのプロファイルフィールドを除いて、Slackワークスペース情報はサーバーからアクセスされたりサーバーに保存されたりしないことです。

私たちはSlackのエンジニアリングチームと積極的に協力して、CodeStreamが提供する機能を可能にするために必要な最小限のスコープの数を減らすように努めています。

おそらく、プライバシーポリシーに「ユーザー名、電子メール、およびいくつかのプロファイルフィールドを除いて、Slackワークスペース情報にアクセスしたりサーバーに保存したりすることはありません」と入力できますか？

素晴らしい提案です！ 現在のプライバシーポリシーは、Slack統合を追加する前に作成されたものです。

これをフォローアップします。

現在のSlack権限は以下を要求します：

• MadKuduからのすべてのイベントをリアルタイムで受信します
• MadKuduのすべてのコンテンツにアクセスする

これは、この問題で最初に説明されたものよりも優れているように見えますが、それでも行き過ぎです。 Slack統合を構築したことで、それがどれほど煩わしいものになるかを知っています。 しかし、現時点では、Codestreamの法的な合意なしに、このレベルの許可を得る余裕はありません。

私のチームはあなたの製品を使いたいので、 paul @ madkudu.comまでお気軽にご連絡ください。

@ pcothenet-メールでご連絡します。

@planteaterこれに関する動きはありますか？ あなたはまだすべてのSlackチャンネルへの完全な読み取り/書き込みアクセスを要求しています

@ BernsteinA-まだ変更はありません。 私はあなたの考えを得たいので、ここで状況を概説させてください。 一般的に言えば、2つのオプションがあります。

最初のオプションは、現在のオプションです。これは、一方では幅広いアクセスを必要としますが、他方では、メッセージングがCodeStreamバックエンドをまったく通過しないモデルを可能にします。 VSCodeクライアントはSlackと直接通信します。 私たちが必要とするスコープは面倒に聞こえますが、実際には、エディターを介して、CodeStreamのサーバーではなく、Slackにアクセスできるようにするためのものです。

もう1つのオプションは、より限定されたスコープを必要とする方法でSlack統合を再実装することですが、CodeStreamを介して対話するSlack会話にCodeStreamボットを明示的に追加する必要があります。 重要なのは、Slackとの間のメッセージがCodeSteamのバックエンドを経由する必要があることも意味します。

これらの2つのオプションについてどう思いますか？

VS CodeクライアントがSlackにアクセスできるようにする権限がある場合は、 https：//api.slack.com/appsで独自の統合を設定できるようにする必要があります。

もう1つのオプションである、ボットユーザーまたはチャネルごとの統合を作成することは、より標準的であり、エンドユーザーにCodeStreamで表示できるメッセージ/データ（つまり、ボットまたはで送信されたメッセージのみ）のより明確な画像を提供します。ボットが明示的に追加されたチャネル）。

CodeStreamが要求しているスコープを見たとき、私も少し心配したと言わなければなりません...このトピックの改善は確かに高く評価されます😉

これは私の会社にとっても大きな問題です。 CodeStreamがコードに関する会話にアクセスできれば問題ありませんが、すべてがうまくいきません...

こっちも一緒。 ツール自体は素晴らしく見えますが、多くの人の会社の方針には合わないと思います。
選択したチャネルでボットを利用することが、これを実装するための（標準的な）方法だと思います。

この問題に関する最新情報をお聞かせください。

カスタムのSlack統合も良いように聞こえますが、提案されたボットソリューションの方が便利なようです。

これを出向。 これは大きなハードルであり、私の会社が私が問題を抱えている可能性があることを検出した場合。

@ BernsteinA-まだ変更はありません。 私はあなたの考えを得たいので、ここで状況を概説させてください。 一般的に言えば、2つのオプションがあります。

最初のオプションは、現在のオプションです。これは、一方では幅広いアクセスを必要としますが、他方では、メッセージングがCodeStreamバックエンドをまったく通過しないモデルを可能にします。 VSCodeクライアントはSlackと直接通信します。 私たちが必要とするスコープは面倒に聞こえますが、実際には、エディターを介して、CodeStreamのサーバーではなく、Slackにアクセスできるようにするためのものです。

もう1つのオプションは、より限定されたスコープを必要とする方法でSlack統合を再実装することですが、CodeStreamを介して対話するSlack会話にCodeStreamボットを明示的に追加する必要があります。 重要なのは、Slackとの間のメッセージがCodeSteamのバックエンドを経由する必要があることも意味します。

これらの2つのオプションについてどう思いますか？

私自身のたるみやチームベースのたるみについては、最初のものが許容されます。 しかし、私の会社にとって、これは大したことではありません。

可能であれば、ボットが欲しいです。

ここで可能な変更についていくつかの意見を聞きたいです。 CodeStreamのSlackアプリの場合…

• Slackアプリディレクトリにありました
• 「$ workspaceからすべてのイベントをリアルタイムで受信する」スコープは不要になりました
• パブリックチャネルの「すべてのコンテンツ」へのアクセスのみが必要です（プライベートチャネル/ DMでコードマークを共有したい場合は、プライベートチャネル/ DMへのアクセスを許可するオプションもあります）
• これらのチャネルのコードマークへの返信のみをリッスンし、他の投稿はリッスンしませんでした。

これで、Slack統合を使用するために必要な安心感が得られますか？

合理的に聞こえる@planteater 。 特定のチャネルにのみリスナーを追加する方法はありますか？

また、利用規約とプライバシーポリシーを更新すると思いますか？ 私が知る限り、Slackを介して収集されたデータ、コードストリームのコメント、またはソースコード自体のいずれかをカバーするものは何もありません。

@planteaterこれは良く聞こえますが、 @ BernsteinAと同じコメントがあります

@planteaterこれに関する動きはありますか？ 私の会社は、この問題が解決されるまでコードストリームを使用できません/使用しません。 他の多くの人も同じだと思います。 コードストリームは素晴らしく見えるので残念ですが、これらの権限はほとんどすべての企業にとって問題がありません。

@ AndrewMorsillo-現在、Slackのメッセージングを活用するチーム、またはCodeStream独自のメッセージングを使用するチームのいずれかを作成できます。 Slackから投稿された返信をCodeStreamに表示する唯一の方法であるため、これらの幅広い権限なしに現在のSlack統合を行う方法はありません。

そうは言っても、私たちの計画は、CodeStreamのメッセージを使用するチームに異なるタイプのSlack統合を追加することです。 基本的に、通知の手段としてSlackにコードマークを共有する方法。 このSlack統合には、おそらく慣れている非常に基本的な権限があるため、その問題は解決されますが、その結果、Slackから直接返信することはできません。 ただし、Slackから返信できるWebページにクリックスルーしたり、CodeStreamを介して返信できるIDEに直接ディープリンクしたりすることはできます。 そしてもちろん、あなたが返信することもできる電子メール通知があります。

今すぐCodeStreamでタイヤを蹴り始めたい場合は、Slackオプションなしでサインアップすることをお勧めします。そうすれば、来月かそこらで準備ができたら、これらの新しい共有機能を利用できるようになります。

@planteaterありがとう！ 今のところ、Slack統合なしで試してみます。 CodeStreamアプリが制御可能なチャネルにしかアクセスできない、より「通常の」Slack統合を使用することはCodeStreamにとってまったく問題ないと思います。 少なくとも私のチームにとっては、現在のモデルと同じくらい便利で、許可の問題はありません。

他のコメントに返信するにはhttps://github.com/TeamCodeStream/CodeStream/issues/14#issuecomment-493461174CodeStreamが「すべてのコンテンツ」を要求するタイプの統合が多くの人に役立つとは思いません。 私のチームではうまくいきません。 「すべてのコンテンツ」に誰が/誰がアクセスしたいかを知る方法がないため、セキュリティリスクが大きすぎます。 編集者のSlackクライアントだけである、または特定のメッセージのみをリッスンしているというコミュニティの保証（私たちはあなたを信じています！）を与えたとしても、それは常にリスクが大きすぎるように感じます-あなたのサービスがpwnされて今は悪意のあるアクターが、大量の人々のSlackインスタンスに完全にアクセスできるSlackアプリを制御していますか？

新しいSlack統合では、ワークスペースに対する広範な権限は不要になりました。 具体的には、チャネル/ DM履歴にアクセスする必要がなくなりました。