Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
Hi Bess, I'm not sure how long the queue is right now, but we're coming back from a vacation weekend here in San Francisco and it'll probably take a bit for us to work through the queue this week. That said, we'll work through it as quickly as we (securely) can. Each request must be researched before approval can be granted due to all the concerns with logins and passwords illustrated in this great discussion thread. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Mon, May 31, 2010 at 9:05 PM, Bess wrote: > Exactly how long does it take to apply and get approved on xAuth? > > If I apply xAuth today, am I standing on a queue that is 1,000 long? > > I am preparing a Twitter Developer Book. If it takes a few weeks and > few months, I would have to change plan not to count on xAuth. Would > anyone give any feedback? > > I also like to confirm that I have tested Objective-C OAuth library on > iPhone. OAuth does take you outside the app to Safari for Twitter > authentication page. I test the work flow at Twitter Annotation > Hackfest this weekend. The Twitter authentication page is not > optimized for iPhone. It is difficult for users to find the section > where user can enter username and password. IMHO I would like to see > at least that page is styled and sized properly for mobile browser > webkit so it looks like part of native app with less word in larger > font size and bigger buttons. > > The only way you can customize and style Twitter username/pwd page > would be using xAuth. > > Thanks > > On May 31, 9:35 am, Jann Gobble wrote: > > On May 31, 2010, at 9:25 AM, Bernd Stramm wrote: > > > > > In any case Jann, you have convinced me of something I strongly > > > suspected - I really should get xauth for my application as well. > > > > If I have convinced one person today, I have done my job. I am used to > that -- what with being a Mac user for decades. > > > > > Be safe, > > > > You too! > > > > Jann >
[twitter-dev] Re: How long does it take to get approved with xAuth?
The oAuth page was changed some months back for the iPhone and it looks quite nice to be honest, it is most definitely the right height and width for Webkit on the iPhone now, so I'm not sure what the library you are using is doing. I still disagree with the above. oAuth in UIWebView can be spoofed yes, but at least it shows the user it's a Twitter page, whereas xAuth still has a username and password field. I'm not convinced yet that xAuth is right for an app that has a decent mobile browser or framework. The library can call a UIWebView inside the app instead of redirecting to Safari and then looking for the oauth call back and grabbing the relevant information and storing it. On Jun 1, 5:05 am, Bess wrote: > Exactly how long does it take to apply and get approved on xAuth? > > If I apply xAuth today, am I standing on a queue that is 1,000 long? > > I am preparing a Twitter Developer Book. If it takes a few weeks and > few months, I would have to change plan not to count on xAuth. Would > anyone give any feedback? > > I also like to confirm that I have tested Objective-C OAuth library on > iPhone. OAuth does take you outside the app to Safari for Twitter > authentication page. I test the work flow at Twitter Annotation > Hackfest this weekend. The Twitter authentication page is not > optimized for iPhone. It is difficult for users to find the section > where user can enter username and password. IMHO I would like to see > at least that page is styled and sized properly for mobile browser > webkit so it looks like part of native app with less word in larger > font size and bigger buttons. > > The only way you can customize and style Twitter username/pwd page > would be using xAuth. > > Thanks > > On May 31, 9:35 am, Jann Gobble wrote: > > > On May 31, 2010, at 9:25 AM, Bernd Stramm wrote: > > > > In any case Jann, you have convinced me of something I strongly > > > suspected - I really should get xauth for my application as well. > > > If I have convinced one person today, I have done my job. I am used to > > that -- what with being a Mac user for decades. > > > > Be safe, > > > You too! > > > Jann
[twitter-dev] Re: How long does it take to get approved with xAuth?
Exactly how long does it take to apply and get approved on xAuth? If I apply xAuth today, am I standing on a queue that is 1,000 long? I am preparing a Twitter Developer Book. If it takes a few weeks and few months, I would have to change plan not to count on xAuth. Would anyone give any feedback? I also like to confirm that I have tested Objective-C OAuth library on iPhone. OAuth does take you outside the app to Safari for Twitter authentication page. I test the work flow at Twitter Annotation Hackfest this weekend. The Twitter authentication page is not optimized for iPhone. It is difficult for users to find the section where user can enter username and password. IMHO I would like to see at least that page is styled and sized properly for mobile browser webkit so it looks like part of native app with less word in larger font size and bigger buttons. The only way you can customize and style Twitter username/pwd page would be using xAuth. Thanks On May 31, 9:35 am, Jann Gobble wrote: > On May 31, 2010, at 9:25 AM, Bernd Stramm wrote: > > > In any case Jann, you have convinced me of something I strongly > > suspected - I really should get xauth for my application as well. > > If I have convinced one person today, I have done my job. I am used to that > -- what with being a Mac user for decades. > > > Be safe, > > You too! > > Jann
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
On May 31, 2010, at 9:25 AM, Bernd Stramm wrote: > > In any case Jann, you have convinced me of something I strongly > suspected - I really should get xauth for my application as well. > If I have convinced one person today, I have done my job. I am used to that -- what with being a Mac user for decades. > Be safe, You too! Jann
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
On Mon, 31 May 2010 08:58:35 -0700 Jann Gobble wrote: Some very good points, > Okay, I think we really need to expand on something... > > oAuth was never designed to promote any app developer to bypass the > built-in web browser (from an App) -- (ie: using UIWebView). There > are many reasons for this. If one wanted to steal usernames and > passwords, it is VERY easy to simulate the look and feel of Twitter's > login page for oAuth in order to take the username and password of > the person logging in. Quite true. > ... In other words, using the UIWebview is insecure 'cos the > user does not have the built-in notifications (some would say > guarantees -- although I don't see them as guarantees) that a > built-in web browser offers. That is, the UIWebView does not > necessarily show the URL line with the REAL url that the user is > being referred to. I can easily put a UITextField at the top of any > UIWebView, put the Twitter URL in that and displaying a lock symbol > somewhere on my UIWebView. This "looks" like the user is going to > the right place but indeed I may be doing a man-in-the-midle type > attack. Indeed a standalone app can fool the user. So can a well designed web page, it is not that hard. Fooling users is big business these days. Web services are an excellent tool to do that. Hey, even many legitimate web services make good money by getting users to pay for completely useless products and services. >... One of the primary reasons oAuth was developed was to ensure > that the app/website NEVER got access to the user's password Yes that is a key point. This point makes a lot of sense for a web based service that acts together with twitter to do something on the user's behalf. The main risk for the user here are malicious web services. My point in saying a webview in the application is that it is more secure than using a browser *from the point of view of the application*. Inside of my application I can forward a URL to the system default browser, or I can handle it myself. When forced to to oauth, I have to do one or the other. Since I have zero information on what the user has installed as their default browser, I have to assume it is not secure. Aside from that, hopping to the browser and back is a really ugly solution. As I said before, a lot of this stuff is inherently insecure for reasons completely unrelated to oauth or xauth. In any case Jann, you have convinced me of something I strongly suspected - I really should get xauth for my application as well. Be safe, Bernd -- Bernd Stramm
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
Okay, I think we really need to expand on something...
oAuth was never designed to promote any app developer to bypass the built-in
web browser (from an App) -- (ie: using UIWebView). There are many reasons for
this. If one wanted to steal usernames and passwords, it is VERY easy to
simulate the look and feel of Twitter's login page for oAuth in order to take
the username and password of the person logging in. Indeed, there is nothing
to stop anyone from doing this (directing the user toward their own website),
getting the username and password and -- in the background -- logging the user
into Twitter using oAuth, getting the token and proceeding as normal in their
app. Later (in this scenario) they could do something insidious with the
username/password combo.) Thus oAuth -- used in this manner (in a UIWebView)
bypasses one major reason oAuth was developed. In other words, using the
UIWebview is insecure 'cos the user does not have the built-in notifications
(some would say guarantees -- although I don't see them as guarantees) that a
built-in web browser offers. That is, the UIWebView does not necessarily show
the URL line with the REAL url that the user is being referred to. I can
easily put a UITextField at the top of any UIWebView, put the Twitter URL in
that and displaying a lock symbol somewhere on my UIWebView. This "looks" like
the user is going to the right place but indeed I may be doing a
man-in-the-midle type attack.
The only security offered by oAuth used in this method is that you are
exchanging a token once for each function you are asking Twitter to do. One of
the primary reasons oAuth was developed was to ensure that the app/website
NEVER got access to the user's password. The other was that the
username/password was passed in the URL, thus being logged in many companies
firewalls, filters and sniffers -- not to mention Twitter's own access_logs
(not known -- assumed).
Here is my main gripe: As someone earlier stated: The only danger with
Twitter's password being captured by the app is that you can post as this user
to Twitter and associated sites. The main worry to me is not that someone can
post as me (to Twitter) -- it is that people like my parent may use the same
username/password combo on Twitter that they do on their banking website. BUT
you cannot save people from their own stupidity.
The time for discussing oAuth vs xAuth is over. Twitter has decided -- and in
my opinion they have offered us a valid alternative to oAuth for Apps. xAuth
is here, it is a valid compromise for the UX in Apps and is not allowed for Web
Apps.
That is good enough for me.
Jann
On May 31, 2010, at 2:09 AM, Rich wrote:
>
> I consider it completely the opposite and that the oauth workflow is
> more secure than the xauth one. To me seeing the Twitter website login
> page shows me that only Twitter will see my login information and not
> the client app itself
>
> An xauth workflow the app should only pass it on in exchange for an
> oauth token but there is nothing to stop them harvesting the
> information in the meantime
>
> Running the oauth workflow on the iPhone is not painful and can all be
> done seamlessly from within your app itself. The user won't ben
> confused either if you do it right
>
>
> On May 30, 6:15 pm, Jann Gobble wrote:
>> Okay, please tell me you know that I can create an app with a UIWebView that
>> will take that password you type in faster than anything.
>>
>> It is NOT secure. This is my problem with oAuth. The work-arounds cause a
>> false sense of security. oAuth was NEVER supposed to be used this way. If
>> the user does not trust the app, they should definitely not trust the
>> developer that puts a UIWebView in it -- it is too easy to do a
>> man-in-the-middle. oAuth fits in well with webapps, not iPhone apps.
>>
>> Anyway, this was all hashed out internally to Twitter -- that is why they
>> came up with xAuth.
>>
>> :)
>>
>> Jann
>>
>> On May 30, 2010, at 3:50 AM, Rich wrote:
>>
>>
>>
>>> You don't have to go from app to browser, embed a UIWebView and then
>>> in
>>
>>> - (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:
>>> (NSURLRequest *)request navigationType:
>>> (UIWebViewNavigationType)navigationType {
>>
>>> Look for your callback URL and read the query string and you'll be
>>> authorised, then just remove the UIWebView and use your application.
>>> The user never has to leave your app.
>>
>>> Then the user gets MORE security that xAuth because they can see they
>>> are logging in on Twitter.com and not giving their password to an
>>> arbitrary application, which could still save their password without
>>> their knowledge.
>>
>>> On May 30, 8:35 am, Jann Gobble wrote:
The requirement for users to go from app to browser to app is untenable
for many of my users. It is a major change to go from app to Safari and
back to app. Many users actually think th
[twitter-dev] Re: How long does it take to get approved with xAuth?
I consider it completely the opposite and that the oauth workflow is
more secure than the xauth one. To me seeing the Twitter website login
page shows me that only Twitter will see my login information and not
the client app itself
An xauth workflow the app should only pass it on in exchange for an
oauth token but there is nothing to stop them harvesting the
information in the meantime
Running the oauth workflow on the iPhone is not painful and can all be
done seamlessly from within your app itself. The user won't ben
confused either if you do it right
On May 30, 6:15 pm, Jann Gobble wrote:
> Okay, please tell me you know that I can create an app with a UIWebView that
> will take that password you type in faster than anything.
>
> It is NOT secure. This is my problem with oAuth. The work-arounds cause a
> false sense of security. oAuth was NEVER supposed to be used this way. If
> the user does not trust the app, they should definitely not trust the
> developer that puts a UIWebView in it -- it is too easy to do a
> man-in-the-middle. oAuth fits in well with webapps, not iPhone apps.
>
> Anyway, this was all hashed out internally to Twitter -- that is why they
> came up with xAuth.
>
> :)
>
> Jann
>
> On May 30, 2010, at 3:50 AM, Rich wrote:
>
>
>
> > You don't have to go from app to browser, embed a UIWebView and then
> > in
>
> > - (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:
> > (NSURLRequest *)request navigationType:
> > (UIWebViewNavigationType)navigationType {
>
> > Look for your callback URL and read the query string and you'll be
> > authorised, then just remove the UIWebView and use your application.
> > The user never has to leave your app.
>
> > Then the user gets MORE security that xAuth because they can see they
> > are logging in on Twitter.com and not giving their password to an
> > arbitrary application, which could still save their password without
> > their knowledge.
>
> > On May 30, 8:35 am, Jann Gobble wrote:
> >> The requirement for users to go from app to browser to app is untenable
> >> for many of my users. It is a major change to go from app to Safari and
> >> back to app. Many users actually think that it the app is less secure
> >> (rightly or wrongly) because they have to exit it -- and go to the web --
> >> in order to login.
>
> >> Indeed, many of them do not understand the permissions that the oAuth
> >> system asks for when they get sent to the Twitter page. Unfortunately
> >> with a phone like the iPhone you are dealing with many many users who are
> >> new to mobile devices in general and just wish to use twitter from within
> >> their favorite apps without the complications.
>
> >> Would you say that oAuth is good enough for Twitterific or Chirpie,
> >> Tweetie? Well, they are using xAuth. All I wish to do is to provide my
> >> users with identical (and what they see is easy -- and safe) method of
> >> using Twitter. xAuth provides this. oAuth does not. Many users prefer a
> >> seamless experience to that of adopting a protocol that causes such a
> >> jarring user experience -- regardless of the perceived safety of oAuth
> >> over xAuth. Safety of one over the other comes down to how much you trust
> >> the app. It no longer comes down to how much you trust Basic Auth.
>
> >> I would have no problem if there was an even playing field where we could
> >> all have our app "signatures" in the Tweet -- and all have the same user
> >> experience where logins and permissions are concerned. This is not the
> >> case.
>
> >> Thanks for your input, though.
>
> >> Jann
>
> >> On May 30, 2010, at 12:03 AM, Rich wrote:
>
> >>> You don't need xAuth to develop an iPhone app, oAuth workflow works
> >>> just fine.
>
> >>> Indeed I though xAuth was designed for clients without a decent mobile
> >>> browser which isn't the case on the iPhone
>
> >>> On May 29, 2:08 am, Jann wrote:
> I sent an email in to api@ this week. Got back a case # which, when
> clicked, requires me to login. It then tells me that the case
> #1008949does not exist.
>
> So, I logged in under the twitter account that created the app and
> created another ticket. Got another ticket #1009859. I am now
> wondering how long this is supposed to take. (if the first one is
> invalid, then my new support case is now over 900 cases farther down
> in the queue. :(
>
> Does anyone have any ideas? I have seen (when searching on google)
> that some people say it takes upwards of a week to get the approval.
> I am stuck however because I cannot even test my iPhone app using this
> method. (I am usinghttp://aralbalkan.com/3133(xAuthTwitterEngine) to
> implement and I can see no method to begin even testing using my own
> account.
>
> Shouldn't there be some way to (at least) test your app using the
> username and password that was used to create the "Application" in
> question
[twitter-dev] Re: How long does it take to get approved with xAuth?
Twitter has been great responding to XAuth application requests, and helping developers implement their API. I suspect with all the OAuth integration work coming to a head, and the annotations hack fest going on this weekend, your request may have just fallen through a crack. On May 30, 7:57 pm, Jann Gobble wrote: > Thanks! > > For now I have implemented xAuth (even though it does not work) by using > examples and what I expect. BUT I have hidden the Twitter button on my app > until xAuth is approved and I can fully test. > > The one thing Twitter does NOT need right now is app developers leaving them > in the dust because they make it too hard to implement their protocols. We > will see how my user base handles *not* having Twitter along side the other > social networks in my app (until I get approved). My guess is that they will > choose to post to their FB Wall instead. > > We will see. > > Jann > > On May 30, 2010, at 5:00 PM, Ron wrote: > > > > > XAuth is is the right choice for an end-user client app and > > satisfactorily resolves the UX issues in client applications that > > OAuth creates. Unfortunately, many web-app developers simply don't > > know enough about end-user client app development to understand these > > UX issues, or why end-user client application trust is neither an > > issue that needs addressing nor one that OAuth can (nor even attempts > > to) address. > > > It shouldn't take more than a week or two to get your authorization > > from Twitter to use XAuth if you're applying for a client app. > > > On May 30, 1:40 pm, Bernd Stramm wrote: > >> On Sun, 30 May 2010 11:14:54 -0700 > > >> Abraham Williams <4bra...@gmail.com> wrote: > >>> On Sun, May 30, 2010 at 11:01, Bernd Stramm > >>> wrote: > > The user does trust the app, otherwise they would not be using it. > The problem with the scheme of using the app *and* a browser is > that the user has to trust *both* of them. > > And if they don't trust the app, why are they using it to post their > tweets? > > >>> Trust is not a boolean value. There are levels of it. I trust my > >>> mobile browser to not take over my Twitter account but I only trust > >>> random new Twitter client to not post spam. If the Twitter client > >>> breaks my trust it is easy to revoke access to it. > > >> Is it easy for most users? The authentication token doesn't expire, so > >> an application (any application, not just desktop/mobile client) can do > >> what it wants for quite a while. > > >> You should be careful with trusting browsers, mobile or otherwise. They > >> are very leaky. > > >> And my point remains, when using a browser *and* a standalone client, > >> the user trusts both of them. From the point of view of the honest > >> application developer, I do not want to assume that another application > >> (the browser) which is completely unknown to me, is trustworthy. Hence > >> I prefer the solution with the small integrated webview in my > >> application. > > >> But also, what do people to with their twitter account that needs > >> protecting, other than posting messages and media content? And of > >> course giving away great data to the data miners. > > >> A lot of this authentication business misses the easiest intrusion > >> vector anyway. People will steal your phone, and have access to > >> everything you store on it. Including any authentication for serious > >> business. Nevermind trusting the standalone app or the browser, the > >> entire system is easily compromised if its stolen. > > >> -- > >> Bernd Stramm > >>
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
Thanks! For now I have implemented xAuth (even though it does not work) by using examples and what I expect. BUT I have hidden the Twitter button on my app until xAuth is approved and I can fully test. The one thing Twitter does NOT need right now is app developers leaving them in the dust because they make it too hard to implement their protocols. We will see how my user base handles *not* having Twitter along side the other social networks in my app (until I get approved). My guess is that they will choose to post to their FB Wall instead. We will see. Jann On May 30, 2010, at 5:00 PM, Ron wrote: > XAuth is is the right choice for an end-user client app and > satisfactorily resolves the UX issues in client applications that > OAuth creates. Unfortunately, many web-app developers simply don't > know enough about end-user client app development to understand these > UX issues, or why end-user client application trust is neither an > issue that needs addressing nor one that OAuth can (nor even attempts > to) address. > > It shouldn't take more than a week or two to get your authorization > from Twitter to use XAuth if you're applying for a client app. > > On May 30, 1:40 pm, Bernd Stramm wrote: >> On Sun, 30 May 2010 11:14:54 -0700 >> >> >> >> >> >> Abraham Williams <4bra...@gmail.com> wrote: >>> On Sun, May 30, 2010 at 11:01, Bernd Stramm >>> wrote: >> The user does trust the app, otherwise they would not be using it. The problem with the scheme of using the app *and* a browser is that the user has to trust *both* of them. >> And if they don't trust the app, why are they using it to post their tweets? >> >>> Trust is not a boolean value. There are levels of it. I trust my >>> mobile browser to not take over my Twitter account but I only trust >>> random new Twitter client to not post spam. If the Twitter client >>> breaks my trust it is easy to revoke access to it. >> >> Is it easy for most users? The authentication token doesn't expire, so >> an application (any application, not just desktop/mobile client) can do >> what it wants for quite a while. >> >> You should be careful with trusting browsers, mobile or otherwise. They >> are very leaky. >> >> And my point remains, when using a browser *and* a standalone client, >> the user trusts both of them. From the point of view of the honest >> application developer, I do not want to assume that another application >> (the browser) which is completely unknown to me, is trustworthy. Hence >> I prefer the solution with the small integrated webview in my >> application. >> >> But also, what do people to with their twitter account that needs >> protecting, other than posting messages and media content? And of >> course giving away great data to the data miners. >> >> A lot of this authentication business misses the easiest intrusion >> vector anyway. People will steal your phone, and have access to >> everything you store on it. Including any authentication for serious >> business. Nevermind trusting the standalone app or the browser, the >> entire system is easily compromised if its stolen. >> >> -- >> Bernd Stramm >>
[twitter-dev] Re: How long does it take to get approved with xAuth?
XAuth is is the right choice for an end-user client app and satisfactorily resolves the UX issues in client applications that OAuth creates. Unfortunately, many web-app developers simply don't know enough about end-user client app development to understand these UX issues, or why end-user client application trust is neither an issue that needs addressing nor one that OAuth can (nor even attempts to) address. It shouldn't take more than a week or two to get your authorization from Twitter to use XAuth if you're applying for a client app. On May 30, 1:40 pm, Bernd Stramm wrote: > On Sun, 30 May 2010 11:14:54 -0700 > > > > > > Abraham Williams <4bra...@gmail.com> wrote: > > On Sun, May 30, 2010 at 11:01, Bernd Stramm > > wrote: > > > > The user does trust the app, otherwise they would not be using it. > > > The problem with the scheme of using the app *and* a browser is > > > that the user has to trust *both* of them. > > > > And if they don't trust the app, why are they using it to post their > > > tweets? > > > Trust is not a boolean value. There are levels of it. I trust my > > mobile browser to not take over my Twitter account but I only trust > > random new Twitter client to not post spam. If the Twitter client > > breaks my trust it is easy to revoke access to it. > > Is it easy for most users? The authentication token doesn't expire, so > an application (any application, not just desktop/mobile client) can do > what it wants for quite a while. > > You should be careful with trusting browsers, mobile or otherwise. They > are very leaky. > > And my point remains, when using a browser *and* a standalone client, > the user trusts both of them. From the point of view of the honest > application developer, I do not want to assume that another application > (the browser) which is completely unknown to me, is trustworthy. Hence > I prefer the solution with the small integrated webview in my > application. > > But also, what do people to with their twitter account that needs > protecting, other than posting messages and media content? And of > course giving away great data to the data miners. > > A lot of this authentication business misses the easiest intrusion > vector anyway. People will steal your phone, and have access to > everything you store on it. Including any authentication for serious > business. Nevermind trusting the standalone app or the browser, the > entire system is easily compromised if its stolen. > > -- > Bernd Stramm >
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
On Sun, 30 May 2010 11:14:54 -0700 Abraham Williams <4bra...@gmail.com> wrote: > On Sun, May 30, 2010 at 11:01, Bernd Stramm > wrote: > > > The user does trust the app, otherwise they would not be using it. > > The problem with the scheme of using the app *and* a browser is > > that the user has to trust *both* of them. > > > > And if they don't trust the app, why are they using it to post their > > tweets? > > > > Trust is not a boolean value. There are levels of it. I trust my > mobile browser to not take over my Twitter account but I only trust > random new Twitter client to not post spam. If the Twitter client > breaks my trust it is easy to revoke access to it. Is it easy for most users? The authentication token doesn't expire, so an application (any application, not just desktop/mobile client) can do what it wants for quite a while. You should be careful with trusting browsers, mobile or otherwise. They are very leaky. And my point remains, when using a browser *and* a standalone client, the user trusts both of them. From the point of view of the honest application developer, I do not want to assume that another application (the browser) which is completely unknown to me, is trustworthy. Hence I prefer the solution with the small integrated webview in my application. But also, what do people to with their twitter account that needs protecting, other than posting messages and media content? And of course giving away great data to the data miners. A lot of this authentication business misses the easiest intrusion vector anyway. People will steal your phone, and have access to everything you store on it. Including any authentication for serious business. Nevermind trusting the standalone app or the browser, the entire system is easily compromised if its stolen. -- Bernd Stramm
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
On Sun, May 30, 2010 at 11:01, Bernd Stramm wrote: > The user does trust the app, otherwise they would not be using it. The > problem with the scheme of using the app *and* a browser is that the > user has to trust *both* of them. > > And if they don't trust the app, why are they using it to post their > tweets? > Trust is not a boolean value. There are levels of it. I trust my mobile browser to not take over my Twitter account but I only trust random new Twitter client to not post spam. If the Twitter client breaks my trust it is easy to revoke access to it. Abraham -- Abraham Williams | Developer for hire | http://abrah.am @abraham | http://projects.abrah.am | http://blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private.
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
On Sun, 30 May 2010 10:15:48 -0700 Jann Gobble wrote: > Okay, please tell me you know that I can create an app with a > UIWebView that will take that password you type in faster than > anything. > > It is NOT secure. This is my problem with oAuth. The work-arounds > cause a false sense of security. oAuth was NEVER supposed to be used > this way. If the user does not trust the app, they should definitely > not trust the developer that puts a UIWebView in it -- it is too easy > to do a man-in-the-middle. oAuth fits in well with webapps, not > iPhone apps. The user does trust the app, otherwise they would not be using it. The problem with the scheme of using the app *and* a browser is that the user has to trust *both* of them. And if they don't trust the app, why are they using it to post their tweets? It looks like the folks who designed this scheme were not thinking about desktop/mobile apps, only about web based solutions. The rest is an afterthought. Be Safe, Bernd -- Bernd Stramm
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
Okay, please tell me you know that I can create an app with a UIWebView that
will take that password you type in faster than anything.
It is NOT secure. This is my problem with oAuth. The work-arounds cause a
false sense of security. oAuth was NEVER supposed to be used this way. If the
user does not trust the app, they should definitely not trust the developer
that puts a UIWebView in it -- it is too easy to do a man-in-the-middle. oAuth
fits in well with webapps, not iPhone apps.
Anyway, this was all hashed out internally to Twitter -- that is why they came
up with xAuth.
:)
Jann
On May 30, 2010, at 3:50 AM, Rich wrote:
> You don't have to go from app to browser, embed a UIWebView and then
> in
>
> - (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:
> (NSURLRequest *)request navigationType:
> (UIWebViewNavigationType)navigationType {
>
> Look for your callback URL and read the query string and you'll be
> authorised, then just remove the UIWebView and use your application.
> The user never has to leave your app.
>
> Then the user gets MORE security that xAuth because they can see they
> are logging in on Twitter.com and not giving their password to an
> arbitrary application, which could still save their password without
> their knowledge.
>
> On May 30, 8:35 am, Jann Gobble wrote:
>> The requirement for users to go from app to browser to app is untenable for
>> many of my users. It is a major change to go from app to Safari and back to
>> app. Many users actually think that it the app is less secure (rightly or
>> wrongly) because they have to exit it -- and go to the web -- in order to
>> login.
>>
>> Indeed, many of them do not understand the permissions that the oAuth system
>> asks for when they get sent to the Twitter page. Unfortunately with a phone
>> like the iPhone you are dealing with many many users who are new to mobile
>> devices in general and just wish to use twitter from within their favorite
>> apps without the complications.
>>
>> Would you say that oAuth is good enough for Twitterific or Chirpie, Tweetie?
>> Well, they are using xAuth. All I wish to do is to provide my users with
>> identical (and what they see is easy -- and safe) method of using Twitter.
>> xAuth provides this. oAuth does not. Many users prefer a seamless
>> experience to that of adopting a protocol that causes such a jarring user
>> experience -- regardless of the perceived safety of oAuth over xAuth.
>> Safety of one over the other comes down to how much you trust the app. It
>> no longer comes down to how much you trust Basic Auth.
>>
>> I would have no problem if there was an even playing field where we could
>> all have our app "signatures" in the Tweet -- and all have the same user
>> experience where logins and permissions are concerned. This is not the case.
>>
>> Thanks for your input, though.
>>
>> Jann
>>
>> On May 30, 2010, at 12:03 AM, Rich wrote:
>>
>>
>>
>>> You don't need xAuth to develop an iPhone app, oAuth workflow works
>>> just fine.
>>
>>> Indeed I though xAuth was designed for clients without a decent mobile
>>> browser which isn't the case on the iPhone
>>
>>> On May 29, 2:08 am, Jann wrote:
I sent an email in to api@ this week. Got back a case # which, when
clicked, requires me to login. It then tells me that the case
#1008949does not exist.
>>
So, I logged in under the twitter account that created the app and
created another ticket. Got another ticket #1009859. I am now
wondering how long this is supposed to take. (if the first one is
invalid, then my new support case is now over 900 cases farther down
in the queue. :(
>>
Does anyone have any ideas? I have seen (when searching on google)
that some people say it takes upwards of a week to get the approval.
I am stuck however because I cannot even test my iPhone app using this
method. (I am usinghttp://aralbalkan.com/3133(xAuthTwitterEngine) to
implement and I can see no method to begin even testing using my own
account.
>>
Shouldn't there be some way to (at least) test your app using the
username and password that was used to create the "Application" in
question?
>>
Please give some insight. Maybe I am missing something stupid.
>>
Thanks!
>>
Jann
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
On Sun, 30 May 2010 03:50:21 -0700 (PDT)
Rich wrote:
> You don't have to go from app to browser, embed a UIWebView and then
> in
>
> - (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:
> (NSURLRequest *)request navigationType:
> (UIWebViewNavigationType)navigationType {
I do the equivalent in Qt. It looks decent, and the user has the
impression that they are typing their password into the app. In fact
they are.
So the user experience is pretty close to basic auth. I doubt that the
users who have been happily giving away their password left and right
really care who stores their password. Perhaps that situation will
improve with better user education.
An approach with a webview integrated into the app is more secure than
using an external browser - my app doesn't know what browser the user
has configured. Why would I assume that some unknown browser is secure
and doesn't grab their password? Many browsers have nice features for
exactly that.
There are other glaring holes in the entire setup. Users get an email
PIN from places like twitpic, and once a black hat has that, they can
impersonate the user with embarassing pictures and tweets all day.
So I would advise users to not use any of the twitter environment and
surroundings for banking transactions. And if embarrassing pics
surface, at least users have plausible deniability.
Be safe,
Bernd
--
Bernd Stramm
[twitter-dev] Re: How long does it take to get approved with xAuth?
You don't have to go from app to browser, embed a UIWebView and then
in
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:
(NSURLRequest *)request navigationType:
(UIWebViewNavigationType)navigationType {
Look for your callback URL and read the query string and you'll be
authorised, then just remove the UIWebView and use your application.
The user never has to leave your app.
Then the user gets MORE security that xAuth because they can see they
are logging in on Twitter.com and not giving their password to an
arbitrary application, which could still save their password without
their knowledge.
On May 30, 8:35 am, Jann Gobble wrote:
> The requirement for users to go from app to browser to app is untenable for
> many of my users. It is a major change to go from app to Safari and back to
> app. Many users actually think that it the app is less secure (rightly or
> wrongly) because they have to exit it -- and go to the web -- in order to
> login.
>
> Indeed, many of them do not understand the permissions that the oAuth system
> asks for when they get sent to the Twitter page. Unfortunately with a phone
> like the iPhone you are dealing with many many users who are new to mobile
> devices in general and just wish to use twitter from within their favorite
> apps without the complications.
>
> Would you say that oAuth is good enough for Twitterific or Chirpie, Tweetie?
> Well, they are using xAuth. All I wish to do is to provide my users with
> identical (and what they see is easy -- and safe) method of using Twitter.
> xAuth provides this. oAuth does not. Many users prefer a seamless
> experience to that of adopting a protocol that causes such a jarring user
> experience -- regardless of the perceived safety of oAuth over xAuth. Safety
> of one over the other comes down to how much you trust the app. It no longer
> comes down to how much you trust Basic Auth.
>
> I would have no problem if there was an even playing field where we could all
> have our app "signatures" in the Tweet -- and all have the same user
> experience where logins and permissions are concerned. This is not the case.
>
> Thanks for your input, though.
>
> Jann
>
> On May 30, 2010, at 12:03 AM, Rich wrote:
>
>
>
> > You don't need xAuth to develop an iPhone app, oAuth workflow works
> > just fine.
>
> > Indeed I though xAuth was designed for clients without a decent mobile
> > browser which isn't the case on the iPhone
>
> > On May 29, 2:08 am, Jann wrote:
> >> I sent an email in to api@ this week. Got back a case # which, when
> >> clicked, requires me to login. It then tells me that the case
> >> #1008949does not exist.
>
> >> So, I logged in under the twitter account that created the app and
> >> created another ticket. Got another ticket #1009859. I am now
> >> wondering how long this is supposed to take. (if the first one is
> >> invalid, then my new support case is now over 900 cases farther down
> >> in the queue. :(
>
> >> Does anyone have any ideas? I have seen (when searching on google)
> >> that some people say it takes upwards of a week to get the approval.
> >> I am stuck however because I cannot even test my iPhone app using this
> >> method. (I am usinghttp://aralbalkan.com/3133(xAuthTwitterEngine) to
> >> implement and I can see no method to begin even testing using my own
> >> account.
>
> >> Shouldn't there be some way to (at least) test your app using the
> >> username and password that was used to create the "Application" in
> >> question?
>
> >> Please give some insight. Maybe I am missing something stupid.
>
> >> Thanks!
>
> >> Jann
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
The requirement for users to go from app to browser to app is untenable for many of my users. It is a major change to go from app to Safari and back to app. Many users actually think that it the app is less secure (rightly or wrongly) because they have to exit it -- and go to the web -- in order to login. Indeed, many of them do not understand the permissions that the oAuth system asks for when they get sent to the Twitter page. Unfortunately with a phone like the iPhone you are dealing with many many users who are new to mobile devices in general and just wish to use twitter from within their favorite apps without the complications. Would you say that oAuth is good enough for Twitterific or Chirpie, Tweetie? Well, they are using xAuth. All I wish to do is to provide my users with identical (and what they see is easy -- and safe) method of using Twitter. xAuth provides this. oAuth does not. Many users prefer a seamless experience to that of adopting a protocol that causes such a jarring user experience -- regardless of the perceived safety of oAuth over xAuth. Safety of one over the other comes down to how much you trust the app. It no longer comes down to how much you trust Basic Auth. I would have no problem if there was an even playing field where we could all have our app "signatures" in the Tweet -- and all have the same user experience where logins and permissions are concerned. This is not the case. Thanks for your input, though. Jann On May 30, 2010, at 12:03 AM, Rich wrote: > You don't need xAuth to develop an iPhone app, oAuth workflow works > just fine. > > Indeed I though xAuth was designed for clients without a decent mobile > browser which isn't the case on the iPhone > > On May 29, 2:08 am, Jann wrote: >> I sent an email in to api@ this week. Got back a case # which, when >> clicked, requires me to login. It then tells me that the case #1008949does >> not exist. >> >> So, I logged in under the twitter account that created the app and >> created another ticket. Got another ticket #1009859. I am now >> wondering how long this is supposed to take. (if the first one is >> invalid, then my new support case is now over 900 cases farther down >> in the queue. :( >> >> Does anyone have any ideas? I have seen (when searching on google) >> that some people say it takes upwards of a week to get the approval. >> I am stuck however because I cannot even test my iPhone app using this >> method. (I am usinghttp://aralbalkan.com/3133(xAuthTwitterEngine) to >> implement and I can see no method to begin even testing using my own >> account. >> >> Shouldn't there be some way to (at least) test your app using the >> username and password that was used to create the "Application" in >> question? >> >> Please give some insight. Maybe I am missing something stupid. >> >> Thanks! >> >> Jann
[twitter-dev] Re: How long does it take to get approved with xAuth?
You don't need xAuth to develop an iPhone app, oAuth workflow works just fine. Indeed I though xAuth was designed for clients without a decent mobile browser which isn't the case on the iPhone On May 29, 2:08 am, Jann wrote: > I sent an email in to api@ this week. Got back a case # which, when > clicked, requires me to login. It then tells me that the case #1008949does > not exist. > > So, I logged in under the twitter account that created the app and > created another ticket. Got another ticket #1009859. I am now > wondering how long this is supposed to take. (if the first one is > invalid, then my new support case is now over 900 cases farther down > in the queue. :( > > Does anyone have any ideas? I have seen (when searching on google) > that some people say it takes upwards of a week to get the approval. > I am stuck however because I cannot even test my iPhone app using this > method. (I am usinghttp://aralbalkan.com/3133(xAuthTwitterEngine) to > implement and I can see no method to begin even testing using my own > account. > > Shouldn't there be some way to (at least) test your app using the > username and password that was used to create the "Application" in > question? > > Please give some insight. Maybe I am missing something stupid. > > Thanks! > > Jann
