<?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: The iPhone Wi-Fi Black Hole</title>
	<atom:link href="http://blog.devicescape.com/2009/01/21/the-iphone-wi-fi-black-hole/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.devicescape.com/2009/01/21/the-iphone-wi-fi-black-hole/</link>
	<description>Get Connected Today!</description>
	<pubDate>Fri, 30 Jul 2010 19:10:10 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Tom Termini</title>
		<link>http://blog.devicescape.com/2009/01/21/the-iphone-wi-fi-black-hole/comment-page-1/#comment-407</link>
		<dc:creator>Tom Termini</dc:creator>
		<pubDate>Thu, 11 Jun 2009 10:10:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.devicescape.com/?p=140#comment-407</guid>
		<description>Interesting concept. In my experience as an Apple developer, the access to 'privileged' APIs by Apple is generally for two reasons: (1) there's some functionality they want to reserve for themselves to make Apple-made software work, well, better, on their platforms. Or, (2), access to system resources are proscribed for security reasons. In a recent Apple presentation to U.S. federal CIOs, I made the case that the 'sandbox' approach on the iPod/iPhone for app memory space makes perfect sense to close a major security issue found in RIM, WinMobile and Symbian operating systems -- the ability for an app to cross over into memory space. 

While Objective C is no fun when it comes to granular memory management, the advantage of this model is clear: very hard to design a malicious app. Taken in concert with the requirement of signing every app (either when submitting to the App Store as a developer, or from an enterprise's own in-house distribution network), and you've got the most secure mobile platform.  With our iPhone customers in the U.S. and the E.U., security remains the number one issue. My approach has been to work within the bounds of the platform to craft solutions that leverage that model -- and forget about a Windoze or Symbian-type approach. In 20+ years of Apple development, this has worked well.

My two-cents.</description>
		<content:encoded><![CDATA[<p>Interesting concept. In my experience as an Apple developer, the access to &#8216;privileged&#8217; APIs by Apple is generally for two reasons: (1) there&#8217;s some functionality they want to reserve for themselves to make Apple-made software work, well, better, on their platforms. Or, (2), access to system resources are proscribed for security reasons. In a recent Apple presentation to U.S. federal CIOs, I made the case that the &#8217;sandbox&#8217; approach on the iPod/iPhone for app memory space makes perfect sense to close a major security issue found in RIM, WinMobile and Symbian operating systems &#8212; the ability for an app to cross over into memory space. </p>
<p>While Objective C is no fun when it comes to granular memory management, the advantage of this model is clear: very hard to design a malicious app. Taken in concert with the requirement of signing every app (either when submitting to the App Store as a developer, or from an enterprise&#8217;s own in-house distribution network), and you&#8217;ve got the most secure mobile platform.  With our iPhone customers in the U.S. and the E.U., security remains the number one issue. My approach has been to work within the bounds of the platform to craft solutions that leverage that model &#8212; and forget about a Windoze or Symbian-type approach. In 20+ years of Apple development, this has worked well.</p>
<p>My two-cents.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
