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.


On May 19, 7:44 am, Damon Parker <> wrote:
> In any security or permissions context the default should be the most secure 
> and least amount of permissions to get the job done. That is Computer and 
> Network Security 101.
> A user must explicitly configure more loose permissions on their own after 
> understanding the implications. This is the way computer network security is 
> and always has been done. This is part of the reason Linux/Unix et al is way 
> more secure than Windows ever could be.
> Just because a user isn't sophisticated enough to configure more lax 
> permissions to get their needs met isn't a reason to default to lower the 
> security context. This is what FB did _completely_ wrong when they updated 
> their permissions system. They defaulted everything to being completely open, 
> accessible and public for purely selfish reasons. They wanted to keep more 
> user data 100% public thus increasing the amount of public and free (as in $ 
> to FB) user-generated content created every day. More pageviews, more pics, 
> more comments equals more ad revenue for them.
> Even though it's a pain in the ass for developer's to rework their apps and 
> re-auth it's the right thing to do for the end user and the overall safety of 
> the community.
> I commend Twitter for doing the right (even if unpopular) thing in this case.
> Damon
> On Thursday, May 19, 2011 at 1:50 AM, janole wrote:
> > Hi Matt,
> > thanks for your feedback. I think the following paragraph can't be
> > generalized, though:
> > > > Why will you not grandfather existing applications into DM access?
> > > Grandfathering all existing read/write tokens assumes they all wanted
> > > access to DMs. The feedback we’ve had from users and developers tells
> > > us otherwise. We want to give users the opportunity to make an
> > > informed choice.

Twitter developer documentation and resources:
API updates via Twitter:
Issues/Enhancements Tracker:
Change your membership to this group:!forum/twitter-development-talk

Reply via email to