<?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"
	>
<channel>
	<title>Comments on: Detecting and Disabling Smart Crash Reporter</title>
	<atom:link href="http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/</link>
	<description>...so google can organize my head.</description>
	<pubDate>Thu, 20 Nov 2008 16:33:39 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Us vs Them</title>
		<link>http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-154487</link>
		<dc:creator>Us vs Them</dc:creator>
		<pubDate>Wed, 26 Sep 2007 18:00:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-154487</guid>
		<description>[...] (bbum) blog primarily in the &#8220;Sandvox Hidden Features&#8221; entry but also in the &#8220;Detecting and Disabling Smart Crash Reports&#8221; and &#8220;SCR: Response from Sandvox&#8221; [...]</description>
		<content:encoded><![CDATA[<p>[...] (bbum) blog primarily in the &#8220;Sandvox Hidden Features&#8221; entry but also in the &#8220;Detecting and Disabling Smart Crash Reports&#8221; and &#8220;SCR: Response from Sandvox&#8221; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Xune</title>
		<link>http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-58159</link>
		<dc:creator>Xune</dc:creator>
		<pubDate>Sun, 14 Jan 2007 16:43:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-58159</guid>
		<description>b.bum's recipe for guarding InputManagers won't work. The Opener hackers demonstrated that, as did the changes in Tiger. If the parent Library is modifiable you can always delete the InputManagers that's being difficult and create a new one. You need a STICKY BIT on the parent instead. Thank you.</description>
		<content:encoded><![CDATA[<p>b.bum&#8217;s recipe for guarding InputManagers won&#8217;t work. The Opener hackers demonstrated that, as did the changes in Tiger. If the parent Library is modifiable you can always delete the InputManagers that&#8217;s being difficult and create a new one. You need a STICKY BIT on the parent instead. Thank you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ACAMUG &#187; Fake Mac OS X 10.5 Screenshots is a Trojan Horse?</title>
		<link>http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-668</link>
		<dc:creator>ACAMUG &#187; Fake Mac OS X 10.5 Screenshots is a Trojan Horse?</dc:creator>
		<pubDate>Thu, 16 Feb 2006 17:17:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-668</guid>
		<description>[...] UPDATE: Its more sophisticated than I&#8217;d thought. According to Andrew Welch&#8217;s analysis it attempts to install a plug-in called an &#8220;input manager&#8221; which had it been successful would have allowed it to remain on the machine and attempt to spread via iChat whenever an application was launched (it fails due to a coding error.) Input Managers are intended to be used to provide alternative keyboard entry methods for non-roman languages but at the moment can be exploited for other means. This page documents a method to disable this feature, in this case to circumvent its unauthorized though helpful use for reporting application crashes, but it may help prevent future attacks of this type. I fully expect Apple will modify this mechanism to make it more secure as they did with Widgets when they were first available. [...]</description>
		<content:encoded><![CDATA[<p>[...] UPDATE: Its more sophisticated than I&#8217;d thought. According to Andrew Welch&#8217;s analysis it attempts to install a plug-in called an &#8220;input manager&#8221; which had it been successful would have allowed it to remain on the machine and attempt to spread via iChat whenever an application was launched (it fails due to a coding error.) Input Managers are intended to be used to provide alternative keyboard entry methods for non-roman languages but at the moment can be exploited for other means. This page documents a method to disable this feature, in this case to circumvent its unauthorized though helpful use for reporting application crashes, but it may help prevent future attacks of this type. I fully expect Apple will modify this mechanism to make it more secure as they did with Widgets when they were first available. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: links for 2006-02-09 at The International House of Nathos</title>
		<link>http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-648</link>
		<dc:creator>links for 2006-02-09 at The International House of Nathos</dc:creator>
		<pubDate>Thu, 09 Feb 2006 04:26:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-648</guid>
		<description>[...] bbum’s weblog-o-mat » Blog Archive » Detecting and Disabling Smart Crash Reporter A handful of Mac OS X apps install SCR without your permission. Here&#8217;s how to find it and remove it (and prevent it from coming back) (tags: ***** macosx) [...]</description>
		<content:encoded><![CDATA[<p>[...] bbum’s weblog-o-mat » Blog Archive » Detecting and Disabling Smart Crash Reporter A handful of Mac OS X apps install SCR without your permission. Here&#8217;s how to find it and remove it (and prevent it from coming back) (tags: ***** macosx) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: allgood2</title>
		<link>http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-641</link>
		<dc:creator>allgood2</dc:creator>
		<pubDate>Tue, 31 Jan 2006 14:54:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-641</guid>
		<description>I think this series of post hits on what I call the "slippery slope" issues. While I agree with Rosyna that 

&lt;blockquote&gt;I’m not sure if comparing Windows malware to a useful developer tool on OS X that discloses what it is doing to the user is a proper comparison at all.&lt;/blockquote&gt;

It's true, they aren't but road to hell is paved with good intentions. I love Unsanity, but the one thing that has stood out for me during this series of postings and rapid flash comments, is that I'd rather have Unsanity argue for what's right (which they did mention, briefly), which is that developers using their product always explicitly gain consent; then for them to argue who's wrong in their statement against Unsanity. I feel that the issue is about consent; and again Rosyna makes good points that their are a number of large developers that violate user consent, Adobe being just one of them. 

Obviously, Unsanity, feels defensive, maybe I'm out of the loop, but I just don't feel like acting defensively does much good in this situation. Correct misconceptions sure. But Unsanity has some brilliant products, including haxies. I also think Unsanity stands the test as a "trusted" developer for most. I know they make my short list of developers I trust. 

But reading these posts have made me depressed that there obviously exists the need for them to feel so defensive. I went back through the original post by bbum, as well as Daring Fireball, and it seems that they both went out of the way NOT to implicate Unsanity of any wrong doing (because there was none); but that the constant arguments and nitpiking by Rosyna seem to imply more and more that the issue was Unsanity; and then comments started becoming more about Unsanity and the SCR rather than, the very legitimate concern of "what care should developers take to keep their users aware and informed."  "Explicit consent" is key. Without it, every developer, would be developer, hacker, cracker, or stalker can argue that they were doing something of benefit, regardless if you agree or not.

Apple and the Mac OS has built a great community of developers. Most go out of their way to stay on the good side of their users; and I think Macintosh users trust and rely on that. So even if one "trusted" developer does something wrong, accidentally or without forethought, and hopefully without malice; it still effects the entire community. I think Karelia's response was thoughtful, and a good step—we were wrong, we will change it, wouldn't it be nice if... 

I wish that people would read carefully, and not get up and arms and adamant and force developers in defensive stands. But I'd also wish for a 100 million dollars, better coding skills, a longer attention span, and a kick-a** vocabulary. I'd rather not hear people trashing developers and running for the hills, but I do want to hear about mistakes, errors in judgement, debates of right and wrong. Why? Because for me, it's how you handle your mistakes that defines your trustworthiness. But also, life is full of slippery slope issues; and its easy to let things slide. 

Without Gruber's reminder, I would have never paid much attention to the issue—probably because I had already decided that Smart Crash Reporter had merit and had installed it independently. I may have thought, its a good app with a good purpose, what's the problem. Sometimes vision becomes too focused. It's never alright to install something "silently". NEVER. And that is important, and its worth users standing up for, and even more so, its worth good and great developers to stand up for as well.</description>
		<content:encoded><![CDATA[<p>I think this series of post hits on what I call the &#8220;slippery slope&#8221; issues. While I agree with Rosyna that </p>
<blockquote><p>I’m not sure if comparing Windows malware to a useful developer tool on OS X that discloses what it is doing to the user is a proper comparison at all.</p></blockquote>
<p>It&#8217;s true, they aren&#8217;t but road to hell is paved with good intentions. I love Unsanity, but the one thing that has stood out for me during this series of postings and rapid flash comments, is that I&#8217;d rather have Unsanity argue for what&#8217;s right (which they did mention, briefly), which is that developers using their product always explicitly gain consent; then for them to argue who&#8217;s wrong in their statement against Unsanity. I feel that the issue is about consent; and again Rosyna makes good points that their are a number of large developers that violate user consent, Adobe being just one of them. </p>
<p>Obviously, Unsanity, feels defensive, maybe I&#8217;m out of the loop, but I just don&#8217;t feel like acting defensively does much good in this situation. Correct misconceptions sure. But Unsanity has some brilliant products, including haxies. I also think Unsanity stands the test as a &#8220;trusted&#8221; developer for most. I know they make my short list of developers I trust. </p>
<p>But reading these posts have made me depressed that there obviously exists the need for them to feel so defensive. I went back through the original post by bbum, as well as Daring Fireball, and it seems that they both went out of the way NOT to implicate Unsanity of any wrong doing (because there was none); but that the constant arguments and nitpiking by Rosyna seem to imply more and more that the issue was Unsanity; and then comments started becoming more about Unsanity and the SCR rather than, the very legitimate concern of &#8220;what care should developers take to keep their users aware and informed.&#8221;  &#8220;Explicit consent&#8221; is key. Without it, every developer, would be developer, hacker, cracker, or stalker can argue that they were doing something of benefit, regardless if you agree or not.</p>
<p>Apple and the Mac OS has built a great community of developers. Most go out of their way to stay on the good side of their users; and I think Macintosh users trust and rely on that. So even if one &#8220;trusted&#8221; developer does something wrong, accidentally or without forethought, and hopefully without malice; it still effects the entire community. I think Karelia&#8217;s response was thoughtful, and a good step—we were wrong, we will change it, wouldn&#8217;t it be nice if&#8230; </p>
<p>I wish that people would read carefully, and not get up and arms and adamant and force developers in defensive stands. But I&#8217;d also wish for a 100 million dollars, better coding skills, a longer attention span, and a kick-a** vocabulary. I&#8217;d rather not hear people trashing developers and running for the hills, but I do want to hear about mistakes, errors in judgement, debates of right and wrong. Why? Because for me, it&#8217;s how you handle your mistakes that defines your trustworthiness. But also, life is full of slippery slope issues; and its easy to let things slide. </p>
<p>Without Gruber&#8217;s reminder, I would have never paid much attention to the issue—probably because I had already decided that Smart Crash Reporter had merit and had installed it independently. I may have thought, its a good app with a good purpose, what&#8217;s the problem. Sometimes vision becomes too focused. It&#8217;s never alright to install something &#8220;silently&#8221;. NEVER. And that is important, and its worth users standing up for, and even more so, its worth good and great developers to stand up for as well.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mat</title>
		<link>http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-640</link>
		<dc:creator>Mat</dc:creator>
		<pubDate>Tue, 31 Jan 2006 11:51:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-640</guid>
		<description>I just discovered that SCR was installed on my system without my permissionb ut by an unknown application. Is there any way of checking so see what installed that file? Does the file system keep a record of things like that? My dev machines will never have an unsanity "haxie" or anything made by them installed for similar reasons to your own, so thanks for giving us these tips.</description>
		<content:encoded><![CDATA[<p>I just discovered that SCR was installed on my system without my permissionb ut by an unknown application. Is there any way of checking so see what installed that file? Does the file system keep a record of things like that? My dev machines will never have an unsanity &#8220;haxie&#8221; or anything made by them installed for similar reasons to your own, so thanks for giving us these tips.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: neoguri</title>
		<link>http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-639</link>
		<dc:creator>neoguri</dc:creator>
		<pubDate>Tue, 31 Jan 2006 09:01:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-639</guid>
		<description>I got here thanks to an enlightening article on John Gruber's&lt;a href="www.daringfireball.net" title="site Daring Fireball" rel="nofollow"&gt;Daring Fireball&lt;/a&gt;. I totally agree with you and John that this is unacceptable behaviour for Mac software. I goes against both "good computer-house-keeping" as common decency. Thanks for the disable work-around.</description>
		<content:encoded><![CDATA[<p>I got here thanks to an enlightening article on John Gruber&#8217;s<a href="www.daringfireball.net" title="site Daring Fireball" >Daring Fireball</a>. I totally agree with you and John that this is unacceptable behaviour for Mac software. I goes against both &#8220;good computer-house-keeping&#8221; as common decency. Thanks for the disable work-around.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gummi</title>
		<link>http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-634</link>
		<dc:creator>gummi</dc:creator>
		<pubDate>Mon, 30 Jan 2006 17:06:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-634</guid>
		<description>Then obviously, Wincent, you live a Mac life without CocoaGestures and PithHelmet.

I think this kerfuffle is a bit overdone. I had the same reaction when PathFinder 4 installed SCR, but I just dumped it and ran a terminal command as well. I think it was bad form that Cocoatech did this *without* informing the user, but since their application is so good I think they deserve a break. 

So, how about we measure our contempt for the InputManager folder based upon the usefulness of any software that needs it?</description>
		<content:encoded><![CDATA[<p>Then obviously, Wincent, you live a Mac life without CocoaGestures and PithHelmet.</p>
<p>I think this kerfuffle is a bit overdone. I had the same reaction when PathFinder 4 installed SCR, but I just dumped it and ran a terminal command as well. I think it was bad form that Cocoatech did this *without* informing the user, but since their application is so good I think they deserve a break. </p>
<p>So, how about we measure our contempt for the InputManager folder based upon the usefulness of any software that needs it?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Mison</title>
		<link>http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-631</link>
		<dc:creator>Paul Mison</dc:creator>
		<pubDate>Mon, 30 Jan 2006 10:03:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-631</guid>
		<description>Will using Disk Utility's Repair Permissions revert the Input Managers folders to their previous, less restrictive permissions? Or are they not in its list of things to check?</description>
		<content:encoded><![CDATA[<p>Will using Disk Utility&#8217;s Repair Permissions revert the Input Managers folders to their previous, less restrictive permissions? Or are they not in its list of things to check?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wincent</title>
		<link>http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-623</link>
		<dc:creator>Wincent</dc:creator>
		<pubDate>Fri, 27 Jan 2006 18:51:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.friday.com/bbum/2006/01/20/detecting-and-disabling-smart-crash-reporter/#comment-623</guid>
		<description>I tried out Path Finder 4 for a few minutes (until it crashed) on the day it came out, then I trashed it. Today thanks to reading your post I discover that it silently installed an input manager. I totally agreed with you Bill; as a software developer I don't want &lt;em&gt;anything&lt;/em&gt; on my system that alters its behaviour. I'll be locking down the InputManagers path to prevent this kind of abuse in the future (it &lt;em&gt;is&lt;/em&gt; abuse because it's done without the user's informed consent, no matter how benign or useful SCR may or may not be in the eyes of its creators). I have never, ever installed any software that needed to make use of input managers, so I don't think I'll miss having the folder.</description>
		<content:encoded><![CDATA[<p>I tried out Path Finder 4 for a few minutes (until it crashed) on the day it came out, then I trashed it. Today thanks to reading your post I discover that it silently installed an input manager. I totally agreed with you Bill; as a software developer I don&#8217;t want <em>anything</em> on my system that alters its behaviour. I&#8217;ll be locking down the InputManagers path to prevent this kind of abuse in the future (it <em>is</em> abuse because it&#8217;s done without the user&#8217;s informed consent, no matter how benign or useful SCR may or may not be in the eyes of its creators). I have never, ever installed any software that needed to make use of input managers, so I don&#8217;t think I&#8217;ll miss having the folder.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
