[twitter-dev] Re: A new permission level
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
errorCould 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
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
[twitter-dev] Re: A new permission level
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 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. -- 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
Re: [twitter-dev] Re: A new permission level
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=gstq=X-Access-Level#87bcc4780e7f2f7d James On Wed, May 25, 2011 at 8:52 AM, Mark Pavlidis mark.pavli...@gmail.com wrote: 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 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. -- 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 -- 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
[twitter-dev] Re: A new permission level
Hi Frank, do you now understand my slightly provoking question about TweetDeck? ;-) Ole On May 19, 11:46 pm, Frank Ash nut...@gmail.com wrote: 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. -- 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
[twitter-dev] Re: A new permission level
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,MarkPavlidismark.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? On May 19, 12:49 pm,MarkPavlidismark.pavli...@gmail.com wrote: 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 On May 19, 9:42 am, TheGuru jsort...@gmail.com wrote: +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.comtwitter: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.comwrote: 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/appsandchangethe permission level of your application to “Read, Write and Direct Messages”. The new permission will not affect existing tokens which means existing
OAuth flow cannot be used from the Japanese mobile of Japan. Re: [twitter-dev] Re: A new permission level
Hello. Because the OAuth flow of twitter.com cannot be used from the Web based client for the Japanese mobile phone that we are providing, XAuth is used. (I get permission in your support.) The following problems occur if it accesses the OAuth flow from the cellular phone of a major career of Japan now. - NTT DoCoMo , Softbank 1.The over memory error happens frequently because the size of HTML and the image is large. 2.The alarm display concerning SSL goes out whenever the page is switched. - KDDI 403 errors occur on the way, and OAuth flow fails. Moreover, because JavaScript cannot be used with a lot of models, the user is confused. Because we cannot provide the DM function from the cellular phone to the user who uses it, an existing user is inconvenient the state as it is it. (The user of the Japanese mobile phone has a lot of people who do not have PC. ) Because it is thought that there is a development expert of the Japanese mobile phone of Japan in your company, Could you add the OAuth flow that can be used from web browser of the cellular phone of Japan by 6/14? -- Shinichi Fujikawa President CTO Mindscope,Inc. http://www.mindscope.co.jp http://www.mindscope.co.jp movatwi http://www.movatwi.jp (Japanese mobile based Twitter app, Winner of OPEN WEB AWARDS 2009 “Best Mobile Based Twitter App”) -- 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
[twitter-dev] Re: A new permission level
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 -- 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
[twitter-dev] Re: A new permission level
@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. On May 19, 6:59 pm, Frank Ash nut...@gmail.com wrote: 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. -- 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
[twitter-dev] Re: A new permission level
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. -- 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
Re: [twitter-dev] Re: A new permission level
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 On Thursday, May 19, 2011 at 1:50 AM, janole wrote: 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. -- 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
[twitter-dev] Re: A new permission level
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. On May 19, 1:44 pm, Damon Parker cartmet...@gmail.com wrote: 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 On Thursday, May 19, 2011 at 1:50 AM, janole wrote: 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. -- 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
[twitter-dev] Re: A new permission level
+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.comtwitter: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.comwrote:
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 to
https://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
[twitter-dev] Re: A new permission level
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 -- 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
[twitter-dev] Re: A new permission level
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 ) On May 19, 2:44 pm, Damon Parker cartmet...@gmail.com wrote: 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 On Thursday, May 19, 2011 at 1:50 AM, janole wrote: 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. -- 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
Re: [twitter-dev] Re: A new permission level
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 On Thursday, May 19, 2011 at 11:14 AM, janole wrote: 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 ) On May 19, 2:44 pm, Damon Parker cartmet...@gmail.com wrote: 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
[twitter-dev] Re: A new permission level
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 On May 18, 5:11 pm, themattharris thematthar...@twitter.com wrote: Hey everyone, Thank you for all the feedback on the list, email and through Tweets. We've been responding throughout the day to many of the Tweets but wanted to group the questions together and respond here as well. Two weeks is not enough time to implement a web OAuth flow and have the app approved. We need an extension. We’ve heard your feedback on this list, privately and through Tweets about this. Based on this feedback we are going to extend the enforcement deadline by two weeks. This means we'll enforce the new permission the week beginning the 14th June 2011. This should provide enough time for you to make the change and have your application approved by your chosen platform’s app store. Will Twitter's own applications also go through the OAuth web flow? We’re taking this step to give more clarity and control to users about the access a third-party application has to their account. The way users interact with Twitter’s clients is not expected to change. Applications who wish to access a user’s DMs will need to update their application permission and incorporate the OAuth web flow if they don’t already. If an application does not need access to DMs it will not need to make any changes. Why will you not grandfather existing applications into DM access? Grandfathering all existing read/write tokens assumes they all wanted access to DMs. The feedback we’ve had from users and developers tells us otherwise. We want to give users the opportunity to make an informed choice. What if the client using xAuth has no browser and therefore cannot go through OAuth? For single user applications and scripts we provide the 'My Access Token' page of the application details. To ensure the 'My Access Token' is correct it is important the app owner revokes their access before change the permission level of the app. If you do not do this, the 'My Access Token' will not be regenerated with the new permission. This revoke action is only needed by you, the owner of the application. Remember Read/Write applications can still send direct messages. When you activate the new permission, will all Read and Read/Write user_tokens issued to third-party applications lose their ability to read direct messages? Existing tokens are unaffected by any change to the application permission level. If you change your application to R/W/DM all future authorizations will be for that permission. When a user re-authorizes, their existing token will be updated to the current application permission level. Access to DMs will be enforced on 14th June 2011 if the user_token wasn't authorised as for R/W/DM. What if I want to request a different level of access for my application instead of the one my application is registered with? You can do this now by using the x_auth_access_type parameter during the request_token phase. Using this parameter you can request a read or a read/write token even if your application is registered for read/ write/direct messages. More information on this method is in our developer documentation: http://dev.twitter.com/doc/post/oauth/request_token Why are permissions attached to the user token? Permissions are attached to the user token to ensure an application only has the access a user has authorised. If permissions were not attached to the user token an application would be able to change the level of access they have without the user’s knowledge. If you tie the permissions to the application each user token would need to be invalidated whenever an application’s permissions are changed. Users already gave their permission for apps to access private messages, why are you making us, and them, reauthorize? The purpose of the re-authorization is to ensure both users and developers know the level of access requested. Re-authorization allows a user to make a more informed decision about the access an application has requested. We hope these responses answer your questions. Please continue to send us your feedback about the permission model and what you would like to see it offer. Best, @themattharris -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] Re: A new permission level
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 On May 19, 7:44 am, Damon Parker cartmet...@gmail.com wrote: 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 On Thursday, May 19, 2011 at 1:50 AM, janole wrote: 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. -- 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
[twitter-dev] Re: A new permission level
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
On May 19, 9:42 am, TheGuru jsort...@gmail.com wrote:
+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.comtwitter: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.comwrote:
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/appsandchange 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
Re: [twitter-dev] Re: A new permission level
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 On Thursday, May 19, 2011 at 12:25 PM, Ron wrote: 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. -- 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
[twitter-dev] Re: A new permission level
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?
On May 19, 12:49 pm, Mark Pavlidis mark.pavli...@gmail.com wrote:
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
On May 19, 9:42 am, TheGuru jsort...@gmail.com wrote:
+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.comtwitter: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.comwrote:
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/appsandchangethe
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
[twitter-dev] Re: A new permission level
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?
On May 19, 12:49 pm, Mark Pavlidis mark.pavli...@gmail.com wrote:
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
On May 19, 9:42 am, TheGuru jsort...@gmail.com wrote:
+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.comtwitter: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.comwrote:
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/appsandchangethe
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}
[twitter-dev] Re: A new permission level
Hmm, thanks. Wonder why some are seeing this take affect and others, as reported in this thread (including myself), are not... On May 19, 1:13 pm, Mark Pavlidis 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? On May 19, 12:49 pm, Mark Pavlidis mark.pavli...@gmail.com wrote: 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 On May 19, 9:42 am, TheGuru jsort...@gmail.com wrote: +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.comtwitter: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.comwrote: 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/appsandchangethe 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
[twitter-dev] Re: A new permission level
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 -- 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
Re: [twitter-dev] Re: A new permission level
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
On 19 May 2011, at 19:04, 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?
On May 19, 12:49 pm, Mark Pavlidis mark.pavli...@gmail.com wrote:
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
On May 19, 9:42 am, TheGuru jsort...@gmail.com wrote:
+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.comtwitter: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.comwrote:
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/appsandchangethe
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
Re: [twitter-dev] Re: A new permission level
Ole- You make some very good points, but you can't use the tired users create poor passwords argument as a reason to stick with outdated security protocols. By that logic, no security upgrade is worth the time because some dumb users are going to foil you every time. If a user wants to chose a poor password and share it across all accounts, that's his business. You will never be able to stop that in a consumer situation such as this (ie. you have a lot of inexperienced users who could go elsewhere). On closed networks, you can disallow simple passwords and force password changes every few months. That's why professionals like you and I exist. We enforce state of the art and create systems as secure as we can given the constraints of the architecture (which your workaround is attempting to do). Many users will take advantage of all of the enhanced security and many won't. But everyone had a choice to educate themselves and use the most secure method they chose. Disclosing the fact that you could have had access to your user's accounts involves your customer's perception, not the reality. You did, in fact have access to their accounts. You may have taken care to secure and/or discard the data but not every developer is as conscientious or as honest as I'm sure you are. That is PR issue you and a few other developers in similar situation are about to be forced to deal with unfortunately. I feel for you. Apple did similar when they would not allow Flash on iOS. IMO, it was the right thing to do for their platform at the time. Flash sucks processing power and is inherently insecure. You can't have your phone lock up and ring 30 seconds late because some Flash advert or game was pegging out your mobile processor. It's a phone first. Did it also help them in the long run not to help a competitor? Obviously. It also forced developers to learn iOS and code for it specifically, not just make Flash apps based on an aging platform. In trying to get away from xAuth as much as possible, Twitter is obviously trying to take the third party out of the authentication equation and that in itself is a positive step towards a more secure system for Twitter. Does it hurt us developers and cost us money in redevelopment? Obviously. Is it a step towards clearing the slate of a lot of client competition? cheers damonp -- 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
[twitter-dev] Re: A new permission level
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,
[twitter-dev] Re: A new permission level
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. -- 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
[twitter-dev] Re: A new permission level
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 -- 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
[twitter-dev] Re: A new permission level
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 -- 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
[twitter-dev] Re: A new permission level
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 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. -- 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
Re: [twitter-dev] Re: A new permission level
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. On Thu, May 19, 2011 at 5:11 PM, TheGuru jsort...@gmail.com wrote: 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 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. -- 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 -- 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
FW: [twitter-dev] Re: A new permission level
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. Lol you're new around here aren't you.. Twitter have never seen developers as equals and don't do things like this. Cheers, Dean From: twitter-development-talk@googlegroups.com [mailto:twitter-development-talk@googlegroups.com] On Behalf Of Derek Gathright Sent: Friday, May 20, 2011 12:09 AM To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: A new permission level 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. On Thu, May 19, 2011 at 5:11 PM, TheGuru jsort...@gmail.com wrote: 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 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. -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues
[twitter-dev] Re: A new permission level
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 -- 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
[twitter-dev] Re: A new permission level
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
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 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
[twitter-dev] Re: A new permission level
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? -- 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
[twitter-dev] Re: A new permission level
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:funkat...@gmail.com -- 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
[twitter-dev] Re: A new permission level
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 -- 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
[twitter-dev] Re: A new permission level
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
[twitter-dev] Re: A new permission level
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 -- 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
[twitter-dev] Re: A new permission level
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 -- 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
Re: [twitter-dev] Re: A new permission level
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. On 18 May 2011, at 19:42, Naveen wrote: 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 -- 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 -- 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
Re: [twitter-dev] Re: A new permission level
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. On Wed, May 18, 2011 at 11:51 AM, Scott Wilcox sc...@dor.ky wrote: 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. On 18 May 2011, at 19:42, Naveen wrote: 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 -- 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 -- 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 -- 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
Re: [twitter-dev] Re: A new permission level
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 -- 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
[twitter-dev] Re: A new permission level
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. -- 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
Re: [twitter-dev] Re: A new permission level
On Wed, May 18, 2011 at 11:37 AM, Jon Colverson jjc1...@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 -- 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
[twitter-dev] Re: A new permission level
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
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
Re: [twitter-dev] Re: A new permission level
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 -- 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
Re: [twitter-dev] Re: A new permission level
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 On Wed, May 18, 2011 at 3:47 PM, Chad Etzel jazzyc...@gmail.com wrote: 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 -- 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
[twitter-dev] Re: A new permission level
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 -- 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
[twitter-dev] Re: A new permission level
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 :( -- 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
[twitter-dev] Re: A new permission level
Hey everyone, Thank you for all the feedback on the list, email and through Tweets. We've been responding throughout the day to many of the Tweets but wanted to group the questions together and respond here as well. Two weeks is not enough time to implement a web OAuth flow and have the app approved. We need an extension. We’ve heard your feedback on this list, privately and through Tweets about this. Based on this feedback we are going to extend the enforcement deadline by two weeks. This means we'll enforce the new permission the week beginning the 14th June 2011. This should provide enough time for you to make the change and have your application approved by your chosen platform’s app store. Will Twitter's own applications also go through the OAuth web flow? We’re taking this step to give more clarity and control to users about the access a third-party application has to their account. The way users interact with Twitter’s clients is not expected to change. Applications who wish to access a user’s DMs will need to update their application permission and incorporate the OAuth web flow if they don’t already. If an application does not need access to DMs it will not need to make any changes. Why will you not grandfather existing applications into DM access? Grandfathering all existing read/write tokens assumes they all wanted access to DMs. The feedback we’ve had from users and developers tells us otherwise. We want to give users the opportunity to make an informed choice. What if the client using xAuth has no browser and therefore cannot go through OAuth? For single user applications and scripts we provide the 'My Access Token' page of the application details. To ensure the 'My Access Token' is correct it is important the app owner revokes their access before change the permission level of the app. If you do not do this, the 'My Access Token' will not be regenerated with the new permission. This revoke action is only needed by you, the owner of the application. Remember Read/Write applications can still send direct messages. When you activate the new permission, will all Read and Read/Write user_tokens issued to third-party applications lose their ability to read direct messages? Existing tokens are unaffected by any change to the application permission level. If you change your application to R/W/DM all future authorizations will be for that permission. When a user re-authorizes, their existing token will be updated to the current application permission level. Access to DMs will be enforced on 14th June 2011 if the user_token wasn't authorised as for R/W/DM. What if I want to request a different level of access for my application instead of the one my application is registered with? You can do this now by using the x_auth_access_type parameter during the request_token phase. Using this parameter you can request a read or a read/write token even if your application is registered for read/ write/direct messages. More information on this method is in our developer documentation: http://dev.twitter.com/doc/post/oauth/request_token Why are permissions attached to the user token? Permissions are attached to the user token to ensure an application only has the access a user has authorised. If permissions were not attached to the user token an application would be able to change the level of access they have without the user’s knowledge. If you tie the permissions to the application each user token would need to be invalidated whenever an application’s permissions are changed. Users already gave their permission for apps to access private messages, why are you making us, and them, reauthorize? The purpose of the re-authorization is to ensure both users and developers know the level of access requested. Re-authorization allows a user to make a more informed decision about the access an application has requested. We hope these responses answer your questions. Please continue to send us your feedback about the permission model and what you would like to see it offer. Best, @themattharris -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] Re: A new permission level
Thanks Matt! I still urge you to reconsider the mass breakage of older and existing apps and the crippling mobile/desktop user experiences apps going forward. My own judgement is that yes, maybe user didn't realize that didn't want to give that level of access and matbe the web flow can help twitter communicate to the user better, but it's going up against all the issues of users that already authorized and throws away all the constant re-hashing of the issues 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. Zac -- 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
[twitter-dev] Re: A new permission level
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 On May 19, 10:11 am, themattharris thematthar...@twitter.com wrote: Hey everyone, Thank you for all the feedback on the list, email and through Tweets. We've been responding throughout the day to many of the Tweets but wanted to group the questions together and respond here as well. Two weeks is not enough time to implement a web OAuth flow and have the app approved. We need an extension. We’ve heard your feedback on this list, privately and through Tweets about this. Based on this feedback we are going to extend the enforcement deadline by two weeks. This means we'll enforce the new permission the week beginning the 14th June 2011. This should provide enough time for you to make the change and have your application approved by your chosen platform’s app store. Will Twitter's own applications also go through the OAuth web flow? We’re taking this step to give more clarity and control to users about the access a third-party application has to their account. The way users interact with Twitter’s clients is not expected to change. Applications who wish to access a user’s DMs will need to update their application permission and incorporate the OAuth web flow if they don’t already. If an application does not need access to DMs it will not need to make any changes. Why will you not grandfather existing applications into DM access? Grandfathering all existing read/write tokens assumes they all wanted access to DMs. The feedback we’ve had from users and developers tells us otherwise. We want to give users the opportunity to make an informed choice. What if the client using xAuth has no browser and therefore cannot go through OAuth? For single user applications and scripts we provide the 'My Access Token' page of the application details. To ensure the 'My Access Token' is correct it is important the app owner revokes their access before change the permission level of the app. If you do not do this, the 'My Access Token' will not be regenerated with the new permission. This revoke action is only needed by you, the owner of the application. Remember Read/Write applications can still send direct messages. When you activate the new permission, will all Read and Read/Write user_tokens issued to third-party applications lose their ability to read direct messages? Existing tokens are unaffected by any change to the application permission level. If you change your application to R/W/DM all future authorizations will be for that permission. When a user re-authorizes, their existing token will be updated to the current application permission level. Access to DMs will be enforced on 14th June 2011 if the user_token wasn't authorised as for R/W/DM. What if I want to request a different level of access for my application instead of the one my application is registered with? You can do this now by using the x_auth_access_type parameter during the request_token phase. Using this parameter you can request a read or a read/write token even if your application is registered for read/ write/direct messages. More information on this method is in our developer documentation: http://dev.twitter.com/doc/post/oauth/request_token Why are permissions attached to the user token? Permissions are attached to the user token to ensure an application only has the access a user has authorised. If permissions were not attached to the user token an application would be able to change the level of access they have without the user’s knowledge. If you tie the permissions to the application each user token would need to be invalidated whenever an application’s permissions are changed. Users already gave their permission for apps to access private messages, why are you making us, and them, reauthorize? The purpose of the re-authorization is to ensure both users and developers know the level of access requested. Re-authorization allows a user to make a more informed decision about the access an application has requested. We hope these responses answer your questions. Please continue to send us your feedback about the permission model and what you would like to see it offer. Best, @themattharris -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group:
