Message event is able to read personal messages sent to/recieved from other users in same workspace from installed app.

[airpods69]

In a workspace, I used my account to create an app and installed it there. Now whenever I text someone else (not bot I mean), app.event("message") gets triggered by the app and it is able to read the message sent or received.

Might be a security issue or I did something wrong...

Reproducible in:

Generate reply is generating replies from a large language model and sending back a json with the contents in 'content' App was initalized like this

 app = App(token=os.environ["SLACK_TOKEN_DEVELOPMENT"],
                  signing_secret=os.environ["SIGNING_SECRET_DEVELOPMENT"])
        slack_client = WebClient(token=os.environ["SLACK_TOKEN_DEVELOPMENT"])

This is message event's code

@app.event("message")
def message_event(ack, body, event, say):
    ack()
    user_id = event['user']
    message_from_user = event['text']

    reponse_json = generate_reply(prompt = message_from_user)
    say(channel=event["channel"], text=reponse_json['content'])

The slack_bolt version

slack-bolt==1.18.1
slack_sdk==3.27.0

Python runtime version

Python 3.11.7

OS info

Ubuntu 20.04

Expected result:

App not being able to read what I send using my account

Actual result:

App is able to read what I send using my account

Requirements

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[filmaj]

Hello @airpods69 , I believe it all depends on which scopes (permissions) your app requires. During the installation process of your app into a workspace, the installer of the app will go through an OAuth flow, asking the installer's permission to install the app into a workspace and also listing out all the scopes (permissions) the app requires to function.

Perhaps your app is requesting a user scope for reading the user's messages? If so, what you describe would be expected behaviour.

[airpods69]

Perhaps your app is requesting a user scope for reading the user's messages?

Hmm sounds like the im:history scope? I'll check it out and report back.

[airpods69]

@filmaj These are the scopes added and I can't tell which one is the problem. Any insights would be helpful! (I still feel like im:history is to be blamed)

user:
      - channels:read
      - channels:write
      - groups:read
      - groups:write
      - im:history
      - im:read
      - im:write
      - mpim:read
      - mpim:write
      - pins:read
      - stars:read
      - team.preferences:read
      - users.profile:read
      - users:read
      - users:read.email
      - files:write
    bot:
      - app_mentions:read
      - channels:history
      - channels:manage
      - channels:read
      - chat:write
      - chat:write.public
      - conversations.connect:read
      - files:read
      - groups:read
      - groups:write
      - im:history
      - im:read
      - im:write
      - mpim:history
      - mpim:read
      - mpim:write
      - users.profile:read
      - users:read
      - users:read.email
      - files:write

[filmaj]

@airpods69 yep exactly! All the scopes you see listed under user mean, for each user that authorizes the application - either to install the app to the workspace or to get the per-user permissions listed under user - your app now has quite-intimate information from that user.

All the private-message-related user scopes (im,mpim,groups) are quite sensitive. You should carefully weigh whether you need those permissions. Personally from my perspective, if an application asked to get access to my DMs or the ability to write messages on my behalf (like all the *:write scopes you have listed under user), I would probably reject it. Most applications probably do not need access to these scopes, though some advanced and sensitive use cases are possible.

An additional point is that asking for user scopes and bot scopes complicates the application implementation. This is because now, for every event incoming that your app registered to respond to, your application has to determine: should it use the bot token in response to the event, or should it use the user token? Remember, each set of user vs. bot scopes ends up issuing a different access token, which is what allows you to act on behalf of different actors. Actions made using bot tokens will end up acting on behalf of the bot (e.g. calling the chat.postMessage API with a bot token will send a message originating as your bot) while using user tokens will end up acting on behalf of the specific user who authorized your application (e.g. calling chat.postMessage with a user token will send a message on behalf of the specific user associated with that user token).

What are you trying to accomplish with this application?

[airpods69]

The bot is a generic chatbot which is used to fetch some data (generated by an LLM). And some buttons which act as a menu for some API calls.

So every functionality is restricted to the individual conversation of user with the bot. And also read and write to the conversation with our user and send system errors to another channel.

On Fri, 22 Mar 2024, 19:00 Fil Maj, @.***> wrote:

@airpods69 https://github.com/airpods69 yep exactly! All the scopes you see listed under user mean, for each user that authorizes the application

• either to install the app to the workspace or to get the per-user permissions listed under user - your app now has quite-intimate information from that user.

All the private-message-related user scopes (im,mpim,groups) are quite sensitive. You should carefully weigh whether you need those permissions. Personally from my perspective, if an application asked to get access to my DMs or the ability to write messages on my behalf (like all the *:write scopes you have listed under user), I would probably reject it. Most applications probably do not need access to these scopes, though some advanced and sensitive use cases are possible.

An additional point is that asking for user scopes and bot scopes complicates the application implementation. This is because now, for every event incoming that your app registered to respond to, your application has to determine: should it use the bot token in response to the event, or should it use the user token? Remember, each set of user vs. bot scopes ends up issuing a different access token, which is what allows you to act on behalf of different actors. Actions made using bot tokens will end up acting on behalf of the bot (e.g. calling the chat.postMessage API with a bot token will send a message originating as your bot) while using user tokens will end up acting on behalf of the specific user who authorized your application (e.g. calling chat.postMessage with a user token will send a message on behalf of the specific user associated with that user token).

What are you trying to accomplish with this application?

— Reply to this email directly, view it on GitHub https://github.com/slackapi/bolt-python/issues/1063#issuecomment-2015103299, or unsubscribe https://github.com/notifications/unsubscribe-auth/APTUZZVBN7SJBOCXGIKZPT3YZQW6DAVCNFSM6AAAAABFA63HKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVGEYDGMRZHE . You are receiving this because you were mentioned.Message ID: @.***>

[filmaj]

I don't think you need user scopes, then. You can simply ask for bot im scopes. This way, your app would have access to any messages in private conversations that your bot is a member of. This would simplify your application and significantly reduce the different kinds of permissions your app needs, which is always a good thing.

[filmaj]

When considering the question of "do I need bot or user scopes/tokens?", think about it from the perspective of: do I want to act as the bot, or do I want to act as the end-user? Very rarely do you want to take action on behalf of a user; plus not many users would trust applications that request to act on their behalf.

[github-actions[bot]]

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

[github-actions[bot]]

As this issue has been inactive for more than one month, we will be closing it. Thank you to all the participants! If you would like to raise a related issue, please create a new issue which includes your specific details and references this issue number.