读者关于我的第一个问题Smart Crash Reports missivetwo weeks ago was, more or less, “I had no idea that any app can install an input manager without permission, and that these input managers load into every running application — isn’t this a serious security hole waiting to be exploited?”
总之，不，不是真的But that doesn’t mean the situation is good.
It’s not a security hole, per se, but rather just one of many routes a malicious application could take if it wanted to do something bad. Once you launch an application, it can pretty much do什么it wants within the confines of your home folder: read your mailboxes, delete the contents of your Documents folder, and, yes, surreptitiously add items to your InputManagers folderBut an app can just as easily add items to any sub-folder in your Library folder, including other code resource plug-ins like QuickTime components, OSA scripting additions, (a.k.aOSAXen), and contextual menu items.
Any of these items could be used for nefarious purposes just as easily as input managers — and any of them could be installed by any running application at any time.
可以是一个有效的词The expected behavior of any application that wants to install any system-wide extension is that it should ask permission first; apps that behave otherwise should be shunnedBut the system doesn’t enforce this, and I’m not sure it could, other than to change the ownership or permissions on these folders such that even administrator users would have to authenticate before adding items to themThat may well be “safer”, but it’s also more complex; the ownership and permissions of all folders within your home folder have always been nice and simple on Mac OS X: you own them, and you can read and write to any of them.
There are so many bad things a malicious app can do once it’s running that it’d be nearly impossible to defend against them all, individually; the best and only defense is not to launch software you don’t trust(And, of course, to back up regularly to a drive that you don’t keep mounted all the time.)
One thought that occurred to me was that Apple should definitely suppress the loading of any invisible items in the magic auto-loading code extension foldersAn app with deeply nefarious intentions should not be able to install, say, an input manager和make it invisible so that it doesn’t appear in the Finder.
这似乎是疏忽，如果不是一个bugIf it’s a good idea to suppress some “invisible” input managers, the system should suppress them allAnd I can’t think of a single legitimate reason why anyone would want invisible input managers (or contextual menu items, QuickTime components, or scripting additions) to load.
If you’re worried about input managers being installed behind your back,这个聪明的评论on MacSlash offers instructions on using Folder Actions to get a notification every time an item is added to your InputManagers folder(Even this isn’t bullet-proof protection — a deeply clever malicious input manager could suppress Folder Actions from firing.)
Unsanity’s Slava Karpenko, lead developer of Smart Crash Reports, has announced that the next release of Smart Crash Reports, in public beta at this writing,will no longer offer the silent installation featureInstead, it now prompts the user with a dialog box asking for permission该对话框显示：
您想安装Smart Crash Reports吗？
Smart Crash Reports helps improve software by notifying its developers of problems when they happenParticipation is voluntary, but your support helps make our software betterFor more information, visit http://smartcrashreports.com/.
I would argue, however, that Unsanity’s description of Smart Crash Reports, both in the dialog box on their web site, does not make clear just what exactly it is: an input manager bundle installed in〜/资源库/ InputManagers /Simple “how to uninstall” instructions in the Smart Crash Reports常问问题会做的伎俩。
There is currently no way for third party developers to access the reports submitted via CrashReporterApple is aware that there is strong demand for such a facility (r3356232）Regardless, your users can still submit crash logs to you manuallyMoreover, there’s no reason why your application couldn’t look at its crash log on each launch and, if it has changed, ask the user whether they want to submit it to your bug tracking system.
This is pretty much the same advice I offered, and many developers do just this(Apple certainly doesn’t recommend using an input manager hack to modify the system’s Crash Reporter at runtime.)
Zonic的BugReporteris self-contained crash reporter available to developers for a very low price ($50 for a single product, $100 for unlimited products; neither license has any restrictions unit sales)来自Zonic的网页：
BugReporter is a developer tool that allows applications to automatically invoke a bug-reporting system in the event of a crash.
The BugReporter API is a simple “C” interface, providing maximum compatibility with development environments such as Carbon or Cocoa.
It is distributed as a stand-alone library, and requires no additional resources, frameworks, or bundlesIt can be invoked from both CFM or Mach-O applications, packaged in either single-file or bundled form.
BugReporter allows bug reports to be submitted through email or over the web, enabling you to pass bug reports directly from an end user’s desktop to your internal support systems.
Lastly, developers who are worried about turning users off with crash reporting dialog boxes should considerAdium的, whose built-in crash reporter conveys a bit of crash-and-burn humor: