Us vs Them

I don’t editorialise very often if at all. Mainly because I’m not egotistic enough to think anybody really cares about another random blogger writing a bunch of opinionated crap. However the storm in a teacup that is brewing over the Smart Crash Reports feature built into the Sandvox beta is beginning to bug me enough that I thought i ought to write about it. The center of the storm is over at Bill Bumgarner’s (bbum) blog primarily in the “Sandvox Hidden Features” entry but also in the “Detecting and Disabling Smart Crash Reports” and “SCR: Response from Sandvox” entries.

Smart Crash Reports (SCR) is software released by Unsanity that third party developers can bundle with their own software to fool Mac OS X’s built-in crash reporter into sending bug reports to the third party developer as well as or instead of Apple. Many third party developers are bundling SCR with their software and a list is available from the Unsanity website. In theory it sounds like a great tool, third party developers can enable SCR with very little work and then improve their software based on crash reports from their users. Unfortunately SCR has been implemented as an Mac OS X Input Manager. Input Managers are bundles that can be loaded into and executed within every application the user runs. They are designed to allow developers to create customised input methods. Because Input Managers are loaded in every application’s address space Input Managers have been used almost exclusively for extended or changing the behavior of existing applications.

Some people believe that Input Managers and other software that inserts itself in other Applications (like Unsanity’s APE “Haxies”) contributes to system instability. I’ve written such software myself and am definitely aware how easy it is to cause unforeseen problems when writing software of this kind. Some people choose not to install Input Managers and Haxies believing that by not installing these 3rd party software that their system as a whole will be more stable. That’s fine and more power to these people for knowing exactly what they want from their system.

Input Managers are stored in “~/Library/Input Managers” and “/Library/Input Managers” and once an Input Manager has been installed, every application the user runs after installing the Input Manager will have the Input Manager inserted and executed within the application. To uninstall an Input Manager the user should remove it from the Input Managers directory and then log out and log back in again (to make sure all effected programs are closed). Unsanity have created an optional feature in SCR that will automatically install SCR to the correct location without the user needing to install it by hand. Some applications that use SCR do not take advantage of the feature and some do. Sandvox does and this is what is causing this controversy.

When Sandvox first runs it silently installs SCR if it hasn’t already been installed. From this point on any newly launched application is affected by SCR. According to Unsanity, SCR is designed only to actually do its thing inside Apple’s crash report application (changing the behavior of the application to allow bug reports to be sent to third party developers). When ran inside any other application SCR effectively does nothing, it is still loaded but is not executing any extra code. This minimizes any potential unforeseen problems with loading the Input Manager.

Now some people are getting very annoyed with Sandvox and SCR, the storm in the teacup has brewed up and is now engulfing Unsanity and their APE technology. There have even been claims that SCR is spyware. Personally I think this is all going too far. The developers of Sandvox made a mistake in not giving the user the option of installing SCR or not. However Sandvox is beta software and will, almost by definition contains bugs and flaws. If you don’t like that then don’t run beta or any other kind of pre-release software. It is that simple. It amazes me that people who are so keen to see their system be as stable as possible would even dream of running beta software.

Unsanity also made a mistake in allowing the SCR install to occur silently. They should probably present the user with the option to prevent the installation of SCR. That way no software using SCR will ever install it without the user’s knowledge.

And finally the Apple engineers made a mistake in not allowing third party developers from hooking into the crash reporter without the need to resort to an Input Manager hack. It could have been so easy for them to do (check for special keys inside a crashed application’s Info.plist and then just forward a copy of the bug log). If they had done this then there wouldn’t have been a need for SCR in the first place.

If Apple disapproves of the way Input Managers are being co-opted then they should close the loophole that allows Input Managers to run. It might be possible to provide a sort of “Input Manager Server” that all legitimate Input Managers run within. I’m sure Apple engineers could even work out a way to disable Haxies too (at least until someone works out how to bypass it).

It has been mentioned that running Input Managers like SCR or running Haxies is akin to voiding a warranty on a piece of electronics equipment. I find this attitude patronising and antithetical to the cultures of hacking and of Macintosh both. Many people want cool features added to the operating system, and there’s no doubt some of the things you can do with Haxies and Input Managers are extremely cool and non-trivial to achieve without some kind of hack. That’s just the way it is. Apple engineers cannot foresee everything a piece of third party software can do and I find it disconcerting to see that Apple engineers have gone out of their way to lock down portions of the operating system from third party developers (google for Apple menu extras). I really hope Apple doesn’t decide to try and prevent haxies and other hacks from working, it will only hurt them instead of hindering them. One of the posters to bbum’s site summed it up quite amusingly: “Mac OS X is the child of Apple’s engineers, their daughter. Nobody is good enough to date her.”

This entry was posted in Uncategorized and tagged . Bookmark the permalink.
  • Which is fine. But not necessarily the optimum behavior. It is better in my opinion if a bug report is sent immediately. (A signal handler can catch the crash immediately, iirc the guys behind MacSQL have released source code showing how to do this).
  • I would just like to point out that SCR is not needed to send crash reports to third party developers. Our product ShutterBug scans for a crash log on start up and asks the user if they would like to send a crash report back to us.

    By just checking the Library/Logs/CrashReporter directory any app can detect if a crash log exists (ie. the app crashed the last time it was run). There is no need to install an Input manager without asking permission from the user.

    All of this is stated right in Apple's developer guide -

    http://developer.apple.com/technotes/tn2004/tn2123.html

    "There is currently no way for third party developers to access the reports submitted via CrashReporter. Apple is aware that there is strong demand for such a facility (r. 3356232). Regardless, your users can still submit crash logs to you manually. Moreover, 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."
  • Well the point is who the heck knows what pre-release software can do? It could accidentally delete your home directory when all it meant to do was delete an old cache file, etc. Heck even released software can have catastrophic bugs (remember the itunes installer that coul wipe out an entire volume?)

    But it stands to reason there will be more bugs with beta software because it hasn't gone through as many test cycles as release software. (the beta test _is_ a test cycle). Honest developers (like Sandvox) are up front with that and make sure the users are aware that the software is incomplete.

    As to users not knowing what beta means - well that basically means that developers should avoid public betas because the meaning of 'beta software' has been diluted by these long term betas (such as Google news). What are you suggesting? Developers should continue the confusion by releasing bug free public betas?

    The whole Sandvox/SCR thing seems like a non-issue to me. A few vocal users have taken a mistake on the developer's part (i.e. not informing the user they were installing SCR) during the public beta of a product and a have magnified the problem out of all proportions. The software was beta, the correct response would have been to inform the developers of the bug and see if/how they plan to address the problem. Sure, if the developers showed no signs of addressing the problem then knock yourself out, blog about it.
  • Dylan
    I'm not a user of Sandvox but I stumbled across this post and found it informative. You have one sentence, however, that I have a disagreement with.

    "It amazes me that people who are so keen to see their system be as stable as possible would even dream of running beta software."

    This philosophy makes sense to me, but there's two things to keep in mind.

    First, many people might run a beta and understand that the beta itself might have problems, but typically in OS X one app shouldn't mess with other apps on the system. Yes, it's possible an app may have a bad enough bug it causes a kernel panic, which might mess up work in other applications, but generally, a beta app might crash itself while other apps remain untouched.

    Second, many users don't really know what "beta" means. Most users aren't programmers. They see something like Google News, which was in beta for ages until this week, and don't understand how it's different from the main Google page. A popular OS X application, Quicksilver, has been around also for ages and used by many people, and has not had an official 1.0 release yet.

    Now as I said, I'm not a user of Sandvox, and perhaps there are numerous warnings by the Sandvox for the innocent non-programmer user, so that they would have been well and duly informed of what was at risk. But if that is the case, then certainly there would have been a disclaimer about the installation of the SCR, and from your text it seems that was not the case.
  • Nice summary. I have been reading along with several of the bloggers' outrage and experience a mix of empathy for Karelia and agreement that the "silent install" factor is bad.

    But heck, the "silent dial home" problem is still way worse than this. I run Little Snitch and am always amazed to observe the amount of net traffic applications think they can sneak in without my concern.
blog comments powered by Disqus