In any security or permissions context the default should be the most secure 
and least amount of permissions to get the job done. That is Computer and 
Network Security 101. 

A user must explicitly configure more loose permissions on their own after 
understanding the implications. This is the way computer network security is 
and always has been done. This is part of the reason Linux/Unix et al is way 
more secure than Windows ever could be.

Just because a user isn't sophisticated enough to configure more lax 
permissions to get their needs met isn't a reason to default to lower the 
security context. This is what FB did _completely_ wrong when they updated 
their permissions system. They defaulted everything to being completely open, 
accessible and public for purely selfish reasons. They wanted to keep more user 
data 100% public thus increasing the amount of public and free (as in $ to FB) 
user-generated content created every day. More pageviews, more pics, more 
comments equals more ad revenue for them.

Even though it's a pain in the ass for developer's to rework their apps and 
re-auth it's the right thing to do for the end user and the overall safety of 
the community.

I commend Twitter for doing the right (even if unpopular) thing in this case.



Damon


On Thursday, May 19, 2011 at 1:50 AM, janole wrote: 
> Hi Matt,
> 
> thanks for your feedback. I think the following paragraph can't be
> generalized, though:
> 
> > > Why will you not grandfather existing applications into DM access?
> > 
> > Grandfathering all existing read/write tokens assumes they all wanted
> > access to DMs. The feedback we’ve had from users and developers tells
> > us otherwise. We want to give users the opportunity to make an
> > informed choice.

-- 
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
https://groups.google.com/forum/#!forum/twitter-development-talk

Reply via email to