Suggestion: More Granular Read & Write App Permissions

restapi
oauth

#1

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

  1. read only
  2. read and write
  3. 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.


#2

Thank you @IgorBrigadir. This is a very well-thought-out request. I have passed this information along to some internal folks who are working on the team that manages this product.


#3

I second that Igor!

I have to say that throughout the years, the most common feedback I get from users is that they are scared when they see the permission “updating your profile”, we never do and we have to put that into an FAQ, and even after we explain it, some remain skeptical. So if a more granular access level was not possible it would be great if at least that alone was moved into a separate permission.

I would also add the following to your list:

  1. oauth/authenticate end point should not override the permissions already set for the user, for example, if the user requested higher than default permissions, we should be able to retain those instead of resetting them at authentication. This allows us to ask for lesser permissions than we need, and only when the user needs more privileged permissions we can ask for higher permissions.

  2. AAAPI should not require DM permissions, if the app only needs read access it should still be able to use AAAPI. This has been a major showstopper for us from implementing AAAPI, we don’t want to ask for DM permissions from users that only require analytics (read only access).

  3. x_auth_access_type should not disable email permission, right now if you want to modify the permission level (for example to read-only) you lose access to email address.


closed #4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.