Sandvox “hidden” feature.

I have turned off comments as it felt like things were about to turn ugly. There are other relevant posts to comment upon. Keep it on topic and no personal attacks, please. Thanks to everyone who contributed to a very interesting conversation/debate.

I was debugging a random crasher problem today and noticed that something called Smart Crash Reports appeared in the inventory of my Cocoa app’s list of frameworks and bundles.

As it turns out, Sandvox silently installs Smart Crash Report in ~/Library/Input Managers/ when it is launched. As an input manager, SCR is thusly loaded into every Cocoa app launched and subsequently uses various non-supported mechanisms to modify the behavior of said application.

Completely unacceptable. Sandvox is now gone from my system and will not return until this feature is “opt in” only.

I know that the whole Haxie thing has caused a bit of controversy in the community. I suppose I should outline my position before anyone tries to do it for me.

Bottom line: Haxies work by modifying the system to do things that it was either not designed to do or by enabling features that were disable for a reason.

I cannot afford to work with a system in such a state; neither professionally nor personally. And if I did choose to run in such a state, I would not expect to be able to receive any kind of support from the operating system vendor or any third party application vendors.

Hell, I do run iPhoto with a hack installed. I lived by FlickrExport until Aperture was released. And it uses Smart Crash Reporter. Big difference: it links directly into the app and only modifies the one application.

It doesn’t matter how brilliant the mod authors are (and the Unsanity guys are really really smart), using such a mod, in effect, voids the warranty.

If you want to run with such things, go for it.

Update 1: Sandvox definitely did not indicate that it was going to install SCR when it was first launched. It gave a standard Beta disclaimer after it had already installed SCR.

Update 2: Responding to Rosyna of Unsanity:

1. SCR is *not* a haxie. It doesn’t use APE and therefore it cannot be a haxie.

OK. Sure. I admit it. I’m not up on the vocabulary of these things entirely. Haxies screw with the system in a similar fashion as the way an Input Manager (that really isn’t an Input Manager) screws with the system.

2. It uses completely supported methods by Apple and the Objective-C runtime to do what it does.

Supported how? Input Managers, method swizzling, class posing, and categories that override existing methods are all operations that can be done via publicly declared API, but that doesn’t make modification of the runtime behavior of existing applications a supported feature.

3. Sandvox asked you if you wanted to install it. You clicked yes. And now you’re complaining because you didn’t read the dialog?

Update: As others have tested, the app does not tell the user that SCR has been installed.

That an app would install something that modifies all other apps is really bad. That it would do so again and again after I rm -rf’d the thing it installed is inexcusable.

4. It doesn’t modify all applications. It *only* changes CrashReporter.app. However, due to a limitation in InputManagers, -init is still called. However, in an application that is not the CrashReporter, SCR does nothing. See http://www.unsanity.com/support.php?vf=32 for more information.

As an Input Manager, it will be loaded by every application. In and of itself, that is enough of an intrusion for it to be unacceptable to me. Maybe not for others and, as I said in the original post, to each his own.

The mere presence of an unknown dylib shoved into the applications on my system is problematic regardless of how many instructions it executes upon load.

It also sounds as if you’re saying that developers should not have access to crash logs and that it’s perfectly ok for there to be crashing bugs in an Application without the author ever finding out. Apple won’t send the crash logs to the developer, that’s why SCR exists.

I guess I should have outlined more of my position as that is certainly not what was intended.

It would be great if there were a universal solution via which all crash logs could be shared with all relevant parties. That would be truly awesome. But that solution hasn’t been presented yet. I have no idea why though I would imagine that their are non-technical issues that may be rather significant.

Conceptually, SCR is an incredibly valuable tool. The implementation is problematic. It modifies an existing mechanism on the system for which modification is not supported. If Apple were to change crash reporter significantly in any random update, the interaction of the two could break one or the other completely.

A less intrusive solution would be a standalone implementation of a crash reporting and report delivery tool that does not work by modifying existing system behavior. It isn’t that hard to do and others have done so. Hell, I wrote just such a product many many years ago.

(comments re-enabled for now. keep it polite and technically relevant, please)



61 Responses to “Sandvox “hidden” feature.”

  1. Garrett Murray says:

    Some of my remarks were taken out of context and changed, so to Mike: You misread what I wrote. I said that it was bad, but I also said that these people downloaded beta software from Karelia and should expect BAD THINGS TO HAPPEN(TM). I said this was an overreaction, not necessarily the wrong one.

  2. bbum says:

    It doesn’t matter if the software is beta, alpha, or production. Installing something that is loaded at launch of any Cocoa app on the system (by that user) is unacceptable, regardless of how well engineered said solution is.

  3. Rosyna says:

    See, this is the problem I have. Now you’re saying that anything loading in applications is bad, even if it does nothing in that application (like SCR). Given my Photoshop example (http://www.unsanity.org/archives/000425.php), you seem to be saying Photoshop is bad as well.

    Anything that modifies the behavior of every Cocoa app on the system is the problem

    Installing something that is loaded at launch of any Cocoa app on the system (by that user) is unacceptable, regardless of how well engineered said solution is.

    I’m all for user’s having full control over their system. If a user wants to run Haxies

    You seem to be going back and forth on your stance, if I’m reading these correctly.

    And can you please elaborate on your definition of “modify” as it clearly does not seem to match the standard definition of “change” since you use it in regards to SCR and you can clearly see from the posted source code just exactly what it is doing in “any Cocoa app” which is definitely not changing anything.

    And haxies are actually probably one of the least invasive methods. The user can control exactly which applications they want to modify and APE won’t load as root, for security reasons, unlike many other methods (like SIMBL and the like).

  4. bbum says:

    It is rather simple!

    If an app installs something that is loaded into every app (or every Cocoa app) and that app doesn’t tell the user, it is bad. That is the primary issue.

    The reason why this is of concern to me is because I choose to not run a system with any modifications for both personal and professional reasons. Others may not feel the same way.

    SCR does load and execute code in every Cocoa app. This does cause change that I find problematic. Three off the top of my head:

    – it makes my system work differently than my colleagues. Then I have to waste time explaining that the mystery item in my crash report or otherwise in my debugging environment is somehow benign.

    – it ever so slightly increases the memory footprint of every Cocoa application. Not by much, but every page counts and since I am often using my machine to determine benchmarks and track performance metrics, every unaccountable variable is problematic.

    – it uses a +load method which will potentially change the order of class initialization or other framework infrastructure. While their shouldn’t be any order dependencies (there have been in the past, but I think they are fixed), it is another change that pushes my system away from working the same as my colleagues.

    As for Haxies — sure, Unsanity has put together a great product for managing them. Kudos. My understanding of haxies is that they often twiddle the system well below the high level frameworks.

    As for PhotoShop: If I’m understanding the problem correctly, they have a scripting addition that is required for CS’s operation? Just like an Input Manager, a Scripting Addition is a well supported means of extending a particular subsystem in the system. And just like an IM, an SA can easily step outside of the bounds of that particular interface’s intention and cause major hell (or it could just be written poorly and cause major hell).

  5. Rosyna says:

    bbum, I understand the problem with not telling the user. It is the application developer’s choice to tell the user they’re installing it or not. In the future, we may add a ready made dialog directly to the install API.

    1. Perhaps we should change the executable name to Smart_Crash_Reports_If_This_Is_Not_CrashReporter_SCR_Is_Unrelated_to_the_Crash. Although from experience, people will still blame it for crashes it can’t possibly have anything to do with.

    2. Uhm… ok.. that seems rather pedantic. Especially since cocoa itself does more than that. Loading AppKit massively slows down app launches and increases the memory footprint greatly. This is why the Dock doesn’t link to Cocoa, why the Finder doesn’t link to Cocoa, and also why not a single APE we make links to Cocoa (unless it targets only specific applications like iSWAD).

    3. Actually, it doesn’t have a +load method, just an -init method. Secondly, if you’re testing for bugs, then wouldn’t every single person having the *same* configuration lead to many uncaught memory smashers? What do you call those bugs that appear and disappear if the environment changes slightly? And if it’s doing that much damage, it sounds like a bug in the Objective-C runtime (which you say may be fixed)

    My understanding of haxies is that they often twiddle the system well below the high level frameworks.

    Not, really, no. We try to be as high level as possible for everything. For example, Menu Master actually installs Carbon Event Handlers on menus. The lower we go in haxies, the more we have to rewrite them for major OS X updates so we avoid them like the plague. A little effort today can save a lot of effort tomorrow.

    As for PhotoShop: If I’m understanding the problem correctly, they have a scripting addition that is required for CS’s operation? Just like an Input Manager, a Scripting Addition is a well supported means of extending a particular subsystem in the system. And just like an IM, an SA can easily step outside of the bounds of that particular interface’s intention and cause major hell (or it could just be written poorly and cause major hell).

    Yes, it installs a CFM scripting addition. And a bug somewhere causes nested functions to blow up if the CFM runtime is loaded. Nested functions are deprecated in both gcc and OS X. Yet for some reason, iSync uses them. This is not something Adobe can fix. It’s not something I can fix either. However, it is something that can be worked around, which iSWAD does until Apple fixes the bug.

    However, the Scripting Addition “suffers” from all the points you’ve mentioned above. Every single plugin does no matter the plugin API. For InputManagers, you are guaranteed that Foundation, AppKit, Carbon, and CoreFoundation are loaded before the InputManagers are even queried. So linking to any of these will not change the order of initialization or plugin loading at all. SCR links to AppKit, Foundation, and CoreServices (which is linked to by Carbon, so it is guaranteed to be there by the time InputManagers are even looked at).

  6. bbum says:

    It is kind of difficult to write a Cocoa app without the AppKit, isn’t it?

    Right — OK — -init method only because the actual loading of the Input Manager is done via supported mechanisms. Still it is a foreign piece of code modifying a system service in an unsupported fashion.

    That is about as innocuous as an unsupported hack can be. But it is still an unsupported hack. It still taints crash reports and taints my work environment. No thanks.

    As for detecting memory smashers/crasher, the tools on the system specifically for doing exactly that are far more effective than relying on random behavior. MallocPreScribble/MallocScribble, libgmalloc, zombies, etc…

    For InputManagers, you are guaranteed that Foundation, AppKit, Carbon, and CoreFoundation are loaded before the InputManagers are even queried. So linking to any of these will not change the order of initialization or plugin loading at all.

    To be pedantic: that is incorrect. While the frameworks might be loaded, all of the classes in said frameworks will not be initialized. Class initialization only happens on first reference. In SCR’s case, the only class referenced in the conditional is NSBundle and that pretty much has to be initialized prior to loading SCR.

    So, Yes, SCR is about as safe and low impact as such a product can be. Flog the horse: It is good engineering. But it is an unsupported change to system behavior. It taints my system that raises both reasonable and unreasonable questions in regards to system integrity.

  7. John Y. says:

    I’d just like to interject that Rosyna’s continued dissembling and deflection of concerns (instead of, say, addressing them) has convinced me to make sure no Unsanity products are ever installed on my machine.

  8. Bob Kerstetter says:

    Well, I was sort of impressed with the basic approach of Sandvox, but was not really crazy about their paranoia related to Apple. However, I was ramping up to work more with this product—it’s tons more flexible than iWeb—but have instead removed it. Don’t care what the reporter does or how helpful it is to the developer. In fact I would be okay with running the reporter, but I need to know about it, and what it does, even if it’s beta software. Omnigroup, for example, has had their own reporter for years. I don’t know if they still do because I haven’t had one of their apps crash in years, or at least months, :). Anyway, I have run lots of betas and the developers have always been transparent about what they install where. It’s not an over reaction to be annoyed about a stealth reporter. This is just poor policy on the part of the developer.

  9. Rosyna says:

    John Y. This is not the place to answer FAQs about Unsanity products. For those go to http://www.unsanity.com/support/

  10. From Concentrate Software says:

    […] bbum has started a minor riot concerning Sandvox’s installation of Smart Crash Reporters. To be fair, I think that bbum is genuinely trying to be a nice guy and it is the other people that posted in the comments that are tainting the discussion. Curious to me, however, is that the post was about Sandvox but the comments targeted Unsanity. […]

  11. Us vs Them says:

    […] 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 […]

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>