A new permission level
1,421 views
Skip to first unread message
Matt Harris
May 18, 2011, 1:01:41 PM5/18/11
to Twitter Development Talk
Hey everyone,
We recently updated our OAuth screens to give users greater transparency about the level of access applications have to their accounts. The valuable feedback Twitter users and developers have given us played a large part in that redesign and helped us identify where we can do more.
In particular, users and developers have requested greater granularity for permission levels.
In response to this feedback, we have created a new permission level for applications called “Read, Write & Direct Messages”. This permission will allow an application to read or delete a user's direct messages. When we enforce this permission, applications without a “Read, Write & Direct Messages” token will be unable to read or delete direct messages. To ensure users know that an application is receiving access to their direct messages, we are also restricting this permission to the OAuth /authorize web flow only. This means applications which use xAuth and want to access direct messages must send a user through the full OAuth flow.
What does this mean for your application?
If you do not need access to direct messages: you won’t need to make any changes to your application. When we enforce the new permission level your read or read/write token will automatically lose access to direct messages.
If you do need access to direct messages: you will need to edit your application record on https://dev.twitter.com/apps and change the permission level of your application to “Read, Write and Direct Messages”. The new permission will not affect existing tokens which means existing users or your app or service will need to reauthorize.
We know this will take some time so we are allowing a transition period until the end of this month. During this time there will be no change to the access Read/Write tokens have to a users account. However, at the end of the month any tokens which have not been upgrade to “Read, Write and Direct Messages” will be unable to access and delete direct messages.
Affected APIs and requests
On the REST API, Read and Read/Write applications will no longer be able to use these API methods:
/1/direct_messages.{format}
/1/direct_messages/sent.{format}
/1/direct_messages/show.{format}
/1/direct_messages/destroy.{format}
For the Streaming API, both User Streams and Site Streams will only receive direct messages if the user has authorised an application to access direct messages.
Applications that use “Sign-in with Twitter” or xAuth will only be able to receive Read or Read/Write tokens.
What this means is only applications which direct a user through the OAuth web flow will be able to receive access tokens that allow access to direct messages. Any other method of authorization, including xAuth, will only be able to receive Read/Write tokens.
What will happen when the permission is activated
When we activate the new permission, all Read and Read/Write user_tokens issued to third-party applications will lose their ability to read direct messages. Any attempt to read direct messages will result in an HTTP 403 error being returned.
For example, a GET request to https://api.twitter.com/1/direct_messages/sent.json will return an HTTP 403 Forbidden with the response body:
{"errors":[{"code":93,"message":"This application is not allowed to access or delete your direct messages"}]}
Key Points
* If you wish to access a user’s direct messages you will need to update your application and reauthorize existing tokens.
* The only way to get direct message access is to request access through the OAuth /authorize web flow. You will not be permitted to access direct messages if you use xAuth.
* When we enforce the permission Read/Write and Read tokens will be unable to access and delete direct messages.
* Read/Write tokens will be able to send direct messages after the permission is enforced.
We’ll be collating responses and adding more information on our developer resources permission model page: https://dev.twitter.com/pages/application-permission-model
We have also blogged about this on the Twitter blog: http://blog.twitter.com/2011/05/mission-permission.html
Best,
@themattharris
Jim Cortez
May 18, 2011, 1:19:19 PM5/18/11
to twitter-deve...@googlegroups.com
Matt,
You say:
> This means applications which use xAuth and want to access direct
> messages must send a user through the full OAuth flow.
What if the client using xAuth has no browser and therefore cannot go
through oAuth? Does this mean that direct messages cannot be accessed?
Is there a process I can go through to get our app approved for use of
direct messages without using oAuth?
You say:
> This means applications which use xAuth and want to access direct
> messages must send a user through the full OAuth flow.
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
May 18, 2011, 1:26:21 PM5/18/11
to Twitter Development Talk
The new permissions level is welcomed by me and a good idea. Removing
the ability for xAuth to access DMs is insanity, pure and simple.
I presume your iOS and Mac clients will be switching off xAuth access
as well then?
On May 18, 6:19 pm, Jim Cortez <j...@jimcortez.com> wrote:
> Matt,
> You say:> This means applications which use xAuth and want to access direct
> > messages must send a user through the full OAuth flow.
>
> What if the client using xAuth has no browser and therefore cannot go
> through oAuth? Does this mean that direct messages cannot be accessed?
> Is there a process I can go through to get our app approved for use of
> direct messages without using oAuth?
>
> Thanks,
> Jim Cortez
>
> > application record onhttps://dev.twitter.com/appsand change the
> >https://api.twitter.com/1/direct_messages/sent.jsonwill return an
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
>
Tom van der Woerdt
May 18, 2011, 1:28:13 PM5/18/11
to twitter-deve...@googlegroups.com
Sounds good! Also sounds like you folks are finally trying to get rid of
xAuth :-)
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
May 18, 2011, 1:29:26 PM5/18/11
to twitter-deve...@googlegroups.com
"We know this will take some time so we are allowing a transition period until the end of this month."
This is such a short timeframe for people to rebuild, QA and resubmit their apps that it will certainly mean some peoples apps will stop working while they are waiting for them to be 'approved' by their own QA, or their internal IT department, or their app store or market. I would request that you think about extending it.Angus
janole
May 18, 2011, 1:39:39 PM5/18/11
to Twitter Development Talk
Hi Matt,
can you please give us more time to adapt to this. It is impossible to
make the appropriate changes and submit to appstore within this
timeframe.
Thanks,
Ole, Gravity Twitter Client for Symbian
On May 18, 7:01 pm, Matt Harris <thematthar...@twitter.com> wrote:
> Hey everyone,
>
> We recently updated our OAuth screens to give users greater transparency
> about the level of access applications have to their accounts. The valuable
> feedback Twitter users and developers have given us played a large part in
> that redesign and helped us identify where we can do more.
>
> In particular, users and developers have requested greater granularity for
> permission levels.
>
> In response to this feedback, we have created a new permission level for
> applications called “Read, Write & Direct Messages”. This permission will
> allow an application to read or delete a user's direct messages. When we
> enforce this permission, applications without a “Read, Write & Direct
> Messages” token will be unable to read or delete direct messages. To ensure
> users know that an application is receiving access to their direct messages,
> we are also restricting this permission to the OAuth /authorize web flow
> only. This means applications which use xAuth and want to access direct
> messages must send a user through the full OAuth flow.
>
> What does this mean for your application?
> If you do not need access to direct messages: you won’t need to make any
> changes to your application. When we enforce the new permission level your
> read or read/write token will automatically lose access to direct messages.
>
> If you do need access to direct messages: you will need to edit your
> application record onhttps://dev.twitter.com/appsand change the permission
> For example, a GET request tohttps://api.twitter.com/1/direct_messages/sent.jsonwill return an HTTP 403
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
Dewald Pretorius
May 18, 2011, 1:59:20 PM5/18/11
to Twitter Development Talk
Matt,
If I understand correctly, activate the new permission, all Read and
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?
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
their ability to read direct messages.
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
May 18, 2011, 2:02:43 PM5/18/11
to twitter-deve...@googlegroups.com
Matt,
Ultimately I understand the issues with xAuth and granularity. Frankly, if you just ditched xAuth entirely, I can see decent arguments for it.
However, we've made a significant investment in the xAuth UX. If we have to change it, 13 days is simply not sufficient for most devs. It will be a stretch for Spaz, given that we are all volunteer and do it in our spare time. Folks who have to deal with app store submissions and the like are even more under the thumb.
2 months, I think is much more reasonable. In addition, real effort being put forth by the dev relations team to show how to migrate to a solid oAuth flow on desktop and mobile would be very useful to many devs.
Good luck.
M. Edward (Ed) Borasky
May 18, 2011, 2:02:34 PM5/18/11
to twitter-deve...@googlegroups.com, Twitter Development Talk
--
http://twitter.com/znmeb http://borasky-research.net
"A mathematician is a device for turning coffee into theorems." -- Paul
Erdos
Quoting Matt Harris <themat...@twitter.com>:
Zac Bowling
May 18, 2011, 2:03:30 PM5/18/11
to twitter-deve...@googlegroups.com
Hi Matt,
I understand the change need to happen. In regards to xAuth though and finding an upgrade path, the assumption is that those that got access to that were developing desktop/mobile clients (not centralized services) so there is no centralized storage of tokens or user data (only in standalone applications in those applications). In a good number of the high profile applications of xAuth, it's an actual client (like TweetBot, Seesmic, Tweetdeck, etc). Those clients almost always interface with direct messages because they replicate most of the twitter features up and down.
In that case, can you please reconsider the case of xAuth. Grandfather existing xAuth users to read, write, and direct message level. Then going forward with xAuth, evaluate the need of the app if it needs read/write/direct message on a case by case basis? You are going to break a good number of applications with that change.
Although a month is just barely enough time to turn around an update for iOS if developers rush, it doesn't leave a lot of grace time for users that do not upgrade their applications very often. My own stats for my apps show without sending out notifications to nag the users to tell of an update (or force them to an update by sending them to the store when they launch the app), nearly half my users do not upgrade for at least 2 to 3 weeks after an update comes out.
I hate to bring up comparisons to facebook, but they give us a good developer roadmap (http://developers.facebook.com/roadmap/ ) with a decent time line for deprecation, ramp downs, and migration paths.
Zac
Paul Haddad
May 18, 2011, 1:49:15 PM5/18/11
to Twitter Development Talk, Matt Harris
Hi Matt,
1. xAuth apps are already approved by you guys and have a (I'm assuming) higher threshold to get access to. I'd really ask you guys to re-consider and allow xAuth access to DMs. Or at the very least allow clients to apply for exceptions to this rule.
2. Under 2 weeks is way too short of a time for this big of a change.
--
Twitter API documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Change your membership to this group: http://groups.google.com/group/twitter-api-announce?hl=en
janole
May 18, 2011, 2:27:24 PM5/18/11
to Twitter Development Talk
I very much agree. To get xAuth, we all had to apply and undergo some
sort of verification process.
Also, if I take my app Gravity as an example, I am using xAuth (and
previously Basic Auth) since the very beginning and there have been
zero complaints from users that Gravity has been misusing the DM
feature.
Why? Well, it can't. It's a standalone, mobile application and not a
web app. I, as the author, do not have access to the users passwords
nor to their oAuth tokens.
Furthermore, Gravity is a client on the Symbian platform where you
cannot open the webbrowser for the OAuth flow on many phone models.
And there is no official client on the Symbian platform (although it
would be nice if it was Gravity :-))
Could you please re-consider this and either grandfather xauth clients
or offer a checkbox on the user's Twitter.com settings for the xAuth
clients where they can manually disable/enable DMs?
Wouldn't that be a very good decision for all xAuth clients anyway?
Just add a checkbox so the users can disable DMs if they really don't
want DMs in their mobile/etc. third party clients.
As a side note, the time to get an app through the OviStore (Nokia's
App Store) process can be quite long. I don't think 13 days will be
enough for this.
Cheers
Ole (@janole / @gravityapp)
On May 18, 7:49 pm, Paul Haddad <paul.had...@gmail.com> wrote:
> Hi Matt,
>
> 1. xAuth apps are already approved by you guys and have a (I'm assuming) higher threshold to get access to. I'd really ask you guys to re-consider and allow xAuth access to DMs. Or at the very least allow clients to apply for exceptions to this rule.
> 2. Under 2 weeks is way too short of a time for this big of a change.
>
> On May 18, 2011, at 12:01 PM, Matt Harris wrote:
>
>
>
>
>
>
>
>
>
> > Hey everyone,
>
> > We recently updated our OAuth screens to give users greater transparency about the level of access applications have to their accounts. The valuable feedback Twitter users and developers have given us played a large part in that redesign and helped us identify where we can do more.
>
> > In particular, users and developers have requested greater granularity for permission levels.
>
> > In response to this feedback, we have created a new permission level for applications called “Read, Write & Direct Messages”. This permission will allow an application to read or delete a user's direct messages. When we enforce this permission, applications without a “Read, Write & Direct Messages” token will be unable to read or delete direct messages. To ensure users know that an application is receiving access to their direct messages, we are also restricting this permission to the OAuth /authorize web flow only. This means applications which use xAuth and want to access direct messages must send a user through the full OAuth flow.
>
> > What does this mean for your application?
> > If you do not need access to direct messages: you won’t need to make any changes to your application. When we enforce the new permission level your read or read/write token will automatically lose access to direct messages.
>
> > If you do need access to direct messages: you will need to edit your application record onhttps://dev.twitter.com/appsand change the permission level of your application to “Read, Write and Direct Messages”. The new permission will not affect existing tokens which means existing users or your app or service will need to reauthorize.
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.
>
>
> > 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:
> > 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.
>
>
> > {"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> > {"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
Jon Colverson
May 18, 2011, 2:37:48 PM5/18/11
to Twitter Development Talk
Hello.
For my app, it's inconvenient that the DM permission is only available
lumped in with the write permission, because now I have to request
both even though my app has no facility for posting (it's a
notification-only app), and I expect users will (rightly) be
suspicious about that.
Also on the subject of granularity, it would be great if the app could
request DM access but make it optional, such that users can turn it
off on the authorization page. If the user declines it then the app
would be able to ask them to reauthorize if they later try to use the
DM feature of the app.
Thank you.
- Jon
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
May 18, 2011, 2:42:42 PM5/18/11
to Twitter Development Talk
I had most of the same thoughts already mentioned in this thread so
wont reiterate everyone, except to add that this seems like a rather
sudden and disruptive change coming just after #devnestsf where
Twitter made a point that it was trying to provide better guidance so
companies that rely on the platform have time to plan and make
changes.
@knight9
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
May 18, 2011, 2:51:55 PM5/18/11
to twitter-deve...@googlegroups.com
Hello,
There have been a lot of opinions voiced about how this is being implemented. This not only proves troublesome for xAuth clients, but it lends me to worry about how the future of permissions will evolve. Effectively now, every single Twitter user needs to get their application re-authed for the new tokens to provide DM access by the end of the month.
The Facebook style of using a 'scope' for individual permissions is so much more viable. I also believe that the API should provide a lookup for the permissions that a set of credentials currently provides. I honestly believe that going down the 'scope' route for permissions will be a lot better for all concerned. When new permissions are introduced to the API in the future, it would be a small matter of updating the requesting scope for the application developer, rather than completely rewriting chunks of code.
I'd like a response from Matt, Taylor or Raffi on this matter and the plans for future permissions and their implementation.
> --
> Twitter developer documentation and resources: https://dev.twitter.com/doc
> API updates via Twitter: https://twitter.com/twitterapi
> Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
> Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
--
Scott Wilcox
@dordotky | sc...@dor.ky | http://dor.ky
+44 (0) 7538 842418 | +1 (646) 827-0580
Derek Gathright
May 18, 2011, 3:50:30 PM5/18/11
to twitter-deve...@googlegroups.com
I agree with Scott. A token should simply be a bond between the user and the app, it should not contain any knowledge of permissions/restrictions. A token simply represents "Hi, I'm making a call on behalf of Joe User. Attached is the request I want to make. Make sure I'm allowed to do this before you execute it."
Forcing re-authentication whenever permissions change is a major pain for both developers and users. Removing permission-based tokens benefits the user because they can modify the access an application has without having to re-authenticate, something 99% of users will not understand.
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
May 18, 2011, 3:59:43 PM5/18/11
to twitter-deve...@googlegroups.com
On Wed, May 18, 2011 at 12:50:30PM -0700, Derek Gathright wrote:
> I agree with Scott. A token should simply be a bond between the user
> and the app, it should not contain any knowledge of
> permissions/restrictions. A token simply represents "Hi, I'm making a
> call on behalf of Joe User. Attached is the request I want to make.
> Make sure I'm allowed to do this before you execute it."
> Forcing re-authentication whenever permissions change is a major pain
> for both developers and users. Removing permission-based tokens
> benefits the user because they can modify the access an application has
> without having to re-authenticate, something 99% of users will not
> understand.
> 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
May 18, 2011, 4:27:56 PM5/18/11
to Twitter Development Talk
The more I think about this, the less it makes any sense whatsoever to
force everyone through a re-authentication if DM access is required.
Here's why:
1) For existing user tokens, the users have already granted access
with the knowledge that it is to their DMs as well. In other words,
they have already granted access to their DMs.
2) If an app needs access to the users' DMs, it is going to force
thousands of people to waste thousands of hours to re-authorize
something they want the app to do and something they have already
implicitly granted to the app.
3) Many users are going to miss the memo, and then be very upset with
the app owner(s) because what had worked before suddenly stopped
working.
4) Additional and completely unnecessary workload and costs are going
to be added to the support staff of the app, to help users who do not
understand why they need to re-authorize, or who have missed the memo
in the first place.
5) By forcing re-authorization for apps that require DM access and
already have DM access, Twitter gains absolutely nothing. After
forcing thousands of people through a redundant process, we're back at
where we started, namely, the app has access to the user's DMs. It's
not like the user has a choice of not granting a requesting app access
to his DMs, but only to his followers and tweets. If the app request
DM access, the user can either grant it, or deny access completely.
Exactly the same way it works today.
The only benefit here is for apps who don't need DM access, which will
now be able to request account access without DM access. But, if the
app does not need or use access to DMs, it provides absolutely no
benefit to take existing DM access of already granted user tokens
away. It is not used.
It makes perfect sense to implement this change from a date going
forward, meaning all user tokens granted after that date will be
either Read, Read & Write, or Read & Write & DM. That provides more
transparency for the user. But to yank away existing access rights and
then force the equivalent of a small nation through a re-
authentication process just to re-establish what had already been
granted and then unilaterally taken away, that makes no sense at all.
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
May 18, 2011, 4:54:09 PM5/18/11
to twitter-deve...@googlegroups.com
On Wed, May 18, 2011 at 11:37 AM, Jon Colverson <jjc...@gmail.com> wrote:
>
> Also on the subject of granularity, it would be great if the app could
> request DM access but make it optional, such that users can turn it
> off on the authorization page. If the user declines it then the app
> would be able to ask them to reauthorize if they later try to use the
> DM feature of the app.
>
> 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
May 18, 2011, 4:47:06 PM5/18/11
to Twitter Development Talk
Quick question and a comment.
1) I see the new Default Access type as "Read, Write & Private
Message" not "Read, Write & Direct Messages." Is there a typo
somewhere?.
2) I just have to agree with everyone here that having all of our
users re-auth our app to give them access to a feature they've already
agreed to as being a pretty poor implementation of this change. The
vast majority of users will not understand why and/or what they need
to re-auth and the ones that don't will be swamping our support people
on June 1st when they no longer see their Direct Mentions. If there
is any way to grandfather in existing users who have already
authorized access to their direct messages that would be a huge help
for every company using twitter in their apps.
Thanks,
Becca
On May 18, 10:01 am, Matt Harris <thematthar...@twitter.com> wrote:
> Hey everyone,
>
> We recently updated our OAuth screens to give users greater transparency
> about the level of access applications have to their accounts. The valuable
> feedback Twitter users and developers have given us played a large part in
> that redesign and helped us identify where we can do more.
>
> In particular, users and developers have requested greater granularity for
> permission levels.
>
> In response to this feedback, we have created a new permission level for
> applications called “Read, Write & Direct Messages”. This permission will
> allow an application to read or delete a user's direct messages. When we
> enforce this permission, applications without a “Read, Write & Direct
> Messages” token will be unable to read or delete direct messages. To ensure
> users know that an application is receiving access to their direct messages,
> we are also restricting this permission to the OAuth /authorize web flow
> only. This means applications which use xAuth and want to access direct
> messages must send a user through the full OAuth flow.
>
> What does this mean for your application?
> If you do not need access to direct messages: you won’t need to make any
> changes to your application. When we enforce the new permission level your
> read or read/write token will automatically lose access to direct messages.
>
> If you do need access to direct messages: you will need to edit your
> application record onhttps://dev.twitter.com/appsand change the permission
> For example, a GET request tohttps://api.twitter.com/1/direct_messages/sent.jsonwill return an HTTP 403
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
Chad Etzel
May 18, 2011, 6:47:44 PM5/18/11
to twitter-deve...@googlegroups.com
Aside from all the emotional/philosophical stuff in this thread, I am
concerned about a major possible bug:
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
May 18, 2011, 6:55:16 PM5/18/11
to twitter-deve...@googlegroups.com
nevermind, i must have been out of the loop.. i was using the old form
so use http://dev.twitter.com/apps
and DO NOT USE http://twitter.com/apps (which, should be deleted or
auto-forwarded or something....)
caramba,
-chad
Zac Bowling
May 18, 2011, 7:50:10 PM5/18/11
to twitter-deve...@googlegroups.com
Matt,
This maybe a harder architectural shift, but a better solution would be to move permissions from being per application, but instead a per authentication token method, wherein that each token stores the permissions that the app requested and was granted at the time they authorized.
So in this case, let us pass in a well know list of fine grain permissions we want/need when we make an oAuth request and then offer an end point to authorize for additional permissions when needed to upgrade a token's access in the future as new features come out.
In the case of xAuth, doing this wouldn't be as disruptive as all existing tokens would have all the permissions they intended when they were requested. In that xAuth could have a default permission level as set by Twitter when someone requests access to xAuth.
Zac
mostafa farghaly
May 18, 2011, 7:51:39 PM5/18/11
to twitter-deve...@googlegroups.com
Please exclude xAuth mobile clients from this, logically and from the usability point of view, it doesn't make any sense, the user authorize my app to use his account, why i ask for his authorization again to view his Direct messages, why you insist on making our life very hard :(
Andrew W. Donoho
May 18, 2011, 7:59:45 PM5/18/11
to twitter-deve...@googlegroups.com
On May 18, 2011, at 12:01 , Matt Harris wrote:
> We know this will take some time so we are allowing a transition period until the end of this month.
Gentlefolk,
This is way too short an amount of time to implement OAuth and transition mobile users off of an xAuth based client. (In my experience, my user base upgrades an app over a full quarter of a year.) Furthermore, even if I was ready right now with a submission to Apple, there is a very good chance that my app would not be approved by your deadline.
Please reconsider this deadline.
Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
a...@DDG.com, +1 (512) 750-7596, twitter.com/adonoho
"We did not come to fear the future.
We came here to shape it."
-- President Barack Obama, Sept. 2009
themattharris
May 18, 2011, 8:11:24 PM5/18/11
to Twitter Development Talk
Hey everyone,
Thank you for all the feedback on the list, email and through Tweets.
We've been responding throughout the day to many of the Tweets but
wanted to group the questions together and respond here as well.
> Two weeks is not enough time to implement a web OAuth flow and have the app approved. We need an extension.
We’ve heard your feedback on this list, privately and through Tweets
about this. Based on this feedback we are going to extend the
enforcement deadline by two weeks.
**** This means we'll enforce the new permission the week beginning
the 14th June 2011. ****
This should provide enough time for you to make the change and have
your application approved by your chosen platform’s app store.
> Will Twitter's own applications also go through the OAuth web flow?
We’re taking this step to give more clarity and control to users about
the access a third-party application has to their account. The way
users interact with Twitter’s clients is not expected to change.
Applications who wish to access a user’s DMs will need to update their
application permission and incorporate the OAuth web flow if they
don’t already. If an application does not need access to DMs it will
not need to make any changes.
> Why will you not grandfather existing applications into DM access?
Grandfathering all existing read/write tokens assumes they all wanted
access to DMs. The feedback we’ve had from users and developers tells
us otherwise. We want to give users the opportunity to make an
informed choice.
> What if the client using xAuth has no browser and therefore cannot go through OAuth?
For single user applications and scripts we provide the 'My Access
Token' page of the application details. To ensure the 'My Access
Token' is correct it is important the app owner revokes their access
before change the permission level of the app. If you do not do this,
the 'My Access Token' will not be regenerated with the new permission.
This revoke action is only needed by you, the owner of the
application. Remember Read/Write applications can still send direct
messages.
> When you activate the new permission, will all Read and Read/Write user_tokens issued to third-party applications lose their ability to read direct messages?
Existing tokens are unaffected by any change to the application
permission level. If you change your application to R/W/DM all future
authorizations will be for that permission. When a user re-authorizes,
their existing token will be updated to the current application
permission level. Access to DMs will be enforced on 14th June 2011 if
the user_token wasn't authorised as for R/W/DM.
> What if I want to request a different level of access for my application instead of the one my application is registered with?
You can do this now by using the x_auth_access_type parameter during
the request_token phase. Using this parameter you can request a read
or a read/write token even if your application is registered for read/
write/direct messages.
More information on this method is in our developer documentation:
http://dev.twitter.com/doc/post/oauth/request_token
> Why are permissions attached to the user token?
Permissions are attached to the user token to ensure an application
only has the access a user has authorised. If permissions were not
attached to the user token an application would be able to change the
level of access they have without the user’s knowledge. If you tie the
permissions to the application each user token would need to be
invalidated whenever an application’s permissions are changed.
> Users already gave their permission for apps to access private messages, why are you making us, and them, reauthorize?
The purpose of the re-authorization is to ensure both users and
developers know the level of access requested. Re-authorization allows
a user to make a more informed decision about the access an
application has requested.
We hope these responses answer your questions. Please continue to send
us your feedback about the permission model and what you would like to
see it offer.
Best,
@themattharris
Thank you for all the feedback on the list, email and through Tweets.
We've been responding throughout the day to many of the Tweets but
wanted to group the questions together and respond here as well.
> Two weeks is not enough time to implement a web OAuth flow and have the app approved. We need an extension.
We’ve heard your feedback on this list, privately and through Tweets
about this. Based on this feedback we are going to extend the
enforcement deadline by two weeks.
**** This means we'll enforce the new permission the week beginning
the 14th June 2011. ****
This should provide enough time for you to make the change and have
your application approved by your chosen platform’s app store.
> Will Twitter's own applications also go through the OAuth web flow?
We’re taking this step to give more clarity and control to users about
the access a third-party application has to their account. The way
users interact with Twitter’s clients is not expected to change.
Applications who wish to access a user’s DMs will need to update their
application permission and incorporate the OAuth web flow if they
don’t already. If an application does not need access to DMs it will
not need to make any changes.
> Why will you not grandfather existing applications into DM access?
Grandfathering all existing read/write tokens assumes they all wanted
access to DMs. The feedback we’ve had from users and developers tells
us otherwise. We want to give users the opportunity to make an
informed choice.
> What if the client using xAuth has no browser and therefore cannot go through OAuth?
For single user applications and scripts we provide the 'My Access
Token' page of the application details. To ensure the 'My Access
Token' is correct it is important the app owner revokes their access
before change the permission level of the app. If you do not do this,
the 'My Access Token' will not be regenerated with the new permission.
This revoke action is only needed by you, the owner of the
application. Remember Read/Write applications can still send direct
messages.
> When you activate the new permission, will all Read and Read/Write user_tokens issued to third-party applications lose their ability to read direct messages?
Existing tokens are unaffected by any change to the application
permission level. If you change your application to R/W/DM all future
authorizations will be for that permission. When a user re-authorizes,
their existing token will be updated to the current application
permission level. Access to DMs will be enforced on 14th June 2011 if
the user_token wasn't authorised as for R/W/DM.
> What if I want to request a different level of access for my application instead of the one my application is registered with?
You can do this now by using the x_auth_access_type parameter during
the request_token phase. Using this parameter you can request a read
or a read/write token even if your application is registered for read/
write/direct messages.
More information on this method is in our developer documentation:
http://dev.twitter.com/doc/post/oauth/request_token
> Why are permissions attached to the user token?
Permissions are attached to the user token to ensure an application
only has the access a user has authorised. If permissions were not
attached to the user token an application would be able to change the
level of access they have without the user’s knowledge. If you tie the
permissions to the application each user token would need to be
invalidated whenever an application’s permissions are changed.
> Users already gave their permission for apps to access private messages, why are you making us, and them, reauthorize?
The purpose of the re-authorization is to ensure both users and
developers know the level of access requested. Re-authorization allows
a user to make a more informed decision about the access an
application has requested.
We hope these responses answer your questions. Please continue to send
us your feedback about the permission model and what you would like to
see it offer.
Best,
@themattharris
Message has been deleted
Zac Bowling
May 18, 2011, 8:38:33 PM5/18/11
to twitter-deve...@googlegroups.com
Thanks Matt!
I still urge you to reconsider the mass breakage of older existing apps, and crippling of the mobile/desktop app user experiences going forward.
My own judgement is that yes, maybe the user didn't realize that they didn't want to give that level of access and maybe the web flow can help twitter communicate to the user better what they app is request, but it's going up against all the issues of users that already authorized are not expecting things to break. It also throws away all the constant re-hashing went through before basic auth went away around the UX of oAuth that drove the development of xAuth in the first place.
I fear it's going to be litteral countdown until doomsday and hell is going to break out of users and developers that didn't get the memo. (I just checked, and my mother is still using a twitter client for the iPad that was updated over 4 months ago.)
Zac
Dewald Pretorius
May 18, 2011, 8:46:26 PM5/18/11
to Twitter Development Talk
> Please continue to send
> us your feedback about the permission model and what you would like to
> see it offer.
Why?
> us your feedback about the permission model and what you would like to
> see it offer.
James Peter
May 18, 2011, 10:08:13 PM5/18/11
to Twitter Development Talk
Thanks Matt,
Two important implementation questions that aren't 100% clear from
that announcement or any supporting docs at this point;
1) "we are also restricting this permission to the OAuth /authorize
web flow only"
To be clear, does this include using the OAuth "/authenticate" method
as well as the "/authorize" method?
2) The method direct_messages/new is not included the list of affected
requests, so sending (writing) DMs does not requires Private Message
permission?
Regards,
James
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
May 19, 2011, 2:50:44 AM5/19/11
to Twitter Development Talk
Hi Matt,
thanks for your feedback. I think the following paragraph can't be
generalized, though:
> > Why will you not grandfather existing applications into DM access?
>
> Grandfathering all existing read/write tokens assumes they all wanted
> access to DMs. The feedback we’ve had from users and developers tells
> us otherwise. We want to give users the opportunity to make an
> informed choice.
I can assure you that if I am asking any of my 100.000's users that
they would disagree with that statement. They all explicitly want to
access DMs in my Symbian based Twitter client. They actually EXPECT to
have access to direct messages.
A Twitter client without access to Direct Messages is not a Twitter
client. Wouldn't you agree? ;-)
I would urge you to rethink this decision - or let us know in all
honesty why you were imposing this bad UX on third party clients only.
If there was a proper way of doing the Web OAuth flow on the Symbian
platform, things would be a bit different (although not much.)
But now, the best option for me is to setup an intermediate server for
the OAuth flow - effectively giving me access to the users' OAuth
credentials. Something, that I didn't have access to before.
Something, that I didn't WANT to have access to from the beginning.
This doesn't seem like an improvement of privacy for my users at
least.
Please, please find a better solution for this. There are many options
that won't break third party clients - clients which cannot go through
the web Oauth flow, clients that have a wonderful user base
contributing to the Twitter "experience" with a lot of great Tweets.
Cheers,
Ole ( @janole / @gravityapp )
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.
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
May 19, 2011, 3:02:41 AM5/19/11
to twitter-deve...@googlegroups.com
Hi Matt,
Adriaan Pelzer
I have started implementing these changes. The app's permissions setting is set to "Read, Write & DM" (the new one).
However, when the user gets redirected to the auth page, it still indicates that the app will not be able to read or send DM's. Is this something that will automatically happen when you activate it, or is there a permissions parameter I should send to the auth page?
Adriaan Pelzer
//))//\\//\\||//
//\\//7//7///\\
putting you in touch with your crowds
skype: adriaan_pelzer
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 requestsOn 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 activatedWhen 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-modelWe have also blogged about this on the Twitter blog: http://blog.twitter.com/2011/05/mission-permission.htmlBest,@themattharris
--
janole
May 19, 2011, 4:29:22 AM5/19/11
to Twitter Development Talk
Hi Matt,
just another tought:
Wouldn't it be possible to keep the DM access rights with xAuth and
only revoke it upon users complaints or your monitoring of API usage?
If I remember correctly, Twitter said they are revoking hundreds of
API clients per day, so it seems like this approach is working well.
Cheers,
Ole ( @janole / @gravityapp )
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
May 19, 2011, 7:03:20 AM5/19/11
to Twitter Development Talk
Hey everyone,
The sad reality is that the way it's being taken in the news is that
"twitter is doing this because developers have been abusing their
privacy." We know this is not the case, we know we just need access
them to provide them the feeds that they WANT to see, by virtue of the
fact that they downloaded an app that clearly states it can do this.
If any of you wouldn't mind jumping into this article and setting a
few people straight, that'd be great:
http://mashable.com/2011/05/18/twitter-permissions/
(see comments)
Best,
Tammy
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
May 19, 2011, 8:44:11 AM5/19/11
to twitter-deve...@googlegroups.com
In any security or permissions context the default should be the most secure and least amount of permissions to get the job done. That is Computer and Network Security 101.
A user must explicitly configure more loose permissions on their own after understanding the implications. This is the way computer network security is and always has been done. This is part of the reason Linux/Unix et al is way more secure than Windows ever could be.
Just because a user isn't sophisticated enough to configure more lax permissions to get their needs met isn't a reason to default to lower the security context. This is what FB did _completely_ wrong when they updated their permissions system. They defaulted everything to being completely open, accessible and public for purely selfish reasons. They wanted to keep more user data 100% public thus increasing the amount of public and free (as in $ to FB) user-generated content created every day. More pageviews, more pics, more comments equals more ad revenue for them.
Even though it's a pain in the ass for developer's to rework their apps and re-auth it's the right thing to do for the end user and the overall safety of the community.
I commend Twitter for doing the right (even if unpopular) thing in this case.
Damon
Tammy Fennell
May 19, 2011, 9:41:55 AM5/19/11
to Twitter Development Talk
For some developers it's not just a pain in the you know what, it's a
case of it simply not working. @janole explained how it just doesn't
work with symbian. For me, and adobe air app, it's a pain, but we can
get over the inconvenience - although it's always nice to have a bit
more time. I think 8 to 12 weeks should be standard for changes of
this magnitude whenever possible.
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.