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.
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.
I still urge you to reconsider the mass breakage of older existing apps, and crippling of the mobile/desktop app user experiences going forward.
My own judgement is that yes, maybe the user didn't realize that they didn't want to give that level of access and maybe the web flow can help twitter communicate to the user better what they app is request, but it's going up against all the issues of users that already authorized are not expecting things to break. It also throws away all the constant re-hashing went through before basic auth went away around the UX of oAuth that drove the development of xAuth in the first place.
I fear it's going to be litteral countdown until doomsday and hell is going to break out of users and developers that didn't get the memo. (I just checked, and my mother is still using a twitter client for the iPad that was updated over 4 months ago.)
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:
> 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.
> > 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.
thanks for your feedback. I think the following paragraph can't be
generalized, though:
> > Why will you not grandfather existing applications into DM access?
> Grandfathering all existing read/write tokens assumes they all wanted
> access to DMs. The feedback we’ve had from users and developers tells
> us otherwise. We want to give users the opportunity to make an
> informed choice.
I can assure you that if I am asking any of my 100.000's users that
they would disagree with that statement. They all explicitly want to
access DMs in my Symbian based Twitter client. They actually EXPECT to
have access to direct messages.
A Twitter client without access to Direct Messages is not a Twitter
client. Wouldn't you agree? ;-)
I would urge you to rethink this decision - or let us know in all
honesty why you were imposing this bad UX on third party clients only.
If there was a proper way of doing the Web OAuth flow on the Symbian
platform, things would be a bit different (although not much.)
But now, the best option for me is to setup an intermediate server for
the OAuth flow - effectively giving me access to the users' OAuth
credentials. Something, that I didn't have access to before.
Something, that I didn't WANT to have access to from the beginning.
This doesn't seem like an improvement of privacy for my users at
least.
Please, please find a better solution for this. There are many options
that won't break third party clients - clients which cannot go through
the web Oauth flow, clients that have a wonderful user base
contributing to the Twitter "experience" with a lot of great Tweets.
> > 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.
> > 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.
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?
> We recently updated our OAuth screens to give users greater transparency > about the level of access applications have to their accounts. The valuable > feedback Twitter users and developers have given us played a large part in > that redesign and helped us identify where we can do more.
> In particular, users and developers have requested greater granularity for > permission levels.
> In response to this feedback, we have created a new permission level for > applications called “Read, Write & Direct Messages”. This permission will > allow an application to read or delete a user's direct messages. When we > enforce this permission, applications without a “Read, Write & Direct > Messages” token will be unable to read or delete direct messages. To ensure > users know that an application is receiving access to their direct messages, > we are also restricting this permission to the OAuth /authorize web flow > only. This means applications which use xAuth and want to access direct > messages must send a user through the full OAuth flow.
> What does this mean for your application? > If you do not need access to direct messages: you won’t need to make any > changes to your application. When we enforce the new permission level your > read or read/write token will automatically lose access to direct messages.
> If you do need access to direct messages: you will need to edit your > application record on https://dev.twitter.com/apps and change the > permission level of your application to “Read, Write and Direct Messages”. > The new permission will not affect existing tokens which means existing > users or your app or service will need to reauthorize.
> We know this will take some time so we are allowing a transition period > until the end of this month. During this time there will be no change to the > access Read/Write tokens have to a users account. However, at the end of the > month any tokens which have not been upgrade to “Read, Write and Direct > Messages” will be unable to access and delete direct messages.
> Affected APIs and requests > On the REST API, Read and Read/Write applications will no longer be able to > use these API methods: > /1/direct_messages.{format} > /1/direct_messages/sent.{format} > /1/direct_messages/show.{format} > /1/direct_messages/destroy.{format}
> For the Streaming API, both User Streams and Site Streams will only receive > direct messages if the user has authorised an application to access direct > messages.
> Applications that use “Sign-in with Twitter” or xAuth will only be able to > receive Read or Read/Write tokens.
> What this means is only applications which direct a user through the OAuth > web flow will be able to receive access tokens that allow access to direct > messages. Any other method of authorization, including xAuth, will only be > able to receive Read/Write tokens.
> What will happen when the permission is activated > When we activate the new permission, all Read and Read/Write user_tokens > issued to third-party applications will lose their ability to read direct > messages. Any attempt to read direct messages will result in an HTTP 403 > error being returned.
> {"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.
> 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.
> > 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.
The sad reality is that the way it's being taken in the news is that
"twitter is doing this because developers have been abusing their
privacy." We know this is not the case, we know we just need access
them to provide them the feeds that they WANT to see, by virtue of the
fact that they downloaded an app that clearly states it can do this.
If any of you wouldn't mind jumping into this article and setting a
few people straight, that'd be great:
http://mashable.com/2011/05/18/twitter-permissions/
(see comments)
Best,
Tammy
On May 19, 9:29 am, janole <s...@mobileways.de> wrote:
> Wouldn't it be possible to keep the DM access rights with xAuth and
> only revoke it upon users complaints or your monitoring of API usage?
> If I remember correctly, Twitter said they are revoking hundreds of
> API clients per day, so it seems like this approach is working well.
> Cheers,
> Ole ( @janole / @gravityapp )
> On May 19, 2: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.
> > > 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.
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.
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.
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.
> 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?
> On Wed, May 18, 2011 at 6:01 PM, Matt Harris <thematthar...@twitter.com>wrote:
> > Hey everyone,
> > We recently updated our OAuth screens to give users greater transparency
> > about the level of access applications have to their accounts. The valuable
> > feedback Twitter users and developers have given us played a large part in
> > that redesign and helped us identify where we can do more.
> > In particular, users and developers have requested greater granularity for
> > permission levels.
> > In response to this feedback, we have created a new permission level for
> > applications called “Read, Write & Direct Messages”. This permission will
> > allow an application to read or delete a user's direct messages. When we
> > enforce this permission, applications without a “Read, Write & Direct
> > Messages” token will be unable to read or delete direct messages. To ensure
> > users know that an application is receiving access to their direct messages,
> > we are also restricting this permission to the OAuth /authorize web flow
> > only. This means applications which use xAuth and want to access direct
> > messages must send a user through the full OAuth flow.
> > What does this mean for your application?
> > If you do not need access to direct messages: you won’t need to make any
> > changes to your application. When we enforce the new permission level your
> > read or read/write token will automatically lose access to direct messages.
> > If you do need access to direct messages: you will need to edit your
> > application record onhttps://dev.twitter.com/appsand change the
> > 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.
> > {"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.
I have created a new app as a test, with the new permission level. In the OAuth dialog it still explicitly states that the app will not be able to read or send DM's. My guess is that I either have to specify the permission level with a variable, or that it is not enabled yet.
On Thu, May 19, 2011 at 2:42 PM, 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?
> > On Wed, May 18, 2011 at 6:01 PM, Matt Harris <thematthar...@twitter.com > >wrote:
> > > Hey everyone,
> > > We recently updated our OAuth screens to give users greater > transparency > > > about the level of access applications have to their accounts. The > valuable > > > feedback Twitter users and developers have given us played a large part > in > > > that redesign and helped us identify where we can do more.
> > > In particular, users and developers have requested greater granularity > for > > > permission levels.
> > > In response to this feedback, we have created a new permission level > for > > > applications called “Read, Write & Direct Messages”. This permission > will > > > allow an application to read or delete a user's direct messages. When > we > > > enforce this permission, applications without a “Read, Write & Direct > > > Messages” token will be unable to read or delete direct messages. To > ensure > > > users know that an application is receiving access to their direct > messages, > > > we are also restricting this permission to the OAuth /authorize web > flow > > > only. This means applications which use xAuth and want to access direct > > > messages must send a user through the full OAuth flow.
> > > What does this mean for your application? > > > If you do not need access to direct messages: you won’t need to make > any > > > changes to your application. When we enforce the new permission level > your > > > read or read/write token will automatically lose access to direct > messages.
> > > If you do need access to direct messages: you will need to edit your > > > application record onhttps://dev.twitter.com/appsand change the > > > 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.
> > > {"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.
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.
However, you guys really need to stop doing this type of stuff. The
war on client apps is getting a bit out of control. They grow the
twitter userbase, and dev's helped make twitter what it is and sustain
its growth by offering many different ways to connect on various
devices, with different UI's that lots of users like, and in places
and ways it may not be available otherwise. And some users effected by
these clients going down, will never use twitter again since their
favorite app or site is now gone, they would just rather not mess with
getting a new one and move on.
You dont have to control the market to capitalize on control of the
user base. If more effort was spent on an iAds type program like for
Twitters case could be TwitAds for developers to integrate, then you
would be making much more in the long run. Or even adding in ads to
the API streams with revenue sharing for clients. Then just have a
good standard guideline for UI, data access and usage, then boom, no
more stress of loosing control. No more having to buy Tweetdeck for 50
million because it controls too much. Just add in revenue sharing from
ads and clear guidelines for clients, then your problem is solved. But
the way it is being looked out now is not sustainable or realistic in
todays market from my perspective.
Developers are scared to death all the time because we know there
will be something new (like this) every other month or so and we are
just waiting for that final one that cuts our legs out from under us
completely. I dont think Twitter should see it as taking away, but the
potential it has to add many more users to the system, and if they
look at revenue differently than just twitter controlling all ads and
clients do their own, they would see a much higher spike in revenue
and clients would have a standard system they could use for their
revenue stream as well. Then if you need to do quality control thats
understandable, just lay out the requirements in simple terms, show
some examples, make them realistic, then we all make money and twitter
continues it growth with the help of Dev's. But without the wealth and
diversity of client apps, you will see slower growth, and less user
engagement.
On May 18, 7:11 pm, themattharris <thematthar...@twitter.com> wrote:
> 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.
> > 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.
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 ;-)
> 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.
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:
> 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.
> > 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.
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.
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 ;-)
> 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.
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.
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?
> > On Wed, May 18, 2011 at 6:01 PM, Matt Harris <thematthar...@twitter.com>wrote:
> > > Hey everyone,
> > > We recently updated our OAuth screens to give users greater transparency
> > > about the level of access applications have to their accounts. The valuable
> > > feedback Twitter users and developers have given us played a large part in
> > > that redesign and helped us identify where we can do more.
> > > In particular, users and developers have requested greater granularity for
> > > permission levels.
> > > In response to this feedback, we have created a new permission level for
> > > applications called “Read, Write & Direct Messages”. This permission will
> > > allow an application to read or delete a user's direct messages. When we
> > > enforce this permission, applications without a “Read, Write & Direct
> > > Messages” token will be unable to read or delete direct messages. To ensure
> > > users know that an application is receiving access to their direct messages,
> > > we are also restricting this permission to the OAuth /authorize web flow
> > > only. This means applications which use xAuth and want to access direct
> > > messages must send a user through the full OAuth flow.
> > > What does this mean for your application?
> > > If you do not need access to direct messages: you won’t need to make any
> > > changes to your application. When we enforce the new permission level your
> > > read or read/write token will automatically lose access to direct messages.
> > > If you do need access to direct messages: you will need to edit your
> > > application record onhttps://dev.twitter.com/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.
> > > {"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.
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.
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.
> 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?
> > > On Wed, May 18, 2011 at 6:01 PM, Matt Harris <thematthar...@twitter.com>wrote:
> > > > Hey everyone,
> > > > We recently updated our OAuth screens to give users greater transparency
> > > > about the level of access applications have to their accounts. The valuable
> > > > feedback Twitter users and developers have given us played a large part in
> > > > that redesign and helped us identify where we can do more.
> > > > In particular, users and developers have requested greater granularity for
> > > > permission levels.
> > > > In response to this feedback, we have created a new permission level for
> > > > applications called “Read, Write & Direct Messages”. This permission will
> > > > allow an application to read or delete a user's direct messages. When we
> > > > enforce this permission, applications without a “Read, Write & Direct
> > > > Messages” token will be unable to read or delete direct messages. To ensure
> > > > users know that an application is receiving access to their direct messages,
> > > > we are also restricting this permission to the OAuth /authorize web flow
> > > > only. This means applications which use xAuth and want to access direct
> > > > messages must send a user through the full OAuth flow.
> > > > What does this mean for your application?
> > > > If you do not need access to direct messages: you won’t need to make any
> > > > changes to your application. When we enforce the new permission level your
> > > > read or read/write token will automatically lose access to direct messages.
> > > > If you do need access to direct messages: you will need to edit your
> > > > application record onhttps://dev.twitter.com/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 a user through the OAuth
> > > > web flow will be able to receive access tokens that allow access to direct
> > > > messages. Any other method of authorization, including xAuth, will only be
> > > > able to receive Read/Write tokens.
> > > > What will happen when the permission is activated
> > > > When we activate the new permission, all Read and Read/Write user_tokens
> > > > issued to third-party applications will lose their ability to read direct
> > > > messages. Any attempt to read direct messages will result in an HTTP 403
> > > > error being returned.
> > > > {"errors":[{"code":93,"message":"This application is not allowed to access
> > > > or delete your direct messages"}]}
> > > > Key Points
> > > > * If you wish to access a user’s direct messages you will need to update
> > > > your application and reauthorize existing tokens.
> > > > * The only way to get direct message access is to request access through
> > > > the OAuth /authorize web flow. You will not be permitted to access direct
> > > > messages if you use xAuth.
> > > > * When we enforce the permission Read/Write and Read tokens will be unable
> > > > to access and delete direct messages.
> > > > * Read/Write tokens will be able to send direct messages after the
> > > > permission is enforced.
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:
> 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?
> > > > On Wed, May 18, 2011 at 6:01 PM, Matt Harris <thematthar...@twitter.com>wrote:
> > > > > Hey everyone,
> > > > > We recently updated our OAuth screens to give users greater transparency
> > > > > about the level of access applications have to their accounts. The valuable
> > > > > feedback Twitter users and developers have given us played a large part in
> > > > > that redesign and helped us identify where we can do more.
> > > > > In particular, users and developers have requested greater granularity for
> > > > > permission levels.
> > > > > In response to this feedback, we have created a new permission level for
> > > > > applications called “Read, Write & Direct Messages”. This permission will
> > > > > allow an application to read or delete a user's direct messages. When we
> > > > > enforce this permission, applications without a “Read, Write & Direct
> > > > > Messages” token will be unable to read or delete direct messages. To ensure
> > > > > users know that an application is receiving access to their direct messages,
> > > > > we are also restricting this permission to the OAuth /authorize web flow
> > > > > only. This means applications which use xAuth and want to access direct
> > > > > messages must send a user through the full OAuth flow.
> > > > > What does this mean for your application?
> > > > > If you do not need access to direct messages: you won’t need to make any
> > > > > changes to your application. When we enforce the new permission level your
> > > > > read or read/write token will automatically lose access to direct messages.
> > > > > If you do need access to direct messages: you will need to edit your
> > > > > application record onhttps://dev.twitter.com/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 a user through the OAuth
> > > > > web flow will be able to receive access tokens that allow access to direct
> > > > > messages. Any other method of authorization, including xAuth, will only be
> > > > > able to receive Read/Write tokens.
> > > > > What will happen when the permission is activated
> > > > > When we activate the new permission, all Read and Read/Write user_tokens
> > > > > issued to third-party applications will lose their ability to read direct
> > > > > messages. Any attempt to read direct messages will result in an HTTP 403
> > > > > error being returned.
> > > > > {"errors":[{"code":93,"message":"This application is not allowed to access
> > > > > or delete your direct messages"}]}
> > > > > Key Points
> > > > > * If you wish to access a user’s direct messages you will need to update
> > > > > your application and reauthorize existing tokens.
> > > > > * The only way to get direct message access is to request access through
> > > > > the OAuth /authorize web flow. You will not be permitted to access direct
> > > > > messages if you use xAuth.
> > > > > * When we enforce the permission Read/Write and Read tokens will be unable
> > > > > to access and delete direct messages.
> > > > > * Read/Write tokens will be able to send direct messages after the
> > > > > permission is enforced.
> 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?
> > > > > On Wed, May 18, 2011 at 6:01 PM, Matt Harris <thematthar...@twitter.com>wrote:
> > > > > > Hey everyone,
> > > > > > We recently updated our OAuth screens to give users greater transparency
> > > > > > about the level of access applications have to their accounts. The valuable
> > > > > > feedback Twitter users and developers have given us played a large part in
> > > > > > that redesign and helped us identify where we can do more.
> > > > > > In particular, users and developers have requested greater granularity for
> > > > > > permission levels.
> > > > > > In response to this feedback, we have created a new permission level for
> > > > > > applications called “Read, Write & Direct Messages”. This permission will
> > > > > > allow an application to read or delete a user's direct messages. When we
> > > > > > enforce this permission, applications without a “Read, Write & Direct
> > > > > > Messages” token will be unable to read or delete direct messages. To ensure
> > > > > > users know that an application is receiving access to their direct messages,
> > > > > > we are also restricting this permission to the OAuth /authorize web flow
> > > > > > only. This means applications which use xAuth and want to access direct
> > > > > > messages must send a user through the full OAuth flow.
> > > > > > What does this mean for your application?
> > > > > > If you do not need access to direct messages: you won’t need to make any
> > > > > > changes to your application. When we enforce the new permission level your
> > > > > > read or read/write token will automatically lose access to direct messages.
> > > > > > If you do need access to direct messages: you will need to edit your
> > > > > > application record onhttps://dev.twitter.com/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 a user through the OAuth
> > > > > > web flow will be able to receive access tokens that allow access to direct
> > > > > > messages. Any other method of authorization, including xAuth, will only be
> > > > > > able to receive Read/Write tokens.
> > > > > > What will happen when the permission is activated
> > > > > > When we activate the new permission, all Read and Read/Write user_tokens
> > > > > > issued to third-party applications will lose their ability to read direct
> > > > > > messages. Any attempt to read direct messages will result in an HTTP 403
> > > > > > error being returned.
> > > > > > {"errors":[{"code":93,"message":"This application is not allowed to access
> > > > > > or delete your direct messages"}]}
> > > > > > Key Points
> > > > > > * If you wish to access a user’s direct messages you will need to update
> > > > > > your application and reauthorize existing tokens.
> > > > > > * The only way to get direct message access is to request access through
> > > > > > the OAuth /authorize web flow. You will not be permitted to access direct
> > > > > > messages if you use xAuth.
> > > > > > * When we enforce the permission Read/Write and Read tokens will be unable
> > > > > > to access and delete direct messages.
> > > > > > * Read/Write tokens will be able to send direct messages after the
> > > > > > permission is enforced.
> 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
> 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?
>>>> On Wed, May 18, 2011 at 6:01 PM, Matt Harris <thematthar...@twitter.com>wrote:
>>>>> Hey everyone,
>>>>> We recently updated our OAuth screens to give users greater transparency >>>>> about the level of access applications have to their accounts. The valuable >>>>> feedback Twitter users and developers have given us played a large part in >>>>> that redesign and helped us identify where we can do more.
>>>>> In particular, users and developers have requested greater granularity for >>>>> permission levels.
>>>>> In response to this feedback, we have created a new permission level for >>>>> applications called “Read, Write & Direct Messages”. This permission will >>>>> allow an application to read or delete a user's direct messages. When we >>>>> enforce this permission, applications without a “Read, Write & Direct >>>>> Messages” token will be unable to read or delete direct messages. To ensure >>>>> users know that an application is receiving access to their direct messages, >>>>> we are also restricting this permission to the OAuth /authorize web flow >>>>> only. This means applications which use xAuth and want to access direct >>>>> messages must send a user through the full OAuth flow.
>>>>> What does this mean for your application? >>>>> If you do not need access to direct messages: you won’t need to make any >>>>> changes to your application. When we enforce the new permission level your >>>>> read or read/write token will automatically lose access to direct messages.
>>>>> If you do need access to direct messages: you will need to edit your >>>>> application record onhttps://dev.twitter.com/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 a user through the OAuth >>>>> web flow will be able to receive access tokens that allow access to direct >>>>> messages. Any other method of authorization, including xAuth, will only be >>>>> able to receive Read/Write tokens.
>>>>> What will happen when the permission is activated >>>>> When we activate the new permission, all Read and Read/Write user_tokens >>>>> issued to third-party applications will lose their ability to read direct >>>>> messages. Any attempt to read direct messages will result in an HTTP 403 >>>>> error being returned.
>>>>> {"errors":[{"code":93,"message":"This application is not allowed to access >>>>> or delete your direct messages"}]}
>>>>> Key Points >>>>> * If you wish to access a user’s direct messages you will need to update >>>>> your application and reauthorize existing tokens. >>>>> * The only way to get direct message access is to request access through >>>>> the OAuth /authorize web flow. You will not be permitted to access direct >>>>> messages if you use xAuth. >>>>> * When we enforce the permission Read/Write and Read tokens will be unable >>>>> to access and delete direct messages. >>>>> * Read/Write tokens will be able to send direct messages after the >>>>> permission is enforced.
