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

Comments

Extensions for Mac OS X

[ahknight]

All APE does is recreate the problematic Extensions architecture of Mac OS 9 with Mac OS X. You know, that architecture we wanted to get away from....

It inserts code into every running program. Blindly. This is somehow defendable on any level?

Re:Extensions for Mac OS X

[beelsebob]

Hmmm... check one for didn't RTFA, if you'd read it you would realise that rosyna refutes that claim in there!

Bob

Re:Extensions for Mac OS X

[falcon5768]

well we are not all tech geniuses.....

course it doesnt take one to see that this in no way recreates the extention problem

Re:Extensions for Mac OS X

[ahknight]

Refutes? Oh, you mean because now it takes down applications and not the system.

Oh. Better.

No.

Re:Extensions for Mac OS X

[beelsebob]

Well, yes, one application going down is better than the system going down. Or are you going to argue that we shouldn't have protected memory, because all that stops is application crashes taking the system down.

If you install a buggy application on your system, then it crashes, and you likely loose work. How is this different to if you install a buggy APE module on your system, then it crashes, and you likely loose work.

Bob

Re:Extensions for Mac OS X

[ahknight]

Because one buggy APE module will possibly kill all programs (one at a time) rather than the whole.

I mean, really, anything that makes the computer, at any level, unstable is not worth using.

Re:Extensions for Mac OS X

[beelsebob]

That's correct, anything that makes your computer unstable is not worth using - APE does not make your computer unstable. Badly coded APE modules do, in the same way as badly coded apps do.

Bob

Re:Extensions for Mac OS X

[MoneyT]

I mean, really, anything that makes the computer, at any level, unstable is not worth using.

So can I take this to mean the only thing you're running on your computer is a hand coded BIOS that you have personaly coded to ensure that there is no possible way it could cause a crash?

Re:Extensions for Mac OS X

[ahknight]

Don't be an idiot. I do not run programs that modify other programs on the fly, which is what this does.

Re:Extensions for Mac OS X

[Rosyna]

Since you didn't read the article, I am assuming that you don't run any Input Managers, QuickTime Codecs, Contextual Menu Modules, or Internet Plugins?

No flash in Safari for you?

Re:Extensions for Mac OS X

[MoneyT]

So you run no plugins? No flash, no java? No frameworks at all?

Re:Extensions for Mac OS X

[moof1138]

Hmmm... check one for didn't read the key point of the parent post: "it inserts code into every running program. Blindly."

That is the point that Rosyna didn't touch in his article. He just pretends that since it is the particular module's code that is injected and not APE Framework that this is somehow okay. If you think it is acceptable to let essentially arbitrary code be injected into every running application, that is your business, but critics are right to point out that it is a security nightmare, and it will destabilize all apps on the system by design.

Rosyna pretended that since there was one bug filed against the APE framework that this means that it would not destabilize apps. But no apps were not designed to have additional code injected into them via APE, and most were generally not tested in that environment. The behavior of the framework is the issue not the fact that the framework and daemon itself are stable.

Re:Extensions for Mac OS X

[ahknight]

I did read the article, actually. A bit before it hit Slashdot, as a matter of fact. His analogy is rather incorrect on that mark. QuickTime does not insert code into every program that runs, regardless of what it does. A buggy codec can't take down every program, even if it does not use QuickTime. APE modules can because they are blindly inserted into any program you don't explicity exclude.

So while the module types listed are indeed external pieces of code that can cause a crash, they don't run in every program you run. Things like Shapeshifter or Ice Coffee do (screw camel-caps).

Re:Extensions for Mac OS X

[ahknight]

I said modify programs ON THE FLY . Flash is a plugin, not a piece of code that modifies how every program runs.

Re:Extensions for Mac OS X

[moof1138]

It is pretty poor analogy to compare APE to QT Codecs or Internet Plugins. Their behavior is for the app to dynamically load and run their code when needed, and they will not be loaded unless they are called. When I launch TextEdit there is no DivX or Flash code loaded into TextEdit's memory space. APE inserts code into all running apps. That is quite different.

Input Managers are a better analogy, and honestly I do not install 3rd party Input Manager since I understand their behavior.

I don't know enough about CMMs to comment.

Re:Extensions for Mac OS X

[LorenTB]

Input Managers are a better analogy, and honestly I do not install 3rd party Input Manager since I understand their behavior.

Well, you should give this one a shot: http://www.bitart.com/CocoaGestures.html Never once caused any problems of any kind. Solid as a rock, and incredibly useful.

Re:Extensions for Mac OS X

[moof1138]

Interesting that you bring up protected memory. In a way APE defeats the purpose of protected memory since it injects code into every running application. Here is the scary part about what that means - once someone has APE running all haxies can poke around anywhere they want in any running apps memory space, so they can know every application password used, they can read anything out of your keychain that an app is allowed to read prompting you on behalf of the app for the keychain password, and so on. APE is a serious security nightmare. I have no reason to think that this has been exploited as yet, but installing APE opens the door for the abuse, especially if you are running closed-source haxies.

While there are no known cases of APE based spyware at this point, APE could potentially be exploited a very effective vector for spyware (and viruses).

Re:Extensions for Mac OS X

[Elwood P Dowd]

That's correct, anything that makes your computer unstable is not worth using - APE does not make your computer unstable. Badly coded APE modules do, in the same way as badly coded apps do.

I don't understand. I don't use APE, and I don't have a horse in this race. What you are saying doesn't make any sense: No, a badly coded application will not make my computer unstable unless something is horribly wrong. Why would a badly coded APE module make my computer unstable? How can that be acceptable?

Re:Extensions for Mac OS X

[Anonymous Coward]

Sigh, this is the idiotic kind of posting that the author was trying to defend against. People that don't realize you can do this stuff with A QUICKTIME COMPONENT. How do I know? I HAVE DONE IT!

Re:Extensions for Mac OS X

[Anonymous Coward]

You'd still have to install that QT component, and I have trouble believing it could access the memory of apps that don't make use of the QT framework. Personally, I wouldn't install APE or the unholy QT component of which you speak...

Re:Extensions for Mac OS X

[bygimis]

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)

Re:Extensions for Mac OS X

[rixstep]

critics are right to point out that it is a security nightmare, and it will destabilize all apps on the system by design

This is correct. Some people know the Mac, but few people know Unix. Ken Thompson, one of the fathers of Unix, said emphatically:

Keep your hands off the drivers.

The whole idea of Unix is not only security but respect - a respect that enhances security.

The very thought that code in a 32-bit protected mode system would be able to do things like this - correct me if I am wrong, but APEs require your administrator password, right? That means that even though they are 3rd party code they want to go where they have no right going.

APEs and everything like them depend on 'hacks' as their name implies. They're going to break easily as what they're doing is not officially supported by the operating system, and yes they are dangerous.

I would also like to cite a few pieces of the Unsanity article.

It is installed in /Library/Frameworks/ like a good framework should be.

This is patently not true. Good frameworks should be installed in ~/Library/Frameworks, your own directory. The directory Unsanity chooses automatically affects all users on the same machine.

Another directory exploited is /Library/Application Enhancers - again, this is an area which affects all users on the same machine. The fact that Unsanity use daemons also points to all users being affected by what one user wishes to do, and preferably in user mode.

One of my favourites is:

Since Apple does not provide a way (other than with kernel extensions) to change the behaviour of different applications, we had to engineer one on our own.

Oh wow. Perhaps - just perhaps - Apple did not provide this for security reasons? And comparing an APE with gdb is just silly: gdb is meant to be used in testing, not on secure stable end user machines.

I also note the following:

They do not break down the barriers of protected memory.

Ah - let me just say that without a more technically substantial run-through, most of us are going to remain unconvinced. And it's fairly obvious, at any rate, that barriers somewhere are being broken down.

Finally, I don't think APEs are spyware, but I get what the complainers are going on about: they feel uneasy because they know there's something 'illicit' going on in their systems.

Remember what Ken Thompson said. Unix didn't get so far and do so well because Bell Labs specialised in application enhancers. Keep your hands off the drivers, and keep your hands off software that won't keep its hands to itself.

If the software isn't coming from Apple and still wants your administrator password, reject it. That software has no business going into areas of your disk where it doesn't belong. That is your security involved.

A good example of what can happen is Interarchy. It wants your adminstrator password and then leaves about 1.5 MB of junk in areas even you can't ordinarily get to, and all without telling you. That's what these freaks find tantamount to 'spyware': 'illicit' things going on in your machine, without your express approval.

If you can't make the operating system work better, write to the vendor (Apple). Don't do anything yourself. If you want apps on top of the operating system, fine - just play by the rules.

I suspect the Unsanity programmers are very good at what they do, but what they're doing is definitely not Unix. Not even close.

Re:Extensions for Mac OS X

[rixstep]

I believe you, and I can't believe Apple would let this happen. We have - or are supposed to have - totally secure 32-bit virtual memory systems here. The actual memory addresses used by one application are supposed to be irrelevant to any other - and most importantly: only the kernel is to be able to execute privileged operations which allow you to get to either physical memory or the system itself.

Knowing Unix as we do, we know this is impossible unless:

1. The application has installed something in system territory; and

2. The installer has had root access, even through being a member of the 'admininstrators' group.

If you can 'root' a Unix box, you can get at anything. But I suspect most APE users are not really sensitised to what they're giving away when they install an APE. They've basically opened the front door and thrown away the key.

Re:Extensions for Mac OS X

[Anonymous Coward]

... Yet another moron who doesn't understand security. At this rate the Mac will be the most exploited and virus-damaged computer within a year.

Re:Extensions for Mac OS X

[rixstep]

Because the APE module attaches to every running application, if it is itself unstable, it can make all your applications unstable.

I'm glad Ken Thompson is still alive, because if he wasn't, he'd roll over in his grave if he heard that.

Re:Extensions for Mac OS X

[steeviant]

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?

Re:Extensions for Mac OS X

[Anonymous Coward]

Parent is NOT flamebait, and the moron mod who marked it so should be shot and tortured slowly to death.

How can Slashdot have such bleating morons doing their modding?

Re:Extensions for Mac OS X

[Anonymous Coward]

course it doesnt take one to see that this in no way recreates the extention problem

Wow. You must really be a genius then, because that's exactly what it does, shit-for-brains.

And it's spelled 'extension'.

How did your mother ever afford buying you a Mac on two johns a night?

Re:Extensions for Mac OS X

[MoneyT]

Er, the only reason it would want you Administrator password is if you tried to install APE to /Library/Frameworks or a module to /Library/Application Enhancers.

Both APE and the modules allow you to choose whether you install localy or for all users on the machine.

Re:Extensions for Mac OS X

[GlobalEcho]

A buggy codec can't take down every program, even if it does not use QuickTime.

True, though from personal experience I can tell you that a buggy codec can make your machine pretty much unusable. There was a version of DivX that was buggy on dual-processor G4's after a QuickTime upgrade. This made it completely impossible to run Finder, and hence to launch any other apps.

That sucked. Thank goodness for a second machine and a running ssh daemon. I finally got backtraces and figured out the problem.

Re:Extensions for Mac OS X

[Textbook Error]

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?

Re:Extensions for Mac OS X

[Anm]

You don't understand. APE doesn't have access to physical memory nor the 'system' itself. By system, I mean operating system/kernel. APE uses the same user level techniques as debuggers. You know, break, step, continue...

This isn't strictly inserting new code, but does give allow an outside APE module to act like it was called from another piece of code: a code break pauses and notifies APE which calls an APE module and then returns control to the original module. I would guess one could also do variable introspection, but I assume this is harder without debugging markers.

It is perfectly possible to do this sort of thing on other Unixes.

Does this have potential to break things? Yes.
Does it break often between versions of code being hooked? Yes.
Is there potential for spyware? Yes.
Has anyone shown any evidence of problems from the standard licensed releases on the appropriate platforms/versions (i.e., non-development versions)? Not to my knowledge.

Anm

Re:Extensions for Mac OS X

[lullabud]

I'd be wary of a hand-coded bios running on a Mac, but even if it were *perfect* it would be susceptible to EMI. No, the only way to make sure your computer is stable is to turn it off and place it flat on the floor.

Re:Extensions for Mac OS X

[moof1138]

While Paranoid Android can increase security, so can RCDefaults which has the added benefit of being very unobtrusive.

I was very clear that my points were entirely theoretical and that I had no reason to believe that there were any current security issues with APE/APE modules. I don't think Unsanity is shipping their software with malicious intent.

But you make one point that is entirely false that I have to address:
"as far as security goes, there's nothing that APE can do that a sneaky application can't do"

That is true in a sense that a malicious app could do the same thing that APE does, though it would be complicated to get all those pieces set up. The thing that APE provides a convenient framework for that. What most apps can't do is to look around in any user's running app's memory space and do whatever it wants with what it finds. Normal apps can't go poking around in another app's memory space at all. APE lets you write code to do that and a malicious coder could use this for lots and lots of bad things.

I don't think it is too likely to be exploited since there aren't a lot of systems out there running APE. But the very fact that when installing APE one is installing a program that opens yourself up to that degree of a serious sercurity hole makes it untenable. Expecially when installing a haxie doesn't require much work, and is easy to hide for a clever developer, so it would be easy to exploit. APE make a complicated and difficult exploit requiring root prive really easy to run in user space.

It is analogous to creating a new app that runs as a daemon to do some cool peer to peer file sharing thing you really like, though it also allows remote users to run any commands on your system with no authentication. Even if you really like what the app does, the app is uncommon, and only runs on an obscure platform, it is still insecure by design.

Re:Extensions for Mac OS X

[Anonymous Coward]

anything that makes the computer, at any level, unstable is not worth using.

True, but I counter the instability by sticking a folded napkin under one of the corners. So far so good!

Re:Extensions for Mac OS X

[Paradise Pete]

Badly coded APE modules do, in the same way as badly coded apps do.

Badly coded apps do not make anything but themselves unstable. A badly coded module makes every program unstable.

Re:Extensions for Mac OS X

[steeviant]

"But you make one point that is entirely false that I have to address:

"as far as security goes, there's nothing that APE can do that a sneaky application can't do"

That is true in a sense that a malicious app could do the same thing that APE does, though it would be complicated to get all those pieces set up. The thing that APE provides a convenient framework for that. What most apps can't do is to look around in any user's running app's memory space and do whatever it wants with what it finds. Normal apps can't go poking around in another app's memory space at all. APE lets you write code to do that and a malicious coder could use this for lots and lots of bad things."

What I said is clearly true, both Silk and WindowShadeX, did exactly what you talk about without the APE framework, long before it was invented. It's been proven possible, nothing to see here, move along.

"It is analogous to creating a new app that runs as a daemon to do some cool peer to peer file sharing thing you really like, though it also allows remote users to run any commands on your system with no authentication. Even if you really like what the app does, the app is uncommon, and only runs on an obscure platform, it is still insecure by design."

No, that would be something which allows people to remotely run commands, APE has never been accused of anything like that. In fact, with Paranoid Android it does the exact opposite of what you just talked about.

A more valid analogy might be something like lookupd which serves a useful purpose but can in the event of a local compromise be used to modify the behaviour of applications so that they can perform malicious tasks.

Lookupd doesn't even need to inject code into programs to perform evil, should I be more or less scared because of that fact? The OS X/NeXT pasteboard server can inject characters into the input buffer of any running application, that's also pretty scary.

I'm sure if I sit here thinking about all the applications on my system I can come up with all sorts of paranoid theoretical fantasies about ways in which applications on my machine could be compromised.

The fact remains that if someone can get a piece of malware onto my system it's too late whether I have APE installed or not, and it's been proven by the unsanity hacks written before APE came into being that it's possible to inject code into running applications without APE's presence.

Neither APE nor any other method seem to be able to inject new modules into running applications without restarting them, so there's no advantage to using it for malware. Plus APE always brings up it's preference pane when it registers a new module, further decreasing the chance that someone is likely to use it for malware.

I'm not trying to argue that APE is inherently safe, but that it's not in any way equivalent to opening the door and throwing away the key to your computer. That's bullshit. All of the methods of exploiting it that you've mentioned would require a local compromise anyway. Which would be disastrous since my only Mac is a laptop, so the offender could simply walk off with it.

Finally, RCDefaultApp doesn't solve the problem of registering arbitrary URL handlers, leaving you possibly exposed to the worst variant of the latest bunch of security risks. The only way to protect yourself against that is to use Paranoid Android. Ironic that you're promoting security as a reason for remaining insecure.

FWIW, I use both RCDefaultApp and Paranoid Android, because the combination of both apps provides both proactive and reactive security should my disabling of protocol handlers turn out not to be enough. I recommend that everyone else do the same at least until Apple fix the problem properly.

Re:Extensions for Mac OS X

[MirokuHotei]

"That is true in a sense that a malicious app could do the same thing that APE does, though it would be complicated to get all those pieces set up. The thing that APE provides a convenient framework for that. What most apps can't do is to look around in any user's running app's memory space and do whatever it wants with what it finds. Normal apps can't go poking around in another app's memory space at all. APE lets you write code to do that and a malicious coder could use this for lots and lots of bad things." You ever hear of mach_inject? http://rentzsch.com/mach_inject/

Re:Extensions for Mac OS X

[moof1138]

I haven't, though I would be interested to see what it does. Unfortunately I think you misspelled that URL since I can't resolve rentzsch.com.

Re:Extensions for Mac OS X

[moof1138]

I tried to install WindowShadeX to see if it required root privileges to install. It turns out it requires APE...
I then tried to install Silk. It turns out it requires APE... I expect that in earlier versions they were standalone apps and required root privileges to install. A Haxie can be installed without root privileges which is one of the problems with it, as I have pointed out previously.

RCDefaultApp alone can protect you from the exploits as described, which I have verified. While Paranoid Android might in theory afford some extra level of protection in some respect, it is not needed to protect against the current exploits as they are described.

My analogy was not perfect, but it is not analogous to lookupd either since that requires root privileges to exploit while an APE based exploit would not. OTOH a malicious Haxie could be used to elevate privileges.

I think that APE has a pooor design security wise. That is really all I have been saying. Theoretically it could serve as a vector for malware. Exploits that took advantage of it would most likely be trojans that sneak in a malicious haxie. In the same way that spyware installed on Win boxes comes from many and various sources, often from installers of other products, many of those same methods could be used to install a Haxie. It isn't being done, but that doesn't mean it can't be done.

Malicious Haxies are theoretical, but then again there are no known malicious exploits in the wild against the URL handler that you installed two apps to protect yourself against. Good security is about protecting yourself from theoretical exploits before they are actual exploits. If you like the benefits of APE enough to leave that theoretical hole open that is your business, I really don't care. But you should quit downplaying the fact that it is a security problem.

Re:Extensions for Mac OS X

[steeviant]

"But you should quit downplaying the fact that it is a security problem."

Oh come on, you're also exaggerating just how much of a security problem it is given that there has never been an exploit that uses APE.

I'm not trying to downplay the fact that it's a possible security problem. I'm saying it is not a security problem at present, and in fact is working to actively increase security for me at the moment.

What I am saying is that if someone can get malicious software onto my machine, that is all that's required for me to regard it as completely compromised and that APE is not going to make a bit of difference to that.

If someone can install malicious software in my user account, they will have already circumvented my machine's security to such a level that I would not feel comfortable until I had wiped the hard drive and reinstalled the operating system and changed passwords on the websites I visit as well as replacing my public keys on the many machines I have to SSH to.

A local compromise of any type would allow the attacker to retreive my cookies, the serial numbers to all my registered applications, and various documents related to my employment that contain trade secrets and other potentially valuable information. Simply accessing that information is damaging enough, regular rsync backups ensure that deleting all my files or doing other things requiring root privilege would pale in comparison to the damage that can be done without root access.

Re:Extensions for Mac OS X

[Anonymous Coward]

Troll?

Who's the moron?

Parent is a technically correct assessment. /. painfully needs more and better meta-moderation. The current moderators would seem to be descendants of the book burners in the Germany of the 1930s.

Re:Extensions for Mac OS X

[rixstep]

This reminds me of the debacle over AnalogX's Proxy Server - a product many anti-spam experts contend is one of the biggest sources of spam relays in the world.

The product ships 'wide open' and users don't bother RTFM and if over a third of all spam relays are due to this product - who's at fault then?

Security experts say AnalogX is, because he ships his product wide open. Security experts have also been hounding Microsoft for years for shipping net tools that leave a user again 'wide open'.

Sorry, but merely giving a user an option to corrupt a local machine and then blaming the user for using this option is not a way out of the corner.

Re:Extensions for Mac OS X

[allgood2]

>>The very thought that code in a 32-bit protected mode system would be able to do things like this - correct me if I am wrong, but APEs require your administrator password, right? That means that even though they are 3rd party code they want to go where they have no right going.

OK. According to the Apple software specifications, any application that follows Apple's guidelines should request an Admin password, insuring that the user is authorized to install applications onto the system. Technically speaking, I have more of a problem when installers DON'T ask for a password, since it means anyone could have installed it on my system, something I expressly do not want.

>>It is installed in /Library/Frameworks/ like a good framework should be.

Unsanity haxies default to a single user, and provide the option of selecting for ALL users on the system, as part of the installer. I would imagine she was just being lazy and referring to 'all' modifiable /Library/Frameworks, rather than specifying both.

>>security
I'm certain someone with enough skill and time could hack APE and take advantage, but as it stands, to install a haxie using APE, the developer must first register their haxie with Unsanity. So its not currently as if I could just script something, take advantage of APE and then perform malicious tasks.

Re:Extensions for Mac OS X

[bnenning]

Sorry, but merely giving a user an option to corrupt a local machine and then blaming the user for using this option is not a way out of the corner.

Yeah, and don't get me started on all the Unix vendors who are so irresponsible as to include the incredibly destructive tool "rm" preinstalled.

Come on. First of all, "corrupt" is a ridiculously loaded term. You may not like what APE does; in fact neither do I in principle, but I consider it an acceptable tradeoff to protect against the *confirmed* threat of malicious URL handlers. Second, the default is in fact to install for the local user only. Third, since the large majority of OS X systems don't have multiple user accounts, it usually makes no difference at all.

Re:Extensions for Mac OS X

[dukerobillard]

Microsoft Windows doesn't cause the blue screen of death, badly written drivers do.

Re:Extensions for Mac OS X

[grahamlee]

So how do you debug things? I take it as given that you're definitely not a LISP fan...

Re:Extensions for Mac OS X

[tgibbs]

Malicious Haxies are theoretical, but then again there are no known malicious exploits in the wild against the URL handler that you installed two apps to protect yourself against. Good security is about protecting yourself from theoretical exploits before they are actual exploits

The concern about the URL vulnerability is that your computer can be attacked as a result of merely clicking on a link, even though these theoretical exploits do nothing worse than could be accomplished by the most trivial trojan--like the recent "Office 2004" trojan. So yes, a haxie could be a trojan, just like any other program you choose to install and run. And the only defense against trojans--haxie or otherwise--is still to only install software from a trusted source.

Re:Extensions for Mac OS X

[YOU LIKEWISE FAIL IT]

I still don't get why people are installing Ape + PA to counter the handlers problem when the obvious solution is to point the handlers to non-dangerous objects using something like RCDefault.app. Why not just write a set of good, non vulnerable rules once, and then be done with it?

Can someone mirror the article?

[Anonymous Coward]

I can't seem to reach unsanity.org.

APE and Shapeshifter works great for me

[bluedream]

and last time I heard.. nobody put a gun to your head to install it. -- this sig withheld for environmental reasons

Re:APE and Shapeshifter works great for me

[Anonymous Coward]

It works great for you - and of course you'd be intelligent to know if your system was compromised or not, right?

Why is it MORONS always think people will be interested in what they have to say?

'APE and Shapeshifter works great for me...'

Only a moron would use that stuff, only the son of the son of an inbred moron would admit it.

Re:APE and Shapeshifter works great for me

[Anonymous Coward]

I can't believe you are doing this. You posted this article totally clueless about how much knowledgeable people hate Unsanity, and when everything backfired, you started modding up all the positive comments.

The parent comment here was down to a 1 yesterday - how in heaven's name could it get to a 4?

This is censorship, this is warping the truth. It's tantamount to astro-turfing.

Slashdot astroturfing? Shame!

THE NAMES!

[SirDrinksAlot]

I still can't stand their names.
The company name, PLEASE! Unsanity? Come on.
Haxies, what are we? 3? Come on, im not going to install something that a crazy mommy and daddy think their 3 month old infant burped up with its dinner.
I feel insulted that they would dare make their own name for a method of changing MacOS that's been around for decades. To top it off their explanation for the term is a pure insult to my intelligence.
Infact I think the MacHack Conference changed its name just because it was insulted by the name "Haxies". MacHaxies Conference *COUGH*

mod parent down!

[Anonymous Coward]

Insightful!? He didn't RTFA! But neither did the jerk of a moderator, so who's the real culprit? Propose a new word: jerkmod.

Re:mod parent down!

[ahknight]

Didn't read the article? I read the article. I disagree with it. It's called 'thought' and you should try it sometime.

The argument he makes is that since it can't take down the whole system when a mod is badly coded that the architecture is sane. It is not. That it can cause the takedown of anything other than itself is cause for alarm.

Re:mod parent down!

[Anonymous Coward]

You said haxies are the same as OS 9 extensions. You wouldn't have said that if you had read the article.

Save your bitching for when a haxie actually causes a crash. Otherwise, STFU.

Re:mod parent down!

[ahknight]

Why would I not say that just by reading a man's opinion? You do realize that's what the "article" is, right? His opinion. His whole point is because the APE modules cause the crashes that the idea of APE is a good one. It works like OS 9 extensions at a fundamental level, only for programs. It's begging for a crash. Indeed, it does. Often.

I support Macs for a living. APE is banned. Every single time we have chronic problems on a Mac, we trace it back to someone using Shapeshifter or some other hack. Does it mean APE is buggy? No, it means it's a bad idea. Unsane, if you will.

Re:mod parent down!

[steeviant]

You talk about instability issues with APE modules, yet I've been running half a dozen different ones for about a year, and I have never experienced any issues that required anything more than logging in with the shift key held down to fix, and that only happened once after a system upgrade, and was due to one APE module trying to trounce into an area Apple had modified, not APE.

I've never had to reboot my laptop because of an APE module, and regularly achieve uptimes of over a month with my PowerBook. I usually go from one software update to the next without rebooting.

I'm curious as to exactly what instability you have experienced as APE hasn't affected speed, security or stability on my machine. Could you name some specific APE incompatibilities you've had to repair, so that we can gain some insight into the problems you've experienced and how you diagnosed and resolved them?

Re:mod parent down!

[Socket Scientist]

Same here. Only positive experiences with multiple modules and APE installed on four machines. On small screens I particularly like the module that prevents new Safari windows from advancing to the right (a feature that's redundant with Exposé anyway).

Having praised APE's stability I should mention that I have studiously avoided ShapeShifter. I've had nothing but negative experiences with OS X theming software in the past and I finally decided just to give up and embrace aqua + brushed metal. The stability has been worth it.

Re:mod parent down!

[chromaphobic]

I just wish they'd have finished Metallifizer 1.3. It would be nice to have a way to get rid of the brushed metal abomination in the finder without having to resort to a full theme.

I still have an old Alpha build from last year installed, and it works (except for a minor display issue) for now. But who knows how much longer it will work?

Re:mod parent down!

[Anonymous Coward]

"I have never experienced any issues that required anything more than logging in with the shift key held down to fix"

That sounds familiar, on yeah, in OS 9 I had to hold down the shift key top to disable extensions when things went to hell.

Hmm.

Re:mod parent down!

[steeviant]

Except of course that when an APE module goes awry it doesn't destabilize the base system, I don't have to reboot to remove the offending hack, it doesn't affect other user accounts, and APE modules can be safely enabled/disabled on the fly for testing.

What was the similarity with extensions again?

Re:mod parent down!

[Anonymous Coward]

Random apps crashing due to other apps fucking with it.

Re:mod parent down!

[Anonymous Coward]

due to one APE module trying to trounce into an area Apple had modified

Yeah, the cajones on those guys! How DARE Apple modify an area of their operating system without informing Unsanity first!

Re:mod parent down!

[steeviant]

I thought I'd made it fairly clear that I felt that Unsanity's APE module was at fault for that problem, but that it was easily fixed.

Just to make things clear.

I believe that on that occasion, the fault for the problem was shared entirely between myself, because I installed, and did not disable between upgrades, an obviously unsupported hack, and Unsanity for failing to update the free version of Silk because it had been superceded by a paid version that was tested with the new OS version I had just installed.

The problem seems to be that idiots install APE and APE modules without appreciating that their functionality is specifically (and sometimes deliberately) unsupported, and then complain to the software authors or Apple when they affect applications in an undesirable way.

My first troubleshooting steps when installing new software that doesn't work is to check for old plists, and temporarily disable APE if that fails. Neither of these problems can or should be attributed to or mitigated by Apple.

I feel that I should mention that disabling APE hasn't helped yet, except in the specific instance of Silk 1 that I mentioned above, but deleting old plists certainly has.

Re:mod parent down!

[DJFriar]

I guess because I only use WindowShade and FruitMenu, but APE and its haxies has never crashed .. in fact - I have only seen the "crash" screen once .. the first time I turned on the computer when it was new. I could deal with not having FruitMenu .. but no way on WindowShade .. just do dang functional. When Apple brings it back .. I'll ditch the Haxie.

tel{e,ly}tubby-like whaaaa?

[Quinn]

Maybe someone could explain the enigmatic "tellytubby-like" comment? Like, please don't say something like that and just assume everyone knows what the funk you're talking about? Like, especially when a google doesn't enlighten?

LIKE, YOU KNOW???

Re:tel{e,ly}tubby-like whaaaa?

[SirDrinksAlot]

If you knew Rosyna, you would know he's the purple one.

Re:tel{e,ly}tubby-like whaaaa?

[Anonymous Coward]

ohhhhhhhhh... "purple"... is this true?

Re:tel{e,ly}tubby-like whaaaa?

[Meowing]

I don't know what that's about, Rosyna looks pretty ordinary to me....

Re:tel{e,ly}tubby-like whaaaa?

[Anonymous Coward]

LIKE, YOU KNOW???

And they really think theirs is the same as the King's English.

Incredible.

Re:tel{e,ly}tubby-like whaaaa?

[Slur]

Again!

Re:tel{e,ly}tubby-like whaaaa?

[PetWolverine]

Hey, don't do that! He said he couldn't find it on Google as it was.

So instead, repeat after me:
teletubby-like Rosyna

And two hours later...

[FFFish]

...we find that no one cares about this topic. Thirteen posts, all scored 1 or lower -- this must be a record for disinterest!

Re:And two hours later...

[FFFish]

D-oh! Some dumb fucker [looks skyward, innocently] should probably have refreshed his cache.

Make that twenty posts, with only one scored better than 2.

I still figure it's some sort of record, though.

Re:And two hours later...

[aftk2]

Clearly, you don't spend too much time at games.slashdot.org

APE is a very clever implementation

[Anonymous Coward]

..of a very bad idea.

Re:APE is a very clever implementation

[wealthychef]

Care to expand on what the bad idea was?

Re:APE is a very clever implementation

[Anonymous Coward]

The bad idea is patching the system libraries. Sure, I know people are nostalgic for UI disasters like windowshades, but when you yank the rug out from under an app by altering the behaviour of the system frameworks, things BREAK.

It happens time after time, that a user sends in a bug report, and it can't be reproduced, and after three or four go-arounds you find out that user's got haxies installed. Remove the haxie, and the app starts working normally again.

I remember when Karl Kraft wrote his article on how to alter the appearance of all NSWindows by patching the AppKit on DP4. It was an interesting article, but you should NEVER try that kind of a hack in a production environment.

MOD PARENT UUUUUUUUP

[Anonymous Coward]

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

Flack about the URL handler exploits

[SailfishMac]

A lot of this came about because of the rash of URL handler exploits in Mac OS X recently.

In the mad rush to secure Mac OS X, two groups emerged. The Paranoid Android (based upon APE) and the RCDefault/More Internet side.

Unsanity (makers of PA) had a incomplete product at first that could not keep up with the rapid new discoveries. It was designed to check the URL handlers for you for suspicious behavior, problem was it didn't cover all the URL handlers.

v 1.1 was no good and finally unsanity came out with v 1.2 which covered them better.

Now on the other side of the camp is the RCDefaultApp and More internet crowd, which schooled people to turn off/reassign the URL handlers themselves with a very easy to use program.

Their argument was that one didn't need to install a "haxie" (in their own words) "injects code in all your programs" &

"they do their thing by violating the boundaries of protected memory."

http://daringfireball.net/2004/05/help_viewer_secu rity_update

Either way, I'm glad the Mac community turned out in force to solve these problems in a jiffy, Apple should be ashamed of themselves, being warned over 4 months ago about them.

If using Paranoid Android was the only option to prevent these exploits, I'm sure everyone would be happy using it. But it seems to me just disabling the URL handlers manually until needed or reassigning would have been a better option.

I'm glad we had a choice, so kudos to both and thanks.

Re:Flack about the URL handler exploits

[rixstep]

Now on the other side of the camp is the RCDefaultApp and More internet crowd, which schooled people to turn off/reassign the URL handlers themselves with a very easy to use program.

RCDefaultApp can't turn off a thing. The use of the string '' within this program is very unfortunate.

RCDefaultApp 'redirects' things. When you want a protocol 'disabled', it actually redirects to another app hidden within its own application package. A package in turn called 'Do Nothing'.

This method might work in a pinch, but it is not a clean solution. The clean idea is to disable the protocols completely. Damage your plist file where RCDefaultApp proclaims its ownership of your protocols, or remove RCDefaultApp because you think you're finished with it, and you may become vulnerable again.

RCDefaultApp does not turn anything off - it redirects. Big diff.

Re:Flack about the URL handler exploits

[Anonymous Coward]

You haven't used RCDefaultApp, have you? It has an option to disable a protocol, which does exactly that - it turns it off.

Re:Flack about the URL handler exploits

[Anonymous Coward]

Based on his description, I believe he has used it. Have you actually opened up the appropriate .plist and verified that it's not doing what he says it's doing?

Just because RCDefaultApp says it sets the protocol to "disable" doesn't mean it actually disables the protocol. The OS may not support this, it may simply have to be set to something.

My interpretation of what he's saying is, in effect, that the OS doesn't support disabling protocols, so it's being redirected to use an application inside of RCDefaultApp which, in turn, does absolutely nothing. The end result is similar to what you think it's doing, but, like he said, he is prone to being broken by the removal of RCDefaultApp.

Now, I haven't verified that his story is true, but it certainly seems to make sense. I always have a hard time finding the right .plist...

Personally, I like to use both PA and RCDefaultApp. I changed some protocol helpers with RCDefaultApp (thank god, finally the ^&*(@#&$(@# Finder doesn't "help" me with FTP sites!), and am using PA as a safety blanket for the rest and any unknowns that may pop up. When Apple patches this hole, PA goes away, RCDefault gets used to return things back to normal (well, except for FTP, Finder's FTP support is annoying).

Well.. I'm interested

[slughead]

I bought a TV tuner card recently and the software included uses APE. I also own windowshadeX (which is better than exposé in a lot of ways)..

Somewhere in their code, Unsanity does include spyware for WSX, I'm not sure if it's WSX or APE, but it's in there somewhere. Me and Rosnya (why does he pose as a russian female?) debated whether or not Unsanity was breaking the law by not telling anyone about their spyware.. (despite what he tells you, he's wrong).

If it were anyone else, I'd probably say this long drawn out PR was just a bunch of cover-their-ass crap, but Unsanity is a good group of guys and until Windows trips over its big fat ass and Apple takes over, we need all the skilled developers we can get. In addition I know this particular redheaded weirdo who calls himself Rosnya, and though he is capable of doublethink, he's not a liar, and I for one now feel relieved that I have one less base to cover when debugging OS X.

Re:Well.. I'm interested

[beelsebob]

1. Rosyna doesn't pose as a russian female, she poses as a tellytubby.
2. Windowshade X is not spyware, and I'd love to see you prove it is with some packet monitoring software as Rosyna suggests in the article
3. Unsanity isn't breaking the law by not telling anyone about their spyware, because they don't give out spyware.

Bob

Re:Well.. I'm interested

[Anonymous Coward]

I think he's just upset because he had a thing for the Russian female Rosyna was posing as.

Re:Well.. I'm interested

[MirokuHotei]

That damn Ivahnya! Turned out it was Rosyna from Unsanity the whole time!

Re:Well.. I'm interested

[iMacGuy]

Rosyna Keller is a man.

A lot of people are missing the point, here.

[g_lightyear]

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.

Re:A lot of people are missing the point, here.

[Anonymous Coward]

how does it feel to be a dinosaur?

Re:A lot of people are missing the point, here.

[Anonymous Coward]

>If you don't like it, don't use it. Plain and simple.

No, you're missing the point. As a third party developer, I can't control what other software is installed by users of my applications. I've seen too many cases of mysterious crashes where the common thread is that the user is running APE, and upon removing it, the crashes go away. Rosyna can claim only a single bug against their code (call Guiness Book of World Records!), but the fact of the matter is that APE costs me time and money, and that pisses me off. Just because they deny problems with their parasitic software doesn't mean it's true. I consider APE to be Unsafe At Any Speed.

Re:A lot of people are missing the point, here.

[YouHaveSnail]

The problem isn't so much that APE framework code is broken or buggy in the sense that the framework itself causes crashes. The problem seems to be that the APE framework is unsafe in that it allows other code (APE modules) to cause problems for other apps. I suppose you could say that the APE framework correctly implements a flawed or dangerous design.

Re:A lot of people are missing the point, here.

[BandwidthHog]

Thanks, I've been looking for something to give me more granular control of my audio output. I've never installed APE as I've never needed any Haxie badly enough to try it out. We'll see...

Re:A lot of people are missing the point, here.

[macserv]

"I consider APE to be Unsafe At Any Speed."

Yeah, and look how many people love the Corvair. :-)

Oh Joy!

[tyrione]

Another Carbon Framework.

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.

Re:Oh Joy!

[Textbook Error]

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.

Re:Oh Joy!

[tyrione]

Have you taken a look at all the sessions this year?

Let's just say last year had more Carbon sessions than this year's WWDC.

Re:Oh Joy!

[Anonymous Coward]

Big deal, sessions change right up to the last minute - and to be honest the relative number of sessions don't mean squat. Existing technologies are always squeezed out by hot new technologies, and established stuff like Carbon/Cocoa/QuickTime is always going to give way to whatever's new in Tiger.

Re:Oh Joy!

[Anonymous Coward]

Carbon's not going away, just like stdlib. Claiming that they're "equal" is just silly, though.

No matter how much work apple puts into exposing C APIs for new funcitonality, the long and short of it is that doing any given task in carbon will ALWAYS be far more work. Sorry, that's just the nature of the beast.

Re:Oh Joy!

[Anonymous Coward]

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.

Frankly, because Apple has lied about (a lot) of stuff like this over the past 20 years. Their in-house developers often get themselves into trouble (design wise), requiring them to make liars of their marketing (excuse me, "evangelist") people. If you place any of your assets at risk on the basis of what comes out of their mouth on stage at WWDC (vs. what is actually shipping to customers), you are in for a rude awakening one of these days.

Re:Oh Joy!

[Anonymous Coward]

Let's just say there's not all that much to say about Carbon.

APE: Neither Blind nor Unique

[ZackSchil]

Don't think that APE is a security nightmare on its own. Sure, it provides means by which to inject code into programs that were launched after the code injector became present, but that's not a unique ability. Technically, any daemon can inject code into a program as it is being launched. The APE framework is not doing anything more than calling existing (but undocumented) APIs used in debugging Mac OS X. APE modules cannot poke around into any program they wish, they may only poke around in the applications in which they have been told to reside (something YOU have control over). They may not touch any other program. Sure, you can call APE a bad idea, and yes it can crash applications or spy on the user, but not more than any other piece of malware could, entirely separate from APE.

Re:APE: Neither Blind nor Unique

[rixstep]

Actually this post does not need a reply, as it is its own best counter-argument. But let's take a few choice examples.

it provides means by which to inject code into programs that were launched after the code injector became present

Meaning it's by definition a type of trojan.

but that's not a unique ability

Oh no? Then tell us what other programs do this so we can rid our systems of them.

any daemon can inject code into a program as it is being launched

Even if this were true, it's a case of trust: we bought the operating system because it had a proven record and we trusted it. An APE is NOT part of the operating system (thankfully).

not doing anything more than calling existing (but undocumented) APIs

This basically says all. Programmers who hack at undocumented APIs should get a slap on the wrists.

APE modules cannot poke around into any program they wish

But you just said they can get into anything - make up your mind.

they may only poke around in the applications in which they have been told to reside

Why do we feel no comfort in these assurances?

They may not touch any other program.

'Bullshit!' - Tom 'Iceman' Kazanski

you can call APE a bad idea

Thank you for your permission.

yes it can crash applications or spy on the user

Thanks again - this time for admitting our point.

not more than any other piece of malware

And a final thanks for categorising it where it belongs.

Re:APE: Neither Blind nor Unique

[ZackSchil]

Allowing APE modules access to programs is the job of the APE framework, which is the one trusted aspect of the system. Yes, modules could probably get around this by executing under the framework and not using its constructs but SO COULD ANY OTHER PROGRAM.

SECURITY ALERT! All executable files are insecure because when launched they are given access to your files without user intervention, can launch daemons, hijack new executables, and spy on the user!!!

My only argument is that APE framework is simply a way to execute haxie code in a way that is more efficient for the programmer than in a stand-alone daemon. In addition, when the developer uses the features provided by APE framework, the user is allowed to control which apps a module is allowed to touch (and here's the key) through the framework. Saying APE modules are insecure is like saying any executables are insecure; which is also like saying that actually DOING anything physically is dangerous because you could be killed, spied on, etc...

Everything is a matter of trust: from running closed-source applications to going outside each day. There is nothing wrong with the APE framework just like there is nothing wrong with your car. Both have the potential for abuse (hell, a car can kill people) but you have to have some level of trust.

You are free to be wary of all untrusted content but honestly, you sound like a conspiracy theorist. If you don't like the idea of APE modules (I personally don't simply because I don't trust that programmers outside of Apple will be able to guess at how a program works well enough to not cause it to crash) then don't use them but please don't spread FUD about their being inherently insecure. Because they're about as insecure as drinking a glass of orange juice (it can choke you! how ever did they get FDA approval!).

Re:APE: Neither Blind nor Unique

[ZackSchil]

In addition: would you trust APE Framework on your system if you only had this module installed? You can even look at the source or compile it yourself.

Re:APE: Neither Blind nor Unique

[iMacGuy]

ANY program in OS X can do this. You would have to remove Mach from the kernel to disable it.

Re:APE: Neither Blind nor Unique

[tgibbs]

Meaning it's by definition a type of trojan.

Whose definition? A trojan, by the usual definition, is a program that pretends to be one thing, but actually does something else. Like the Trojan Horse, you know. The documentation of APE is quite straightforward about what it does.

I've used APE for years, and have only once had a problem which turned out to be due, not to APE, but to an APE module. Which was immediately obvious, since like any reasonably sophisticated user, I disable APE modules when trying to isolate the source of a problem.

In support of Unsanity

[John Siracusa]

You can take my Haxies from me when you pry them from my cold, dead hands.

Yes, it would be better if Apple provided clean(er) hooks for things like Windowshade and FruitMenu. But they don't, and I'll take Unsanity's implementations over nothing at all and day of the week and twice on Sunday. They make my computing life so much better that they are, by far, the best investment I have ever made in software, dollar for dollar (I bought when they were $7 too :-)

Lots of "code that you didn't write" runs in your application's process space. I don't see how Apple or the DivX guys or anyone else are any better or more trustworthy than Unsanity in this regard. If a QuickTime plugin causes a crash, disable it. If an APE Module causes a crash, disable it (or exclude that app using APE Manager). IMO, Unsanity's record is impeccable thus far, and they are certainly a lot more responsive than a big company like Apple.

Yes, being a developer is hard. Sometimes you have to debug problems caused by other people's code. Sometimes new versions of the OS break your app. How dare those users upgrade their OS! How dare they install software that runs in your process space! Sorry, but that's the right of the user.

If you want to blame anyone, blame Apple for not providing "nicer" ways to do the things that so many users so obviously want to do. Unsanity would have been out of business long ago if there wasn't a real demand for the services they provide--despite the particular way they are forced to implement them.

Re:In support of Unsanity

[FredFnord]

> Lots of "code that you didn't write" runs in your application's process space. I don't see how Apple or the DivX guys or anyone
> else are any better or more trustworthy than Unsanity in this regard.

Do you really not see how Apple is better in this regard? It seems unlikely that anyone could be that thick, but I'll give it a go:

Apple uses talented programmers, has a QA department, doesn't allow commits without thorough code reviews (or at least, didn't in my department when I worked there), and tests in a multitude of different environments. Plus they have guidelines for acceptable programming.

People who write 'haxies', by and large, have none of these advantages. Some of them are actively incompetent, but not very many.

> Lots of "code that you didn't write" runs in your application's process space. I don't see how Apple or the DivX guys or anyone
> else are any better or more trustworthy than Unsanity in this regard. If a QuickTime plugin causes a crash, disable it.

I can address this one. At Apple, they have a fellow (poor fellow) whose job it is, almost entirely, to sit there taking the bug reports that they get for QuickTime from external testers, developers, and users (via Feedback), and figure out which ones are known bugs, which ones are new bugs, and which ones are bugs caused by third-party products.

Most shareware developers don't have this luxury. (I except groups like Ambrosia, who can at least spread the work around a little.) They have to poke around at every trouble report that they get until they figure out what happened with it, or risk being panned as 'unresponsive'. If the problem is caused by, say, a new version of the MacOS which breaks an API you were depending on (which has happened to me several times), you will typically see the same problem over and over and be able to classify them pretty easily. With 'haxies', it's a guessing game, and not one that I would particularly enjoy.

There's a simple answer, of course. APE adds a thread to every application that it infects. It's trivial to detect this thread and put up a dialog box that says, 'Sorry, this program is not compatible with 'haxies'. Please uninstall APE or disable it for this program.' And then exit. And some people will uninstall APE. And some people will disable it for my application. And some people will decide not to use my software. And some people, people with an attitude like yours, will find some way around my safeguards, and then will still send me crash logs with APE in them and expect me to fix them. And it is they, and only they, whom I will tell to blow me.

If I ever release any of the Cocoa apps that I whipped up for my own use to the general public, that's probably what I'll do. I don't see any compelling reason to release them right now... it would take dozens of hours of polishing, and then some sort of a volunteer beta program, all so that 0.1% of my users can send me $10 and 80% of my users can expect me to fix my bugs for them even though they haven't paid me. (I'm not a big fan of cripple-ware.) Add haxies (which I've run afoul of before, when I was doing contract work) and their ilk to that mix, requiring me to fix OTHER PEOPLE'S BUGS for free, and you'll probably never see my apps out there. They work for me, and that's all I need.

> Yes, being a developer is hard. Sometimes you have to debug problems caused by other people's code. Sometimes new
> versions of the OS break your app. How dare those users upgrade their OS! How dare they install software that runs in
> your process space! Sorry, but that's the right of the user.

It is the right of the user to do whatever he damn well pleases with an app he bought, aside from giving away copies or reselling them for profit. (Well, it isn't, in the US, but I agree that broadly speaking it probably should be.) It is the right of the developer not to have to support it if the user uses it in a way that makes such support impossible.

Re:In support of Unsanity

[Anonymous Coward]

Why don't you spend a month working in AppleCare customer tech support, and let us know if you're still a fan of Haxies.

Re:In support of Unsanity

[John Siracusa]

I don't see how Apple or the DivX guys or anyone else are any better or more trustworthy than Unsanity in this regard.

Do you really not see how Apple is better in this regard? It seems unlikely that anyone could be that thick, but I'll give it a go:

Apple uses talented programmers, has a QA department, doesn't allow commits without thorough code reviews (or at least, didn't in my department when I worked there), and tests in a multitude of different environments. Plus they have guidelines for acceptable programming.

...and yet Unsanity has yet to produce an installer with a novice-level bug (improper quoting in a shell script) that could cause entire disks to be erased (iTunes installer, I forget the version...remember that one?)

Everyone creates bugs. My point was that many kinds of "foreign code" is running in other applications' address spaces: QuickTime plugins, InputManagers, Contextual Menu Plug-ins, and so on, all written by many different kinds of developers and organizations, none of which are inherently inferior or superior to any other, in the aggregate.

And some people, people with an attitude like yours, will find some way around my safeguards, and then will still send me crash logs with APE in them and expect me to fix them.

A crash log with "APE in it" does not necessarily mean that an APE module caused the crash. Anyway, if you did get such a crash log, it's your choice to ignore it or not. But if 90% of your customers are running APE because they all want to use Windowshade or whatever, that's just a reality of the market. Cursing it and turning your back is not going to win you any new customers.

If I ever release any of the Cocoa apps that I whipped up for my own use to the general public, that's probably what I'll do. I don't see any compelling reason to release them right now... it would take dozens of hours of polishing, and then some sort of a volunteer beta program, all so that 0.1% of my users can send me $10 and 80% of my users can expect me to fix my bugs for them even though they haven't paid me. (I'm not a big fan of cripple-ware.) Add haxies (which I've run afoul of before, when I was doing contract work) and their ilk to that mix, requiring me to fix OTHER PEOPLE'S BUGS for free, and you'll probably never see my apps out there. They work for me, and that's all I need.

Yes, it's quite a hardship creating software for use in such an "impure" thing as the real world... ;)

.If you don't like Mac OS X's user interface, you don't have to use it, but the last thing you should expect is good support for changing it.

Why shouldn't I expect OS support for something a lot of people want to do? From the article comments:

Apple should provide a way to do the things that the most popular haxies do (Apple menu customization, window minimization plug-ins, etc.), without resorting to "universal code injection." [...]

By providing clean hooks for commonly desired functionality, Apple can substantially decrease the demand for and usage of APEs (and other, worse software that, say, actually modifies your system files).

But the demand for APE-like thingies will never be eliminated entirely because there is a large class of things that users want their computers to do that, by definition, affect every running app. Themes are just one example.

The most constructive course of action for Apple is to recognize this fact and try to come up with a way to allow such software to be created as safely as possible. Thus far, Apple has tried to discourage and prevent such software, but attacking the supply side is not the answer. First, recognize the demand, then try to provide for it (or allow others to

Re:In support of Unsanity

[tgibbs]

Apple uses talented programmers, has a QA department, doesn't allow commits without thorough code reviews (or at least, didn't in my department when I worked there), and tests in a multitude of different environments. Plus they have guidelines for acceptable programming. People who write 'haxies', by and large, have none of these advantages.

That sounds nice in theory. However, in practice, I have had more serious problems with minor Apple updates than I have with APE.

That is to say, blame Apple for wanting their OS to have a consistent user interface and consistent operation. If you don't like Mac OS X's user interface, you don't have to use it, but the last thing you should expect is good support for changing it.

Wishful thinking aside, if the UI does not meet people's expectations, then they are going to change it. The fact that other user interfaces may be even less satisfactory is irrelevant. So Apple might as well accept reality and provide a reasonably benign way of doing it.

APE is crAPE

[Anonymous Coward]

The gay thing about Rosyna's little rant is that it doesn't address my number one complaint with APE; that is slows the system down. And the more modules you add the slower it gets. Unsanity has publicly admitted this in the past.

Rosyna didn't address it because he can't address it; this is a fundamental problem with APE, and it's the reason why I don't (and won't ever) use it.

In short, APE is crAPE.

Re:APE is crAPE

[allgood2]

Probably because it doesn't slow the system down on thousands of systems. Or prehaps you still can't differentiate between the APE framework versus an APE module. I've been using APE for years, and their is no noticeable difference in my system speed. Of course I don't use one of the popular, but known unstable APE modules--ShapeShifter. I would expect ShapeShifter to slow the computer down, its modifying the whole frekkin interface.

That said, I LOVE FruitMenu, MenuMaster, and now Paranoid Android. In fact, I think the combo of Paranoid Android and Little Snitch (different vendor) are hard to beat if you value security and privacy.

Re:APE is crAPE

[tgibbs]

The gay thing about Rosyna's little rant is that it doesn't address my number one complaint with APE; that is slows the system down.

Ironically, that used to be the major complaint about graphical user interfaces. And it's true. A nice user interface slows the system down. Fortunately, in many cases, a substantial increment in usability and convenience can be obtained with only a tiny effect on speed.

Bang head here...

[dpbsmith]

OK, so the problems are not in the APE framework, but in the modules that run under it. However, the framework is useless without modules to run under it. The equation is clear enough: install haxies and incur a significant risk of problems. The benefits may, in a sensible person's mind, outweigh the risks, just as was true of extensions in OS 9 and TSR's in MS-DOS, but the risks are not negligible. To say that they don't matter because they're not the fault if the APE framework itself is silly.

Please spare me the enthusiasts for whom no failure is ever the fault of the object of their enthusiasm. For example, Windows advocates who insist that bluescreens don't count because they're caused by "drivers," while ignoring the fact that you needed to install drivers to get your display hardware/Adaptec SCSI card/whatever to work.

True story. Circa late seventies. A friend was praising his NorthStar computer to the skies. I asked if it was reliable. He said it had been 100% reliable and he'd never had any problems at all. I asked him to demonstrate it to me. He said, "Oh, sorry, I can right now, the power supply burned out and I'm waiting for a replacement." I said, "But I thought you said it was 100% reliable." He replied, "The computer works fine--it's just the power supply that's out."

Re:Bang head here...

[Richard_at_work]

Please spare me the enthusiasts for whom no failure is ever the fault of the object of their enthusiasm. For example, Windows advocates who insist that bluescreens don't count because they're caused by "drivers," while ignoring the fact that you needed to install drivers to get your display hardware/Adaptec SCSI card/whatever to work.

Im no MS apologist (but then Im not linux/BSD fanboi either), but the arguements Ive heard along those lines are more of the "Well, most bluescreens are caused by drivers, which need to reside in kernel space. Linux/Unix has the same problem, kernel modules can cause a kernel panic." Yes, you need to install those drivers to have your hardware run, but then Ive never heard anyone say you dont :D Its jsut a case of it can happen to the majority of OSes.

Re:Bang head here...

[allgood2]

>>The equation is clear enough: install haxies and incur a significant risk of problems.

That's not true. This is all dependent on which haxies you install. Many of Unsanity and other companies haxies have cause no issues to date. It doesn't mean that they couldn't, but thats a little like saying install software and incur a significant risk of problems.

A slew of user problems are caused by bugging applications, and without those pesky little applications its far more likely your computing experience would be problem free (well at least on a Mac), but typical your OS itself doesn't allow you to get the work you need to do done.

I could install APE and some haxies to work with it, and experience problems (with the Finder, Contextual Menus or other Applications) or I could install Microsoft Office and experience printing problems, Eudora crashing when grammar menu is open, unexplainable application shutdowns, whatever.

A system without risks is a system not in use.

No ones claimed APE was perfect, though Unsanity does claim the APE framework has generally been bug-free. But they acknowledge that haxies (APE Modules), even some of their ow haven't always been stable (hence version releases).

Re:Bang head here...

[dpbsmith]

And where is it written that all drivers need to reside in kernel space? Isn't this determined by the OS design, and isn't it a legitimate target for critique?

Why should buggy code in a device driver bring down the OS as a whole? Why should it affect anything but the operation of that specific device?

What is there, exactly, about a SCSI device that requires the specific driver for that specific device to have full, unrestricted access to space? Is it logically impossible to think of any other architecture at all?

Or is this a deliberate tradeoff of performance and convenience against stability?

why?

[Anonymous Coward]

Well, can somebody explain why OSXVNC's GUI portion refuses to function due to APE? The developer seems to think that the blame lies at the door's of Unsanity, and I sure as hell can't get the GUI part of it to work for more than 5 minutes.

Why is that?

http://www.redstonesoftware.com/osxvnc/OSXvnc.ht ml

Re:why?

[blackdragon7777]

Well after RTFA, I read this paragraph which I believe to be the likely case:

"Another possibility may be that neither the APE Framework nor the APE Modules you are using are directly causing the crash. In at least three confirmed (by the application's developer) cases the application had a memory bug in it. In these cases the developer freed memory they shouldn't have freed and it was reused as if it was not free. The loading of APE Modules caused new information to be assigned to the free memory space (as it is supposed to be) and when the application reused the free memory it wouldn't give them the data they expected, causing a crash. In other words, APE can actually expose a pre-existing bug in an application."

APE + Menucracker equaled bad

[Anonymous Coward]

APE, along with an older version of ASM (the MenuCracker part specifically) on 10.2 caused the finder to quit and restart repeatedly ad infinitum. I removed all modules, still caused the problem. removed APE, the problem stopped. Spoke to him about it, he denied it was the cause, but it's hard to deny.

He can say what he wants, but APE does things it's not "supposed" to be able to do, and this can cause conflicts. I've removed all "hacks" and I haven't had any trouble since.

RCDefaultApp doesn't prevent new URL handlers

[iamacat]

It can only reassign existing ones. How will it protect you from spam:// URL handler registered by opening an ftp URL? Since the problem is in a shared library, it's only logical to use fix it by injecting code into every process. Just like for other things haxies are doing, like global UI changes.

Re:RCDefaultApp doesn't prevent new URL handlers

[Anonymous Coward]

Answer: Little Snitch, if something gets through and trys to call in something worse, Little Snitch is there to prevent it, at least give you a warning and a option to cancel.

This goes for stuff that gets by Paranoid Android as well.

Steve Jobs better get Mac OS X in line quick, security wise, there won't be a reason to use Mac's anymore.

You can't be serious

[iamacat]

If you can't make the operating system work better, write to the vendor (Apple). Don't do anything yourself.

Come on, Apple was contacted in Feburary about URI exploits and didn't do anything until now. Should I just sit, do nothing and invite "software" that will really break down my protection barriers or should I download a fix that works in the only possible way - by patching existing software.

As for other haxies like UI skins - well if it's your personal machine, the defaults hurt your eyes and you are willing to accept some risk of instability, go for it. If your Mac is supported by other people, well they might uninstall your skin haxies if you get unusual crashes. But they should leave this one in until Apple has a fix.

I feel obliged to say

[Ilgaz]

They are one of nicest "companies" I met so far. I am only 5 month mac user, I mailed them about a program of theirs (theme thing) and how much time it will be supported on Jaguar (osx 10.2) and one of the coders gave me answer with all details.

Its nothing I am used in PC world (windows) or Linux.

Re:I feel obliged to say

[airdrummer]

i agree that unsanity has been very responsive, but i don't use windowshade because last time i tried it (for the minimize-in-place feature...i miss IRIX;-) X11 apps would become unresponsive:-(

Erf.

[FredFnord]

Tried to delete the first bit of this but apparently I missed. So I end up responding to the same part of a post twice. Teach me not to proofread.

Well, what I wish it would teach me is to get a sufficient amount of sleep. But that doesn't seem likely right at the moment.

-fred

AbiWord, Firefox, TextSoap crash only with APE

[ankhank]

I tried Paranoid Android 1.2; accumulated immediate crashes from AbiWord and TextSoap, when doing anything involving a large block of text between them, whether by drag'n'drop or copy/paste.

Removed APE, rebooted, problem gone.

Reported to developer.

Last time I tried APE, a year ago, similar problems persisted til I removed it. Reported it then too.

Some extra precautions

[Anonymous Coward]

I'm posting now from a completely fresh install of Mac OS X because these vunerabilities have been "in the wild" for quite some time. Time enough for keystroke loggers and and other nasties to be installed in supposely the most secure operating system available.

I have my RCDefaultApp installed and disabled all my unused URL handlers, some folks go as far as reassigning to a rarely used application that pop's up in front of their face, thereby warning the user that a exploit has been attempted. This way a alarm can be sent out about a particular web site.

Since we cannot prevent the exploits, we can halt the program is uses to do damage.

I have considered Paranoid Android, problem is I hear it can be tricked, all a malicious person has to do is download PA and test it's defenses in the safety of their own home.

With RCDefaultApp, a malicious person has to take a chance distributing the exploit hoping one didn't reassign their URL handlers, so I think this approach is a better measure of security. They have to expose themselves to see if their exploit works.

Also I also installed Little Snitch, (there are "other" exploits which can intiate a download), which monitors all outbound network traffic and halts it for my review.

And Apple, don't even think about charging for "Tiger"

Unsanity in general

[Distortions]

Personally I think APE is useful. It does pose a security threat though. APE needs to require a password before activating new modules so a malicious module can't load on its own.

As far as Unsanity as a "company", I greatly dislike them.
Most of their software is "Whine and bitch until you give me money - ware". Shapeshifter flashes the screen and puts large letters on the screen that ask you to register ( at short intervals even ).

It did that ( while I was playing a game ). the huge image with a alpha map renders slow.. Therefor I died in the MMORPG I was playing.. Thanks.

Their prices are OK.. Although a bit high for a "toy". I call it a toy because, would you use this on a computer you do *any* work on? Most of them are small changes that aren't complicated like the uh font module whatever its called.

I got sick of the whole deal and deleted APE...

other (non-APE) audio routing tools

[phossie]

you may want to look at Jack and Soundflower too.

APE is EVIL!!!

[WiseWeasel]

I'm a part of several independent software development projects (on the PR side, mostly), and can vouch that APE is a piece of shit, and should not be installed by anyone who cares about stability and data integrity. When users get crashing problems and send us their crash logs, APE modules are usually to blame. As such, we just tell our users that we won't support them as long as APE is installed, and get them to uninstall it whenever we see it active in logs users send us. We might even have to add code to our app to prevent it from running if APE tries to insert its threads in our app's memory. I sincerely hope that Apple makes this kind of software impossible by preventing arbitrary third party code from being inserted into apps' protected memory (with explicit exceptions for valid plug-ins, of course). I don't care what Unsanity says, they're full of crap. APE has got to be the #1 source of crashes on MacOS X. Congratulations, Unsanity, for millions of dollars worth of lost work and time. I say we get the torches and rope!

Re:APE is EVIL!!!

[Anonymous Coward]

I have to agree. APE ALONE is enough to cause system instability, even with no modules installed. There is a simple way to test this - install an an Unsanity product that comes with APE (I think they all do now), and then turn OFF the module but leave APE installed. You'll start experiencing more system crashes. That's pretty damn black & white. The first thing I ask any of my clients who say "My Mac just started crashing a lot" is "Did you install anything from Unsanity?"

Re:APE is EVIL!!!

[Anonymous Coward]

If you do write that code (to prevent running if APE is installed), please share it with the class. Thanks!

who gives a shit

[Anonymous Coward]

this article is pointless and dumb.

I would appreciate it if this comment would be moderated to +5, insightful, but I will also accept +5, funny