A new permission level

[Matt Harris]

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]

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]

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]

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]

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

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]

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]

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

http://funkatron.com

@funkatron

AIM: funka7ron / ICQ: 3922133 / XMPP:funk...@gmail.com

[M. Edward (Ed) Borasky]

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

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]

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

---

Paul Haddad

paul....@gmail.com, pa...@tapbots.com, pa...@pth.com

[janole]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Zac Bowling]

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]

> Please continue to send
> us your feedback about the permission model and what you would like to
> see it offer.

Why?

[James Peter]

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]

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]

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

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

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

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]

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]

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]

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]

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

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

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

+4478 7978 1743

[Mark Pavlidis]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Hmm, thanks.

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

[janole]

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]

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

[themattharris]

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]

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]

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]

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

[Frank Ash]

I wish they would just tell the developers to go to hell in a way and let us know they hate us instead of doing these back handed attacks on our apps all the time. This has very very little to do with privacy. Especially for the developer that wants to abuse accounts, this doesn't stop them and serves no real purpose. And putting it to the media as we having access to their DM's is misguided at best. Users now think we are reading their DM's and have access to monitoring their conversations. Which is just crap.

This is all about clients having a large control over the twitterverse and the mismanagement of the situation by Twitter execs. Seeing us instead as competitors for the same resource. To disguise this as a security issue is laughable at best and a bit insulting. You have to realize the benefit Twitter is getting to know why they are doing this. It isn't mandatory to break all the client apps to make this change, but its convenient for Twitters current attack scheme on client apps.

This will cause mass exodus from 3rd party apps. If you have an app now, you are about to face a wave of pissed off people and bad reviews. There is no way you can realistically avoid this, and they know that. Thats the real meaning for this not because we all wanted it and have been requesting it. No serious Dev would want this. Maybe we want some more security options like Facebook has but we don't want to ruin our relationship with our customers to get it.

Twitter should hire some people with sense enough to know how to work with developers. It is no secret that Twitter is at war with the devs, so just tell us yes or no. You want us or you don't. Opening up for developers helped grow Twitter, now they don't need us anymore so they want to weed us out because "we control too much of their market" again, the same market we all created for them.

All this whole thing does is make people weary of client apps with saying we can access their DM's and then a whirlwind of confusion and complaints from our users will guarantee we loose many many users. Think about the normal person that uses tweetdeck. They will load the all, see nothing, and think its broken. If they figure out they need to confirm their info again and accept new permissions, they will be confused and weary as to why they have to do that. There is NO positive outcome for developers or their customers on this. It's a shame that we keep getting slammed with these sneaky back door slaps in the face disguised as some enhancement for users and more laughable, developers.

[Damon Parker]

On that day when your users open up our various clients and see issues with direct messages I suggest you insert your own DMs to your users with succinct descriptions to the root of the problem and links to further info.  

It looks like there is no way to prevent having to update apps for those that can, but you certainly have the platform and your customer's eyeballs at the exact point of failure to explain.

We all know not everyone is going to read the email we are all dreading to send, at least this way we have another method to get the point to them at the exact time they need it.

[TJ Luoma]

On Thu, May 19, 2011 at 5:18 PM, Frank Ash <nut...@gmail.com> wrote:

> To disguise this as a security issue is laughable at best and a bit insulting.

As USAmericans learned after 9/11/2001, you can push through just
about any policy you want if you wrap it up as security.

It's just astounding to watch Twitter, Inc. ignore the realities of
the developers' world when it takes weeks to get an app through
Apple's App Store process yet Twitter feels like they can just
announce this change and a 30 day deadline.

One might almost wonder if this wasn't yet another attempt to
discourage 3rd party developers from "competing" with Twitter's own
apps. And when you're done wondering about that, think about this:
what rule will Twitter change next?

"Twitter's fall from grace as the best API platform to the most
developer hostile is an exciting trainwreck to watch."

— http://twitter.com/justinw/status/70922532915642368

Then there was John Gruber's
http://daringfireball.net/linked/2011/05/18/twitter-translation:

> Translation From Weasel-Speak to English of the Key Question in Twitter’s FAQ for Developers Regarding Their New Policy for Third-Party Client Apps

>> Q: Will Twitter’s own applications also go through the OAuth web flow?

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

> Translation: No.

Or as I said yesterday: https://twitter.com/#!/TJLuoma/status/70954138103586816

> Shorter Message from @Twitter to 3rd Party Devs: "This is Phase One of getting rid of xAuth and Phase Two of getting rid of 3rd party devs."

First they came for basic auth…

TjL

[janole]

Hi Frank,

> Think about the normal person that uses tweetdeck. They will load the all, see nothing, and think its broken.

will the new policy be applied to all clients - even TweetDeck Mobile?

Ole

[Frank Ash]

Yes janol, everything but twitters official apps will fail. This is specifically aimed at client apps. It is a way to specifically Target client apps because it deals only with DM's which are mostly viewed through client applications. And specifically you said even tweetdeck, I would say especially tweetdeck. They control the largest amount of users outside of the official app and they have been attacking these large clients for some time now. By directly targeting DM's only it should be obvious to everyone why they are doing this. It's presented as some small change but the fallout for clients will be insane. You can't spin the news in a way to make it sound positive or even necessary. It's going to cause a storm of user confusion, deleted apps, bad reviews, complaints to customer support, uncertainty as to why they have to regive permission and religion their accounts. And if you app holds multiple accounts, your in for a nightmare. No one will want to go through putting all their info back into the app.

[Frank Ash]

I'll give an example for people using multiple accounts. From a customer point of view. I have 12 Twitter accounts, and I use 3 separate clients for different things. When this comes out I will have to re-authorize 36 times over these 3 apps alone. And they won't work until I do. If I was a normal user and didnt hear about the change, what am I going to think about this? I can already tell you I don't want to do it, and its gonna take a lot of time just to get these apps working again. That is for a power user though. Now someone like my mom who uses tweetdeck just to follow celebrities, she will have no clue what happened or why its not working and will be weary when tweetdeck asks her to confirm a new permissions scheme and wonder why they want her info again. Just step back and look at it for what it is and how people will react. We all know what's going to happen.

[Damon Parker]

Frank-

Correct me if I'm wrong, but the applications won't quit working altogether.  You'll get a 403 error when trying to access DMs through the API.  Everything else should work as normal.

Has there been a better official answer if this affects Twitter's own apps other than this:

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.

Which doesn't quite answer my question or the one it's supposed to. 

cheers

damonp

On Thursday, May 19, 2011 at 4:58 PM, Frank Ash wrote:

I'll give an example for people using multiple accounts. From a customer point of view. I have 12 Twitter accounts, and I use 3 separate clients for different things. When this comes out I will have to re-authorize 36 times over these 3 apps alone. And they won't work until I do. If I was a normal user and didnt hear about the change, what am I going to think about this? I can already tell you I don't want to do it, and its gonna take a lot of time just to get these apps working again. That is for a power user though. Now someone like my mom who uses tweetdeck just to follow celebrities, she will have no clue what happened or why its not working and will be weary when tweetdeck asks her to confirm a new permissions scheme and wonder why they want her info again. Just step back and look at it for what it is and how people will react. We all know what's going to happen.

[Frank Ash]

Cartmetrix, We don't know for sure what will happen. That's kinda the problem. My guess is we all prepare now by making our app request rwdm access, then when the switch takes effect any token that has been changed with this update will then need to be reauthorized. Not effecting us now, but when that change takes hold, I imagine all our tokens will be basically unauthorized because its an all new permission request, thus forcing each user to accept the new authorizations before they can use the app to communicate with the Api. Also I spoke unclear earlier about all apps failing. It will only be ones that use DM as a feature. Which is basically any client app. I just assume everyone here is effected by the DM permission change in some way, so I say all our apps. But little Twitter apps that just read and write won't be effected at all. Because Twitter isn't afraid of them, just client apps.

Also there is no way Twitter will make themselves do the same thing. Lol that would be hilarious. They will in no way form or fashion make all their users go through this process. That would be something I would be fine with. If they want this change, let them do it also lol. But yeah, there is no way they would, because they know exactly what would happen.

[Damon Parker]

Frank-

http://dev.twitter.com/pages/application-permission-model-faq

The way I read the FAQ posted is _only_ apps requiring DM read access will be affected under the following endpoints:

/1/direct_messages.{format}

/1/direct_messages/sent.{format}

/1/direct_messages/destroy.{format}

/1/direct_messages/show.{format}

These will receive an HTTP 403 with:

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

In fact, it explicitly says:

"Yes. Read/Write tokens can send direct messages using direct_messages/new."

Which doesn't quite make sense from a security standpoint... but I'm not going to argue.

Unless this is all PR spin, the only thing that seemed unclear was whether Twitter's own apps would require re-authorization into the new perms.  The only thing that addresses that was what I posted previously:

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.

Which says they'll be subject to oAuth web flow... but as I understand it, they already are.   It says nothing about the re-auth steps for the own apps.  

Maybe someone from Twitter will provide a more clear response regarding re-auth of their own apps instead of an ambiguous answer.  This could defuse some developer concern and conspiracy theory conjecture.

Damon

On Thursday, May 19, 2011 at 5:22 PM, Frank Ash wrote:

Cartmetrix, We don't know for sure what will happen. That's kinda the problem. My guess is we all prepare now by making our app request rwdm access, then when the switch takes effect any token that has been changed with this update will then need to be reauthorized. Not effecting us now, but when that change takes hold, I imagine all our tokens will be basically unauthorized because its an all new permission request, thus forcing each user to accept the new authorizations before they can use the app to communicate with the Api. Also I spoke unclear earlier about all apps failing. It will only be ones that use DM as a feature. Which is basically any client app. I just assume everyone here is effected by the DM permission change in some way, so I say all our apps. But little Twitter apps that just read and write won't be effected at all. Because Twitter isn't afraid of them, just client apps.

Also there is no way Twitter will make themselves do the same thing. Lol that would be hilarious. They will in no way form or fashion make all their users go through this process. That would be something I would be fine with. If they want this change, let them do it also lol. But yeah, there is no way they would, because they know exactly what would happen.

[Frank Ash]

That would be much better cartmatrix but either way, its a negative and unnecessary to take this approach. I am still a bit sceptical that everything will still work fine, just if they try to send a DM it will fail to a 403 error. There is language in the post that suggests both outcomes as possible. I would really like someone from Twitter to clarify exactly what will happen. Very clearly and plainly.

I am interested also to here the way they will dance around not doing this themselves as well. They won't, I can guarantee that. I would bet my house on it. Eiyer way the outcome will be negative in any scenario, so they won't want any part of that. But they think its fine if we have to.

[TheGuru]

This is where my confusion stemmed from.

I'm not sure I was aware of the fact there were 2 OAuth login flows,
"web flow" versus "sign in with Twitter".

As soon as I flipped the boolean in my PHP include for OAuth to set
sign_in_with_twitter = FALSE, so that it would use /authorize instead
of /authenticate (sign in with twitter), I then saw the correct
permissions on the login page.

I'm not sure this is obvious to many devs (it wasn't to me), that
there was a difference. I just happened to use / assume "sign in with
twitter" was the only web based login available after the
implementation of OAuth.

What are the implications / reasons for using one method over the
other? They seem to essentially do the same exact thing / accomplish
the same exact goal.

On May 19, 3:17 pm, themattharris <thematthar...@twitter.com> wrote:

> The permission level for your application can be edited onhttp://dev.twitter.com/apps. When the website is busy, it can take a

[Derek Gathright]

Matt Harris said:

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

Only because that is the way the system is currently built, but it doesn't have to be that way (see: Facebook).


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

Not if there were no API for it and permission changes must be done by a user inside twitter.com (the logical thing).  For additional security, have an opt-in/out email when permission/settings change on a user's account so they are aware of any changes (see: Banking websites).


>> If you tie the permissions to the application each user token would need to be invalidated whenever an application’s permissions are changed.

Yes, and that's only because that is the way the system currently operates, which is a nuisance for both the developer and user.  Imagine if every time I changed any of my Facebook permission settings (a common thing), I had to re-authenticate every. single. app.  That eventually leads me to leave permissions as wide-open as possible to avoid the annoying task of re-authentication, defeating the purpose of permissions in the first place.


I'm not trying to be argumentative. I understand why it was originally built the way it was and I understand why Twitter is adding the new permission.  I'm just saying there are improvements that Twitter should consider to prevent these types of problems going forward. This same outcry will happen next time you add a permission setting, and the time after that, etc...

Another suggestion, would it hurt to say "Hey, we're thinking about doing X, what do you guys think?" That way we can give you feedback before any firm decisions or deadlines are set.  Those types of conversations used to be very common on this list.  Twitter has some smart & talented people working for the company, but there are also many smart & talented people on this list that would love to be involved in these types of things before it becomes an issue and it erupts into a 65+ reply email thread with deadline extensions.

[Jef Poskanzer]

On May 19, 5:11 pm, TheGuru <jsort...@gmail.com> wrote:
> I'm not sure I was aware of the fact there were 2 OAuth login flows,
> "web flow" versus "sign in with Twitter".

Same here. Looks like I was using /authorize already though.

> What are the implications / reasons for using one method over the
> other?  They seem to essentially do the same exact thing / accomplish
> the same exact goal.

Yeah.
---
Jef

[Orian Marx]

@rsarver made it very clear in some recent tweets that Twitter's apps
will not be subject to the new OAuth requirements as they are part of
the 'service' not 3rd party offerings.

[Tyson Lowery]

I noticed this as well. When I did that, I thought maybe that meant
everyone would be grandfathered in, but from reading this thread I do
not think that is the case.

This also makes it difficult for us to troubleshoot this with our
users since we won't know if they have the old token or the new
token.



On May 19, 7:12 am, Mark Pavlidis <mark.pavli...@gmail.com> wrote:
>
> 2. I have changed the permission level for my application. When I view
> the permission onhttps://twitter.com/settings/applicationsis 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.
>

[Frank Ash]

Did anyone else change their permission on Twitter to rwdm and now their app doesn't show anything? I changed mine, and today I had to reauthorized my account because nothing would load inTo the app. Now it works as usual after I re added my info. Am I the only one? could possibly just be a glitch idk.

[janole]

Hi Frank,

do you now understand my "slightly provoking" question about
TweetDeck? ;-)

Ole

[Mark Pavlidis]

According to Matt's response above "When the website is busy, it can
take a
little bit longer for changes to your application to be reflected." If
you still haven't see then change try setting it again.

On May 19, 4:45 pm, janole <s...@mobileways.de> wrote:
> HiMark,

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

> On May 19, 8:13 pm,MarkPavlidis<mark.pavli...@gmail.com> wrote:
>
>
>
> > 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.
>
> > On May 19, 2:04 pm, TheGuru <jsort...@gmail.com> wrote:
>
> > > 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?
>

[Mark Pavlidis]

Matt is this header in yet I haven't seen any announcements elsewhere

On May 19, 4:17 pm, themattharris <thematthar...@twitter.com> wrote:
>
> > 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 newheaderto authentication requests that will tell

[James Estes]

Arnaud replied recently indicating that the header is now in:

"We just started to return the "X-Access-Level" header for
authenticated API requests, that tells you what access level the user
token has"

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/5bf53b81f2d868c/87bcc4780e7f2f7d?lnk=gst&q=X-Access-Level#87bcc4780e7f2f7d

James

[BikerBecca]

Matt,

A question about the error being returned. You wrote that when you
throw a 403 it will be in the format:

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

Rather than the traditional twitter format, as documented in the
Twitter API Wiki http://apiwiki.twitter.com/w/page/22554652/HTTP-Response-Codes-and-Errors
, of something like:

{"error":"Could not authenticate you.","request":"\/1\/direct_messages
\/sent.json"}

or

<hash>
<error>Could not authenticate you.</error>
<request>/1/direct_messages/sent.xml</request>
</hash>

Is this a type-O or is twitter changing the format of how it returns
errors? Since I currently look for the <hash> element to know exactly
what error I am receiving am I now going to have to test for an
additional twitter error format? I cannot make the necessary coding
changes to our application until I know how errors are going to be
formatted by twitter going forward.

Thank you,
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