<?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: Society &#8211; Thin Client Model</title>
	<atom:link href="http://philosecurity.org/2008/12/14/society-thin-client-model/feed" rel="self" type="application/rss+xml" />
	<link>http://philosecurity.org/2008/12/14/society-thin-client-model</link>
	<description></description>
	<lastBuildDate>Tue, 09 Mar 2010 23:41:40 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: John H</title>
		<link>http://philosecurity.org/2008/12/14/society-thin-client-model/comment-page-1#comment-3943</link>
		<dc:creator>John H</dc:creator>
		<pubDate>Wed, 14 Jan 2009 10:40:34 +0000</pubDate>
		<guid isPermaLink="false">http://philosecurity.org/?p=137#comment-3943</guid>
		<description>The concept of caching data on machines like that is a lot trickier than you can imagine.  If any of you have time, do some looking into &quot;occasionally connected computing&quot;.  It&#039;s been a major deal for &quot;field agents&quot; such as salespersons and technicians.  Data synchronization between two &quot;authorative&quot; sources is highly complex.   Beyond the data itself, the software architecture for accessing that data in a useful manner is also troublesome to support in a distributed environment.

Actually, some hospitals (like UPMC) are developing things of that nature.  There are several pilot programs in place where PDAs are kept at the nurses station and patients records are both created and transferred to the PDAs.  So as patients are evaluated, that evaluation is placed on the PDA and then &#039;synced&#039; at the nurses station.  In this scenario, you would have a series of devices that have all current patients information on them (but not past patients or patients in other wings).

However, even with keeping current patients information available in case of a network crash, you have an issue of patients checking in during the crash.  As referenced in the one Dr quote above, he had to ask patients he had treated in the past about their medical issues because he didn&#039;t trust his own memory.  And that is probably the real danger.</description>
		<content:encoded><![CDATA[<p>The concept of caching data on machines like that is a lot trickier than you can imagine.  If any of you have time, do some looking into &#8220;occasionally connected computing&#8221;.  It&#8217;s been a major deal for &#8220;field agents&#8221; such as salespersons and technicians.  Data synchronization between two &#8220;authorative&#8221; sources is highly complex.   Beyond the data itself, the software architecture for accessing that data in a useful manner is also troublesome to support in a distributed environment.</p>
<p>Actually, some hospitals (like UPMC) are developing things of that nature.  There are several pilot programs in place where PDAs are kept at the nurses station and patients records are both created and transferred to the PDAs.  So as patients are evaluated, that evaluation is placed on the PDA and then &#8217;synced&#8217; at the nurses station.  In this scenario, you would have a series of devices that have all current patients information on them (but not past patients or patients in other wings).</p>
<p>However, even with keeping current patients information available in case of a network crash, you have an issue of patients checking in during the crash.  As referenced in the one Dr quote above, he had to ask patients he had treated in the past about their medical issues because he didn&#8217;t trust his own memory.  And that is probably the real danger.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon C. Ion</title>
		<link>http://philosecurity.org/2008/12/14/society-thin-client-model/comment-page-1#comment-3929</link>
		<dc:creator>Simon C. Ion</dc:creator>
		<pubDate>Wed, 14 Jan 2009 07:07:21 +0000</pubDate>
		<guid isPermaLink="false">http://philosecurity.org/?p=137#comment-3929</guid>
		<description>Kevin H:

To mitigate the theft risk, why not encrypt the local storage devices and keep the decryption key on something like a flash drive locked in a manager&#039;s safe?</description>
		<content:encoded><![CDATA[<p>Kevin H:</p>
<p>To mitigate the theft risk, why not encrypt the local storage devices and keep the decryption key on something like a flash drive locked in a manager&#8217;s safe?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin H</title>
		<link>http://philosecurity.org/2008/12/14/society-thin-client-model/comment-page-1#comment-3904</link>
		<dc:creator>Kevin H</dc:creator>
		<pubDate>Tue, 13 Jan 2009 23:52:48 +0000</pubDate>
		<guid isPermaLink="false">http://philosecurity.org/?p=137#comment-3904</guid>
		<description>Hmm, one way to somewhat mitigate thin client problems is for each machine or at least each store to have a local cache of important info. The radio shack might know if they had any FM transmitters, but not if the store in the next town did. Individual med stations might have information for any patient currently in the wing, but not info on past patients or patients in other parts of the hospital. This makes theft of hard drives a more dangerous event, but keeps data in a more distributed, error resilient network.</description>
		<content:encoded><![CDATA[<p>Hmm, one way to somewhat mitigate thin client problems is for each machine or at least each store to have a local cache of important info. The radio shack might know if they had any FM transmitters, but not if the store in the next town did. Individual med stations might have information for any patient currently in the wing, but not info on past patients or patients in other parts of the hospital. This makes theft of hard drives a more dangerous event, but keeps data in a more distributed, error resilient network.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: A. Peon</title>
		<link>http://philosecurity.org/2008/12/14/society-thin-client-model/comment-page-1#comment-3895</link>
		<dc:creator>A. Peon</dc:creator>
		<pubDate>Tue, 13 Jan 2009 22:24:14 +0000</pubDate>
		<guid isPermaLink="false">http://philosecurity.org/?p=137#comment-3895</guid>
		<description>Ha!  Check out the 2007(?) &quot;VCF East 4.0&quot; interview with Chuck Peddle, famous of MOS Technologies / Commodore (and graciously uploaded to YouTube by Dave Haynie of the Commodore-Amiga team): http://www.youtube.com/user/hazydave

Somewhere in there is the anecdote of his participation in a major retailer&#039;s (Macy&#039;s?) decision to go electronic at some point in the early prehistory of computing.  Of course, the day after Thanksgiving, someone hit a pole, and all the dumb terminals at the stores went out -- reinforcing his belief that there&#039;d be a market for a smart terminal... really a computer... a simple, &lt;i&gt;personal&lt;/i&gt; computer... that&#039;d have enough smarts to handle transactions locally and reconcile them with headquarters when possible -- and not leaving an entire company dead in the water when &quot;The Internet’s down.&quot;</description>
		<content:encoded><![CDATA[<p>Ha!  Check out the 2007(?) &#8220;VCF East 4.0&#8243; interview with Chuck Peddle, famous of MOS Technologies / Commodore (and graciously uploaded to YouTube by Dave Haynie of the Commodore-Amiga team): <a href="http://www.youtube.com/user/hazydave" rel="nofollow">http://www.youtube.com/user/hazydave</a></p>
<p>Somewhere in there is the anecdote of his participation in a major retailer&#8217;s (Macy&#8217;s?) decision to go electronic at some point in the early prehistory of computing.  Of course, the day after Thanksgiving, someone hit a pole, and all the dumb terminals at the stores went out &#8212; reinforcing his belief that there&#8217;d be a market for a smart terminal&#8230; really a computer&#8230; a simple, <i>personal</i> computer&#8230; that&#8217;d have enough smarts to handle transactions locally and reconcile them with headquarters when possible &#8212; and not leaving an entire company dead in the water when &#8220;The Internet’s down.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt</title>
		<link>http://philosecurity.org/2008/12/14/society-thin-client-model/comment-page-1#comment-3324</link>
		<dc:creator>Matt</dc:creator>
		<pubDate>Thu, 18 Dec 2008 21:18:35 +0000</pubDate>
		<guid isPermaLink="false">http://philosecurity.org/?p=137#comment-3324</guid>
		<description>Sherri,
Great post!  This is also a concern with physical security systems as more and more business place their physical security systems onto the network.  I know of two instance where network outages took physical access control systems off-line, in both cases the outage was caused by a network worm basically DoSing the network.
In one case, at a large university, when the network went down the readers went into a fail safe mode and would not unlock the door.  In this case they needed to use old fashion brass keys to open the door. The network outage occurred after hours so didn&#039;t cause a big impact and only took a few hours to clean up.
In the second case, a large hospital, when the network went down the door all unlocked themselves.  In this case the hospital needed to bring in a large number of guards to monitor door to sensitive area.  All in all it took them a few days to get the network back online.  I never got an estimate on how much the network outage cost the hospital but the guard cost alone were probably substantial.
So when moving to a thin client model it&#039;s also important to test and understand what happens when the network go offline.  Does the system fail in a graceful manner?
Cheers,
Matt</description>
		<content:encoded><![CDATA[<p>Sherri,<br />
Great post!  This is also a concern with physical security systems as more and more business place their physical security systems onto the network.  I know of two instance where network outages took physical access control systems off-line, in both cases the outage was caused by a network worm basically DoSing the network.<br />
In one case, at a large university, when the network went down the readers went into a fail safe mode and would not unlock the door.  In this case they needed to use old fashion brass keys to open the door. The network outage occurred after hours so didn&#8217;t cause a big impact and only took a few hours to clean up.<br />
In the second case, a large hospital, when the network went down the door all unlocked themselves.  In this case the hospital needed to bring in a large number of guards to monitor door to sensitive area.  All in all it took them a few days to get the network back online.  I never got an estimate on how much the network outage cost the hospital but the guard cost alone were probably substantial.<br />
So when moving to a thin client model it&#8217;s also important to test and understand what happens when the network go offline.  Does the system fail in a graceful manner?<br />
Cheers,<br />
Matt</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: miah</title>
		<link>http://philosecurity.org/2008/12/14/society-thin-client-model/comment-page-1#comment-3227</link>
		<dc:creator>miah</dc:creator>
		<pubDate>Tue, 16 Dec 2008 20:29:54 +0000</pubDate>
		<guid isPermaLink="false">http://philosecurity.org/?p=137#comment-3227</guid>
		<description>Sherri,

I got 2 months of AC storage free from Uhaul because of a computer outage, and a nice manager.  When we moved from Boston to Houston, I had called to arrange storage at a Uhaul location near the area we&#039;d be staying (and moved to).  When I went in to sign up, the manager told me that if I bought one of the locks from them I would get a month free.  I kinda felt like it was a scam, but considering we&#039;d just moved cross country any savings we could get would be great, and we figured we&#039;d be out of the storage within the month anyways.  We found a house and signed just after the first month, but they didn&#039;t bill me because of a computer outage!  I moved all of our items out of storage to our new place before the second month was up, and when I went in to pay up the manager just told us that we were set.  Since we&#039;d just bought a house and nothing was missing from our storage I was fine with this.

Anyways, Houston is not nearly as cool as Boston, but no snow (the snow we had last week doesn&#039;t count)!

-miah</description>
		<content:encoded><![CDATA[<p>Sherri,</p>
<p>I got 2 months of AC storage free from Uhaul because of a computer outage, and a nice manager.  When we moved from Boston to Houston, I had called to arrange storage at a Uhaul location near the area we&#8217;d be staying (and moved to).  When I went in to sign up, the manager told me that if I bought one of the locks from them I would get a month free.  I kinda felt like it was a scam, but considering we&#8217;d just moved cross country any savings we could get would be great, and we figured we&#8217;d be out of the storage within the month anyways.  We found a house and signed just after the first month, but they didn&#8217;t bill me because of a computer outage!  I moved all of our items out of storage to our new place before the second month was up, and when I went in to pay up the manager just told us that we were set.  Since we&#8217;d just bought a house and nothing was missing from our storage I was fine with this.</p>
<p>Anyways, Houston is not nearly as cool as Boston, but no snow (the snow we had last week doesn&#8217;t count)!</p>
<p>-miah</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: carl</title>
		<link>http://philosecurity.org/2008/12/14/society-thin-client-model/comment-page-1#comment-3157</link>
		<dc:creator>carl</dc:creator>
		<pubDate>Tue, 16 Dec 2008 01:45:26 +0000</pubDate>
		<guid isPermaLink="false">http://philosecurity.org/?p=137#comment-3157</guid>
		<description>This is something I&#039;ve given thought to more than once.  I&#039;ve come to assume that someday, whether due to massive attacks on the system, solar flares, mismanagement, world war, or whatever form of disaster, a prolonged loss of the information superhighway to at least a good-sized chunk of the developed world would be a sufficient wake-up call to spawn investment into a completely separate privately funded Internetco(tm).  Local service providers and larger businesses would tap into both nets, using one or the other as backup.
The costs of going back to paper-based systems simply to improve continuity of transactions would simply be too daunting and &#039;backwards&#039; for large organizations.</description>
		<content:encoded><![CDATA[<p>This is something I&#8217;ve given thought to more than once.  I&#8217;ve come to assume that someday, whether due to massive attacks on the system, solar flares, mismanagement, world war, or whatever form of disaster, a prolonged loss of the information superhighway to at least a good-sized chunk of the developed world would be a sufficient wake-up call to spawn investment into a completely separate privately funded Internetco(tm).  Local service providers and larger businesses would tap into both nets, using one or the other as backup.<br />
The costs of going back to paper-based systems simply to improve continuity of transactions would simply be too daunting and &#8216;backwards&#8217; for large organizations.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Karsten Nohl</title>
		<link>http://philosecurity.org/2008/12/14/society-thin-client-model/comment-page-1#comment-3078</link>
		<dc:creator>Karsten Nohl</dc:creator>
		<pubDate>Sun, 14 Dec 2008 10:27:23 +0000</pubDate>
		<guid isPermaLink="false">http://philosecurity.org/?p=137#comment-3078</guid>
		<description>Businesses are scared of volatility in all its forms, including variance in employees&#039; judgment and skills. Quality assurance requires (at least according to ISO) that processes can be repeated as accurately as possible independent of the people executing them. 

When making systems less vulnerable to human error we often presume that computing systems become more reliable than humans can ever be. Large-scale IT outages caused by increasing system complexity will hopefully shift the focus back to people&#039;s education as the major asset for companies.</description>
		<content:encoded><![CDATA[<p>Businesses are scared of volatility in all its forms, including variance in employees&#8217; judgment and skills. Quality assurance requires (at least according to ISO) that processes can be repeated as accurately as possible independent of the people executing them. </p>
<p>When making systems less vulnerable to human error we often presume that computing systems become more reliable than humans can ever be. Large-scale IT outages caused by increasing system complexity will hopefully shift the focus back to people&#8217;s education as the major asset for companies.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
