Codestream: Slack 集成需要太多权限，隐私政策和服务条款都没有解释 CodeStream 如何或为什么使用这些权限，也没有保护从 Slack 收集的信息

非常感谢您对@BernsteinA的关注。 这里要注意的关键是，除了您的用户名、电子邮件和一些个人资料字段之外，您的任何 Slack 工作区信息都不会被我们的服务器访问或存储在我们的服务器上。

我们正在积极与 Slack 的工程团队合作，尝试将范围的数量减少到允许 CodeStream 提供的功能所需的最低限度。

也许您可以在您的隐私政策中添加“除了您的用户名、电子邮件和一些个人资料字段之外，您的 Slack 工作空间信息都不会被我们的服务器访问或存储在我们的服务器上”？

很棒的建议！ 我们当前的隐私政策显然是在我们添加 Slack 集成之前编写的。

跟进此事。

当前的 Slack 权限要求：

• 实时接收来自 MadKudu 的所有事件
• 访问 MadKudu 中的所有内容

这似乎比问题中最初描述的要好，但仍然过分。 构建了 Slack 集成后，我知道这有多烦人。 但目前，如果没有 Codestream 中的法律协议，我无法承受这种级别的许可。

我的团队很乐意使用您的产品，请随时通过[email protected]与我联系

@pcothenet - 我会通过电子邮件与您联系。

@planteater 对此有何动静？ 您仍在请求对每个 Slack 频道的完全读/写访问权限

@BernsteinA - 还没有变化。 让我在这里概述一下情况，因为我很想听听您的想法。 一般来说，我们有两种选择。

第一个选项是我们今天所拥有的，它一方面需要广泛的访问权限，但另一方面允许您的消息传递根本不通过 CodeStream 后端的模型。 您的 VS Code 客户端直接与 Slack 通信。 尽管我们需要的范围听起来很繁琐，但它确实允许您通过您的编辑器访问 Slack，而不是 CodeStream 的服务器。

另一种选择是以需要更有限范围的方式重新实现 Slack 集成，但需要您将 CodeStream 机器人显式添加到您希望通过 CodeStream 与之交互的任何 Slack 对话中。 重要的是，这也意味着您与 Slack 之间的消息必须通过 CodeSteam 的后端。

你对这两个选项有什么看法？

如果权限是允许我的 VS Code 客户端访问 Slack，那么您应该让用户能够在https://api.slack.com/apps上设置自己的集成

另一种选择是创建机器人用户或按通道集成，这将更加标准，并且可以让最终用户更清楚地了解 CodeStream 可以看到哪些消息/数据（即仅发送到机器人或在机器人已明确添加到的频道）。

我不得不说，当我看到 CodeStream 要求的范围时，我也有点担心……对此主题的改进肯定会受到赞赏😉

这对我的公司来说也是一个交易破坏者！ 如果 CodeStream 可以访问围绕代码的对话，我们很好，但一切对我们来说都是不行的......

同样在这里。 该工具本身看起来很棒，但我猜它不会符合许多人的公司政策。
我认为在选定的渠道中寻找机器人是实现这一点的（标准）方式，而不必

希望听到有关此问题的任何更新！

自定义松弛集成听起来也不错，但提议的机器人解决方案似乎更方便。

以此为辅。 这是一个很大的障碍，如果我的公司发现我可能会遇到麻烦。

@BernsteinA - 还没有变化。 让我在这里概述一下情况，因为我很想听听您的想法。 一般来说，我们有两种选择。

第一个选项是我们今天所拥有的，它一方面需要广泛的访问权限，但另一方面允许您的消息传递根本不通过 CodeStream 后端的模型。 您的 VS Code 客户端直接与 Slack 通信。 尽管我们需要的范围听起来很繁琐，但它确实允许您通过您的编辑器访问 Slack，而不是 CodeStream 的服务器。

另一种选择是以需要更有限范围的方式重新实现 Slack 集成，但需要您将 CodeStream 机器人显式添加到您希望通过 CodeStream 与之交互的任何 Slack 对话中。 重要的是，这也意味着您与 Slack 之间的消息必须通过 CodeSteam 的后端。

你对这两个选项有什么看法？

对于我自己的 slack 或基于团队的 slack，第一个是可以接受的； 但是对于我的公司来说，这是一个很大的禁忌。

如果可行的话，我宁愿拥有机器人。

想在此处获得有关可能更改的一些意见。 如果 CodeStream 的 Slack 应用程序...

• 在 Slack 应用程序目录中
• 不再需要“从 $workspace 实时接收所有事件”范围
• 只需要访问您的公共频道中的“所有内容”（如果您想在私人频道/DM 中共享代码标记，您可能还可以选择允许访问私人频道/DM）
• 只收听这些频道中对代码标记的回复，而不收听任何其他帖子。

这会让您安心使用 Slack 集成吗？

@planteater听起来很合理。 有没有办法只将监听器添加到某些频道？

另外，我假设您会更新 TOS 和隐私政策？ 据我所知，其中没有任何内容涵盖通过 Slack 收集的数据、代码流注释或源代码本身。

@planteater这听起来更好，但我和@BernsteinA有相同的评论

@planteater对此有何动静？ 在解决此问题之前，我的公司不能/不会使用码流。 我想这对许多其他人来说也是一样的。 很遗憾，因为 codestream 看起来很棒，但这些权限几乎不适用于任何公司。

@AndrewMorsillo - 现在您可以拥有一个利用 Slack 消息传递的团队，或者一个使用 CodeStream 自己的消息传递的团队。 如果没有这些广泛的权限，根本无法进行当前的 Slack 集成，因为这是让 Slack 发布的回复出现在 CodeStream 中的唯一方法。

也就是说，我们的计划是为使用 CodeStream 消息的团队添加不同类型的 Slack 集成。 基本上，这是一种将任何代码标记共享给 Slack 作为通知方式的方法。 此 Slack 集成将具有您可能习惯的非常基本的权限，因此它将解决该问题，但因此您将无法直接从 Slack 回复。 但是，您可以从 Slack 点击进入可以回复的网页，或者直接深度链接到您的 IDE，您可以通过 CodeStream 回复。 当然，您也可以回复电子邮件通知。

如果您现在想开始使用 CodeStream，我建议您在没有 Slack 选项的情况下注册，然后您将能够在下个月左右准备好这些新的共享功能时利用它们。

@planteater谢谢！ 我们现在将尝试不使用松弛集成。 我认为 CodeStream 使用更“正常”的松弛集成是非常好的，其中 CodeStream 应用程序只能访问我们可以控制的通道。 至少对于我的团队来说，这将与当前模型一样有用，并且不会出现权限问题。

要回复您的其他评论https://github.com/TeamCodeStream/CodeStream/issues/14#issuecomment -493461174 我认为 CodeStream 请求“所有内容”的任何类型的集成都不适用于许多人。 这对我的团队不起作用。 它只是带来了太大的安全风险，因为无法知道谁/想要访问“所有内容”。 即使你向社区保证（我们相信你！）它只是编辑器内的 slack 客户端，或者它只收听某些消息，它总是会觉得风险太大——如果你的服务被 pwned 并且现在邪恶的演员控制着一个可以完全访问大量人的 Slack 实例的 Slack 应用程序？

新的 Slack 集成不再需要对您的工作区具有广泛的权限。 具体来说，我们不再需要访问您的频道/DM 历史记录。