Ole- 

You make some very good points, but you can't use the tired "users create poor 
passwords" argument as a reason to stick with outdated security protocols. By 
that logic, no security upgrade is worth the time because some dumb users are 
going to foil you every time.

If a user wants to chose a poor password and share it across all accounts, 
that's his business. You will never be able to stop that in a consumer 
situation such as this (ie. you have a lot of inexperienced users who could go 
elsewhere). On closed networks, you can disallow simple passwords and force 
password changes every few months. 

That's why professionals like you and I exist. We enforce state of the art and 
create systems as secure as we can given the constraints of the architecture 
(which your workaround is attempting to do). Many users will take advantage of 
all of the enhanced security and many won't. But everyone had a choice to 
educate themselves and use the most secure method they chose. 

Disclosing the fact that you could have had access to your user's accounts 
involves your customer's perception, not the reality. You did, in fact have 
access to their accounts. You may have taken care to secure and/or discard the 
data but not every developer is as conscientious or as honest as I'm sure you 
are. That is PR issue you and a few other developers in similar situation are 
about to be forced to deal with unfortunately. I feel for you.

Apple did similar when they would not allow Flash on iOS. IMO, it was the right 
thing to do for their platform at the time. Flash sucks processing power and is 
inherently insecure. You can't have your phone lock up and ring 30 seconds late 
because some Flash advert or game was pegging out your mobile processor. It's a 
phone first. Did it also help them in the long run not to "help" a competitor? 
Obviously. It also forced developers to learn iOS and code for it specifically, 
not just make Flash apps based on an aging platform.

In trying to get away from xAuth as much as possible, Twitter is obviously 
trying to take the third party out of the authentication equation and that in 
itself is a positive step towards a more secure system for Twitter. Does it 
hurt us developers and cost us money in redevelopment? Obviously. Is it a step 
towards clearing the slate of a lot of client competition?




cheers


damonp 

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

Reply via email to