Suggestion: Opt-in solution to Privileged Intents #3835
-
Most of the problems with bots accessing sensitive data could be solved by allowing the user of a bot to accept the privacy policies and ToS of any bots they might use before being allowed access to the bot or any servers that use the bot. Here is my suggested implementation: Privileged intents will only be allowed to get sensitive data of users who have authorized the bot (otherwise it gives a 403). I suggest a settings page where you can then unauthorize any bots that you have previously authorized (similar to the authorized oauth2 applications page). When a user joins a server with one or more bots that the user has not authorized, an additional page of membership screening is added, requiring users to authorize said bots. This page lists the bots' Privacy Policies, Terms of Service, and their privileged intents. When a new bot is added, all members of the server are forced to re-do that step of membership screening. In the bot developer dashboard, there will also be a button that notifies all users of an update in the privacy policy or ToS of the application (or the privacy policy could be hosted in discord with its own tab). All users will be de-authorized (and could receive a DM from the bot) and will be prompted to re-authorize (which they may deny). This would also be triggered when the privileged intents are changed. This could also remove the need to hard-whitelist privileged intents. Un-whitelisted intents could be enabled for public bots, but a warning screen (similar to google's unverified app screen: https://support.google.com/cloud/answer/7454865?hl=en) could be shown, which should discourage the majority of users from authing the application. Other similarly annoying hard caps could be removed in this fashion. In addition, private bots will not have this restriction. The privacy policy & ToS should be made clear in the rules instead. These are just my two cents, but I think this would be a great idea. EDIT: Changed wording. (Also, if Discord could provide e.g. a bot privacy policy template that would really help a lot) |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
By the number of confused reactions, here are some proof-of-concept images that might help you imagine this:
|
Beta Was this translation helpful? Give feedback.
-
There's a couple of aspects here that I really like, namely making privacy info more accessible to users However i do not think something like this store be used instead of approval, or as an option instead of approval, this honestly feels like a way to replace approval for privlaged intents and i think this solution would be a step back if it was implemented to do that, because people will just click yes, or may not be aware of implications. Instead a possibility could be (for example for message content) a multiple level system, for example a moderation bot on the level of not being able to opt out, but a bot that responds with a funny message to key words on a level that can be opted out of?, Both requiring manual approval (I'm aware this is probably a massive long shot, and may be making incorrect assumptions about future policy 🙂) Also there's major issues with being able to opt-out of bots having acces (other than by leaving the server) in terms of moderation. (Ps, did you mean to mark your follow up as the answer?) |
Beta Was this translation helpful? Give feedback.
-
This is my personal opinion but, everyone requiring to accept the ToS on membership screen every time a new bot is added seems like a bad user experience. What I suggest instead is to simply make the intents user specific. For example, take the message content intent. Users can use a command to open the ToS screen (I'll add an example design later) for the bot and opt-in. After that, the bot will have access to the message contents from that particular user. Also, I agree with @AnotherCat that this shouldn't replace the current whitelisting implementation. Maybe Discord could check if the bot has a proper ToS workflow in place and use that to provide the privileged intents requested. |
Beta Was this translation helpful? Give feedback.
-
Individually-scoped access to intents works really well in some use cases, but is problematic for others. For example, a user being able to opt-out of message reading when a server has moderation bots. Intents are going to remain a platform-level approval. Separately, we are considering new interactions for receiving text from individual users. |
Beta Was this translation helpful? Give feedback.
Individually-scoped access to intents works really well in some use cases, but is problematic for others. For example, a user being able to opt-out of message reading when a server has moderation bots.
Intents are going to remain a platform-level approval. Separately, we are considering new interactions for receiving text from individual users.