Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
OS X Businesses Operating Systems Programming Software Apple IT Technology

Unsanity Developer Comes to APE's Defense 138

Posted by pudge from the kill-teletubby-smash dept.
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."
This discussion has been archived. No new comments can be posted.

Unsanity Developer Comes to APE's Defense More

Unsanity Developer Comes to APE's Defense

Comments Filter:
  • and last time I heard.. nobody put a gun to your head to install it. -- this sig withheld for environmental reasons
  • 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???

  • And two hours later... (Score:3, Funny)

    by FFFish ( 7567 ) on Thursday May 27, 2004 @09:25PM (#9273902) Homepage
    ...we find that no one cares about this topic. Thirteen posts, all scored 1 or lower -- this must be a record for disinterest!

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

    • Well.. I'm interested (Score:3, Interesting)

      by slughead ( 592713 )
      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
    • Clearly, you don't spend too much time at games.slashdot.org

  • Flack about the URL handler exploits (Score:5, Informative)

    by SailfishMac ( 732653 ) on Thursday May 27, 2004 @11:57PM (#9274642)
    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 (Score:5, Informative)

      by rixstep ( 611236 ) on Friday May 28, 2004 @06:59AM (#9275978) Homepage
      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.
    • 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.

  • A lot of people are missing the point, here. (Score:5, Insightful)

    by g_lightyear ( 695241 ) on Friday May 28, 2004 @03:21AM (#9275293) Homepage
    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 [rogueamoeba.com], 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 [unsanity.com] 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. (Score:3, Insightful)

      by 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 pisse
      • 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.
    • 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...

  • APE: Neither Blind nor Unique (Score:5, Informative)

    by ZackSchil ( 560462 ) on Friday May 28, 2004 @08:58AM (#9276684)
    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.
    • 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:
      • 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 simpl
      • In addition: would you trust APE Framework on your system if you only had this module [ragingmenace.com] installed? You can even look at the source or compile it yourself.
      • ANY program in OS X can do this. You would have to remove Mach from the kernel to disable it.
      • 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 t

  • In support of Unsanity (Score:5, Interesting)

    by John Siracusa ( 4209 ) on Friday May 28, 2004 @11:10AM (#9277896) Homepage
    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.
    • > 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 te
      • 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

      • Re:In support of Unsanity (Score:4, Interesting)

        by John Siracusa ( 4209 ) on Saturday May 29, 2004 @10:07PM (#9287913) Homepage

        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

      • 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 wan

  • Bang head here... (Score:5, Interesting)

    by dpbsmith ( 263124 ) on Friday May 28, 2004 @02:40PM (#9280100) Homepage
    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."

    • 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,

      • Re:Bang head here... (Score:3, Insightful)

        by dpbsmith ( 263124 )
        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

    • Re:Bang head here... (Score:3, Insightful)

      by allgood2 ( 226994 )
      >>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 experienc

  • why? (Score:3, Interesting)

    by Anonymous Coward on Friday May 28, 2004 @04:57PM (#9281297)
    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? (Score:2, Informative)

      by blackdragon7777 ( 720994 )
      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 (a

  • APE + Menucracker equaled bad (Score:2, Informative)

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

  • I feel obliged to say (Score:1, Offtopic)

    by Ilgaz ( 86384 )
    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.
    • 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:-(

  • AbiWord, Firefox, TextSoap crash only with APE (Score:5, Interesting)

    by ankhank ( 756164 ) on Saturday May 29, 2004 @04:02PM (#9286497) Journal
    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.

  • APE is EVIL!!! (Score:4, Interesting)

    by WiseWeasel ( 92224 ) on Monday May 31, 2004 @05:54AM (#9295280)
    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!

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close