Warn users when inviting bot with administrator permissions or restrict bots from requiring it upon invite

[kkrypt0nn]

Background information

Currently every bot can be invited with the ADMINISTRATOR within the permissions field when using an invite link or we can give the bot that permission manually in the server settings. People nowadays tend to just set permissions=8 because their bot needs to be able to, for example, ban someone due a command they have. However there is no need for such a bot to have the ADMINISTRATOR permission. One perfect example was Rythm, a music bot, that had its invite link with permissions=8 so that people inviting it would not turn into "some permissions issues" when using the bot.

Current issues

The issues are quite clear:

• Bots requiring this permission although it's not needed, which can lead to seeing and managing almost everything possible within the guild, considering the messages content intent has been enabled
• A bot could be used maliciously after being a legit bot for some months
• A legit and compromised bot could be used maliciously by a threat actor

My Proposals

Ideally the second proposal would be more handy and catch people's attention.

Developer Portal Proposal

Make developers actually prove, just like privileged intents procedure, that they actually need this permission when inviting the bot - according to some trusted users there are some very rare cases where the permission might be needed. Server members would later be able to grant the permission to the bot, with the warning already within the description of the permission.

Invite Warning Proposal

Give a clear warning when inviting the bot with this permission that it is a dangerous permission to grant, just like in the description of the permission. There are lots and lots of people who just invite the bot without checking/removing the permissions it actually needs. There are way too many bots being invited with this and only this permission.
Some people invite bots without knowing what permissions it should even have due to their lack of knowledge and experience, as they might be new to the platform.

Hovering would give more insight on why it's red.

[Jupith]

there are actions bots can carry out that require the admin permission

[JABirchall]

Hence my proposal, if you have even read it, to make them like intents. There are bots that need the message content, but definitely not all need the administrator permission - and definitely not a music bot like Rythm.

But its not an intent, its a permission.
Intents allow bots to fetch certain data
Permissions allow bots to perform specific tasks.

intents = data
permissions = tasks

[kkrypt0nn]

Hence my proposal, if you have even read it, to make them like intents. There are bots that need the message content, but definitely not all need the administrator permission - and definitely not a music bot like Rythm.

But its not an intent, its a permission. Intents allow bots to fetch certain data Permissions allow bots to perform specific tasks.

intents = data permissions = tasks

What I meant with

like intents

is the process in having your bot being allowed to be invited directly with that permission.

[JABirchall]

Again, intents are for restricting access to data. Not permissions.

And the admin inviting the bot can choose what permission the bot gets before inviting the bot. The permissions the bot requests are just the recommended permissions set by the bot author. The admin inviting the bot can choose to disable the permissions or even change them in the the server after.

You are asking for an intent to act like a permission to restrict access to a permission, circular refernces come to mind

[kkrypt0nn]

As said below, completely hindering the permission might've been over exaggerated.
Hence I changed the proposal to lock them upon invite to the server. There are lots and lots of people who just invite the bot without checking/removing the permissions it actually needs. There are way too many bots being invited with this and only this permission.

Server members would later be able to grant the permission to the bot, with the warning already within the description of the permission.

[JABirchall]

As said below, completely hindering the permission might've been over exaggerated. Hence I changed the proposal to lock them upon invite to the server. There are lots and lots of people who just invite the bot without checking/removing the permissions it actually needs. There are way too many bots being invited with this and only this permission.

Server members would later be able to grant the permission to the bot, with the warning already within the description of the permission.

I can agree with your second proposal, making a user highly aware that admin permission is being requested, then the user can research if the bot really needs it or not.

[splatterxl]

Do you want to make this a privileged intent for users as well, who can be compromised just like bots? This isn't going to work...

[kkrypt0nn]

Might've been over exaggerated to completely prevent bots from having the permission. Hence I changed the proposal to lock them upon invite to the server.
If required users are always free to give administrator permissions to the bot, just like they can on any user. This would at least prevent bots from requiring the administrator permission upon first invite. Or at least a fair red warning from Discord's side to inform the user that granting such a permission is dangerous.

[splatterxl]

Or at least a fair red warning from Discord's side to inform the user that granting such a permission is dangerous.

There's already a warning. "This is a dangerous permission to grant"

[kkrypt0nn]

Not when inviting the bot, only in the role settings within the guild.

[splatterxl]

True. On a semi-related note, you can simply toggle the permission in the OAuth2 screen to not grant it.

[kkrypt0nn]

As said above, there are lots and lots of people who just invite the bot without checking/removing the permissions it actually needs. There are way too many bots being invited with this and only this permission.
Some people invite bots without knowing what permissions it should even have due to their lack of knowledge and experience, as they might be new to the platform.

[ckohen]

Ultimately the problem here is that neither bot developers or server admins are following the principle of least privilege. The reason for this is generally ease of use, which is usually the case made for not following that principle.

There are server admins that actually think about permissions (typically bot developers themselves in my experience) based on what they are using the bot for and what the bot needs to do that. They may even change the URL to put their own desired bitfield in / remove it entirely as to have a single role for all bots.

It sounds like a good solution here is simply better education on the principle of least privilege for both bot developers and server administrators. On top of that, there should be a more prevalent warning when granting the permission during the OAuth flow, as most people simply click through.

[kkrypt0nn]

On top of that, there should be a more prevalent warning when granting the permission during the OAuth flow, as most people simply click through.

That is also another possibility I've added, unfortunately there is none at all at the moment so it would be to actually put a warning and not to put a more prevalent warning.

[NurMarvin]

I think the main issue here is that bots couldn't really provide feedback on why a command failed if permissions were set up incorrectly since they might not be able to even see the command being run to begin with (since they didn't have access to the channel) or simply didn't have permissions to talk in the channel.

Once slash commands get enforced for verified bots through the message intent, this should (for the most part) be an issue of the past, since a bot will always be able to respond to commands and tell the user why exactly a command didn't work properly.

I totally agree that bots shouldn't request too many permissions but in the past bots were pretty much forced to request the Administrator permission to enhance the user experience by not making the user go "why didn't the command work" after the bot couldn't respond due to missing permissions. However, there are legitimate reasons a bot might be requesting the Administrator permission so putting it behind a privileged intent would only make things unnecessarily complicated for bot developers and Discord because it would add an unneeded approval queue.

Also, on a side note, it wouldn't be considered a "privileged intent" since intents are a concept for receiving specific gateway events, hence it would rather be considered a "privileged toggle" or something along those lines.

[kkrypt0nn]

Totally agree, however I do believe that nowadays a basic bot that has a ban and mute command should not put the administrator permission on the invite URL, same for a music bot like Rythm.
For the error handling most, if not all, popular libraries gives you enough information as a developer to handle them correctly and give appropriate response back.
Whereas for the privileged intents, I do know what they are and mean - I probably phrased it wrongly but my intention for the first proposal was the procedure that would be similar to privileged intents, not the background system in itself.

[KubaZ2]

Rythm had the right to require administrator permission to easily access private channels.

[applebee1558]

The issue is discord requires bots to have permission beforehand before being able to add that said permission to other roles. However, a random breaking change was pushed into oauth2 pages 2 months ago that made certain permissions completely inaccessible to bots. ADMINISTRATOR permissions are the only way you can bridge the gap caused by that change right now. If this proposal was set to stone, then there should also be a proposal for ways a bot can assign the restricted permissions to roles.

[onerandomusername]

The permissions that they removed were already unusable by bots.

[Jupith]

Not true, can't set an override without having the permission you wanna override

[applebee1558]

@onerandomusername no, bots need to have that permission themselves in order to set that permission for roles or overrides.

[onerandomusername]

Ah, right. I forgot about permission overrides. I agree with you now!

[DV8FromTheWorld]

A fix is going out for this. Devportal will show all permissions and the oauth screen will allow all permissions

[advaith1]

I agree that bots shouldn't be able to request admin in the invite; if a bot really needs admin for some reason (which is an edge case) then users can modify its roles/permissions in server settings. At a bot list, we have blocked invite links with admin for a long time.

[nmsturcke]

Users can always uncheck the "Administrator" box at the top of permissions.

[advaith1]

sure they can, but most users don't do that

[i0bs]

I believe most people have summed it well to why this would be an inefficient solution. The problem at hand is that a server mod/admin/owner are going to invite the bot without the principle of least privilege, and lazily go about it. The Discord Moderator Academy goes over in detail how moderation teams should treat the permission.

At the end of the day, it's who invites the bot's decision whether or not they want the bot to carry that privilege. The privilege can always be unchecked, whether a user will actually proceed with it or not. Making a warning on the invite seems like a stopgap solution. The invite is based on the premise of trust. Chances are, most bots invited to guilds are verified already or are on an interim period of receiving it. If someone were to not already trust that verification, then the value to warning users about a permission this risky is already meaningless.

[quirky-bluejay]

I agree that in an ideal world it should be up to the person who invites the bot, and that person knows all the implications of granting administrator to a bot. There are a lot of user's who will just click through, or assume that it required for the bot to function (when for most it is not).
For example roughly 30% of guilds my bot is in have granted it the administrator permission, (for context I do not request it, or have any features that require it). This is most likely because of a culture of some large bots requesting admin, and users expecting that is required for most (or being lazy about permissions).

Something along the lines of the current warning in the roles menu, in the oauth invite flow, would go a long way:

[nmsturcke]

Something along the lines of the current warning in the roles menu, in the oauth invite flow, would go a long way:

Not sure how many people actually read that, but I agree, a notice in the Oauth2 page would be great.

[Zoddo]

When seeing questions/screenshots that are often posted in dapi/ddevs, I believe a lot of inexperienced devs just check the ADMINISTRATOR permission in the developer portal's URL generator because it's easier, or just to be sure it will works.

A first step would be to remove it from the OAuth URL generator. Someone who wants to request the administrator permission would have to manually set it in the permissions query string. I'm pretty sure this change would decrease the number of new bots that require this permission.

On another note, I also like the idea of requring admins to explicitly set that permission after inviting the bot if absolutely necessarily.

[jagrosh]

I think this is a step in the wrong direction.

It's already an issue that despite Read Messages being a permission that can already be granted or denied from bots, a separate intent is also needed in order to read messages. If a server manager wants to grant permissions or capabilities to a bot, they should be able to do so. If a bot needs certain permissions to function, and a server manager does not grant those permissions, then the bot failing to function correctly is the fault of the server manager.

I think the underlying issue here is not the permissions system itself, but rather the average server owners' ability to understand what they are actually doing when they add a bot to their server. This issue is twofold:

• Many people who add bots to their server don't actually realize that the bots have just as much power (or more, in some cases) than a user with the same permissions has. If they grant a bot access to read messages in their secret channels, they should be aware that the owner of the bot (or anybody with access to the bot's account) could be reading their messages. If they don't want the bot to read these messages, they should deny permissions from the bot, the same you'd do for a user that you don't want to read your secret messages.
• Many people who add bots to their server don't know how to fix permissions-related issues. Sometimes a bot will need a permission that an average user does not have (for example, the ability to send a message in a channel that is read-only for average users). Fixing these granular, channel-by-channel issues is too difficult for many server managers. When the bot developer faces enough people asking how to fix these issues (and eventually gets frustrated with the number of people that have permissions issues), a common response is to just have the bot request admin so that there are no more permissions issues.

Both of these issues could be resolved with more education about permissions, as well as making granting per-channel permissions easier. For example, if bots had the ability to request permissions and permission overrides in the client, there would be fewer questions and confusions about why a bot isn't working; the bot would simply ask for the permissions it needs in that instance, the server manager would confirm the override, and then the permissions would be fixed. (Note that this system is even more reliable with the introduction of slash commands, as a response to a slash command with such a request would always be possible).

I don't want more permissions to go the way of intents. If a server manager wants to grant a bot a permission, they should be able to.

[jagrosh]

To follow up, consider an alternative: All bots can request any permissions they want, but elevated permissions require an additional confirmation box to be clicked (next to each elevated permission checkbox) before allowing the bot to be authorized, forcing users to acknowledge the difference between elevated and non-elevated permissions. If a bot actually needs those permissions to function, and the user is not willing to grant them, then it is probably the case that the bot should simply not be added to the server at all.