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."
course it doesnt take one to see that this in no way recreates the extention problem
"Slashdot, where telling the truth is overrated but lying is insightful."
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?
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.
Hyperbole is the worst thing ever.
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.
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).
Hyperbole is the worst thing ever.
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?
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.
Latewire
critics are right to point out that it is a security nightmare, and it will destabilize all apps on the system by design
/Library/Frameworks/ like a good framework should be.
/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.
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
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
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.
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.
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."
"How to Do Nothing," kids activities, back in print!
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.
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.
t ml
Why is that?
http://www.redstonesoftware.com/osxvnc/OSXvnc.h
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?
.plist...
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
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).
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.
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.
>>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.
/Library/Frameworks/ like a good framework should be.
/Library/Frameworks, rather than specifying both.
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
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
>>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.
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.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
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!
"I like systems, their application excepted", George Sand (French)