This idea is following on from Scary permissions required? some other posts with confusion over app permissions, and mostly events like this: https://open.buffer.com/buffer-has-been-hacked-here-is-whats-going-on/
This falls under https://trello.com/c/1iCoKpJG/20-more-apis-with-self-managed-access
Currently, there are 3 rough permission levels for an application, and an app can have app only or user context: https://developer.twitter.com/en/docs/basics/apps/guides/app-permissions
- read only
- read and write
- read, write and access Direct Messages
The permission model could be better if it had more granular options, breaking down Read & Write in the user context by use case, for example:
All apps get default read permissions in the app and user context for endpoints like Authentication, Read User Profile, Search, rate limit status, trends, geo, streaming.
Rather than Read everything permissions for user context: “Read” can be composed of 3 commonly useful things:
- Profile: Makes sense to have this always allowed by default, since user info is embedded in lots of places.
- Network: Allow reading friends, followers, lists endpoints.
- Tweets: Allow reading User timelines, Likes, Moments, Collections anything with statuses endpoints.
The same with Write permissions:
- Profile: Permissions to change / update user profile (eg: things like Twibbon that people sometimes use can go here)
- Network: Again, any endpoints allowing Follow / Unfollow, Mute / Block, List modification go here.
- Tweets: Permissions to Tweet, Retweet, Reply, Like, Add to collections etc.
The Lists and Moments / Collections & Likes permissions could actually be merged into their own “Curation” permission level - but I think Read:[Profile, Network, Tweets] and Write[Profile, Network, Tweets] is easier to understand, and isn’t too complicated, but Write:[Profile, Network, Tweets, Curation] could work too.
To simplify it a bit more, “Read only” can be kept as is and only Write can be segmented into Profile, Network, Tweets, etc.
It’s a slightly different arrangement of the grouping of endpoints in https://developer.twitter.com/en/docs/api-reference-index
Also, some more cases:
- login with twitter can be it’s own thing with read only access to profile and nothing else.
- media related endpoints are with Write:Tweets permission,
- DMs stay as their own Read & Write permission,
- Email access stays as it’s own permission
- Maybe Geo / Location / Timezone can be a separate permission too, apart from the “profile”.
- Allowing access to “Account Activity API” is a separate permission,
- all Ads endpoints are all under one thing too.
This way, you can create an app that would only modify your lists & follows etc. and not be able to tweet on your behalf for example, or a smaller app that just reads your timeline / faves and does something else like summarize / display, and won’t have access to your friends and followers.
This way apps can be more upfront about what information is provided and how it’s used, so if i make a recommender system, i can ask people for Read permissions for everything, but write permissions only for network, and not tweets, so (even if compromised), my app can’t be used to change people’s profiles, or tweet. Or if i’m running a user study, or have a notification / chat bot I can just request Login, DM & Read User permissions.