Detecting and Disabling Smart Crash Reporter

A number of folks have indicated that various apps anonymously install Smart Crash Reporter. As well, a number have asked how to detect and disable SCR.

Easy enough. Look in Library/InputManagers in your account. Smart Crash Reporter will be found in there, if installed in your user account. It could also appear in /Library/InputManagers (or, if something truly evil installed it, /System/Library/InputManagers).

If it is there, tossing it in the trash will disable Smart Crash Reporter. Until the next time you run an app that silently installs it.

To permanently disable the anonymous installation of all InputManagers, go to Terminal and:

# Yes -- this next line will remove all InputManagers in your account.
rm -rf Library/InputManagers
touch Library/InputManagers
sudo chown root Library/InputManagers
sudo chmod a-rwx Library/InputManagers

This could obviously be modified just to target Smart Crash Reporter, but I really don’t want any Input Managers installed unless I specifically give the OK.

If your user account has administrative privileges, you will also likely want to do this:

sudo chmod -R g-w /Library/InputManagers

This will require authorization (or sudo) to install anything into /Library/InputManagers. Personally, my user account is not enabled for administration. I edited /etc/sudoers to allow sudo access for my primary account and I have a separate admin-only account that I use to do machine administration.

20 Responses to “Detecting and Disabling Smart Crash Reporter”

  1. Rosyna says:

    I do not believe what you are suggesting is supported by Apple 😉

    That and it’s complete and utter overkill.

  2. bbum says:


    Overkill? Yeah. A bit. But I really really do not want InputManagers used without my express permission. In the long run, I’m considering what parts of my home directory I want to make read only and owned by someone other than my user. I already have all my apps in that state — anything that writes into its own app wrapper deserves to meet the trash can.

    A bit fascist? Yep. Chalk it up to having to clean out about 4 rootkits too many on Linux/Solaris. I know, I know, we aren’t talking rootkits here, but Windows has certainly demonstrated that mass destruction can be caused by user level processes.

  3. Rosyna says:

    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.

    In fact, you’ve said or implied that SCR “voids your warranty”, “is spyware”, “is malware”, “is a rootkit”, and “makes the situation as bad as Windows”. None of which are true. But people reading your site or darginfireball will believe these accusations without the need for anything backing them up. If they’re told the correct information about the software by the developers (us), they still will believe what your implied assertions over us. That is not good. This is also what happened to the “haxie” name. One person, (initials BP) emailed many user sites and mailing lists decrying their use. He had never used a single one, but it appeared on so many websites, websites users trusted, that his complaints were quoted word for word and posted to other sites. It then became the telephone game and his quotes were changed quite a bit. The point is that one person, even if they are well meaning, can do a lot of damage by even implying malicious intent.

  4. bbum says:

    Blunt clarification here:

    “voids your warranty” is an analogy. Haxies and, to a lesser degree, Input Managers change the apps they are loaded into in a way that the app author or operating system vendor likely does not support. It is similar to taking the cover off of a TiVo and replacing the hard drive; the device is now in a state that the manufacturer did not qualify. It should work, but the manufacturer cannot guarantee so and, given the economics of support, may rightly make the claim that they aren’t interested in further diagnosing the problem.

    “spyware”. I don’t think I have said anything that would indicate that I think that SCR is truly like spyware. SCR does take information normally only destined for Apple and spits it off in a different direction (only if the user wants it too — not really spyware like at all), but that is about it.

    “malware”. SCR modifies the behavior of every Cocoa app in my account. Even just by loading and executing enough code to determine that it shouldn’t do anything else, it is modifying the launch behavior of an app. Shouldn’t be a problem for most users, but it very much is a problem for me. The “malware” in this case wasn’t SCR but Karelia’s Sandvox for having installed such a thing behind my back without warning. They have indicated that the next version will fix that problem.

    “rootkit”. Nope. Didn’t say anything comparing SCR to a rootkit. Just that I have dealt with rootkits and have scars from it.

    “Windows” Poor analogy. More like “Mac OS 9 and extensions”. Extensions were cool, but they totally sucked to support.

    Bottom line: Haxies and SCR both modify application and operating system behavior in ways that the vendor(s) never intended. Regardless of how well engineered they are (and they are well engineered!!), it is still an intrusive operation that does have implications for a number of users. More likely than not, nothing bad will happen. But it does have impact on the user’s system and the level of support they might receive from various vendors. And for some of us, that level of intrusion is completely unacceptable. That is my choice. How others interpret my musings is their choice. I have tried very hard to be fair throughout all of this.

  5. Rosyna says:

    The problem isn’t what you meant by any of those things. The fact is that the words were used is close proximity. From years of supporting software, haxies, and writing software, haxies, I have seen personally how very, very easily users misinterpret things. For example, you went from talking about InputManagers (which SCR is, and InputManagers are supported and have been released by Apple employees such as Mike Ferris’s TextExtras) to talking about rootkits. A user that may only know what a rootkit is from the Sony BMG debacle might draw a parallel between the two statements. Especially since you then say we aren’t talking rootkits then mention a problem with Windows. Again, a parallel might be drawn by users that have only heard horror stories about windows.

    As for the spyware thing, it was explicitly described as such in a comment to your first post on SCR. Granted, you didn’t make the comment but someone interpreted your comments in such a way that it made them say “spyware”.

    The same goes for your “Mac OS 9 and extensions” comment. You cannot compare haxies and Mac OS 9 extensions. Their implementations aren’t the same, their features aren’t the same, the set of possible worst case problems are not the same (and do not overlap), and their security is definitely not the same. And I consider comparing them to be far more like FUD than a useful and accurate statement.

  6. bbum says:

    Fair enough regarding rootkits and windows. I can certainly understand how one might be sensitive to any association with such products.

    An Input Manager is a supported extension for extending the behavior of Cocoa’s text system. It is not intended to be a generic hook for modifying the behavior of applications. The documentation needs to be clarified and I have filed a bug to do exactly that.

    As for TextExtras, it does a bunch of things that really are pretty invasive such as modifying the application’s menus. Useful tool, certainly, and even pretty close to the intended purpose of Input Managers, but still problematic. At one point, TE conflicted with an app on my system. Deleting TE fixed the problem.

    However, I do completely disagree regarding the comparison of haxies and Mac OS 9 extensions. Sure, the features may be the same, but that is irrelevant. The only real difference between the two is that Mac OS 9 extensions modified the system while haxies are largely limited to modifying processes that are owned by the user. You are absolutely correct that the security implications are vastly different.

    The end result is still the same. Both mechanisms are used to modify the system in ways that were not intended or supported. Haxies are better engineered and more localized to the user’s workspace (more isolated from the system underpinnings), but that doesn’t change the fact that they modify system behavior in ways that may be unexpected, may cause conflicts, and cannot be effectively supported by Apple or third party application authors.

  7. Michael Tsai - Blog - rm -rf ~/Library/InputManagers says:

    […] Bill Bumgarner shows how to prevent applications from automatically installing Smart Crash Reporter (and other input managers). […]

  8. Chucky says:


    Perhaps future haxies and input managers from your shop could modify the text in web browsers to prohibit misinterpretation of your products. Perhaps that would solve everyone’s problems, no?


    “Haxies are better engineered and more localized to the user’s workspace (more isolated from the system underpinnings)”

    Of course, haxies install stuff into /System, and haxies run code in the space of every user on a machine…

  9. Darth Sidious says:

    I would not say that an InputManager is related to the OS. Unless Mac OS X Kernel and main libraries have been rewritten in Cocoa last night.

    Anyway, this is how I see this kind of scenario similar to the MenuExtras and Docklet:

    Mac OS X is the child of Apple’s engineers, their daughter. Nobody is good enough to date her.

  10. Shawn Mole says:

    As for the spyware thing, it was explicitly described as such in a comment to your first post on SCR. Granted, you didn’t make the comment but someone interpreted your comments in such a way that it made them say “spyware”.

    Rosyna, I was the first of two people to call SCR, as the Sandvox beta uses it, “spyware.” In fact, I prefaced “spyware” with “altruistic,”. The second poster, Nate Silva, also seemd to clearly understand that SCR was well intentioned, but that this was a “bad precedent.”

    To clarify, I wrote that that SCR was “installed without the user’s express consent … to collect … data” (I’ve removed my parenthetical additions that made SCR sound helpful). To put it another way, I do not believe any reasonable argument can be made that SCR, in this case, was installed with the user’s express consent nor that the purpose of SCR is something other than data collection. This means that SCR, as deployed in Sandvox’s beta, meets at least some of the criteria for spyware.

    Yes, “spyware” is a harsh term and implies evil intent while SCR’s purpose is altruistic. However, your defense that Unsanity and Karelia are acting for the common good doesn’t change the fact that SCR’s installation, in this instance, violated my rights as a user. If you’re really worried about SCR being misconstrued as spyware, Unsanity could take three easy steps to avoid being mis-labelled:

    – Insist that developers using SCR notify users they are installing it and allow users to opt out
    – Add information to SCR’s FAQ on how to temporarily disable SCR (just in case) for troubleshooting
    – Add information to SCR’s FAQ about how to uninstall it (all software should come with this)

    Obviously, Rosyna, you could have easily posted the last two pieces of information here along with your arguments. Instead, you’ve been commenting here trying to correct semantics, clarify terms, and broaden the debate to the damage done to Unsanity’s and APE’s reputation. At the same time, bbum has actually posted a helpful FAQ about how to remove SCR (if necessary), and Dan Wood responded to my e-mailed support request with more information about SCR and its future in Sandvox.

    SCR’s clandestine installation violates my rights, both my right to privacy and consent. Yes, Software Developers have rights, too, including Unsanity. SCR deserves to be categorized fairly, and Unsanity deserves to have a good reputation (for instance, Paranoid Android). But if SCR’s installation is circumventing my right to consent and Unsanity continues to support this, I will describe both SCR and Unsanity as I like.

    bbum, thanks for your service to the Mac community and following up on this issue. Also, thank you for treating Karelia’s Sandvox and SCR respectfully. I think you’ve been exceedingly courteous in your posts and comments. I’m sorry if I’ve over posted, especially as I am a new reader. I wanted to be clear, publicly, that I do not believe you to be responsible for any negative word attributed to SCR or Unsanity.

  11. Wincent says:

    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 anything 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 is 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.

  12. Paul Mison says:

    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?

  13. gummi says:

    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?

  14. neoguri says:

    I got here thanks to an enlightening article on John Gruber’sDaring Fireball. 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.

  15. Mat says:

    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.

  16. allgood2 says:

    I think this series of post hits on what I call the “slippery slope” issues. While I agree with Rosyna that

    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.

    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.

  17. links for 2006-02-09 at The International House of Nathos says:

    […] 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’s how to find it and remove it (and prevent it from coming back) (tags: ***** macosx) […]

  18. ACAMUG » Fake Mac OS X 10.5 Screenshots is a Trojan Horse? says:

    […] UPDATE: Its more sophisticated than I’d thought. According to Andrew Welch’s analysis it attempts to install a plug-in called an “input manager” 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. […]

  19. Xune says:

    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.

  20. Us vs Them says:

    […] (bbum) blog primarily in the “Sandvox Hidden Features” entry but also in the “Detecting and Disabling Smart Crash Reports” and “SCR: Response from Sandvox” […]

Leave a Reply

Line and paragraph breaks automatic.
XHTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>