Twitter should provide more granular app permissions
Twitter currently offers three levels of app permissions: (1) read only; (2) read and write; (3) read, write and access Direct Messages. These options are not granular enough for some developers, and developers would like more options to choose from.
For example, an app’s “write” permission could be segmented into more granular options: (1) write access to a user’s profile; (2) write access to a user’s network (follow/unfollow, mute, block, list modification); (3) write access to a user’s timeline, including the permission to Tweet, Retweet, or like a post.
Another example includes Sign In With Twitter: there could be an option to implement the sign in flow with “read” access only.
Here’s one example of a past forum post with a related request: https://twittercommunity.com/t/suggestion-more-granular-read-write-app-permissions/121810
To add to the original suggestion, the permissions required for "Hide Feature" recently announced should be also as atomic as possible: https://twitterdevfeedback.uservoice.com/forums/921790-twitter-developer-labs/suggestions/39308614-make-permission-for-this-as-atomic-as-possible
Please make permissions required for Hide Replies API calls as atomic as possible.
Mass users are reluctant to allowing any write, and often read permissions. This is major stopper for Blocktogether.org broader adoption, for example.
Jon Ogle-Barrington commented
I also consider this to be a critical improvement to the platform
Alex Wait commented
I would consider this a critically needed improvement for effectively supporting Twitter on various platforms considering the permissions dialog is 100 times scarier for the average user now since the expanded dialog was released. We only need say follow permissions + bio but have to request the world because of the write permission needed. I like how we can go down to read only if needed but that's often not sufficient either.
It would also be very useful to be able to use the Account Activity API without DM permissions and just not send that information in the callbacks.
Igor Brigadir commented
I also like the idea of giving users control over denying permissions selectively - similarly to how Android apps work - apps must explicitly declare permissions, and users are free to accept or deny them - it is up to the app developer to turn app functionality off if permissions are revoked or denied (eg: chat app still works even if you deny permissions to contacts etc.)
Thanks for this additional information. Have you heard of OIDC and what are your thoughts on this?
Terence Eden commented
I like the way Mastodon does it. As a developer, I can be quite explicit in wanting to post on behalf of the user, but not alter their bio etc.
Similarly, as a user, I should be able to "untick" a permission requested by a developer.
Luca Hammer commented
The current write access stops me from exploring ideas with mute- and blocklists. Most people aren't comfortable with giving full access and my idea doesn't need it. This idea would improve the situation.