Slashdot Mirror
Unsanity Developer Comes to APE's Defense
beelsebob writes "Rosyna, the famously tellytubby-like Unsanity Developer has spoken out in the defense of their Application Enhancer (APE) framework. The framework has taken a beating since it came out, being accused of being spyware, or of crashing computers. In fact Unsanity have only received one bug report about APE itself, which was promptly fixed. The article is a very good defence of the product, and a very good read."
Bob
This is the key point that Unsanity is missing. We removed trap patching (as a supported extensibility mechanism) and all the insanity that goes with it in Mac OS X for a reason. That shit destablizes everything. - a former Carbon developer at Apple
If you don't like it, don't use it. Plain and simple.
Some of us, for example, route audio from different applications to different places; when I play music or games, it comes out through my audio system and the amplified speakers - when an e-mail dings at me, it comes out through an internal speaker.
Haxies like Detour, which provide real, interesting function, which is useful for any pro-audio guy with a lot of very loud audio hardware that you don't want system beeps playing over, is fundamentally interesting - moreso if you've got more than one set of audio outputs.
So, before people go off badmouthing how awful it is, they should think twice: that same code injection technology enables everything from Shapeshifter to reskin your UI to useful functions like being able to reroute your audio away or into your pro-audio equipment on an application-by-application basis.
In other words: despite everyone's nasty opinions, it provides a useful service to those of us with unusual requirements of our systems.
-- A mind is a terrible thing.
Because the APE module attaches to every running application, if it is itself unstable, it can make all your applications unstable.
Because its not run in kernel space it can't cause a kernel panic and make the OS unstable BUT having all your apps crash out regularly fits most definitions of an unstable system.
(I'm not saying that APE modules *are* unstable, just that if one was it would cause problems)
Interesting that you should mention security, considering that so far the only APE plugin that has anything to do with the subject actually improves security.
You're arguing against a tangible increase in security (Paranoid Android) in favour of a theoretical decrease in security that no one has yet figured out how to exploit.
There is, as yet no reason to believe that APE makes your system insecure in any way, and it's hardly the sort of thing that Virus/Spyware writers could depend on being pre-installed.
So if you're suggesting that a malware author is going to use it as a road into the system internals, are you also suggesting that they are going to install APE, and then have APE register their APE module and restart every application so that the new module and APE can take effect, entirely without the user noticing?
While it's almost certainly possible that someone could exploit via APE, it seems impractical and improbable without an easy method to target APE users. Hyperbole and hysteria aside, there is really no reason for the bad rap that this very useful app has been given.
I'm not convinced that APE makes my system unstable/insecure. In my experience I've had no reduction in stability or speed, and an increase in security and convenience directly attributable to APE.
Finally, as far as security goes, there's nothing that APE can do that a sneaky application can't do; Silk and WindowShadeX were working long before APE came into being.
After all, APE is just a convenient framework for legitimate applications to access that same functionality without needing to worry whether their low level hooks are buggy or are going to interfere with other hacks that might be installed.
It's much more likely that malware would simply access those functions provided by APE directly rather than relying on the user installing some third party software.
After all, why would they limit their potential audience in that way?
Let's hope after WWDC people see the trend of less Carbon and more Cocoa that Apple is committing to, now and the long-term.
Enough already with the Cocoa fanboy stuff - if you like the API, you do neither it nor yourself any favors with this kind of post. Bits of the system are implemented in Carbon, bits are implemented in Cocoa, and neither are going away.
Apple have committed to maintaining both Carbon and Cocoa as equally valid frameworks for application development within the system - that's been the message on stage from the last 3 WWDCs, and I see no reason to think it'll be any different this year.
Nae bother
That's a pretty weak analogy - those plug-ins are plug-ins that the host application designed itself to be able to support. An app developer may not have anticipated exactly what QuickTime codecs the user was planning to install, but they're aware that the list is extensible and may change over time.
A haxie is injecting completely arbitrary code into the app, code that the app developer had no way of planning for. E.g., I call MoveWindow to move the window - and your code replaces my call with one to a FunkyMoveWindow that snaps it to some other position. Except that elsewhere in my code I assumed (quite reasonably) that MoveWindow(100,100) would do exactly what I expected it to - and wasn't anticipating it leaving the window at (30,100) instead...
Moving a window to the wrong place might not be a problem (then again, who can tell) but that level of redirection can easily get you into trouble - a haxie just doesn't know what assumptions the app code is making that it might be changing from under it. And that's not even touching on the fact that my app has no idea what your code is doing: if it scribbles over my address space and makes me crash, how am I supposed to debug something like that?
Nae bother
Badly coded apps do not make anything but themselves unstable. A badly coded module makes every program unstable.