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. John C. Randolph says:

    Dan,

    If you’re reading this, I agree with Bill: you really need to fix this ASAP. If you must use SCR, confine it to your own app.

    -jcr

  2. Blake Seely says:

    Sandvox *did* ask me if I wanted to install SCR… at least, I’m pretty sure it did.

  3. Silent Lurker says:

    bill, i removed this app once i found out that it installed one of those dispicable haxies.

  4. Rosyna says:

    A few things:

    1. SCR is *not* a haxie. It doesn’t use APE and therefore it cannot be a haxie.
    2. It uses completely supported methods by Apple and the Objective-C runtime to do what it does.
    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?
    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.

    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.

  5. Mike says:

    Is any input manager a bad thing?

    I mean it is an officially supported mechanism to inject code into other apps that those apps don’t control. Or is this sort of like obscenity where you know it’s bad when you see it?

  6. Fraser Speirs says:

    FlickrExport will use Smart Crash Reports, but only if the user has independently installed it – it won’t modify your system. Similarly, there’s a version of the Growl framework that’s able to install Growl for those who don’t have it – FlickrExport doesn’t use that either.

  7. Ravi Khalsa says:

    Is it safe to just trash the ‘Smart Crash Reports’ folder from the Finder?

  8. Mike says:

    This is appalling. Really sneaky and horrid. I was annoyed to find out that Path Finder had done this, and I would never have known if I hadn’t read Daring Fireball. As it happens, I was unimpressed by Path Finder and removed it and it’s sneaky unsupported 3rd-party hack. I’d thought about using Sandvox, but now I shall avoid doing so. Developers should *never* do something like this without asking.

  9. matt says:

    it still does that, just downloaded the latest version, beta12, as of jan. 17th, and had emptied the folder inputManagers before.
    no questions asked, no information given :(

  10. Steve says:

    I call complete BS on “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?”

    There is NOTHING EXPLICIT in the installer regarding SCR. The EULA is generic and makes no reference to *what* is installed, outside the given understanding of the core app (even if it did, everyone knows how disingenuous it would be to use that as defense). On first launch, the app has a beta dialog, which also says nothing regarding or SCR.

    Frankly, no matter how benign SCR *might* be, it is A bad Thing™ to install *anything* on your system outside the core application bundle or sanctified directories (app supprt/prefs etc.) without explicit consent of the user.

    Poo on Karelia, they should know better.

  11. Fraser Speirs says:

    FWIW, I just checked this. I:

    - Removed the ~/Library/InputMangers/Smart Crash Reports directory.
    - defaults delete com.karelia.Sandvox
    - Downloaded a fresh copy of Sandvox and ran it.

    Here’s the text of the alert dialog I got on first-run:

    You are running Sandvox version 1.0b12, build 331.

    This is a Public Beta version and will expire on 17 February 2006.

    If you find problems, please use “Send Feedback…” under the Help menu, or email support@karelia.com.

    Since this is BETA software, DO NOT use it with critical data or for critical business functions. Please keep backups of your files and all source material. We cannot guarantee that future versions of Sandvox will be able to open sites created with this version!

    Use of this version is subject to the terms and conditions of Karelia Software’s Sandvox Beta License Agreement.

    …and it did indeed install SCR.

  12. Shawn Mole says:

    I’ll confirm what Fraser has reported: I removed every file I could find related to Sandvox and Smart Crash Reports, rebooted, and then reinstalled the software. The same dialog and no mention of SCR … and yet, SCR was re-installed without my knowledge.

    I don’t think this is an issue for Unsanity as much as it is for Karelia. I couldn’t find any mention of SCR in their documentation. However, it doesn’t speak well of Unsanity that I could find no information on their site about how to uninstall SCR, and their own uninstaller won’t remove the copy of SCR that Sandvox installed (without, presumably, installing SCR with Unsanity’s installer and then uninstalling it).

    Although the purpose here may be altruistic, this is spyware. It is being installed without the user’s express consent (or knowledge … how many end users understand what SCR is?), and it is being used to collect (admittedly not that important) data. It can, no offense intended to Unsanity, cause system instability, and the provider of the software isn’t including real support or troubleshooting instructions (ie, how to remove it).

    Spare me the argument that this app is safe and useful–I think from a customer service / support / documentation / relationship perspective, regardless of SCR’s merits, Karelia has fallen short.

  13. Nate Silva says:

    Who cares if they asked whether they could install the input manager? Bill doesn’t remember being asked and neither do I. Neither do most Windows users who “approved” the installation of spyware on their systems. I have no idea if this input manager will damage my system, but it sets a bad precedent and I don’t want to support it.

  14. Adam says:

    Is it possible to remove this Smart Crash Reports without affecting other programs? Is Smart Crash Reports something that existed before Sandvox installed it?

  15. John Gruber says:

    I can confirm Fraser’s report above — Sandvox does display a dialog upon first launch, but it says nothing about Smart Crash Reports, and offers only a single button: “OK”. Regardless of the dialog, the automatic installation of Smart Crash Reports occurs *before* you dismiss the dialog.

  16. Jon Hendry says:

    It’d be nice if developers could put ~/Library-type things in their app bundles, with the contents being scoped only to the app. So there could be a Sandvox.app/Contents/Input Managers directory, and the SCR input manager wouldn’t be loaded into any other apps.

    If I’m not mistaken, wasn’t this possible on NeXTSTEP to some extent? Perhaps it was only with things like fonts.

  17. Scott Park says:

    On the subject of developers getting crash reports without affecting other applications, Adium X uses it’s own crash reporter to send back logs. It’s unfortunate that Apple doesn’t have a method for distributing reports collected through their crash reporter. Similarly there was a lot of talk about Apple opening up Software Update to third parties, but that too is unlikely to happen.

    P.S. I found my way here from Daring Fireball.

  18. Steve says:

    Yes, there is no reason why the crash reporting could not have been bundled into the app itself, as do so many other programs. I wonder if SCR was part of their private beta seeding, and with the rush to bring Sandvox to the public on the heels of the iWeb announcement, they didn’t do due diligence on whether this would be a good thing for a wider distro.

    Kinna like Apple and the mini store…

  19. Ryan Schroeder says:

    So is standard SCR behavior? Do all the apps in this list do the same thing?

  20. Chris says:

    There is a way for a 3rd party to implement “Smart Crash Reporting” which would NOT require input managers, haxies or anything else. Write a background app which monitors /Library/Logs/CrashReporter and ~/Library/Logs/CrashReporter, parses the crash.logs when they are written and then e-mails those logs to the appropriate address for the crashed app.

  21. David Young says:

    What’s the deal with an input manager for crash reports? I’ve had crash report catchers in my apps for years without having to resort to input managers or other such “modify-everything” mechanisms.

    On a similar note, how do people feel about applications installing bundles or plugins into places that *are* supported? For example, MyGreatApp.app installs the MyGreatStuff.webplugin, which is a fully tested Safari plugin that only uses the supported Apple APIs. Still, its every existence modifies the behavior of Safari, albeit in a supported way. And it doesn’t ask, for one politcal reason or another.

    Do people think this is OK, or is this taboo also?

  22. Terrence Talbot says:

    b.bum: Sorry to catch you off-guard. In the next public version of Sandvox we’ll include an extra dialog specifically allowing the user to install — or not — SmartCrashReports.

    A number of great apps out there make use of SCR. I don’t mean to draw other developers into the controversy, but Unsanity publishes a list on their site. FlickrExport, for example, links to the same .o as we do, but doesn’t install SCR. If it’s there, fine, it uses it. If not, no crash reports go back to the developer. This is a fairly important feature for us, however, particularly during the beta period. You’re right though, we should have made its use explicitly optional.

    Putting the merits of using an InputManager aside just for a moment, SCR is actually a very nice solution in terms of “on the screen” user experience. Apps crash, and reports go out, in the “standard” way (over HTTP).

    The only other “public” crash reporter for developers is ILCrashReporter which we’ve also tried. It, too, is somewhat of a hack, killing off Apple’s CrashReporter and leaving a third process running around that didn’t always go away. (It also explicitly uses SMTP which our early beta testers found to be blocked by corporate firewalls.)

    An in-house solution would probably need to be a similar hack since some process would have to run outside the app watching for problems — just as Apple’s crashreporterd does now. Would you consider this to be unacceptable? (I think having extra processes running around, not under control of the system, has its own set of problems for the user.)

    Obviously as a user you shouldn’t have to care. As a fellow developer, however, I’d rather use this as an opportunity to push for a crash reporter that we all can use. SCR seemed to be a great step in that direction. What’s the best way to move this forward for everyone?

  23. n[ate]vw says:

    Didn’t I give Apple my e-mail adress when I registered some Application Creator Codes? What’s keeping them from sending crash reports to me via that?

  24. Stephen Deken says:

    There is a way for a 3rd party to implement “Smart Crash Reporting” which would NOT require input managers, haxies or anything else. …

    This solution would not present the end user with the option to send the report to Apple or Apple and the developers of the application. It would either have to present its own UI (leading to two popups on each crash) or silently do something without the user’s explicit consent. The InputManager hack, however bizarre from a development point of view, is a cleaner solution for the end user.

  25. Pepe Lopez says:

    I was suprised recently when Cyberduck crashed and I had the ability to submit the report to Apple, Cyberduck, or both… Is this SCR in action? I have noticed in subsequent crashes of other apps that it doesn’t alwatys come up (but I don’t know how to crash cyberduck in order to verify that it always does there…)

    I’ll be OK with SCR if it is App-specific, and I can have the option to disable it at install or via preference – in each app. But if is a global mod, even when only used by one app – I don’t wan it.

    -Pepe

  26. Garrett Murray says:

    Some of the reactions in this thread are melodramatic. I understand where Karelia is coming from with this–especially in a beta. The final product should do what most other SCR-using apps do, which is use SCR only if it’s there.

    I also agree that there needs to be a standard CR for independent developers to use, and so far Unsanity’s seems to be the best option.

    Yes, apps shouldn’t silently install other apps, especially if they can affect your whole system. But still, we’re talking beta here and we’re talking about two trustworthy companies–I think this is a gross overreaction. I’m sure there are people who will respond saying that Unsanity isn’t trustworthy, but I’m going to disagree strongly with that. I use and have been using several Unsanity haxies for years and I stand by them not only because they make my life easier, but because they’re well done and I’ve never had ANY issues with them.

    The whole anti-haxie thing is ridiculous. If you don’t want to use a haxie, don’t install it, but being anti-haxie is asinine.

  27. John Y. says:

    The whole anti-haxie thing is ridiculous. If you don’t want to use a haxie, don’t install it, but being anti-haxie is asinine.

    I’d like to not install it, but Karelia hasn’t given a choice here, have they?

    I’m not even going to address the rest of the nonsense you spouted off.

  28. bbum says:

    Garrett’s response is correct; the reactions can be and have been melodramatic.

    However, some corrections.

    (1) There is no reason why a crash reporting mechanism has to work by either modifying or replacing the Apple supplied crash reporting mechanism. There are many ways to avoid doing that.

    (2) That Sandvox is beta gives absolutely zero justification for Sandvox silently installing something that can impact every single other application.

    (3) I agree that “anti-haxie” is asinine. It is a personal choice or professional requirement. That is, I personally choose to not use haxies because I have seen many problems related to them over the years and because I cannot afford to have any more variables in my computing environment. Professionally, I choose not to use them because I’m often running odd configurations or need to qualify a product in a supported configuration.

    Finally, everything I have seen from Unsanity on an engineering front has been top notch in quality. They work very very hard to ensure that their products don’t blow up your system. Kudos. However, haxies are specifically created to make the system do things that it was not designed to do or to enable features that were likely disabled for a technical reason.

  29. Claus Broch says:

    I think most of the responses to this topic are missing the real problem: Developers need to get detailed information if their application crashes. Otherwise it is very difficult to fix these bugs and prevent further crashes.
    I am one of the developers of a large application for the professional market as well as on a few shareware applications. For professional applications it is expected that these are rock solid since they are often used for mission critical tasks. For shareware developers it is more often the danger of being bogged down with too many support mails so you can’t focus on the software development. Both of these scenarios both required immediate action if some major bug is suddenly sticking it’s head out and crashing your application otherwise the problems will simply grow over your head. I’ve been trying to convince Apple on a number of occasions that it is important for developers to get access to the crash reports users have submitted.
    Apple has even published a about one and a half year ago acknowledging this need – but nothing has happened so far. This lead me to develop so I and other developers could get access to these from their own applications. By popular demand I decided at some point to release the source code so anybody could see there was no secret backdoors hidden in it. Of course it was also in the hope that somebody would contribute bug fixes and improvements – and a few have already that you.
    But what this has proven to me is that there is a huge demand for this. Both by the developers as well as the users. Both wants the applications to be free of bugs.
    So in my opinion we should instead focus our joint powers and convince Apple to provide this information to the developers. That is the only way we can prevent these hacks. Because they are hacks.

    Edited: I just fixed the links to not spam 2/3rds of the article. No content changes.

  30. Rosyna says:

    bbum, have you actually seen real problems with haxies or are have you just read about problems with haxies from other people? Other people that may have been melodramatic as well and just repeated what others said?

    I ask because you say (and have said since 2002, the last email I have from you on the subject) that you refuse to install haxies.

    Granted, as with any software, you should always stay up to date.

  31. bbum says:

    I have seen very real problems related to Haxies (and haxie like software). Obviously, not in a long time because I haven’t installed haxies in a long time. Some of the problems had to do with the interaction between the haxie and other software that I was testing; it may very well have been a bug in the targeted test software, but the presence of the haxie made it impossible for others to diagnose without trying to duplicate my configuration and, thus, moving well away from a “supported” system configuration.

    I’m familiar with the whole echo effect going on here and am trying hard not to perpetuate it. In particular, I don’t think I saw any actual systemic badness caused by Smart Crash Reporter. The reason why I took offense at its presence has more to do with Sandvox’s failure to notify me of installation and that presence of SCR makes every crash report my machine generates suspect.

    As a user, if you don’t have a requirement to run with a supported system configuration and you want to use Haxies, go for it. They do some cool stuff.

  32. Shawn Mole says:

    I don’t think the major issue here is the usefulness of SCR or other haxies or system instability or what not. Yes, SCR fills a hole on the Mac. Yes, many people don’t wan to or can’t operate with system modifications.

    Given that SCR is both useful (to some) and unwanted (by some), I do not think it is melodramatic to expect software developers to explain what they are installing and to provide documentation (or a script) to undo that installation. The issue here, I think, is that Karelia thought SCR was common enough that they didn’t need to notify users they were installing it–clearly all users didn’t want the choice to use SCR made for them.

    A simple dialog would have sufficed: “To help us develop this software, we’d like to install Smart Crash Reporter (SCR), which will allow you to notify both us and Apple if Sandvox crashes for some reason. SCR has become a standard for many other applications (link to Unsanity’s page), but it does modify OS X’s own Crash Reporter. If you needed to remove it or disable it to troubleshoot a problem on your computer, it resides in ~/Library/Input Managers. May Sandvox install SCR to help Karelia’s development team?.”

    Surreptitiously installing software for the user–no matter how benevolent–is just plain bad all around. Explain what’s what, tell me where to get more information, and give me the option to opt out, and we’re good to go. Given that Sandvox is such a lovely, well thought out public beta from a source as trusted as Karelia, I’m surprised that a dialog wasn’t there. But that’s what betas are for, and I’m glad they’ll add the dialog in the next version.

  33. John C. Randolph says:

    Rosyna,

    Speaking as the person who took all the Cocoa DTS incidents for about a year, I will go on the record as saying that haxies were a very bad idea from the beginning, and I hope that Apple is investigating ways to render them impossible altogether. Sure, they’re a clever hack, but you don’t know, and CAN’T know how they will behave with every app that they might affect. They are an intrinsically destabilizing factor.

    There’s a reason why Apple got rid of the init mess from the old Mac OS, and as proud as you may be of your cleverness in bringing it back, it is nevertheless something that Apple should not only refuse to support, but work to prohibit.

    -jcr

  34. Philippe says:

    As a developer for a major commercial/professional application who pushed for SCR integration, let me tell you that it’s great for developers and users.

    No matter what we tried, we could not get crash reports sent to Apple (unlike Minidumps from Microsoft). We could have used our own Crash Reporter, but it would have taken a significant amount of time to engineer (and would have diverted resources from other, more important features).

    The SCR gives our users a seamless experience, identical (save an extra button) to a regular crash report. It only modifies CrashReporter.app, which to us is the best solution. And we get really good crash reports.

    About asking the user: how would you feel if this app you just bought for (say) 500$ told you up front: “I could crash”. That would shake your confidence a lot more than looking at ~/Library/InputManagers.

    Developers know their app can crash (and they often know how to crash it). Users kinda know, but it’s in their subconscious and doesn’t surface until they are confronted with an actual crash. Our testing shows that at that point, they are much more willing to help than when faced with a hypothetical crash. And we can fix the problem!

    So, crash reports are good. And SCR is the best solution out there. What do you propose we use, if not SCR? We’re looking for constructive criticism, not paranoia and FUD.

  35. Paul Reading says:

    I agree with the sentiments of this thread. I have watched time after time when Apple releases a point update and many people with haxies report all sorts of problems with the updates. So it is a matter of policy not to install them for me, and I am quite cross to find that this i exactly what has happened. How do I delete this thing?

  36. Rosyna says:

    Paul Reading, *please* pay attention. SCR is not a haxie. Two, there hasn’t been a single OS X point update that has broken a haxie yet. For major system updates, APE automatically disables itself.

    jcr, this is why SCR was created. People like you at Apple repeatedly said this. Yet when we asked for crash reports we were given the cold shoulder, yet you still spouted off about these “imaginary” crashes. When we actually confronted a specific Apple employee that repeatedly said this (in public) it turns out it wasn’t a haxie at all, but some third party Safari and Mail.app plugins that don’t even use APE nor did the users have APE installed. It was a case of employees at Apple blaming a company for a problem that wasn’t associated with them at all. And there is absolutely no reason to believe your claims aren’t the same as I don’t have a single email from you or correspondence from you about a single incompatibility issue with APE.

  37. Nate Silva says:

    Come on, Rosyna, quit playing word games. I am not opposed to the idea of APE, haxies, SCR, or whatever. I just would like to know, and have an option, when installing things that modify system-wide behavior.

    With your attitude of pretending that is not a real concern, just because Paul doesn’t know your company’s jargon, it makes me less likely to want to install such things. How does one remove SCR? Delete it from the Library and reboot?

  38. John C. Randolph says:

    “Yet when we asked for crash reports we were given the cold shoulder”

    The way I would state that is, when you asked for proprietary information which Apple has a duty to keep confidential, because it belongs to parties other than Apple, your request was of course denied.

    Like I’ve said before, I WISH I could have handed you all the Radars that showed the damage that your cleverness was inflicting on the rest of my developers, so you’d get off your high horse. Unfortunately, that wasn’t possible for legal reasons.

    -jcr

  39. John C. Randolph says:

    ” there is absolutely no reason to believe your claims ”

    I simply can’t imagine caring whether you believe me. It’s just too much of a stretch.

    “I don’t have a single email from you or correspondence from you about a single incompatibility issue with APE.”

    Of course you don’t. APE is unsupported, it will never BE supported, and when a developer ran into a compatibility issue with it, I advised them to check for the presence of your hack, and exit if it was detected.

    If you had filed a DTS incident looking for help with making APE work, I’d have rejected it immediately. I hope that my successor in DTS would do likewise.

    -jcr

  40. Quentin says:

    Good ol’ Apple, always willing to help a third party developer out…

    Oh wait…

  41. John C. Randolph says:

    Quentin,

    I know you think you’re being funny, but Apple is not going to help a third-party developer render the system unstable. If you have an issue with that, then please become a Windows developer. In that world, stability has never been anything more than wishful thinking.

    -jcr

  42. Mike says:

    Garrett Murray: “… we’re talking about two trustworthy companies … I’m sure there are people who will [disagree] but I’m going to disagree strongly with that”

    So, in other words, Garrett Murray considers that whether it is acceptable for someone to silently install software on someone else’s system depends on whether the company/ies involved are “trustworthy”. Further, “trustworthy” is to understood as “considered trustworthy by Garrett Murray” since he explicitly says that he brooks no disagreement.

    So, the user is to have no control over his own property, because how it is used is to depend on Garrett Murray’s opinions. Who on earth does he think he is?

    This man clearly has no conception of inviduals’ having the right to make their own judgments and carry out their own decisions – general principles that I should have thought anyone living in a liberal-democratic society should be aware of in many contexts.

    But it’s good, after all, to have the underlying rationale spelt out so clearly for us. This is the issue that Karelia missed and that the response from Terence Talbot totally fails to address.

  43. David says:

    You know, I wonder if had Karelia developed their own modification to the crash reporter to do this, rather than using Unsanity’s Crashreporter, if we would even be seeing this post. Even if it was buggier (because they didn’t do as much testing, with as much software) or if it did the modification in a way that made the modification even worse? I think that most of the objection is from the fact that they decided to use software from Unsanity to do the work, software that has been tested and retested, but which so many seem to object to because of some of the other things that Unsanity produces.

    Frankly, no one has shown that the methods that SCR uses has caused a crash, they simply have objected to it because of it’s existence on their system. I’ve seen nothing that points that SCR has caused anyone a problem.

  44. bbum says:

    It wouldn’t matter if Karelia rolled their own solution or used a different third party solution. Anything that modifies the behavior of every Cocoa app on the system is the problem and Karelia — and any other company that released a product that did something similar — would receive the same ire.

    As I have said numerous times, Unsanity’s haxies and Smart Crash Reporter (yes, two very different things) are very well engineered. Regardless of how well engineered, they use non-supported mechanisms to modify system behavior. Therein lies the problem. Haxies have definitely caused many problems, typically in conjunction with Apple software updates. Unsanity is always quick to resolve said problems, but there have been many an angry and negative comment directed at Apple or third parties as a result of a Haxie conflict.

    Smart Crash Reporter has not caused any problems that I have noted. That it has not goes back to good engineering on Unsanity’s part. However, it does show up in every Cocoa app’s crash report and it does modify the system in a way that Apple does not support. As an engineer (and engineering manager) that has to qualify products for the Macintosh, I cannot do my job on a system modified in such a fashion.

    So, yes, the existence of SCR on my system without my permission is exactly what I was objected to.

  45. Rosyna says:

    bbum, do you feel the same way about Adobe Photoshop CS2? Which installs something that also “modifies” every application? Modify using your definition of existing in the same memory space as another application, neither SCR nor this Adobe thing actually changes anything inside the application, but they both show up in crash reports. In fact, due to a bug in OS X that iSync triggers, having this Adobe installed piece of software causes iSync to crash if you try to sync. It’s been reported to Apple, it has not been fixed by Apple. However, I wrote and released a piece of software that works around it until Apple can fix it (it’s less than a five minute fix for Apple to do). What do you say about those kinds of cases?

  46. Rosyna says:

    Err, I meant to also ask that in that situation, would you say that Apple does not support anyone that has Adobe Photoshop CS installed? (It will not function without this installed piece of software that “modifies” every application).

  47. bbum says:

    Should Apple support the customer? I would bet that one of the first questions would be to see if the problem can be reproduced after uninstalling said application or disabling said feature.

    Stuffit Expander also installs a kernel extension that modifies the Finder, IIRC. It was causing a lot of crashes and was a complete pain for a while.

    There are already enough problems with plugins that are using supported API. Even Mike’s Text Extras — an Input Manager solely focused on the NSText subsystem — causes problems. Some of it is related to the menubar editing, but some is caused directly by the NSTextView behavior changes.

    I’m all for user’s having full control over their system. If a user wants to run Haxies — the most invasive of the various mods that I have seen — then go for it! Have a blast! Make your Mac do whatever the heck you want! All of this has motivated me to browse Unsanity’s site and I might invade an iMac I have laying around.

    The key is disclosure. If your app is going to modify all other apps, even if it is only because the mechanism for doing so doesn’t prevent specific app targeting, then tell the user and let them decide.

    I would also like to see Unsanity’s products automatically disable themselves after the installation of a system update, popping a dialog saying “hey, the system has been updated, better check the [support forums] to see if anything exploded. [click here] to re-enable.”. That would save Apple a lot of grief.

  48. Jonathan Wight says:

    Curious, Rosyna – what does Adobe Photoshop install that modifies every application?

  49. Rosyna says:

    Stuffit Expander never installed a kernel extension. Stuffit Deluxe 8.0 did, but that was quickly remedied in 8.0.1 after we at Unsanity complained loudly and greatly about it. See http://www.unsanity.org/archives/000253.php for more information. They understood their mistake and resolved it quickly.

    The key is disclosure. If your app is going to modify all other apps, even if it is only because the mechanism for doing so doesn’t prevent specific app targeting, then tell the user and let them decide.”

    How does this apply to the Adobe situation?

    I would also like to see Unsanity’s products automatically disable themselves after the installation of a system update, popping a dialog saying “hey, the system has been updated, better check the [support forums] to see if anything exploded. [click here] to re-enable.”. That would save Apple a lot of grief.

    Uhm, it does. Has since before 10.3 was released. The specific error message is:

    “This is the first time Application Enhancer has been run under Mac OS X 10.3 Panther. In order to keep your Mac OS experience as problem free as possible some modules were disabled. You are free to re-enable the modules, but first please check the Unsanity website (www.unsanity.com) to check if there is an update available. Please find more information on which modules were disabled in the file \”Application Enhancer Disabled Modules.rtf\” on your Desktop. Thank you for understanding!”

    With the version of OS X changed depending on the version the user just updated to.

    Also, there has never been a point update (say from 10.3.1 to 10.3.2) that has caused any problems with haxies whatsoever. In fact, many of the system updates have fixed bugs we’ve found in OS X.

  50. bbum says:

    Cool. Thanks for the information. And I’ll say it again — Unsanity’s stuff is very well engineered.

    And thanks for filing bugs that you find!

  51. 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.

  52. 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.

  53. 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).

  54. 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).

  55. 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).

  56. 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.

  57. 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.

  58. 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.

  59. Rosyna says:

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

  60. 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. [...]

  61. 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=""> <strike> <strong>