Codestream: Slack integration requires too many permissions, and neither the privacy policy nor terms of service address explains how or why CodeStream uses these permissions, or safeguards the information gathered from Slack

Totally appreciate your concern @BernsteinA . The key thing to note here is that, other than your username, email and a few profile fields, none of your Slack workspace information is accessed by or stored on our servers.

We're actively working with Slack's engineering team to try reduce the number of scopes down to the bare minimum required to allow the functionality that CodeStream provides.

Perhaps you could put "other than your username, email and a few profile fields, none of your Slack workspace information is accessed by or stored on our servers" in your privacy policy?

Excellent suggestion! Our current privacy policy was obviously written before we added the Slack integration.

Following up on this.

The current Slack permissions asks for:

• Receive all events from MadKudu in realtime
• Access all content in MadKudu

This seems better than what was originally described in the issue but is still over-reaching. Having built a Slack integration I know how annoying that can be. But at the moment, I cannot afford this level of permission without a legal agreement in Codestream.

My team would love to use your product, so feel free to contact me at [email protected]

@pcothenet - I'll reach out to you via email.

@planteater any movement on this? You're still requesting full read/write access to every Slack channel

@BernsteinA - No changes yet. Let me outline the situation here, as I’d love to get your thoughts. Generally speaking we have two options.

The first option is what we have today, which on one hand requires broad access, but on the other hand allows for a model where your messaging doesn’t go through the CodeStream backend at all. Your VS Code client communicates directly with Slack. Although the scopes we require sound onerous, it’s really to allow you, via your editor, to access Slack, and not CodeStream’s servers.

The other option would be to reimplement the Slack integration in a way that would require more limited scopes, but would require you to explicitly add a CodeStream bot to any Slack conversation you wanted to interact with via CodeStream. Importantly, it would also mean that your messages to/from Slack would have to go through CodeSteam’s backend.

What are your thoughts on those two options?

If it's the case that the permissions are to allow my VS Code client to access Slack, then you should give users the ability to set up their own integration at https://api.slack.com/apps

The other option, creating a bot user or a per-channel integration, would be more standard, and would give end-users a much clearer picture of what messages / data can be seen by CodeStream (i.e. only messages sent to the bot or in a channel that the bot has been explicitly added to).

I have to say I got a bit concerned too when I saw the scopes CodeStream was asking... improvements on this topic will be surely appreciated 😉

This is a deal-breaker for my company too! We're fine if CodeStream has access to conversations around the code, but everything is a no go for us...

Same here. The tool itself looks awesome but it won't go with company policies for many people, I guess.
I think going for bots in chosen channels is the (standard) way to implement this, without having to

Would love to hear from any updates on this issue!

Custom slack integrations sound good as well but the proposed bot solution seems more convenient.

Seconding this. This was a big hurdle, and if my company detects that I can be in trouble.

@BernsteinA - No changes yet. Let me outline the situation here, as I’d love to get your thoughts. Generally speaking we have two options.

The first option is what we have today, which on one hand requires broad access, but on the other hand allows for a model where your messaging doesn’t go through the CodeStream backend at all. Your VS Code client communicates directly with Slack. Although the scopes we require sound onerous, it’s really to allow you, via your editor, to access Slack, and not CodeStream’s servers.

The other option would be to reimplement the Slack integration in a way that would require more limited scopes, but would require you to explicitly add a CodeStream bot to any Slack conversation you wanted to interact with via CodeStream. Importantly, it would also mean that your messages to/from Slack would have to go through CodeSteam’s backend.

What are your thoughts on those two options?

For my own slack or a team based slack, the first one would be acceptable; however for my company this is a big no-go.

I'd rather have bots if that's feasible.

Want to get some opinions on possible changes here. If CodeStream’s Slack app…

• Was in the Slack App Directory
• No longer required the “Receive all events from $workspace in realtime” scope
• Only required access to “all content” in your public channels (maybe with an option for you to allow access to private channels/DMs as well if you wanted to share codemarks in private channels/DMs)
• Only listened for replies to codemarks in those channels, and not any other posts.

Would that give you the peace of mind you needed in order to use the Slack integration?

@planteater that sounds reasonable. Is there a way to only add the listener to certain channels?

Also, I assume you'll update the TOS and privacy policy? There's nothing in there, as far as I can tell, that covers either the data gathered via Slack, the codestream comments, or the source code itself.

@planteater this sounds better, but I have the same comments as @BernsteinA

@planteater Any movement on this? My company can't/won't use codestream until this issue is resolved. I imagine it's the same for many others. It's a shame because codestream looks awesome but those permissions just aren't ok for nearly any company.

@AndrewMorsillo - Right now you can either have a team that leverages Slack's messaging, or one that uses CodeStream's own messaging. There's simply no way to do the current Slack integration without those broad permissions, as it's the only way to have replies posted from Slack appear in CodeStream.

That said, our plan is to add a different type of Slack integration to the teams that use CodeStream's messages. Basically, a way to share any codemark out to Slack as a means of notification. This Slack integration will have the very basic permissions that you're probably used to, so it will solve that issue, but as a result you won't be able to reply directly from Slack. You would, however, be able to click through from Slack to a web page where you could reply, or deep link directly into your IDE where you could reply via CodeStream. And of course, there will be email notifications that you can also reply to.

If you want to start kicking the tires on CodeStream now, I would suggest signing up without the Slack option, and then you'll be able to leverage these new sharing features when they're ready in the next month or so.

@planteater thanks! We will try without the slack integration for now. I think it would be perfectly fine for CodeStream to use a more "normal" slack integration where the CodeStream app only has access to channels we can control. At least for my team that would be just as useful as the current model and there would be no permission issues.

To respond to your other comment https://github.com/TeamCodeStream/CodeStream/issues/14#issuecomment-493461174 I don't think any type of integration where CodeStream requests "all content" will work for many people. It wouldn't work for my team. It just poses too large of a security risk since there's no way to know who/want is accessing "all content". Even if you give the community assurance (we do believe you!) that it's only the in-editor slack client or that it only listens to certain messages it will always feel like too much risk -- what if your service gets pwned and now a nefarious actor controls a slack app that has full access to tons of people's slack instances?

The new Slack integration no longer requires extensive permissions for your workspace. Specifically, we no longer need access to your channel/DM histories.