<?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/"
		>
<channel>
	<title>Comments on: In-browser AIR functionality</title>
	<atom:link href="http://danny-t.co.uk/index.php/2007/11/19/in-browser-air-functionality/feed/" rel="self" type="application/rss+xml" />
	<link>http://danny-t.co.uk/index.php/2007/11/19/in-browser-air-functionality/</link>
	<description>Web apps fanatic, ramblings on dev for web, mobile and other geeky stuff</description>
	<lastBuildDate>Wed, 25 Jan 2012 21:06:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: DannyT</title>
		<link>http://danny-t.co.uk/index.php/2007/11/19/in-browser-air-functionality/comment-page-1/#comment-34093</link>
		<dc:creator>DannyT</dc:creator>
		<pubDate>Thu, 22 Nov 2007 23:50:11 +0000</pubDate>
		<guid isPermaLink="false">http://danny-t.co.uk/index.php/2007/11/19/in-browser-air-functionality/#comment-34093</guid>
		<description>Thanks for the info Ethan, I think the security aspects are going to be something that&#039;ll continue to crop up now AIR gets us onto the desktop. I&#039;m still interested in the approach and will try to mock-up a prototype when I get a chance.</description>
		<content:encoded><![CDATA[<p>Thanks for the info Ethan, I think the security aspects are going to be something that&#8217;ll continue to crop up now AIR gets us onto the desktop. I&#8217;m still interested in the approach and will try to mock-up a prototype when I get a chance.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ethan Malasky</title>
		<link>http://danny-t.co.uk/index.php/2007/11/19/in-browser-air-functionality/comment-page-1/#comment-34062</link>
		<dc:creator>Ethan Malasky</dc:creator>
		<pubDate>Thu, 22 Nov 2007 18:15:47 +0000</pubDate>
		<guid isPermaLink="false">http://danny-t.co.uk/index.php/2007/11/19/in-browser-air-functionality/#comment-34062</guid>
		<description>The LocalConnection pattern is already in use by some AIR apps you&#039;ve seen. Finetune uses it, for instance, to transfer a selected radio station from the browser page to the desktop player.

As far as security goes, you&#039;re half-correct.  Users still (always) need to be vigilant about whose apps they install.  But when applications themselves start offering services to other content, the security burden on app developers increases.

Clearly, it&#039;s not impossible, but it&#039;s something developers need to consider.  Who is going to be able to call your &quot;saveLocal&quot; function?  How do you verify the caller&#039;s identity?  The level of verification required changes, depending on the level of functionality being exposed.   How can your exposed function be abused?  Caller-provided paths or filenames are extremely dangerous, as they can be used to give an attacker local access.  And on and on.

All these concerns can be addressed.  But development is likely to be slow, because the price of getting it wrong is so high.</description>
		<content:encoded><![CDATA[<p>The LocalConnection pattern is already in use by some AIR apps you&#8217;ve seen. Finetune uses it, for instance, to transfer a selected radio station from the browser page to the desktop player.</p>
<p>As far as security goes, you&#8217;re half-correct.  Users still (always) need to be vigilant about whose apps they install.  But when applications themselves start offering services to other content, the security burden on app developers increases.</p>
<p>Clearly, it&#8217;s not impossible, but it&#8217;s something developers need to consider.  Who is going to be able to call your &#8220;saveLocal&#8221; function?  How do you verify the caller&#8217;s identity?  The level of verification required changes, depending on the level of functionality being exposed.   How can your exposed function be abused?  Caller-provided paths or filenames are extremely dangerous, as they can be used to give an attacker local access.  And on and on.</p>
<p>All these concerns can be addressed.  But development is likely to be slow, because the price of getting it wrong is so high.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Weiland</title>
		<link>http://danny-t.co.uk/index.php/2007/11/19/in-browser-air-functionality/comment-page-1/#comment-33805</link>
		<dc:creator>Mike Weiland</dc:creator>
		<pubDate>Mon, 19 Nov 2007 15:55:57 +0000</pubDate>
		<guid isPermaLink="false">http://danny-t.co.uk/index.php/2007/11/19/in-browser-air-functionality/#comment-33805</guid>
		<description>I&#039;ve used this concept before, I&#039;ve used Director with embeded Flash movies do the heavy lifting on the client side and localconnections between the SWF running in a browser. I haven&#039;t tested this with AIR, but the concept shouldn&#039;t run into any roadblocks.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve used this concept before, I&#8217;ve used Director with embeded Flash movies do the heavy lifting on the client side and localconnections between the SWF running in a browser. I haven&#8217;t tested this with AIR, but the concept shouldn&#8217;t run into any roadblocks.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

