Hi Matt,

thanks for your feedback. I think the following paragraph can't be
generalized, though:

> > 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.

I can assure you that if I am asking any of my 100.000's users that
they would disagree with that statement. They all explicitly want to
access DMs in my Symbian based Twitter client. They actually EXPECT to
have access to direct messages.

A Twitter client without access to Direct Messages is not a Twitter
client. Wouldn't you agree? ;-)

I would urge you to rethink this decision - or let us know in all
honesty why you were imposing this bad UX on third party clients only.

If there was a proper way of doing the Web OAuth flow on the Symbian
platform, things would be a bit different (although not much.)

But now, the best option for me is to setup an intermediate server for
the OAuth flow - effectively giving me access to the users' OAuth
credentials. Something, that I didn't have access to before.
Something, that I didn't WANT to have access to from the beginning.

This doesn't seem like an improvement of privacy for my users at
least.

Please, please find a better solution for this. There are many options
that won't break third party clients - clients which cannot go through
the web Oauth flow, clients that have a wonderful user base
contributing to the Twitter "experience" with a lot of great Tweets.

Cheers,
Ole ( @janole / @gravityapp )


>
> > 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

Reply via email to