<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"
	>
<channel>
	<title>Comments on: Twitter fixes oAuth for desktop and mobile with xAuth</title>
	<atom:link href="http://aralbalkan.com/3057/feed" rel="self" type="application/rss+xml" />
	<link>http://aralbalkan.com/3057</link>
	<description>Passionate geekisms.</description>
	<lastBuildDate>Sun, 12 Feb 2012 17:52:56 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Jay</title>
		<link>http://aralbalkan.com/3057/comment-page-1#comment-261265</link>
		<dc:creator>Jay</dc:creator>
		<pubDate>Tue, 07 Sep 2010 02:55:19 +0000</pubDate>
		<guid isPermaLink="false">http://aralbalkan.com/?p=3057#comment-261265</guid>
		<description>Thanks for the clean upgrade to xAuth, Aral!

One thing though, I was using your library and couldn&#039;t get my friends tweets + my own to show up. I found out later that this is because the API included has an older version of MGTwitterEngine. The newest one includes a new function, &quot;getHomeTimeline&quot; which reflects the latest Twitter API.</description>
		<content:encoded><![CDATA[<p>Thanks for the clean upgrade to xAuth, Aral!</p>
<p>One thing though, I was using your library and couldn&#8217;t get my friends tweets + my own to show up. I found out later that this is because the API included has an older version of MGTwitterEngine. The newest one includes a new function, &#8220;getHomeTimeline&#8221; which reflects the latest Twitter API.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Console Bloke</title>
		<link>http://aralbalkan.com/3057/comment-page-1#comment-260053</link>
		<dc:creator>Console Bloke</dc:creator>
		<pubDate>Thu, 22 Apr 2010 14:42:49 +0000</pubDate>
		<guid isPermaLink="false">http://aralbalkan.com/?p=3057#comment-260053</guid>
		<description>I&#039;m new to all this and got the job of trying to integrate twitter with our game which is running on both PS3 and 360 and the fact they are deprecating Basic Authentication in favour of oAuth was enough to make me nearly give up till I read this. So I&#039;m praying that xAuth is what I need unless there is any way of using oAuth without a browser.</description>
		<content:encoded><![CDATA[<p>I&#8217;m new to all this and got the job of trying to integrate twitter with our game which is running on both PS3 and 360 and the fact they are deprecating Basic Authentication in favour of oAuth was enough to make me nearly give up till I read this. So I&#8217;m praying that xAuth is what I need unless there is any way of using oAuth without a browser.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: iphoneholic</title>
		<link>http://aralbalkan.com/3057/comment-page-1#comment-259499</link>
		<dc:creator>iphoneholic</dc:creator>
		<pubDate>Tue, 23 Feb 2010 03:43:59 +0000</pubDate>
		<guid isPermaLink="false">http://aralbalkan.com/?p=3057#comment-259499</guid>
		<description>So oAuth gives an application a token it can use to access my account with the same authority as my username/password.  This token will accompany method calls from this application to my account so that each request can be authenticated.

So how is this better (or even different) than giving the application my username/password credentials in the first place?  The access rights are identical in either case, as are the security risks.  A stolen token is as serious as a stolen password is it not?

Maybe I&#039;m missing something, but I just don&#039;t see any advantage oAuth offers an end-user application over Basic Auth credential authentication via https.  After all, if your own Twitter application can&#039;t be trusted with your username/password, what makes someone think their internet browser can be?

I think oAuth was really thought up to help social networks share user data with one another without sharing specific account credentials.  That perhaps makes a little better sense.  Attempting to ubiquitously extend that to individual user apps is a gross misapplication IMHO.</description>
		<content:encoded><![CDATA[<p>So oAuth gives an application a token it can use to access my account with the same authority as my username/password.  This token will accompany method calls from this application to my account so that each request can be authenticated.</p>
<p>So how is this better (or even different) than giving the application my username/password credentials in the first place?  The access rights are identical in either case, as are the security risks.  A stolen token is as serious as a stolen password is it not?</p>
<p>Maybe I&#8217;m missing something, but I just don&#8217;t see any advantage oAuth offers an end-user application over Basic Auth credential authentication via https.  After all, if your own Twitter application can&#8217;t be trusted with your username/password, what makes someone think their internet browser can be?</p>
<p>I think oAuth was really thought up to help social networks share user data with one another without sharing specific account credentials.  That perhaps makes a little better sense.  Attempting to ubiquitously extend that to individual user apps is a gross misapplication IMHO.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aral</title>
		<link>http://aralbalkan.com/3057/comment-page-1#comment-259342</link>
		<dc:creator>Aral</dc:creator>
		<pubDate>Fri, 05 Feb 2010 13:55:15 +0000</pubDate>
		<guid isPermaLink="false">http://aralbalkan.com/?p=3057#comment-259342</guid>
		<description>oAuthlover Fat: I don&#039;t think there&#039;s anything else I can say that I haven&#039;t already said in the article. I can only hope that the oAuth working group do not share your fundamentalist view.

As I see it, the oAuth working group has two options: either embrace the pragmatic solution for desktop or mobile apps (which it xAuth) or watch as it becomes a de-facto standard and risk irrelevancy.</description>
		<content:encoded><![CDATA[<p>oAuthlover Fat: I don&#8217;t think there&#8217;s anything else I can say that I haven&#8217;t already said in the article. I can only hope that the oAuth working group do not share your fundamentalist view.</p>
<p>As I see it, the oAuth working group has two options: either embrace the pragmatic solution for desktop or mobile apps (which it xAuth) or watch as it becomes a de-facto standard and risk irrelevancy.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aral</title>
		<link>http://aralbalkan.com/3057/comment-page-1#comment-259341</link>
		<dc:creator>Aral</dc:creator>
		<pubDate>Fri, 05 Feb 2010 13:40:42 +0000</pubDate>
		<guid isPermaLink="false">http://aralbalkan.com/?p=3057#comment-259341</guid>
		<description>Hey Noel, 

First off, thank you for your kind words on the blog, I appreciate it :) 

Re: xAuth, the point I was trying to make was not that it is any more secure than what the Exposure app does, it was that it isn&#039;t any less secure. :) 

PS. Edited your comment to change the quote since I updated the article.</description>
		<content:encoded><![CDATA[<p>Hey Noel, </p>
<p>First off, thank you for your kind words on the blog, I appreciate it :) </p>
<p>Re: xAuth, the point I was trying to make was not that it is any more secure than what the Exposure app does, it was that it isn&#8217;t any less secure. :) </p>
<p>PS. Edited your comment to change the quote since I updated the article.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: OAuthlover Fat</title>
		<link>http://aralbalkan.com/3057/comment-page-1#comment-259333</link>
		<dc:creator>OAuthlover Fat</dc:creator>
		<pubDate>Thu, 04 Feb 2010 22:53:58 +0000</pubDate>
		<guid isPermaLink="false">http://aralbalkan.com/?p=3057#comment-259333</guid>
		<description>And yet the user still must risk giving their login credentials to a third party. There is no win here. There&#039;s no excuse for this. UX is about understanding users. The first thing to understand about users is that their login credentials pose a security risk for not only the originating site but every site the user ever has used. 

This trumps everything.</description>
		<content:encoded><![CDATA[<p>And yet the user still must risk giving their login credentials to a third party. There is no win here. There&#8217;s no excuse for this. UX is about understanding users. The first thing to understand about users is that their login credentials pose a security risk for not only the originating site but every site the user ever has used. </p>
<p>This trumps everything.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Noel</title>
		<link>http://aralbalkan.com/3057/comment-page-1#comment-259332</link>
		<dc:creator>Noel</dc:creator>
		<pubDate>Thu, 04 Feb 2010 15:39:56 +0000</pubDate>
		<guid isPermaLink="false">http://aralbalkan.com/?p=3057#comment-259332</guid>
		<description>Hi Aral,

I&#039;ve been reading your blog for a while, its really great.

I had a little trouble following your points about how xAuth is more secure than some of the examples you gave like the Exposure app.

&quot;it has often been circumvented by loading the oAuth authorization screen in a web control.  As the Exposure iPhone App example in the previous link shows, this nullifies the advantages of having a trusted third-party application present the page, along with its URL, to the user.&quot;

I understand how this is less secure than flipping over to a browser. However, replacing a web pane login with a login built directly into the app itself (&quot;LoudBird asks the user for her username and password&quot;) seems equally insecure.

Am I missing something?</description>
		<content:encoded><![CDATA[<p>Hi Aral,</p>
<p>I&#8217;ve been reading your blog for a while, its really great.</p>
<p>I had a little trouble following your points about how xAuth is more secure than some of the examples you gave like the Exposure app.</p>
<p>&#8220;it has often been circumvented by loading the oAuth authorization screen in a web control.  As the Exposure iPhone App example in the previous link shows, this nullifies the advantages of having a trusted third-party application present the page, along with its URL, to the user.&#8221;</p>
<p>I understand how this is less secure than flipping over to a browser. However, replacing a web pane login with a login built directly into the app itself (&#8220;LoudBird asks the user for her username and password&#8221;) seems equally insecure.</p>
<p>Am I missing something?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Damon Oehlman</title>
		<link>http://aralbalkan.com/3057/comment-page-1#comment-259330</link>
		<dc:creator>Damon Oehlman</dc:creator>
		<pubDate>Thu, 04 Feb 2010 12:27:38 +0000</pubDate>
		<guid isPermaLink="false">http://aralbalkan.com/?p=3057#comment-259330</guid>
		<description>Great post Aral - thanks for creating such a comprehensive post on the state of mobile oAuth with regards to Twitter.  Will be interesting to see what other players do in the space.</description>
		<content:encoded><![CDATA[<p>Great post Aral &#8211; thanks for creating such a comprehensive post on the state of mobile oAuth with regards to Twitter.  Will be interesting to see what other players do in the space.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

