Unsanity Developer Comes to APE's Defense 138
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."
APE and Shapeshifter works great for me (Score:2, Insightful)
tel{e,ly}tubby-like whaaaa? (Score:2)
LIKE, YOU KNOW???
Re:tel{e,ly}tubby-like whaaaa? (Score:1)
Re:tel{e,ly}tubby-like whaaaa? (Score:5, Informative)
Re:tel{e,ly}tubby-like whaaaa? (Score:1)
So instead, repeat after me:
teletubby-like Rosyna [unsanity.org]
Re:tel{e,ly}tubby-like whaaaa? (Score:3, Funny)
And two hours later... (Score:3, Funny)
Re:And two hours later... (Score:1, Offtopic)
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)
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
Re:Well.. I'm interested (Score:4, Interesting)
Bob
Re:Well.. I'm interested (Score:1)
Re:Well.. I'm interested (Score:1)
Re:And two hours later... (Score:2)
Flack about the URL handler exploits (Score:5, Informative)
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_sec
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)
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 (Score:1, Interesting)
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 RCDefau
RCDefaultApp doesn't prevent new URL handlers (Score:2)
A lot of people are missing the point, here. (Score:5, Insightful)
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)
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
Re:A lot of people are missing the point, here. (Score:3, Insightful)
Re:A lot of people are missing the point, here. (Score:1)
other (non-APE) audio routing tools (Score:1)
APE: Neither Blind nor Unique (Score:5, Informative)
Re:APE: Neither Blind nor Unique (Score:2, Redundant)
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:
Re:APE: Neither Blind nor Unique (Score:3, Insightful)
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
Re:APE: Neither Blind nor Unique (Score:2)
Re:APE: Neither Blind nor Unique (Score:1)
Re:APE: Neither Blind nor Unique (Score:2)
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)
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 (Score:3, Insightful)
> 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
Erf. (Score:2)
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)
...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.
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.
Yes, it's quite a hardship creating software for use in such an "impure" thing as the real world... ;)
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 (Score:2)
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)
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... (Score:2)
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)
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)
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)
Why is that?
http://www.redstonesoftware.com/osxvnc/OSXvnc.h
Re:why? (Score:2, Informative)
APE + Menucracker equaled bad (Score:2, Informative)
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)
Its nothing I am used in PC world (windows) or Linux.
Re:I feel obliged to say (Score:1)
AbiWord, Firefox, TextSoap crash only with APE (Score:5, Interesting)
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)
Re:Extensions for Mac OS X (Score:5, Informative)
Bob
Re: (Score:2, Interesting)
Re:Extensions for Mac OS X (Score:5, Interesting)
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.
MOD PARENT UUUUUUUUP (Score:4, Insightful)
Re:Extensions for Mac OS X (Score:5, Interesting)
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.
Re:Extensions for Mac OS X (Score:5, Informative)
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 (Score:2)
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 me
Re:Extensions for Mac OS X (Score:3, Interesting)
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
You can't be serious (Score:2)
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 a
Re:Extensions for Mac OS X (Score:4, Interesting)
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.
Re:Extensions for Mac OS X (Score:3, Informative)
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 (Score:2, Flamebait)
I mean, really, anything that makes the computer, at any level, unstable is not worth using.
Re:Extensions for Mac OS X (Score:5, Insightful)
Bob
Re:Extensions for Mac OS X (Score:2)
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 (Score:3, Insightful)
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 (Score:3, Funny)
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 (Score:3, Insightful)
Badly coded apps do not make anything but themselves unstable. A badly coded module makes every program unstable.
Re:Extensions for Mac OS X (Score:1)
Re:Extensions for Mac OS X (Score:5, Funny)
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 (Score:2)
Re:Extensions for Mac OS X (Score:3, Interesting)
No flash in Safari for you?
Re:Extensions for Mac OS X (Score:2, Flamebait)
So while the module types listed are indeed external pieces of code that can cause a crash, they don't run in e
Re:Extensions for Mac OS X (Score:2)
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 (Score:5, Informative)
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 (Score:1)
Re:Extensions for Mac OS X (Score:5, Insightful)
A haxie is injecting [rentzsch.com] 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 (Score:2)
Re:Extensions for Mac OS X (Score:2)
Re:Extensions for Mac OS X (Score:2)
Re:Extensions for Mac OS X (Score:2)
Re:Extensions for Mac OS X (Score:5, Interesting)
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 (Score:3, Insightful)
Knowing Unix as we do, we know this is impossible unless:
1. The application has installed something in syst
Re:Extensions for Mac OS X (Score:5, Informative)
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 (Score:5, Insightful)
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 (Score:4, Informative)
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 (Score:2)
"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
Re:Extensions for Mac OS X (Score:3, Insightful)
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 Andro
Re:Extensions for Mac OS X (Score:2)
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
Re:Extensions for Mac OS X (Score:2)
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-
Re:Extensions for Mac OS X (Score:1)
Re:Extensions for Mac OS X (Score:2)
mod parent down! (Score:3, Funny)
Re:mod parent down! (Score:2)
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! (Score:5, Interesting)
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! (Score:3, Interesting)
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 u
Re:mod parent down! (Score:2, Informative)
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 st
Re:mod parent down! (Score:1)
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! (Score:3, Insightful)
What was the similarity with extensions again?
Re:mod parent down! (Score:2)
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 inst
Re:Oh Joy! (Score:5, Insightful)
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! (Score:2)
Let's just say last year had more Carbon sessions than this year's WWDC.
Re:Oh Joy! (Score:3, Interesting)
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:APE is a very clever implementation (Score:1)
Re:APE is a very clever implementation (Score:2, Insightful)
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
Re:APE is crAPE (Score:3, Interesting)
That said, I LOVE FruitMenu, MenuMaster, and now Paranoid Android. In fac
Re:APE is crAPE (Score:2)
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.