Damon, with all due respect and in all politeness, have you even read what this thread is about?
Do you really think an xAuth application - that knows the users full credentials - is getting more secure without the right to access direct messages? I mean ... really ;-) We both do not know why Twitter tries to introduce this change. I have a feeling what it is about, but it's definitely not about user privacy or security if it comes to xAuth applications. OAuth apps, granted, different story and I could live with that change. But as I am not using OAuth, I leave it to the developers affected to voice their concerns. They should know better. For me, who needs to have xAuth access to provide my users access to Twitter - actually to provide it to the Symbian platform ( biggest smartphone OS worldwide, 2010 ... ) - these changes are not good. And my users do think the same. Most of my users love Twitter and I try to provide a client that makes them use Twitter a lot - because I love Twitter, too ( well, better to say, I am addicted to Twitter. ) I just don't see any reason why this privacy related change couldn't be implemented in a way which does NOT break so many applications. We are also talking about preloaded mobile apps here - apps that cannot be changed quickly - or cannot be changed at all. My planned work-around for this xAuth change ( I still hope it is being reverted! ) will include running a Twitter service for authentication. That way, I would have access to my users' OAuth tokens. I don't like that. It imposes a great risk to me and my servers being hacked. So far, I do not know nothing about my users via my Twitter client. No password, no credentials. I like it that way. More secure for my users. As for Linux, yes, we all know Linux is way more secure. That's why companies like Sony and Gawker are running their services on top of Linux servers ... okay, forget about that one ;-) Cheers & please don't feel offended, Ole ( @janole / @gravityapp ) On May 19, 2:44 pm, Damon Parker <cartmet...@gmail.com> wrote: > In any security or permissions context the default should be the most secure > and least amount of permissions to get the job done. That is Computer and > Network Security 101. > > A user must explicitly configure more loose permissions on their own after > understanding the implications. This is the way computer network security is > and always has been done. This is part of the reason Linux/Unix et al is way > more secure than Windows ever could be. > > Just because a user isn't sophisticated enough to configure more lax > permissions to get their needs met isn't a reason to default to lower the > security context. This is what FB did _completely_ wrong when they updated > their permissions system. They defaulted everything to being completely open, > accessible and public for purely selfish reasons. They wanted to keep more > user data 100% public thus increasing the amount of public and free (as in $ > to FB) user-generated content created every day. More pageviews, more pics, > more comments equals more ad revenue for them. > > Even though it's a pain in the ass for developer's to rework their apps and > re-auth it's the right thing to do for the end user and the overall safety of > the community. > > I commend Twitter for doing the right (even if unpopular) thing in this case. > > Damon > > > > > > > > On Thursday, May 19, 2011 at 1:50 AM, janole wrote: > > Hi Matt, > > > thanks for your feedback. I think the following paragraph can't be > > generalized, though: > > > > > Why will you not grandfather existing applications into DM access? > > > > Grandfathering all existing read/write tokens assumes they all wanted > > > access to DMs. The feedback we’ve had from users and developers tells > > > us otherwise. We want to give users the opportunity to make an > > > informed choice. -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
