Hey everyone, The sad reality is that the way it's being taken in the news is that "twitter is doing this because developers have been abusing their privacy." We know this is not the case, we know we just need access them to provide them the feeds that they WANT to see, by virtue of the fact that they downloaded an app that clearly states it can do this. If any of you wouldn't mind jumping into this article and setting a few people straight, that'd be great: http://mashable.com/2011/05/18/twitter-permissions/
(see comments) Best, Tammy On May 19, 9:29 am, janole <s...@mobileways.de> wrote: > 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. > > Cheers, > 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: https://groups.google.com/forum/#!forum/twitter-development-talk
