[twitter-dev] Re: OAuth + Mobile nightmare

2009-08-18 Thread Otávio Ribeiro
no.. just the same problem.
On Mon, Aug 17, 2009 at 3:09 PM, AArruda arrud...@gmail.com wrote:


 I've been developing a Java/MIDP Twitter client for the past two
 months, and i still need a couple more months to publish a beta
 version. A few days ago i found out that the update source (app name)
 is no longer customizable unless the client uses OAuth for
 authentication, which means that any update sent through my client is
 shown as from API instead of my app's name.

 I understand that OAuth is important for many security reasons, but it
 still has important issues with mobile applications, forcing the user
 to open a page through a mobile device, writing down the PIN,
 switching back to the app and logging in again is just hell. Not to
 mention the smartphones that don't support programs running in the
 background.

 The current API's methods shouldn't be restricted to OAuth unless
 these issues are solved first. We, developers and mobile users, would
 be thankful.

 Is anyone using any other solution for OAuth and mobile devices, if
 there is any?



[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?

2009-07-31 Thread Otávio Ribeiro
About the first point, this will just keep happening. The only difference is
that instead of have their credential stolen, they will have their token
stolen. Then, spammers, for example, will use this tokens to send a lot of
spam messages, or do whatever they want. When the user notice it will be too
late.The damage will be done.
Spammers can just provide a simple site, like those test sites around, for
example, and collect a lot of request token before send the spams.
But it is ok, the user can just block this application without changing the
password. That is very nice.

Second,

there will be applications asking for username and password even if twitter
do not support basic authentication anymore. And we can try to educate our
users, but, as far as I know all Banks are trying to do this for some couple
of years without success.

The main problem here is that the security breach of all systems is the
user. And unfortunately we can not change them as fast as we can change our
codes. :-(

That is just my opinion and i´m a little out of date within oauth. I like
the idea but think that the current flow is very poor for mobile and
embedded devices.

regards,
Otávio Ribeiro


On Fri, Jul 31, 2009 at 9:18 AM, Duane Roelands duane.roela...@gmail.comwrote:


 With basic auth you are aware of the fact you are giving application
 credentials, so are able to make thoughtful decision.
 This is not supported by the evidence, as thousands of people
 thoughtfully gave their Twitter credentials to TwitViewer and got
 their accounts stolen.

 With OAuth you (ordinary user) are not aware of the fact that you
 give application credentials
 This is incorrect.  WIth OAuth, you don't give your credentials to
 anyone except Twitter.

 It's a bad idea to give your account credentials to a third party.
 Basic Auth forces you to give your account credentials to a third
 party.
 Therefore, using Basic Auth is a bad idea.

 On Jul 31, 8:09 am, Nicole Simon nee...@gmail.com wrote:
  I am surprised nobody is bringing up these too points:
 
  - people will use the more secure thing once they are educated. you know
 the
  kind of stuff where you tell the people you support that they will not
 get
  tech support any more if they do this.
 
  - the argument about 'having to agree on something' is not as bad as it
  sound because they do it every day on facebook. The one thing I do mind
 that
  even I always have to search aruond to find the place where my apps are
  located.
 
  Nicole
 
  ~~~
 
  --
  Jetzt im Buchhandel:
  Twitter - Mit 140 Zeichen zum Web 2.0
  Amazon:http://tinyurl.com/6at9c5
 
  http://mit140zeichen.de-http://twitter.com/m140z
 
  Kontakt:
 http://twitter.com/NicoleSimonhttps://www.xing.com/profile/Nicole_Simon
 
  skype: nicole.simon / mailto:nicole.si...@mit140zeichen.de
  phone: +49 451 899 75 03 / mobile: +49 179 499 7076



[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?

2009-07-28 Thread Otávio Ribeiro
+1.
Unfortunately i have to agree. I´m working with mobile twitter applications
and oauth is far for been a good solution. I really hope that twitter team
provide us a better solutions to work with mobile or embedded environments
where the web browser may not be available or have a limited support.

regards,
Otávio Ribeiro


On Tue, Jul 28, 2009 at 8:27 AM, chinaski007 chinaski...@gmail.com wrote:



 Let's be honest...

 The end-result for third-party developers using OAuth appears to be
 fewer sign-ups, less reliability, more complexity, and potentially
 less security.

 Google Optimizer reveals that users are more likely to sign-up for
 Basic Auth than OAuth.  That's just fact.  Test it for yourself to
 confirm.

 I suppose this is not so weird.  Users are accustomed to giving user/
 pass information even to foreign apps.  It is far more disruptive
 and invasive for them to go to some bizarre Twitter screen asking them
 to approve an app.  To the average user, what does that mean?  (And,
 heck, it may even require more steps if they have to login again to
 Twitter.)

 In terms of reliability, Twitter OAuth was down for days several weeks
 ago.  Tonight yet another unannounced change occurred that broke major
 code libraries.  Meanwhile, Basic Auth has been plugging along just
 fine and dandy...

 So what IS the benefit of OAuth?

 It doesn't benefit developers as you will likely get more sign-ups
 with Basic Auth and Basic Auth is far, far easier to setup.  Sure,
 OAuth might satisfy some power users hungry for security...

 But is OAuth even more secure than Basic Auth?

 Perhaps not.  After all, tonight's fix was for an OAuth security flaw
 known for at least 10+ days (judging by tweets to @twitterapi) that
 allowed for potential impersonations of credentialed users.

 On the heels of Twitter's (unofficial) assurance of better
 communication with developers, this sort of unannounced change is
 distressing.  What's next?  (Have Labor Day Weekend plans?  You might
 want to cancel those... just the right time for Twitter to make an
 unannounced API change!)

 As for us, we are in the strange position of deprecating OAuth in
 favor of Basic Auth.

 Weird, eh??

 Okay, we are not totally deprecating OAuth, but we are advising users
 that Basic Auth is far more robust and reliable.

 And so our message to new developers: avoid OAuth like the plague.  If
 you must, offer it.  But let Basic Auth be your backbone: more
 reliable, more sign-ups, simpler, and probably just as secure.  (Just
 look at Google Code bug reports about OAuth to get a sense of
 reliablity.)

 (Okay, okay, this post was written at 4am after a workday that started
 at 8am, and after Twitter introduced this new change at 5pm... (hey
 Twitter, can you introduce major new changes EARLIER in the day so we
 can react!?!?)... it still doesn't excuse Twitter's continued
 disregard for the small-to-medium size developer.)




[twitter-dev] Re: OAuth and native clients

2009-07-13 Thread Otávio Ribeiro
agreed,
regards,
Otávio Ribeiro

On Wed, Jul 8, 2009 at 11:52 PM, Zach zcox...@gmail.com wrote:


 I'm going to 3rd Sebastian's POV.  This is a serious problem that
 needs to be addressed now.  Mobile app developers want to integrate
 their native apps with sites like Twitter and Facebook, but the
 current user experience is so unacceptable that no one is going to use
 it in its current form.

 For more on the topic:


 http://www.hueniverse.com/hueniverse/2009/02/beyond-the-oauth-web-redirection-flow.html

 Kudos to the Twitter team for actually starting to think about a
 reasonable solution to this problem.  Facebook has the Connect for
 iPhone library, but even that is just their terrible JavaScript-based
 Connect login shown in an embedded browser.  And forget about trying
 to authenticate with Facebook from something like a BlackBerry app.

 We are anxiously awaiting a OAuth for Mobile option for the Twitter
 API (as are a lot of other developers).  Our app missed the from
 [MyApplication] using Basic Auth cutoff so now every status update we
 push says from Twitter4J... not the best for marketing purposes.  We
 would also love not having to store passwords on the device and send
 them over the wire every time a user clicks the Share button.



 On Jun 30, 4:42 pm, morefromalan sbal...@gmail.com wrote:
  Just wanted to second Sebastian's POV here.  UserExperience is a key
  revenue driver for us, andOAuthfor nativemobileapps is really
  painful for the user.
 
  On Jun 19, 5:41 am, Sebastian sdelm...@gmail.com wrote:
 
   Thanks for the pointer... I did some searches, but they were all
   focused onmobileclients.
 
   In my case, I'm not worried about the complexity of implementing
  OAuth. I can deal with that, and once it's done, it's gone from the
   picture. It's the user experience that worries me, as exposed on that
   thread by the TTYtter example.
 
   Well, since people are asking, the workflow doesn't significantly
   differ
   from otherOAuthapplications and depends on the fact that access
   tokens
   don't expire. When people start TTYtter up for the first time without
   an
   access token (or TTYtter tries the access token and it fails), it asks
   for
   the usual request token, prints the access URL with the request token
   it
   wants the user to authorize, and waits for the user to authorize.
   Twitter,
   presumably, will say, ok, tell your program to continue. Back on
   TTYtter's
   side, the user hits ENTER, and TTYtter exchanges its request token for
   an
   access token *and caches it* once it has verified it can successfully
   hit
   the user timeline for data. So far, this is not significantly
   different than
   any otherOAuthapp. 
 
   Is there any other way to doOAuthand at the same time, behave like a
   sensible application?
 
   Could Twitter implement a basic auth api call to perform theoauth
   authorization in the first place? Such a call would only be allowed
   from clients that prove they need it, and could be revoked for rogue
   clients. I know this lowers the security ofOAuth, but it only
   officializes a hack many apps will try to implement.
 
   On Jun 19, 12:39 am, Cameron Kaiser spec...@floodgap.com wrote:
 
 Or is the door for basic auth really closing forever?
 
This has been discussed in a number of threads and an exact
 determination
has not yet been made. However, this might give you some context:
 
   
 http://groups.google.com/group/twitter-development-talk/browse_thread...
 
--
 personal:
 http://www.cameronkaiser.com/--
  Cameron Kaiser * Floodgap Systems *www.floodgap.com*
 ckai...@floodgap.com
-- The cost of living has not adversely affected its popularity.
 --- Hide quoted text -
 
   - Show quoted text -