How we cut down 50% of permission scopes we request on Slack overnight!
So the other day, just before our beta launch, we were just doing one final review of the product and were checking if we are accessing only the bare minimum information that we need for the app to function properly. From what we thought was the bare minimum, we ended up cutting 50% of the scopes, just by digging deep into our internal biases!
Just to give you some context to understand the permission scopes we would need, our product, 360Katas is a 360 degree feedback tool that enables users to seek anonymous feedback from co-workers and use it to create development goals. So, we need the ability to know users in a workspace, and send & receive messages.
Here is a list of permission scopes we requested the user, before our discussion:
- Team:read — View the name, email domain, and icon for workspaces your slack app is connected to
- users:read — View people in the workspace
- users:read.email — View email addresses of people in the workspace
- users.profile:read — View profile details about people in the workspace
- Im:history — View messages and other content in direct messages that your slack app has been added to
- Im:read — View basic information about direct messages that your slack app has been added to
- Im:write — Start direct messages with people
- Chat:write:bot — Send messages as your slack app
Pretty limited right, given that Slack offers so much more? We thought so too, until we ended up with this!
- users:read — View people in the workspace
- Im:history — View messages and other content in direct messages that your slack app has been added to
- Im:write — Start direct messages with people
- Chat:write:bot — Send messages as your slack app
Let’s dive deep into how the discussion progressed!
Team Details (team:read):
We assumed that team:read is what gives us the name of the team, which we need to know who our users are. Ideally, we don’t need the email domain or the icon, but it was coming packaged with this permission scope. This was pretty much closed until one of our colleagues, Vamshi asked what event we get when our app is added to a workspace. The assumption was that we would get at least the Workspace ID so that we can differentiate between users from different workspaces. Luckily, this event also gave us the name of the workspace. That meant we just didn’t need the team:read again and scrapped it! 🎉
User Details (users:read, users:read.email, users.profile:read):
This was the trickiest of the lot. We need just enough information to serve the user and anything more than that would make us uncomfortable from a user privacy perspective. Slack offered multiple variants of this permission scope as listed below. By looking at the description, we felt that we needed all 3.
- Users:read to know who all are part of the team, so we can allow users to seek feedback from others
- Users.profile:read to get the name and other profile information of the users so we can address them accordingly
- Users:read.email to get the email addresses to send reminders and later allow user to retrieve their account on our platform using their email
The easiest thing to scrap was Users:read.email. We just said Slack itself is a communication tool and we can send whatever reminders within Slack itself. Allowing users to take their feedback and goals when they move organizations is part of our longer term roadmap. For this, we would need their personal Email and not work email. We decided that we could just build a flow for users to connect their personal email IDs and do away with this permission scope. This would be extremely impactful since workspace admins now need not worry about us doing Email marketing to their team or showing targeted Ads based on these email addresses. 🤗
Between Users:read and Users.profile:read, we had a heated discussion ⚔️. We felt the descriptions are a little counterintuitive.
With this knowledge, we started debating whether we need a list of all team members and their information. If we did, it was a privacy setback. The way our app was designed currently was to capture all the users’ details once the app is added to the workspace and then use it to deliver functionality whenever needed. The alternative way was to add a user to our db only when they interact with our app. With this alternative, we could do away with Users:read and work with just Users:profile.read. Although this change potentially pushed our launch out by a day, we told ourselves that we are doing the right thing for our users. So this was sorted, end of story? Sadly, not!
Once we started building out with just Users.profile:read, we realized that this permission did not give us the timezone of the user and gave us their email addresses (yes, even without Users:read.email). This meant that we would now get access to email addresses of any user who clicks on our App in Slack. In addition, we would not know which part of the world the user is in and could potentially create horrible user experience around due dates.
We had to get back to the drawing board once again. Is there anything we can do to work around the timezone functionality? And how can we avoid getting the users’ email addresses. Unfortunately, we did not find answers for both the questions. This meant that using the Users:read permission was much better from a privacy standpoint, because all the information we would then get additionally is the number of people in the workspace and without any other identifier connecting these users to any external network (Ad IDs, Emails etc), this would not be a privacy concern at all 👍! That’s how we settled for just Users:read permission scope!
We would love for Slack to share the timezone information in the Users.profile:read and create another scope called Users.profile:read.email to get the Email Id of specific users in the upcoming releases. That would have been our ideal situation! — Tweet!
Permission scopes to interact with users (im:history, im:read, im:write, chat:write:bot)
This was probably the most straightforward of the lot. Our app needed to perform the following actions:
- Send messages to users to notify them of updates (feedback requests, feedback ready to review etc.)
- Initiate DMs with users to notify them when a team member requested feedback from them
- Respond to messages that users send us. While we don’t have an intelligent bot yet, Slack recommends that we send a default message at least in response.
We needed the following permission scopes to perform the above actions respectively: chat:write:bot, im:write, im:history
We realized that im:read wasn’t really necessary although it first appeared like we needed it. We thought it was to read the messages we received but it was actually to get metadata about the DMs our app was added to. We didn’t really need it, so we scrapped it. Looking at the name of im:history, we assumed it would give us access to all the history of messages across all our DM threads, which we don’t really need. Unfortunately, the permission scope that gives us access to messages that user sends us real-time is clubbed with this and we had to keep it in.
With that our permission review was done. It was an eye-opening experience for us, since we could cut 50% of permission scopes just by taking a closer look at what is really essential and what we assume to be essential — Tweet!. Now, we are all set for beta launch, and are happy that we are seeking the bare minimum permissions needed for the app to function. 🚀
Please feel free to reach out to me at nitish(at)360katas.com with your experiences, comments, and suggestions! Stay tuned for more such stories about our daily experiences in ‘The Other Day’ series!
Proud Plug: Hope you liked the story, especially if you’ve come this far! This is where I proudly request you to try out 360Katas with your team. It’s easy to use and empowers each of us to take feedback into our own hands and be our best self! Slack App Install Link: https://slack.com/apps/A016QPZRFTK-360katas
