Hi Matt,

just another tought:

Wouldn't it be possible to keep the DM access rights with xAuth and
only revoke it upon users complaints or your monitoring of API usage?

If I remember correctly, Twitter said they are revoking hundreds of
API clients per day, so it seems like this approach is working well.

Ole ( @janole / @gravityapp )

On May 19, 2:11 am, themattharris <thematthar...@twitter.com> wrote:
> Hey everyone,
> Thank you for all the feedback on the list, email and through Tweets.
> We've been responding throughout the day to many of the Tweets but
> wanted to group the questions together and respond here as well.
> > Two weeks is not enough time to implement a web OAuth flow and have the app 
> > approved. We need an extension.
> We’ve heard your feedback on this list, privately and through Tweets
> about this. Based on this feedback we are going to extend the
> enforcement deadline by two weeks.
> **** This means we'll enforce the new permission the week beginning
> the 14th June 2011. ****
> This should provide enough time for you to make the change and have
> your application approved by your chosen platform’s app store.
> > Will Twitter's own applications also go through the OAuth web flow?
> We’re taking this step to give more clarity and control to users about
> the access a third-party application has to their account. The way
> users interact with Twitter’s clients is not expected to change.
> Applications who wish to access a user’s DMs will need to update their
> application permission and incorporate the OAuth web flow if they
> don’t already. If an application does not need access to DMs it will
> not need to make any changes.
> > Why will you not grandfather existing applications into DM access?
> Grandfathering all existing read/write tokens assumes they all wanted
> access to DMs. The feedback we’ve had from users and developers tells
> us otherwise. We want to give users the opportunity to make an
> informed choice.
> > What if the client using xAuth has no browser and therefore cannot go 
> > through OAuth?
> For single user applications and scripts we provide the 'My Access
> Token' page of the application details. To ensure the 'My Access
> Token' is correct it is important the app owner revokes their access
> before change the permission level of the app. If you do not do this,
> the 'My Access Token' will not be regenerated with the new permission.
> This revoke action is only needed by you, the owner of the
> application. Remember Read/Write applications can still send direct
> messages.
> > When you activate the new permission, will all Read and Read/Write 
> > user_tokens issued to third-party applications lose their ability to read 
> > direct messages?
> Existing tokens are unaffected by any change to the application
> permission level. If you change your application to R/W/DM all future
> authorizations will be for that permission. When a user re-authorizes,
> their existing token will be updated to the current application
> permission level. Access to DMs will be enforced on 14th June 2011 if
> the user_token wasn't authorised as for R/W/DM.
> > What if I want to request a different level of access for my application 
> > instead of the one my application is registered with?
> You can do this now by using the x_auth_access_type parameter during
> the request_token phase. Using this parameter you can request a read
> or a read/write token even if your application is registered for read/
> write/direct messages.
> More information on this method is in our developer documentation:
>    http://dev.twitter.com/doc/post/oauth/request_token
> > Why are permissions attached to the user token?
> Permissions are attached to the user token to ensure an application
> only has the access a user has authorised. If permissions were not
> attached to the user token an application would be able to change the
> level of access they have without the user’s knowledge. If you tie the
> permissions to the application each user token would need to be
> invalidated whenever an application’s permissions are changed.
> > Users already gave their permission for apps to access private messages, 
> > why are you making us, and them, reauthorize?
> The purpose of the re-authorization is to ensure both users and
> developers know the level of access requested. Re-authorization allows
> a user to make a more informed decision about the access an
> application has requested.
> We hope these responses answer your questions. Please continue to send
> us your feedback about the permission model and what you would like to
> see it offer.
> Best,
> @themattharris

Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 

Reply via email to