A new permission level

1332 views
Skip to first unread message

Matt Harris

unread,
May 18, 2011, 1:01:41 PM5/18/11
to Twitter Development Talk
Hey everyone,

We recently updated our OAuth screens to give users greater transparency about the level of access applications have to their accounts. The valuable feedback Twitter users and developers have given us played a large part in that redesign and helped us identify where we can do more.

In particular, users and developers have requested greater granularity for permission levels.

In response to this feedback, we have created a new permission level for applications called “Read, Write & Direct Messages”. This permission will allow an application to read or delete a user's direct messages. When we enforce this permission, applications without a “Read, Write & Direct Messages” token will be unable to read or delete direct messages. To ensure users know that an application is receiving access to their direct messages, we are also restricting this permission to the OAuth /authorize web flow only. This means applications which use xAuth and want to access direct messages must send a user through the full OAuth flow.


What does this mean for your application?
If you do not need access to direct messages: you won’t need to make any changes to your application. When we enforce the new permission level your read or read/write token will automatically lose access to direct messages.

If you do need access to direct messages: you will need to edit your application record on https://dev.twitter.com/apps and change the permission level of your application to “Read, Write and Direct Messages”. The new permission will not affect existing tokens which means existing users or your app or service will need to reauthorize.

We know this will take some time so we are allowing a transition period until the end of this month. During this time there will be no change to the access Read/Write tokens have to a users account. However, at the end of the month any tokens which have not been upgrade to “Read, Write and Direct Messages” will be unable to access and delete direct messages.


Affected APIs and requests
On the REST API, Read and Read/Write applications will no longer be able to use these API methods:
/1/direct_messages.{format}
/1/direct_messages/sent.{format}
/1/direct_messages/show.{format}
/1/direct_messages/destroy.{format}

For the Streaming API, both User Streams and Site Streams will only receive direct messages if the user has authorised an application to access direct messages.

Applications that use “Sign-in with Twitter” or xAuth will only be able to receive Read or Read/Write tokens.

What this means is only applications which direct a user through the OAuth web flow will be able to receive access tokens that allow access to direct messages. Any other method of authorization, including xAuth, will only be able to receive Read/Write tokens.


What will happen when the permission is activated
When we activate the new permission, all Read and Read/Write user_tokens issued to third-party applications will lose their ability to read direct messages. Any attempt to read direct messages will result in an HTTP 403 error being returned.

For example, a GET request to https://api.twitter.com/1/direct_messages/sent.json will return an HTTP 403 Forbidden with the response body:

{"errors":[{"code":93,"message":"This application is not allowed to access or delete your direct messages"}]}


Key Points
* If you wish to access a user’s direct messages you will need to update your application and reauthorize existing tokens.
* The only way to get direct message access is to request access through the OAuth /authorize web flow. You will not be permitted to access direct messages if you use xAuth.
* When we enforce the permission Read/Write and Read tokens will be unable to access and delete direct messages.
* Read/Write tokens will be able to send direct messages after the permission is enforced.

We’ll be collating responses and adding more information on our developer resources permission model page: https://dev.twitter.com/pages/application-permission-model

We have also blogged about this on the Twitter blog: http://blog.twitter.com/2011/05/mission-permission.html

Best,
@themattharris

Jim Cortez

unread,
May 18, 2011, 1:19:19 PM5/18/11
to twitter-deve...@googlegroups.com
Matt,
You say:

> This means applications which use xAuth and want to access direct
> messages must send a user through the full OAuth flow.
What if the client using xAuth has no browser and therefore cannot go
through oAuth? Does this mean that direct messages cannot be accessed?
Is there a process I can go through to get our app approved for use of
direct messages without using oAuth?

Thanks,
Jim Cortez

> --
> 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
> <https://groups.google.com/forum/#%21forum/twitter-development-talk>

Rich

unread,
May 18, 2011, 1:26:21 PM5/18/11
to Twitter Development Talk
The new permissions level is welcomed by me and a good idea. Removing
the ability for xAuth to access DMs is insanity, pure and simple.

I presume your iOS and Mac clients will be switching off xAuth access
as well then?

On May 18, 6:19 pm, Jim Cortez <j...@jimcortez.com> wrote:
> Matt,
>      You say:> This means applications which use xAuth and want to access direct
> > messages must send a user through the full OAuth flow.
>
> What if the client using xAuth has no browser and therefore cannot go
> through oAuth? Does this mean that direct messages cannot be accessed?
> Is there a process I can go through to get our app approved for use of
> direct messages without using oAuth?
>
> Thanks,
> Jim Cortez
>
> > application record onhttps://dev.twitter.com/appsand change the
> >https://api.twitter.com/1/direct_messages/sent.jsonwill return an

Tom van der Woerdt

unread,
May 18, 2011, 1:28:13 PM5/18/11
to twitter-deve...@googlegroups.com
Sounds good! Also sounds like you folks are finally trying to get rid of
xAuth :-)

Of course, for desktop (and mobile) applications this will mean that
they will have to integrate the normal OAuth flow. "Yay!".

In the past, I've seen several occurrences where popular clients weren't
affected by the rules. Will we yet again see this, or will there not be
an exception for those clients? The same question goes for Twitter's own
apps: will they make the switch to OAuth, or will they keep using xAuth?

Tom


On 5/18/11 7:01 PM, Matt Harris wrote:
> Hey everyone,
>
> We recently updated our OAuth screens to give users greater
> transparency about the level of access applications have to their
> accounts. The valuable feedback Twitter users and developers have
> given us played a large part in that redesign and helped us identify
> where we can do more.
>
> In particular, users and developers have requested greater granularity
> for permission levels.
>
> In response to this feedback, we have created a new permission level

> for applications called �Read, Write & Direct Messages�. This

> permission will allow an application to read or delete a user's direct
> messages. When we enforce this permission, applications without a

> �Read, Write & Direct Messages� token will be unable to read or delete

> direct messages. To ensure users know that an application is receiving
> access to their direct messages, we are also restricting this
> permission to the OAuth /authorize web flow only. This means
> applications which use xAuth and want to access direct messages must
> send a user through the full OAuth flow.
>
>
> What does this mean for your application?

> If you do not need access to direct messages: you won�t need to make

> any changes to your application. When we enforce the new permission
> level your read or read/write token will automatically lose access to
> direct messages.
>
> If you do need access to direct messages: you will need to edit your
> application record on https://dev.twitter.com/apps and change the

> permission level of your application to �Read, Write and Direct
> Messages�. The new permission will not affect existing tokens which

> means existing users or your app or service will need to reauthorize.
>
> We know this will take some time so we are allowing a transition
> period until the end of this month. During this time there will be no
> change to the access Read/Write tokens have to a users account.
> However, at the end of the month any tokens which have not been

> upgrade to �Read, Write and Direct Messages� will be unable to access

> and delete direct messages.
>
>
> Affected APIs and requests
> On the REST API, Read and Read/Write applications will no longer be
> able to use these API methods:
> /1/direct_messages.{format}
> /1/direct_messages/sent.{format}
> /1/direct_messages/show.{format}
> /1/direct_messages/destroy.{format}
>
> For the Streaming API, both User Streams and Site Streams will only
> receive direct messages if the user has authorised an application to
> access direct messages.
>

> Applications that use �Sign-in with Twitter� or xAuth will only be

> able to receive Read or Read/Write tokens.
>
> What this means is only applications which direct a user through the
> OAuth web flow will be able to receive access tokens that allow access
> to direct messages. Any other method of authorization, including
> xAuth, will only be able to receive Read/Write tokens.
>
>
> What will happen when the permission is activated
> When we activate the new permission, all Read and Read/Write
> user_tokens issued to third-party applications will lose their ability
> to read direct messages. Any attempt to read direct messages will
> result in an HTTP 403 error being returned.
>
> For example, a GET request to
> https://api.twitter.com/1/direct_messages/sent.json will return an
> HTTP 403 Forbidden with the response body:
>
> {"errors":[{"code":93,"message":"This application is not allowed to
> access or delete your direct messages"}]}
>
>
> Key Points

> * If you wish to access a user�s direct messages you will need to

> update your application and reauthorize existing tokens.
> * The only way to get direct message access is to request access
> through the OAuth /authorize web flow. You will not be permitted to
> access direct messages if you use xAuth.
> * When we enforce the permission Read/Write and Read tokens will be
> unable to access and delete direct messages.
> * Read/Write tokens will be able to send direct messages after the
> permission is enforced.
>

> We�ll be collating responses and adding more information on our

> developer resources permission model page:
> https://dev.twitter.com/pages/application-permission-model
>
> We have also blogged about this on the Twitter blog:
> http://blog.twitter.com/2011/05/mission-permission.html
>
> Best,
> @themattharris

@nuxnix

unread,
May 18, 2011, 1:29:26 PM5/18/11
to twitter-deve...@googlegroups.com
"We know this will take some time so we are allowing a transition period until the end of this month."

This is such a short timeframe for people to rebuild, QA and resubmit their apps that it will certainly mean some peoples apps will stop working while they are waiting for them to be 'approved' by their own QA, or their internal IT department, or their app store or market. I would request that you think about extending it.

Angus

janole

unread,
May 18, 2011, 1:39:39 PM5/18/11
to Twitter Development Talk
Hi Matt,

can you please give us more time to adapt to this. It is impossible to
make the appropriate changes and submit to appstore within this
timeframe.

Thanks,
Ole, Gravity Twitter Client for Symbian

On May 18, 7:01 pm, Matt Harris <thematthar...@twitter.com> wrote:
> Hey everyone,
>
> We recently updated our OAuth screens to give users greater transparency
> about the level of access applications have to their accounts. The valuable
> feedback Twitter users and developers have given us played a large part in
> that redesign and helped us identify where we can do more.
>
> In particular, users and developers have requested greater granularity for
> permission levels.
>
> In response to this feedback, we have created a new permission level for
> applications called “Read, Write & Direct Messages”. This permission will
> allow an application to read or delete a user's direct messages. When we
> enforce this permission, applications without a “Read, Write & Direct
> Messages” token will be unable to read or delete direct messages. To ensure
> users know that an application is receiving access to their direct messages,
> we are also restricting this permission to the OAuth /authorize web flow
> only. This means applications which use xAuth and want to access direct
> messages must send a user through the full OAuth flow.
>
> What does this mean for your application?
> If you do not need access to direct messages: you won’t need to make any
> changes to your application. When we enforce the new permission level your
> read or read/write token will automatically lose access to direct messages.
>
> If you do need access to direct messages: you will need to edit your
> application record onhttps://dev.twitter.com/appsand change the permission
> For example, a GET request tohttps://api.twitter.com/1/direct_messages/sent.jsonwill return an HTTP 403

Dewald Pretorius

unread,
May 18, 2011, 1:59:20 PM5/18/11
to Twitter Development Talk
Matt,

If I understand correctly, activate the new permission, all Read and
Read/Write user_tokens issued to third-party applications will lose
their ability to read direct messages.

That is a HUGE and MAJOR headache for existing apps and their
thousands of users who are currently using any of the /1/
direct_messages methods.

Can't you rather grand-father in apps and user_tokens that have
already been granted?

Ed Finkler

unread,
May 18, 2011, 2:02:43 PM5/18/11
to twitter-deve...@googlegroups.com
Matt,

Ultimately I understand the issues with xAuth and granularity. Frankly, if you just ditched xAuth entirely, I can see decent arguments for it.

However, we've made a significant investment in the xAuth UX. If we have to change it, 13 days is simply not sufficient for most devs. It will be a stretch for Spaz, given that we are all volunteer and do it in our spare time. Folks who have to deal with app store submissions and the like are even more under the thumb.

2 months, I think is much more reasonable. In addition, real effort being put forth by the dev relations team to show how to migrate to a solid oAuth flow on desktop and mobile would be very useful to many devs.

Good luck.

--
Ed Finkler
@funkatron
AIM: funka7ron / ICQ: 3922133 / XMPP:funk...@gmail.com

M. Edward (Ed) Borasky

unread,
May 18, 2011, 2:02:34 PM5/18/11
to twitter-deve...@googlegroups.com, Twitter Development Talk

--
http://twitter.com/znmeb http://borasky-research.net

"A mathematician is a device for turning coffee into theorems." -- Paul
Erdos


Quoting Matt Harris <themat...@twitter.com>:

Zac Bowling

unread,
May 18, 2011, 2:03:30 PM5/18/11
to twitter-deve...@googlegroups.com
Hi Matt,

I understand the change need to happen. In regards to xAuth though and finding an upgrade path, the assumption is that those that got access to that were developing desktop/mobile clients (not centralized services) so there is no centralized storage of tokens or user data (only in standalone applications in those applications). In a good number of the high profile applications of xAuth, it's an actual client (like TweetBot, Seesmic, Tweetdeck, etc). Those clients almost always interface with direct messages because they replicate most of the twitter features up and down. 

In that case, can you please reconsider the case of xAuth. Grandfather existing xAuth users to read, write, and direct message level. Then going forward with xAuth, evaluate the need of the app if it needs read/write/direct message on a case by case basis? You are going to break a good number of applications with that change. 

Although a month is just barely enough time to turn around an update for iOS if developers rush, it doesn't leave a lot of grace time for users that do not upgrade their applications very often. My own stats for my apps show without sending out notifications to nag the users to tell of an update (or force them to an update by sending them to the store when they launch the app), nearly half my users do not upgrade for at least 2 to 3 weeks after an update comes out. 

I hate to bring up comparisons to facebook, but they give us a good developer roadmap (http://developers.facebook.com/roadmap/ ) with a decent time line for deprecation, ramp downs, and migration paths.   

Zac 

Paul Haddad

unread,
May 18, 2011, 1:49:15 PM5/18/11
to Twitter Development Talk, Matt Harris
Hi Matt,

1.  xAuth apps are already approved by you guys and have a (I'm assuming) higher threshold to get access to. I'd really ask you guys to re-consider and allow xAuth access to DMs. Or at the very least allow clients to apply for exceptions to this rule.
2.  Under 2 weeks is way too short of a time for this big of a change.

-- 
Twitter API documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Change your membership to this group: http://groups.google.com/group/twitter-api-announce?hl=en

janole

unread,
May 18, 2011, 2:27:24 PM5/18/11
to Twitter Development Talk
I very much agree. To get xAuth, we all had to apply and undergo some
sort of verification process.

Also, if I take my app Gravity as an example, I am using xAuth (and
previously Basic Auth) since the very beginning and there have been
zero complaints from users that Gravity has been misusing the DM
feature.

Why? Well, it can't. It's a standalone, mobile application and not a
web app. I, as the author, do not have access to the users passwords
nor to their oAuth tokens.

Furthermore, Gravity is a client on the Symbian platform where you
cannot open the webbrowser for the OAuth flow on many phone models.
And there is no official client on the Symbian platform (although it
would be nice if it was Gravity :-))

Could you please re-consider this and either grandfather xauth clients
or offer a checkbox on the user's Twitter.com settings for the xAuth
clients where they can manually disable/enable DMs?

Wouldn't that be a very good decision for all xAuth clients anyway?
Just add a checkbox so the users can disable DMs if they really don't
want DMs in their mobile/etc. third party clients.

As a side note, the time to get an app through the OviStore (Nokia's
App Store) process can be quite long. I don't think 13 days will be
enough for this.

Cheers
Ole (@janole / @gravityapp)

On May 18, 7:49 pm, Paul Haddad <paul.had...@gmail.com> wrote:
> Hi Matt,
>
> 1.  xAuth apps are already approved by you guys and have a (I'm assuming) higher threshold to get access to. I'd really ask you guys to re-consider and allow xAuth access to DMs. Or at the very least allow clients to apply for exceptions to this rule.
> 2.  Under 2 weeks is way too short of a time for this big of a change.
>
> On May 18, 2011, at 12:01 PM, Matt Harris wrote:
>
>
>
>
>
>
>
>
>
> > Hey everyone,
>
> > We recently updated our OAuth screens to give users greater transparency about the level of access applications have to their accounts. The valuable feedback Twitter users and developers have given us played a large part in that redesign and helped us identify where we can do more.
>
> > In particular, users and developers have requested greater granularity for permission levels.
>
> > In response to this feedback, we have created a new permission level for applications called “Read, Write & Direct Messages”. This permission will allow an application to read or delete a user's direct messages. When we enforce this permission, applications without a “Read, Write & Direct Messages” token will be unable to read or delete direct messages. To ensure users know that an application is receiving access to their direct messages, we are also restricting this permission to the OAuth /authorize web flow only. This means applications which use xAuth and want to access direct messages must send a user through the full OAuth flow.
>
> > What does this mean for your application?
> > If you do not need access to direct messages: you won’t need to make any changes to your application. When we enforce the new permission level your read or read/write token will automatically lose access to direct messages.
>
> > If you do need access to direct messages: you will need to edit your application record onhttps://dev.twitter.com/appsand change the permission level of your application to “Read, Write and Direct Messages”. The new permission will not affect existing tokens which means existing users or your app or service will need to reauthorize.
>
> > We know this will take some time so we are allowing a transition period until the end of this month. During this time there will be no change to the access Read/Write tokens have to a users account. However, at the end of the month any tokens which have not been upgrade to “Read, Write and Direct Messages” will be unable to access and delete direct messages.
>
> > Affected APIs and requests
> > On the REST API, Read and Read/Write applications will no longer be able to use these API methods:
> > /1/direct_messages.{format}
> > /1/direct_messages/sent.{format}
> > /1/direct_messages/show.{format}
> > /1/direct_messages/destroy.{format}
>
> > For the Streaming API, both User Streams and Site Streams will only receive direct messages if the user has authorised an application to access direct messages.
>
> > Applications that use “Sign-in with Twitter” or xAuth will only be able to receive Read or Read/Write tokens.
>
> > What this means is only applications which direct a user through the OAuth web flow will be able to receive access tokens that allow access to direct messages. Any other method of authorization, including xAuth, will only be able to receive Read/Write tokens.
>
> > What will happen when the permission is activated
> > When we activate the new permission, all Read and Read/Write user_tokens issued to third-party applications will lose their ability to read direct messages. Any attempt to read direct messages will result in an HTTP 403 error being returned.
>
> > For example, a GET request tohttps://api.twitter.com/1/direct_messages/sent.jsonwill return an HTTP 403 Forbidden with the response body:
>
> > {"errors":[{"code":93,"message":"This application is not allowed to access or delete your direct messages"}]}
>
> > Key Points
> > * If you wish to access a user’s direct messages you will need to update your application and reauthorize existing tokens.
> > * The only way to get direct message access is to request access through the OAuth /authorize web flow. You will not be permitted to access direct messages if you use xAuth.
> > * When we enforce the permission Read/Write and Read tokens will be unable to access and delete direct messages.
> > * Read/Write tokens will be able to send direct messages after the permission is enforced.
>
> > We’ll be collating responses and adding more information on our developer resources permission model page:https://dev.twitter.com/pages/application-permission-model
>
> > We have also blogged about this on the Twitter blog:http://blog.twitter.com/2011/05/mission-permission.html
>
> > Best,
> > @themattharris
>
> > --
> > Twitter API documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Change your membership to this group:http://groups.google.com/group/twitter-api-announce?hl=en
>
> ---
> Paul Haddad
> paul.had...@gmail.com, p...@tapbots.com, p...@pth.com

Jon Colverson

unread,
May 18, 2011, 2:37:48 PM5/18/11
to Twitter Development Talk
Hello.

For my app, it's inconvenient that the DM permission is only available
lumped in with the write permission, because now I have to request
both even though my app has no facility for posting (it's a
notification-only app), and I expect users will (rightly) be
suspicious about that.

Also on the subject of granularity, it would be great if the app could
request DM access but make it optional, such that users can turn it
off on the authorization page. If the user declines it then the app
would be able to ask them to reauthorize if they later try to use the
DM feature of the app.

Thank you.

- Jon

Naveen

unread,
May 18, 2011, 2:42:42 PM5/18/11
to Twitter Development Talk
I had most of the same thoughts already mentioned in this thread so
wont reiterate everyone, except to add that this seems like a rather
sudden and disruptive change coming just after #devnestsf where
Twitter made a point that it was trying to provide better guidance so
companies that rely on the platform have time to plan and make
changes.

@knight9

Scott Wilcox

unread,
May 18, 2011, 2:51:55 PM5/18/11
to twitter-deve...@googlegroups.com
Hello,

There have been a lot of opinions voiced about how this is being implemented. This not only proves troublesome for xAuth clients, but it lends me to worry about how the future of permissions will evolve. Effectively now, every single Twitter user needs to get their application re-authed for the new tokens to provide DM access by the end of the month.

The Facebook style of using a 'scope' for individual permissions is so much more viable. I also believe that the API should provide a lookup for the permissions that a set of credentials currently provides. I honestly believe that going down the 'scope' route for permissions will be a lot better for all concerned. When new permissions are introduced to the API in the future, it would be a small matter of updating the requesting scope for the application developer, rather than completely rewriting chunks of code.

I'd like a response from Matt, Taylor or Raffi on this matter and the plans for future permissions and their implementation.

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

--
Scott Wilcox

@dordotky | sc...@dor.ky | http://dor.ky
+44 (0) 7538 842418 | +1 (646) 827-0580

Derek Gathright

unread,
May 18, 2011, 3:50:30 PM5/18/11
to twitter-deve...@googlegroups.com
I agree with Scott.  A token should simply be a bond between the user and the app, it should not contain any knowledge of permissions/restrictions.  A token simply represents "Hi, I'm making a call on behalf of Joe User.  Attached is the request I want to make.  Make sure I'm allowed to do this before you execute it."

Forcing re-authentication whenever permissions change is a major pain for both developers and users.  Removing permission-based tokens benefits the user because they can modify the access an application has without having to re-authenticate, something 99% of users will not understand.

mart...@gmail.com

unread,
May 18, 2011, 3:59:43 PM5/18/11
to twitter-deve...@googlegroups.com
On Wed, May 18, 2011 at 12:50:30PM -0700, Derek Gathright wrote:
> I agree with Scott. A token should simply be a bond between the user
> and the app, it should not contain any knowledge of
> permissions/restrictions. A token simply represents "Hi, I'm making a
> call on behalf of Joe User. Attached is the request I want to make.
> Make sure I'm allowed to do this before you execute it."
> Forcing re-authentication whenever permissions change is a major pain
> for both developers and users. Removing permission-based tokens
> benefits the user because they can modify the access an application has
> without having to re-authenticate, something 99% of users will not
> understand.

+1


--
Martin Dapas

Dewald Pretorius

unread,
May 18, 2011, 4:27:56 PM5/18/11
to Twitter Development Talk
The more I think about this, the less it makes any sense whatsoever to
force everyone through a re-authentication if DM access is required.

Here's why:

1) For existing user tokens, the users have already granted access
with the knowledge that it is to their DMs as well. In other words,
they have already granted access to their DMs.

2) If an app needs access to the users' DMs, it is going to force
thousands of people to waste thousands of hours to re-authorize
something they want the app to do and something they have already
implicitly granted to the app.

3) Many users are going to miss the memo, and then be very upset with
the app owner(s) because what had worked before suddenly stopped
working.

4) Additional and completely unnecessary workload and costs are going
to be added to the support staff of the app, to help users who do not
understand why they need to re-authorize, or who have missed the memo
in the first place.

5) By forcing re-authorization for apps that require DM access and
already have DM access, Twitter gains absolutely nothing. After
forcing thousands of people through a redundant process, we're back at
where we started, namely, the app has access to the user's DMs. It's
not like the user has a choice of not granting a requesting app access
to his DMs, but only to his followers and tweets. If the app request
DM access, the user can either grant it, or deny access completely.
Exactly the same way it works today.

The only benefit here is for apps who don't need DM access, which will
now be able to request account access without DM access. But, if the
app does not need or use access to DMs, it provides absolutely no
benefit to take existing DM access of already granted user tokens
away. It is not used.

It makes perfect sense to implement this change from a date going
forward, meaning all user tokens granted after that date will be
either Read, Read & Write, or Read & Write & DM. That provides more
transparency for the user. But to yank away existing access rights and
then force the equivalent of a small nation through a re-
authentication process just to re-establish what had already been
granted and then unilaterally taken away, that makes no sense at all.

Marc Mims

unread,
May 18, 2011, 4:54:09 PM5/18/11
to twitter-deve...@googlegroups.com
On Wed, May 18, 2011 at 11:37 AM, Jon Colverson <jjc...@gmail.com> wrote:
>
> Also on the subject of granularity, it would be great if the app could
> request DM access but make it optional, such that users can turn it
> off on the authorization page. If the user declines it then the app
> would be able to ask them to reauthorize if they later try to use the
> DM feature of the app.

Agreed.

I'm really disappointed with this change.

Asking users to reauthorize is a burden on both developers and users.
Existing users already gave their permission for apps to access
private messages.

The lead time for developers to respond to this change is ridiculously short.

In my opinion, Twitter should have allowed users finer grained control
over permissions, allowing them to selectively remove "private
message" permissions for existing apps.

An app should be able to request a set of default permissions. Users
should be able to accept the defaults, or selectively deny individual
permissions.

If an app has optional "private message" features, it must request
"private message" permission from *all* users. Either that or
register multiple apps for each set of appropriate permissions, which
is confusing and difficult for users and developers to manage.

Is it too late to re-think this, Twitter?

-Marc

BikerBecca

unread,
May 18, 2011, 4:47:06 PM5/18/11
to Twitter Development Talk
Quick question and a comment.

1) I see the new Default Access type as "Read, Write & Private
Message" not "Read, Write & Direct Messages." Is there a typo
somewhere?.

2) I just have to agree with everyone here that having all of our
users re-auth our app to give them access to a feature they've already
agreed to as being a pretty poor implementation of this change. The
vast majority of users will not understand why and/or what they need
to re-auth and the ones that don't will be swamping our support people
on June 1st when they no longer see their Direct Mentions. If there
is any way to grandfather in existing users who have already
authorized access to their direct messages that would be a huge help
for every company using twitter in their apps.

Thanks,
Becca


On May 18, 10:01 am, Matt Harris <thematthar...@twitter.com> wrote:
> Hey everyone,
>
> We recently updated our OAuth screens to give users greater transparency
> about the level of access applications have to their accounts. The valuable
> feedback Twitter users and developers have given us played a large part in
> that redesign and helped us identify where we can do more.
>
> In particular, users and developers have requested greater granularity for
> permission levels.
>
> In response to this feedback, we have created a new permission level for
> applications called “Read, Write & Direct Messages”. This permission will
> allow an application to read or delete a user's direct messages. When we
> enforce this permission, applications without a “Read, Write & Direct
> Messages” token will be unable to read or delete direct messages. To ensure
> users know that an application is receiving access to their direct messages,
> we are also restricting this permission to the OAuth /authorize web flow
> only. This means applications which use xAuth and want to access direct
> messages must send a user through the full OAuth flow.
>
> What does this mean for your application?
> If you do not need access to direct messages: you won’t need to make any
> changes to your application. When we enforce the new permission level your
> read or read/write token will automatically lose access to direct messages.
>
> If you do need access to direct messages: you will need to edit your
> application record onhttps://dev.twitter.com/appsand change the permission
> For example, a GET request tohttps://api.twitter.com/1/direct_messages/sent.jsonwill return an HTTP 403

Chad Etzel

unread,
May 18, 2011, 6:47:44 PM5/18/11
to twitter-deve...@googlegroups.com
Aside from all the emotional/philosophical stuff in this thread, I am
concerned about a major possible bug:

I have updated my apps to use Read/Write/DM permissions, and then it
saves it as Read-Only... I tried to change it back to just Read/Write,
and again it is saved as Read-Only.

Is anyone else having this problem? Users are going insane...

-Chad

Chad Etzel

unread,
May 18, 2011, 6:55:16 PM5/18/11
to twitter-deve...@googlegroups.com
nevermind, i must have been out of the loop.. i was using the old form

so use http://dev.twitter.com/apps

and DO NOT USE http://twitter.com/apps (which, should be deleted or
auto-forwarded or something....)

caramba,
-chad

Zac Bowling

unread,
May 18, 2011, 7:50:10 PM5/18/11
to twitter-deve...@googlegroups.com
Matt, 

This maybe a harder architectural shift, but a better solution would be to move permissions from being per application, but instead a per authentication token method, wherein that each token stores the permissions that the app requested and was granted at the time they authorized. 

So in this case, let us pass in a well know list of fine grain permissions we want/need when we make an oAuth request and then offer an end point to authorize for additional permissions when needed to upgrade a token's access in the future as new features come out. 

In the case of xAuth, doing this wouldn't be as disruptive as all existing tokens would have all the permissions they intended when they were requested. In that xAuth could have a default permission level as set by Twitter when someone requests access to xAuth. 

Zac



mostafa farghaly

unread,
May 18, 2011, 7:51:39 PM5/18/11
to twitter-deve...@googlegroups.com
Please exclude xAuth mobile clients from this, logically and from the usability point of view, it doesn't make any sense, the user authorize my app to use his account, why i ask for his authorization again to view his Direct messages, why you insist on making our life very hard :(


Andrew W. Donoho

unread,
May 18, 2011, 7:59:45 PM5/18/11
to twitter-deve...@googlegroups.com

On May 18, 2011, at 12:01 , Matt Harris wrote:

> We know this will take some time so we are allowing a transition period until the end of this month.


Gentlefolk,

This is way too short an amount of time to implement OAuth and transition mobile users off of an xAuth based client. (In my experience, my user base upgrades an app over a full quarter of a year.) Furthermore, even if I was ready right now with a submission to Apple, there is a very good chance that my app would not be approved by your deadline.

Please reconsider this deadline.

Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
a...@DDG.com, +1 (512) 750-7596, twitter.com/adonoho

"We did not come to fear the future.
We came here to shape it."

-- President Barack Obama, Sept. 2009


themattharris

unread,
May 18, 2011, 8:11:24 PM5/18/11
to Twitter Development Talk
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
Message has been deleted

Zac Bowling

unread,
May 18, 2011, 8:38:33 PM5/18/11
to twitter-deve...@googlegroups.com
Thanks Matt! 

I still urge you to reconsider the mass breakage of older existing apps, and crippling of the mobile/desktop app user experiences going forward. 

My own judgement is that yes, maybe the user didn't realize that they didn't want to give that level of access and maybe the web flow can help twitter communicate to the user better what they app is request, but it's going up against all the issues of users that already authorized are not expecting things to break. It also throws away all the constant re-hashing went through before basic auth went away around the UX of oAuth that drove the development of xAuth in the first place.  

I fear it's going to be litteral countdown until doomsday and hell is going to break out of users and developers that didn't get the memo. (I just checked, and my mother is still using a twitter client for the iPad that was updated over 4 months ago.)

Zac 

Dewald Pretorius

unread,
May 18, 2011, 8:46:26 PM5/18/11
to Twitter Development Talk
> Please continue to send
> us your feedback about the permission model and what you would like to
> see it offer.

Why?

James Peter

unread,
May 18, 2011, 10:08:13 PM5/18/11
to Twitter Development Talk
Thanks Matt,

Two important implementation questions that aren't 100% clear from
that announcement or any supporting docs at this point;

1) "we are also restricting this permission to the OAuth /authorize
web flow only"
To be clear, does this include using the OAuth "/authenticate" method
as well as the "/authorize" method?

2) The method direct_messages/new is not included the list of affected
requests, so sending (writing) DMs does not requires Private Message
permission?


Regards,
James

janole

unread,
May 19, 2011, 2:50:44 AM5/19/11
to Twitter Development Talk
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 )

Adriaan Pelzer

unread,
May 19, 2011, 3:02:41 AM5/19/11
to twitter-deve...@googlegroups.com
Hi Matt,

I have started implementing these changes. The app's permissions setting is set to "Read, Write & DM" (the new one).

However, when the user gets redirected to the auth page, it still indicates that the app will not be able to read or send DM's. Is this something that will automatically happen when you activate it, or is there a permissions parameter I should send to the auth page?


Adriaan Pelzer

 //))//\\//\\||//
//\\//7//7///\\

putting you in touch with your crowds
skype: adriaan_pelzer
+4478 7978 1743



On Wed, May 18, 2011 at 6:01 PM, Matt Harris <themat...@twitter.com> wrote:
Hey everyone,

We recently updated our OAuth screens to give users greater transparency about the level of access applications have to their accounts. The valuable feedback Twitter users and developers have given us played a large part in that redesign and helped us identify where we can do more.

In particular, users and developers have requested greater granularity for permission levels.

In response to this feedback, we have created a new permission level for applications called “Read, Write & Direct Messages”. This permission will allow an application to read or delete a user's direct messages. When we enforce this permission, applications without a “Read, Write & Direct Messages” token will be unable to read or delete direct messages. To ensure users know that an application is receiving access to their direct messages, we are also restricting this permission to the OAuth /authorize web flow only. This means applications which use xAuth and want to access direct messages must send a user through the full OAuth flow.


What does this mean for your application?
If you do not need access to direct messages: you won’t need to make any changes to your application. When we enforce the new permission level your read or read/write token will automatically lose access to direct messages.

If you do need access to direct messages: you will need to edit your application record on https://dev.twitter.com/apps and change the permission level of your application to “Read, Write and Direct Messages”. The new permission will not affect existing tokens which means existing users or your app or service will need to reauthorize.

We know this will take some time so we are allowing a transition period until the end of this month. During this time there will be no change to the access Read/Write tokens have to a users account. However, at the end of the month any tokens which have not been upgrade to “Read, Write and Direct Messages” will be unable to access and delete direct messages.


Affected APIs and requests
On the REST API, Read and Read/Write applications will no longer be able to use these API methods:
/1/direct_messages.{format}
/1/direct_messages/sent.{format}
/1/direct_messages/show.{format}
/1/direct_messages/destroy.{format}

For the Streaming API, both User Streams and Site Streams will only receive direct messages if the user has authorised an application to access direct messages.

Applications that use “Sign-in with Twitter” or xAuth will only be able to receive Read or Read/Write tokens.

What this means is only applications which direct a user through the OAuth web flow will be able to receive access tokens that allow access to direct messages. Any other method of authorization, including xAuth, will only be able to receive Read/Write tokens.


What will happen when the permission is activated
When we activate the new permission, all Read and Read/Write user_tokens issued to third-party applications will lose their ability to read direct messages. Any attempt to read direct messages will result in an HTTP 403 error being returned.

For example, a GET request to https://api.twitter.com/1/direct_messages/sent.json will return an HTTP 403 Forbidden with the response body:

{"errors":[{"code":93,"message":"This application is not allowed to access or delete your direct messages"}]}


Key Points
* If you wish to access a user’s direct messages you will need to update your application and reauthorize existing tokens.
* The only way to get direct message access is to request access through the OAuth /authorize web flow. You will not be permitted to access direct messages if you use xAuth.
* When we enforce the permission Read/Write and Read tokens will be unable to access and delete direct messages.
* Read/Write tokens will be able to send direct messages after the permission is enforced.

We’ll be collating responses and adding more information on our developer resources permission model page: https://dev.twitter.com/pages/application-permission-model

We have also blogged about this on the Twitter blog: http://blog.twitter.com/2011/05/mission-permission.html

Best,
@themattharris

--

janole

unread,
May 19, 2011, 4:29:22 AM5/19/11
to Twitter Development Talk
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 )

Tammy Fennell

unread,
May 19, 2011, 7:03:20 AM5/19/11
to Twitter Development Talk
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

Damon Parker

unread,
May 19, 2011, 8:44:11 AM5/19/11
to twitter-deve...@googlegroups.com
In any security or permissions context the default should be the most secure and least amount of permissions to get the job done.  That is Computer and Network Security 101.  

A user must explicitly configure more loose permissions on their own after understanding the implications.  This is the way computer network security is and always has been done.  This is part of the reason Linux/Unix et al is way more secure than Windows ever could be.

Just because a user isn't sophisticated enough to configure more lax permissions to get their needs met isn't a reason to default to lower the security context.  This is what FB did _completely_ wrong when they updated their permissions system.  They defaulted everything to being completely open, accessible and public for purely selfish reasons.  They wanted to keep more user data 100% public thus increasing the amount of public and free (as in $ to FB) user-generated content created every day. More pageviews, more pics, more comments equals more ad revenue for them.

Even though it's a pain in the ass for developer's to rework their apps and re-auth it's the right thing to do for the end user and the overall safety of the community.

I commend Twitter for doing the right (even if unpopular) thing in this case.



Damon

Tammy Fennell

unread,
May 19, 2011, 9:41:55 AM5/19/11
to Twitter Development Talk
For some developers it's not just a pain in the you know what, it's a
case of it simply not working. @janole explained how it just doesn't
work with symbian. For me, and adobe air app, it's a pain, but we can
get over the inconvenience - although it's always nice to have a bit
more time. I think 8 to 12 weeks should be standard for changes of
this magnitude whenever possible.

TheGuru

unread,
May 19, 2011, 9:42:21 AM5/19/11
to Twitter Development Talk
+1. I'm seeing the same thing and not sure if it is a waiting game or
something that needs adjusted in the flow from the client side as
well.

Any insight is appreciated.

Has anyone who adjusted their app permissions on dev.twitter.com seen
this reflected on the OAuth login page at Twitter?

On May 19, 2:02 am, Adriaan Pelzer <adri...@wewillraakyou.com> wrote:
> Hi Matt,
>
> I have started implementing these changes. The app's permissions setting is
> set to "Read, Write & DM" (the new one).
>
> However, when the user gets redirected to the auth page, it still indicates
> that the app will not be able to read or send DM's. Is this something that
> will automatically happen when you activate it, or is there a permissions
> parameter I should send to the auth page?
>
> Adriaan Pelzer
>
>  //))//\\//\\||//
> //\\//7//7///\\
>
> putting you in touch with your crowdshttp://www.wewillraakyou.com
> <http://www.wewillraakyou.com>twitter:http://www.twitter.com/adriaan_pelzer
> linkedIn:http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
> skype: adriaan_pelzer
> <http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/>
> +4478 7978 1743
>
> On Wed, May 18, 2011 at 6:01 PM, Matt Harris <thematthar...@twitter.com>wrote:
>
>
>
>
>
>
>
> > Hey everyone,
>
> > We recently updated our OAuth screens to give users greater transparency
> > about the level of access applications have to their accounts. The valuable
> > feedback Twitter users and developers have given us played a large part in
> > that redesign and helped us identify where we can do more.
>
> > In particular, users and developers have requested greater granularity for
> > permission levels.
>
> > In response to this feedback, we have created a new permission level for
> > applications called “Read, Write & Direct Messages”. This permission will
> > allow an application to read or delete a user's direct messages. When we
> > enforce this permission, applications without a “Read, Write & Direct
> > Messages” token will be unable to read or delete direct messages. To ensure
> > users know that an application is receiving access to their direct messages,
> > we are also restricting this permission to the OAuth /authorize web flow
> > only. This means applications which use xAuth and want to access direct
> > messages must send a user through the full OAuth flow.
>
> > What does this mean for your application?
> > If you do not need access to direct messages: you won’t need to make any
> > changes to your application. When we enforce the new permission level your
> > read or read/write token will automatically lose access to direct messages.
>
> > If you do need access to direct messages: you will need to edit your
> > application record onhttps://dev.twitter.com/appsand change the
> >https://api.twitter.com/1/direct_messages/sent.jsonwill return an HTTP

Adriaan Pelzer

unread,
May 19, 2011, 9:45:30 AM5/19/11
to twitter-deve...@googlegroups.com
I have created a new app as a test, with the new permission level. In the OAuth dialog it still explicitly states that the app will not be able to read or send DM's. My guess is that I either have to specify the permission level with a variable, or that it is not enabled yet.

Any ideas which it is?

Adriaan Pelzer

 //))//\\//\\||//
//\\//7//7///\\
putting you in touch with your crowds
+4478 7978 1743

Mark Pavlidis

unread,
May 19, 2011, 10:12:56 AM5/19/11
to Twitter Development Talk
On May 18, 1:01 pm, Matt Harris <thematthar...@twitter.com> wrote:
> If you do need access to direct messages: you will need to edit your
> application record onhttps://dev.twitter.com/appsand change the permission
> level of your application to “Read, Write and Direct Messages”. The new
> permission will not affect existing tokens which means existing users or
> your app or service will need to reauthorize.
>

1. Despite the added dev time and complexity, from a user perspective
I thank Twitter for increasing the granularity of security. Yes most
devs don't misuse it but it only take one bad apple.

2. I have changed the permission level for my application. When I view
the permission on https://twitter.com/settings/applications is shows
"read, write, and private message access" despite the fact that I have
not updated the existing token. This is misleading to the user. They
might think their current token is RWPM but it is really only RW. I
understand the complexities in reporting this accurately, but it will
lead to confusion.

3. I have not seen a method we can effectively test this besides
changing our code and waiting for PMpocalypse. Nor found a way to
obtain the current permissions of the token in use. Having access to
either would give me more confidence that my app won't break come June
14th.

Thanks,
Mark Pavlidis

Frank Ash

unread,
May 19, 2011, 5:39:46 AM5/19/11
to Twitter Development Talk
Thanks for the info Matt. It is much appreciated.

However, you guys really need to stop doing this type of stuff. The
war on client apps is getting a bit out of control. They grow the
twitter userbase, and dev's helped make twitter what it is and sustain
its growth by offering many different ways to connect on various
devices, with different UI's that lots of users like, and in places
and ways it may not be available otherwise. And some users effected by
these clients going down, will never use twitter again since their
favorite app or site is now gone, they would just rather not mess with
getting a new one and move on.

You dont have to control the market to capitalize on control of the
user base. If more effort was spent on an iAds type program like for
Twitters case could be TwitAds for developers to integrate, then you
would be making much more in the long run. Or even adding in ads to
the API streams with revenue sharing for clients. Then just have a
good standard guideline for UI, data access and usage, then boom, no
more stress of loosing control. No more having to buy Tweetdeck for 50
million because it controls too much. Just add in revenue sharing from
ads and clear guidelines for clients, then your problem is solved. But
the way it is being looked out now is not sustainable or realistic in
todays market from my perspective.

Developers are scared to death all the time because we know there
will be something new (like this) every other month or so and we are
just waiting for that final one that cuts our legs out from under us
completely. I dont think Twitter should see it as taking away, but the
potential it has to add many more users to the system, and if they
look at revenue differently than just twitter controlling all ads and
clients do their own, they would see a much higher spike in revenue
and clients would have a standard system they could use for their
revenue stream as well. Then if you need to do quality control thats
understandable, just lay out the requirements in simple terms, show
some examples, make them realistic, then we all make money and twitter
continues it growth with the help of Dev's. But without the wealth and
diversity of client apps, you will see slower growth, and less user
engagement.

janole

unread,
May 19, 2011, 12:14:34 PM5/19/11
to Twitter Development Talk
Damon,

with all due respect and in all politeness, have you even read what
this thread is about?

Do you really think an xAuth application - that knows the users full
credentials - is getting more secure without the right to access
direct messages? I mean ... really ;-)

We both do not know why Twitter tries to introduce this change. I have
a feeling what it is about, but it's definitely not about user privacy
or security if it comes to xAuth applications.

OAuth apps, granted, different story and I could live with that
change. But as I am not using OAuth, I leave it to the developers
affected to voice their concerns. They should know better.

For me, who needs to have xAuth access to provide my users access to
Twitter - actually to provide it to the Symbian platform ( biggest
smartphone OS worldwide, 2010 ... ) - these changes are not good.

And my users do think the same.

Most of my users love Twitter and I try to provide a client that makes
them use Twitter a lot - because I love Twitter, too ( well, better to
say, I am addicted to Twitter. )

I just don't see any reason why this privacy related change couldn't
be implemented in a way which does NOT break so many applications.

We are also talking about preloaded mobile apps here - apps that
cannot be changed quickly - or cannot be changed at all.

My planned work-around for this xAuth change ( I still hope it is
being reverted! ) will include running a Twitter service for
authentication. That way, I would have access to my users' OAuth
tokens. I don't like that. It imposes a great risk to me and my
servers being hacked. So far, I do not know nothing about my users via
my Twitter client. No password, no credentials. I like it that way.
More secure for my users.

As for Linux, yes, we all know Linux is way more secure. That's why
companies like Sony and Gawker are running their services on top of
Linux servers ... okay, forget about that one ;-)

Cheers & please don't feel offended,
Ole ( @janole / @gravityapp )

Steve Streza

unread,
May 19, 2011, 12:56:28 PM5/19/11
to Twitter Development Talk
If you're a developer who got bit in the ass by this move by Twitter,
and need to migrate your application from using xAuth to using OAuth,
I have a sample project which shows you how to obtain authorization
for a user. It's Objective-C, but the concepts should be applicable to
whatever language you're coding in. You can check it out at
https://github.com/amazingsyco/oauthery.

Steve

Damon Parker

unread,
May 19, 2011, 1:20:48 PM5/19/11
to twitter-deve...@googlegroups.com
Janole

None, taken.  I am a network sysadmin, developer and ultimately businessman so I do know a little bit about how they are all related.

I understand you are in a slightly different position having to deal with xAuth.  However, xAuth is not a secure system in itself.  Any system that passes a user and password through a third party cannot be secure.  Yes you are "supposed" to discard the info after the initial tokens are exchanged and received back, but there is no proof that actually happens.  A third party still had access to my username and password.

From a purely network and security standpoint xAuth should be done away with in lieu of newer more secure methods where no one other than myself and the service I am accessing know my password.  For that matter, the service shouldn't know my password either beyond when I submit it as it should be hashed and that token saved instead of the raw password.  Authentication then involves comparing two hashes instead of two raw text passwords.

In your case you are limited by the the underlying OS from achieving a traditional OAuth flow.  Your work around sounds like it will suffice and is no less potentially insecure than the existing if properly setup.

You say you "know nothing" about your users under the current system, and that's the way it should be.  But that is you in your specific case, being I'm sure an honest developer.  Allowing insecure methods to continue though, lowers the security of the whole.  It only takes one bad app to screw a bunch of users and ultimately it's Twitter who would have the proverbial egg on the face.  The app developer would be banned and forgotten.

I'm not happy about this change being forced down everyone's throat so quickly as much as the next developer.  In my option more levels of privacy and security should have been rolled out all at once instead of this one change.  This change fixes one minor problem when a more broad change to add finer-grained permissions could have been rolled out and affected third-party developers not much more than this current one.  

I also suspect as you hinted there may be other more selfish reasons partly behind such changes and have written several articles about the subject.  http://bit.ly/lFZuZC

But as I said... from a purely network and security standpoint the changes are sound. Economics and competition may be a different story.



damonp

Ron

unread,
May 19, 2011, 1:25:20 PM5/19/11
to Twitter Development Talk
Users do not need protection from their personal mobile Twitter
clients any more than they do from their browsers. It's their app
running on their device accessing their account at their direction.
Requiring separate authentication for DMs for a mobile client app is
like requiring separate cars keys for ignition, gas pedal, and
breaks. Millions of mobile Twitter users are going to get really
ticked off when they can no longer use their favorite apps. So let's
be honest. When it comes to Twitter mobile clients, this isn't about
user security. It's about pruning client competition from the market.

Ron

Mark Pavlidis

unread,
May 19, 2011, 1:49:43 PM5/19/11
to Twitter Development Talk
Yes i've seen the changes on my applications page and on the OAuth
login page. Further, my other device that was logged in using the old
Read,Write token was getting Unauthorized (401) responses as that
token was revoked an replaced with the Read, Write, Private message
token. Should be handled appropriately if you are a dev with an app
on multiple platforms.

Mark
> > > application record onhttps://dev.twitter.com/appsandchange the
> > >https://api.twitter.com/1/direct_messages/sent.jsonwillreturn an HTTP

Damon Parker

unread,
May 19, 2011, 2:00:45 PM5/19/11
to twitter-deve...@googlegroups.com
It will be interesting to see where the PR nightmare falls more squarely on when it happens...  Twitter or the app developers themselves.  We will get the tech support nightmare but if recent history is any indication (ie. Ubertwitter ban) many users are going to ultimately blame Twitter.



-- 
damonp

TheGuru

unread,
May 19, 2011, 2:04:08 PM5/19/11
to Twitter Development Talk
That is to be expected regarding the 401.

However, while I see the changes on the application page of a
particular account, the OAuth login screen at Twitter for my
application still states:

This application will not be able to:

Access your private messages.
See your Twitter password.

Did you make any other changes other than upading the privilege level
for your application at dev.twitter.com?
> > > >https://api.twitter.com/1/direct_messages/sent.jsonwillreturnan HTTP

Mark Pavlidis

unread,
May 19, 2011, 2:13:33 PM5/19/11
to Twitter Development Talk
TheGuru,
I set my app to RWPM permission at dev.twitter.com/apps and now it
displays as such on the OAuth login page and on twitter.com/settings/
applications.

TheGuru

unread,
May 19, 2011, 2:16:28 PM5/19/11
to Twitter Development Talk
Hmm, thanks.

Wonder why some are seeing this take affect and others, as reported in
this thread (including myself), are not...

janole

unread,
May 19, 2011, 2:16:40 PM5/19/11
to Twitter Development Talk
Hi Damon,

> None, taken. I am a network sysadmin, developer and ultimately businessman so I do know a little bit about how they are all related.

Cool, so we have exactly the same background :-)

> I understand you are in a slightly different position having to deal with xAuth. However, xAuth is not a secure system in itself. Any system that passes a user and password through a third party cannot be secure. Yes you are "supposed" to discard the info after the initial tokens are exchanged and received back, but there is no proof that actually happens. A third party still had access to my username and password.

This seems more like a question of philosophy. You certainly cannot
say xAuth / disclosing passwords to third party apps is insecure while
oAuth is secure. In the end, the risk is exactly the same: a malicious
app impersonating you and sending spam links or fishing links in your
name. No matter if you use xAuth or OAuth. Such a malicious app can
and will do the very same.

The only advantage of OAuth for the user: he doesn't need to change
his password. The obvious disadvantage of this: the user thinks that
OAuth makes his password secure. But you - as an admin - know very
well that passwords of "users" are seldom secure. Usually, they use
the same password for everything and it's their name and their
birthdate or so. But they shouldn't. You should use a specific
password only for Twitter, another for Facebook, another for ... and
so on. Why have people been so upset about the Sony hack? Their
usernames and passwords are the same for all the services they use ...

> In your case you are limited by the the underlying OS from achieving a traditional OAuth flow. Your work around sounds like it will suffice and is no less potentially insecure than the existing if properly setup.

Well, the workaround makes me a Twitter service "provider" and makes
me responsible to take care of my users OAuth tokens. I think there is
a difference. If I tell my users that I have access to their accounts
soon, whereas before I haven't had, I think they will find the new
solution less secure.

> You say you "know nothing" about your users under the current system, and that's the way it should be. But that is you in your specific case, being I'm sure an honest developer. Allowing insecure methods to continue though, lowers the security of the whole. It only takes one bad app to screw a bunch of users and ultimately it's Twitter who would have the proverbial egg on the face. The app developer would be banned and forgotten.

But this will happen anyways. Twitter said they have to revoke
hundreds of apps per day. It is happening and xAuth/OAuth is the way
to keep the platform clean. There will be malicious apps even without
xAuth.

Actually, I bet that Twitter only has to revoke OAuth apps and never
xAuth apps. Only Twitter itself could disclose this info, but my
reasoning is: if someone breaches the privacy, will he get access to
xAuth again? I mean, we developers would risk a lot. That's why
there's some "approval process" in place for xAuth.

> I'm not happy about this change being forced down everyone's throat so quickly as much as the next developer. In my option more levels of privacy and security should have been rolled out all at once instead of this one change. This change fixes one minor problem when a more broad change to add finer-grained permissions could have been rolled out and affected third-party developers not much more than this current one.

Yes, I agree. And I think there are a lot of options for implementing
this new security "feature" and even more stricter privacy or security
options - but without breaking current implementations. It would be
very easy to do so.

That's why I am concerned about this move. Not granting DM access to
xAuth apps doesn't really make sense in my opinion.

> I also suspect as you hinted there may be other more selfish reasons partly behind such changes and have written several articles about the subject.http://bit.ly/lFZuZC

Oh, didn't know about that one. No, I had something else on my
mind ...

I'd just like to continue working on my Twitter client and using
Twitter the way I've done for the last three years or so. I think
Twitter and third party devs can get along if we both want to, and I
think we do :-)

Again, I hope I didn't offend you with my first reply :-)
Ole

Adriaan Pelzer

unread,
May 19, 2011, 2:56:00 PM5/19/11
to twitter-deve...@googlegroups.com
I've also been trying to figure this out. Could someone from Twitter maybe respond?

My assumption is that it will stay in this state until they activate it. Is this right, or do we have to pass an extra permission parameter?

Sent from my iPod

Message has been deleted

themattharris

unread,
May 19, 2011, 4:17:11 PM5/19/11
to Twitter Development Talk
Hey everyone,

There has been some really great discussion and questions since the
last set of answers. I've responded to the ones we seen since last
night below.

> Can Read/Write applications send direct messages?
Yes. Read/Write tokens can send direct messages using direct_messages/
new.

The endpoints which will require the R/W/DM permission will be:
- /1/direct_messages.{format}
- /1/direct_messages/sent.{format}
- /1/direct_messages/show.{format}
- /1/direct_messages/destroy.{format}


> I adjusted my application permissions but the OAuth login still shows no permissions for direct messages. Should this change have been immediate?
The permission level for your application can be edited on
http://dev.twitter.com/apps. When the website is busy, it can take a
little bit longer for changes to your application to be reflected.


> Is using a web view against the Terms of Service (TOS)?
Using an in-app web view to show the OAuth pages is not against our
TOS. However, we encourage developers to use the built-in browser
where appropriate.


> You said you were restricting this permission to the OAuth /authorize web flow only. Will /oauth/authenticate (Sign in with Twitter) support the new permission?
The R/W/DM permission can only be granted through the /oauth/authorize
route. Sign in with Twitter cannot be used to grant R/W/DM.

We understand applications may use other methods of authentication
like Sign in with Twitter as well. For this reason, if a user has
authorised your application for R/W/DM and you direct them through
Sign in with Twitter, we will respect the existing access token
permission. This means you can use Sign in with Twitter after a user
has authorized your application for R/W/DM.


> I’ve read that users will be asked to do this on every use of an application, is that true?
No, this is a misunderstanding. The way OAuth works hasn’t changed and
users only need to authorize an application once. Remember we do not
expire access tokens and the only time users have to reauthorize is
when an application requests them to.


> Wouldn't it be possible to keep the DM access rights with xAuth and only revoke it upon user complaints or your monitoring of API usage?
The reason for asking users to reauthorize is so they can make a more
informed decision about the access an application has requested.

There may be users of your application who are comfortable with the
level of access you have requested, while there could be others who
complain. By having the user re-authorize, they get to decide if they
agree with the access your application has requested.


> The way it's being taken in the news is that Twitter is doing this because developers have been abusing their privacy.
The new permission level has been added in response to user and
developer requests for more clarity around the access an application
has to an account.


> I have not seen a method we can use to effectively test this besides changing our code and waiting?
When the new permission is enforced we will return an HTTP 403
Forbidden error with the response body:

{"errors":[{"code":93,"message":"This application is not allowed to
access or delete your direct messages"}]}


> How do we know what the access level of a user token is?
This is a great idea and one the team has discussed. What we are going
to do is add a new header to authentication requests that will tell
you the access level of the token you authenticated with. We’re
working on this now and hope to have it released in the next few days.


> We support multiple accounts in our application, how do we force a login on the authorize flow?
Currently the only flow that supports the force_login parameter is /
oauth/authenticate but adding it to /oauth/authorize flow is a good
idea. We’ll begin working on this now and will let you know when it is
released.


> Is there sample code we can use that shows the appropriate OAuth flow and how to handle multiple users?
This is a great idea and one which is best handled by our client
teams. When they have some example code we’ll let you know.


> How do I specify a custom callback URL? The website won’t let me.
You can set the callback dynamically during the request_token phase of
OAuth. To this you should register your application as browser based,
and put a placeholder URL in the callback box. The placeholder URL
should be something like the about page of your application. Custom
callbacks can only be specified at runtime and cannot be registered as
the default callback of an application.

More information on the request_token method is provided on our
developer resources site: http://dev.twitter.com/doc/post/oauth/request_token

Be sure to include a path with your callback. For example: myapp://oauth_complete

We're collating all these questions and answers on the developer
resources site. If your email client doesn't render the responses
above clearly please visit https://dev.twitter.com/pages/application-permission-model

Best,
@themattharris

Mark Krieger

unread,
May 19, 2011, 4:23:20 PM5/19/11
to Twitter Development Talk
I could not agree more! I was about to write the same when I saw this
message.

I do not mind changing the Read/Write on my apps page. I do not even
mind
having to change my app to allow 'Re-connect' to re-authenticate. Even
though it is
a pain (but it is done at least).

I DO mind now having to live with many many users not reading our mail
about having
to re-authenticate and then being angry with my company. They'll even
be angry at us
and confused that they have to re-auth if they do read the email,
since they knew what
they were doing when they auth'd in the first place.

Twitter: Please grandfather in old users who've accepted that their
DMs are being
sent and received by our apps. It will save us and our users from a
lot of headache.

Thanks,

Mark Krieger, Mediaroost @mediaroost, home of TweetRoost

On May 18, 4:27 pm, Dewald Pretorius <dpr...@gmail.com> wrote:
> The more I think about this, the less it makes any sense whatsoever to
> force everyone through a re-authentication if DM access is required.
>
> Here's why:
>
> 1) For existing user tokens, the users have already granted access
> with the knowledge that it is to their DMs as well. In other words,
> they have already granted access to their DMs.
>
> 2) If an app needs access to the users' DMs, it is going to force
> thousands of people to waste thousands of hours to re-authorize
> something they want the app to do and something they have already
> implicitly granted to the app.
>
> 3) Many users are going to miss the memo, and then be very upset with
> the app owner(s) because what had worked before suddenly stopped
> working.
>
> 4) Additional and completely unnecessary workload and costs are going
> to be added to the support staff of the app, to help users who do not
> understand why they need to re-authorize, or who have missed the memo
> in the first place.
>
> 5) By forcing re-authorization for apps that require DM access and
> already have DM access, Twitter gains absolutely nothing. After
> forcing thousands of people through a redundant process, we're back at
> where we started, namely, the app has access to the user's DMs. It's
> not like the user has a choice of not granting a requesting app access
> to his DMs, but only to his followers and tweets. If the app request
> DM access, the user can either grant it, or deny access completely.
> Exactly the same way it works today.
>
> The only benefit here is for apps who don't need DM access, which will
> now be able to request account access without DM access. But, if the
> app does not need or use access to DMs, it provides absolutely no
> benefit to take existing DM access of already granted user tokens
> away. It is not used.
>
> It makes perfect sense to implement this change from a date going
> forward, meaning all user tokens granted after that date will be
> either Read, Read & Write, or Read & Write & DM. That provides more
> transparency for the user. But to yank away existing access rights and
> then force the equivalent of a small nation through a re-
> authentication process just to re-establish what had already been
> granted and then unilaterally taken away, that makes no sense at all.

janole

unread,
May 19, 2011, 4:36:30 PM5/19/11
to Twitter Development Talk
Hi Matt,

thanks for the follow-up. I've still got some questions ... ;-)

> > Can Read/Write applications send direct messages?
>
> Yes. Read/Write tokens can send direct messages using direct_messages/
> new.

Does this mean xAuth applications can still send direct messages but
not read them?

> > Wouldn't it be possible to keep the DM access rights with xAuth and only revoke it upon user complaints or your monitoring of API usage?
>
> The reason for asking users to reauthorize is so they can make a more
> informed decision about the access an application has requested.
>
> There may be users of your application who are comfortable with the

Unfortunately, my app is a Twitter client. You won't find any user
being uncomfortable with reading their direct messages in my Twitter
client.

I'm just wondering, would it help asking my users and provide some
feedback from them? Like maybe 10.000 saying they want to continue to
use direct messages within Gravity? Would that help?

> level of access you have requested, while there could be others who
> complain. By having the user re-authorize, they get to decide if they
> agree with the access your application has requested.

Yes, that's fine, but my users simply cannot re-authorize using OAuth.
This is not possible on many Symbian apps/phones. Isn't there any
other way? You will lock out a lot of people next month.

Does this make sense given that xAuth apps do have access to the
users' passwords!? I don't really understand this.

Apart from the problem that Symbian apps cannot open the browser on
some phones, the current Oauth login page is even crashing the browser
on some of the models. Are you aware of this?

Cheers
Ole

janole

unread,
May 19, 2011, 4:45:25 PM5/19/11
to Twitter Development Talk
Hi Mark,

I am still having the same problem like TheGuru. I've created a new
app with RWPM and modified an old app. Both still show as "... not be
able to: Access your private messages."

How did you manage to get it to work?

Ole