[yukon]

Wow, this thread got heavy into the logic. I'm learning a bit, I think, but I'll just state my opinion as an end user.

Applications communicate, which is good, it's expected and helpful behavior, very nice things can result, bad things seem to only happen when an application handles the message incorrectly (IANAOSXProgrammer). I don't really know what all these things are doing that they can get into other processes through plugin-type functionality and change behavior in an unintended (by apple or application programmer) general way ("All Applications Now Are Green And Play MP3s" etc.), but this seems really...well, like a hack. It can be misused, it isn't hard to make a mistake, it can screw up applications. Maybe it's difficult on OS X to do this kind of stuff, that mach_inject is difficult to use this way, because it's not really supposed or intended to be done.

I had my share of extension conflicts, meaning everything from actual conflicts to load order problems, to infamous version incompatibilities...usually, it was the author of the extension who would take the blame, but there was always a little corner of ire reserved for Apple who put me in the position. Same for APE and it's modules I suppose. It's not "evil" but it's against good design principles and circumvents efforts made to stop it from happening, but there's a demand, so IMHO Apple needs to stop this from happening and create/allow a real way to do some of the kind of modifications that people want APE modules for.

(btw, found SIMBL on my machine, it was pithhelmet, thanks, mind-at-ease. Pacificst is really cool, I don't use it much but it helps me get out of the "crap, now I need to reformat again" problems. BootCD, great for putting DiskWarrior+TechTool etc on the same CD. MenuMeters, was really awesome for my old modem connection, but I have routers with rapidly blinking lights now, and my G4 is getting old enough that any animated CPU monitor only shows 10% to 99% usage and doesn't help when it's at 99%...using aquamon on a very slow update now, but my menubar space feels a little empty )

[goMac]

The problem is with themes there is no other way to do it. The only other option is creating a kext, which very well CAN bring down the whole system.

Once again, in comparison to APE, mach_inject is significantly less risky because it doesn't make broad injections without someone coding their own daemon, at which point it becomes a lot like APE.

The comparison between APE and mach_inject was just to make a distinction. No where was Duality brought into the conversation, although you certainly could substitute Duality for APE in that comparison.

My point in comparing XTender (Duality's Application Enhancer) and APE is that XTender is significantly less bloated, and easier to deploy. It also uses a significant amount less of reverse engineering than APE (for a code injector ).

[Person Man]

There is only one problem I have here.

First, I'm not trying to minimize the problems that developers have with APEs causing their applications to crash. Especially when the (ignorant, in many cases) end user blames the developer of the application that crashed.

The problem I have is with the way developers handle the APE situation. Their answer is a simple, "Do not use APE. Period. It is the work of the devil. It is evil. Especially if you want to use my application."

Excuse me? I happen to like the functionality that APE provides. That's why I have it on my system. Most of the applications I run work fine alongside APE. Yours doesn't. Fine. Tell me to add your application to the exclude list first and see if that fixes the problem. If it does, then great. Best of both worlds. If it doesn't fix the problem, THEN try disabling APE entirely.*

Most developers here give a knee-jerk "get rid of APE. period." as the answer to the crash. Sure, it takes more time to do it the other way, but it avoids scaring users unnecessarily.

* Note: if an application crashes on MY (me, personally) system, the first thing I do is disable any system-wide patch programs/frameworks/whatever and try the application in question again, before e-mailing a developer about a bug. I'm sure most developers would love it if everyone did this before complaining.

[CharlesS]

Originally posted by yukon:
[some really well said comments, up until this:]

It's not "evil" but it's against good design principles and circumvents efforts made to stop it from happening, but there's a demand, so IMHO Apple needs to stop this from happening and create/allow a real way to do some of the kind of modifications that people want APE modules for.

Apple used to have such a method. It was called extensions. It didn't turn out so well, because unfortunately the only way to do a lot of the things that these APEs do is to use hacks like APEs which can cause application instability and weird behavior.

(btw, found SIMBL on my machine, it was pithhelmet, thanks, mind-at-ease. Pacificst is really cool, I don't use it much but it helps me get out of the "crap, now I need to reformat again" problems. BootCD, great for putting DiskWarrior+TechTool etc on the same CD.

Just to clarify, to make sure no one misunderstands this - Pacifist and BootCD do not use APE or mach_inject, and do not patch other apps on your system in any way. What BootCD does is somewhat unorthodox as OS X wasn't designed to boot to the Finder or Dock from a boot CD or to be stripped down enough to do so, but that's the extent of it.

[CharlesS]

Originally posted by Person Man:
There is only one problem I have here.

First, I'm not trying to minimize the problems that developers have with APEs causing their applications to crash. Especially when the (ignorant, in many cases) end user blames the developer of the application that crashed.

The problem I have is with the way developers handle the APE situation. Their answer is a simple, "Do not use APE. Period. It is the work of the devil. It is evil. Especially if you want to use my application."

Excuse me? I happen to like the functionality that APE provides. That's why I have it on my system. Most of the applications I run work fine alongside APE. Yours doesn't. Fine. Tell me to add your application to the exclude list first and see if that fixes the problem. If it does, then great. Best of both worlds. If it doesn't fix the problem, THEN try disabling APE entirely.*

Most developers here give a knee-jerk "get rid of APE. period." as the answer to the crash. Sure, it takes more time to do it the other way, but it avoids scaring users unnecessarily.

Well, the trouble is that the only way to really, completely be sure that APE is not the cause of a problem is to ask the user to remove it completely and see if the problem still occurs. Otherwise, the daemon is still running, and could still theoretically be responsible if there's a bug somewhere. And I don't know about you, but I want to make sure that a bug is actually mine before I spend tons of time working with a user to figure out and fix a bug that I can't reproduce on my machine!

* Note: if an application crashes on MY (me, personally) system, the first thing I do is disable any system-wide patch programs/frameworks/whatever and try the application in question again, before e-mailing a developer about a bug. I'm sure most developers would love it if everyone did this before complaining.

Indeed.

[Person Man]

Originally posted by CharlesS:
Well, the trouble is that the only way to really, completely be sure that APE is not the cause of a problem is to ask the user to remove it completely and see if the problem still occurs. Otherwise, the daemon is still running, and could still theoretically be responsible if there's a bug somewhere.

Well, yes. But the possibility still exists that simply excluding your app may fix the problem too. I don't know about you, but I'd give my users the least-disruptive (to their overall computing environment) solution first. If the problem still exists, then try disabling APE entirely (which is what I said before), which then gets the daemon out of the way.

And I don't know about you, but I want to make sure that a bug is actually mine before I spend tons of time working with a user to figure out and fix a bug that I can't even reproduce on my machine!

I agree. Which is why I disable any "system enhancements" (and in the case of APEs, add the app in question to the exclude list first before turning APE off globally) to make sure that the bug is actually yours before I e-mail you about it.

[yukon]

Person Man- First of all, watch out for frying pans (you greatest man you ;-) Second, I imagine developers could despise APE because they wrote their programs to do things a certain way, and take pride in their work. When APE injects it's own code and that of random modules without asking and even causing crashes and making work for the developers, it's sorta like "**** off! My program, get out you *******s!" ;-)

CharlesS, RE: Apple fix- I don't want to see extensions, I'd like to see Apple create some kind of method of theming that doesn't hack stuff (I have no idea if this is feasible for non-system applications or requires redoing interfaces per application), some nice and clean way of adding things to the menubar....adding the things good modules do as features at least...they've been responding to my requests actually, I was really happy to see a contrast slider in Universal Access ;-)

Didn't mean to imply your apps use these methods, everyone's work was suddenly being questioned, and I like your applications. And despite the use of menucracker, I'd been using Basilisk's MenuMeters for quite a while, I found it very useful and had no trouble with it (the trouble was Application Switcher Menu ("ASM"), which I've since weaned myself off of :-\).

[Person Man]

Originally posted by yukon:
Person Man- First of all, watch out for frying pans (you greatest man you ;-) Second, I imagine developers could despise APE because they wrote their programs to do things a certain way, and take pride in their work. When APE injects it's own code and that of random modules without asking and even causing crashes and making work for the developers, it's sorta like "**** off! My program, get out you *******s!" ;-)

I know that. I also suspect that APE is "singled out" only because it's much more high profile than any of the other programs that do their work using similar means.

Let me use another analogy. The people who automatically say "disable APE entirely first" instead of what I proposed are similar to doctors who would say... "Only get an MRI to diagnose _____." What happens when 90% of the time, a simple (and cheaper) X-ray will also diagnose _____? This is no different.

Oh, and I happen to LIKE frying pans... I DO hate Triangle Man, though. All he ever wants to do is fight.

[Person Man]

Originally posted by yukon:
CharlesS, RE: Apple fix- I don't want to see extensions, I'd like to see Apple create some kind of method of theming that doesn't hack stuff (I have no idea if this is feasible for non-system applications or requires redoing interfaces per application), some nice and clean way of adding things to the menubar....adding the things good modules do as features at least...they've been responding to my requests actually, I was really happy to see a contrast slider in Universal Access ;-)

Two problems... Apple wants to reserve the Menu Extras functionality for themselves alone, and neither do they want to "support" theming. Something about "interface consistency," which they seem to do a good job of ignoring, themselves.

[Basilisk]

I didn't say that plugins cannot break memory protection. Yes, no system is perfect and there will be exploits such as in InputManagers that get outside the limits that the plug-in is designed to have.

Code or data inside the same memory space as your application don't break memory protection. Code loaded from other sources (wanted or not) don't violate memory protection _unless_ they actually change or patch memory?

Isn't that just saying that patching is wrong? Where did the memory protection argument come in? What precisely does memory protection mean to you? That you have complete control over your memory space? My point in this regard has always been that you don't control it completely. If I send you deliberately corrupt data over IPC and you crash as a result have I violated memory protection?

Just say patching is risky, say its inconsiderate, say its unsupported.

Then quit spreading them.

Oh please, I'm not the one using the tortured analogy of home breakin. Its loaded terminology and its misleading. Using it to make your point what I'm arguing with. I DON'T disagree with your basic point, I just wish that the developers (you included) who don't like APE resisted the urge to leap to extreme examples and inflammatory terms.

Hell, its bad if only because the analogy doesn't hold together. Its not your house. Its _my_ house, and I invited you and another developer in. Their precense in the same room with you isn't yours to control.

Look, I understand that we're just arguing terminology at this point. You have a different view of what "memory protection" means in terms of guarantees about your application runtime environment. All I can point out (repeating as necessary) is that your definition of the term doesn't actually exist on MacOS X.

The designers of OS X wrote the whole thing specifically to prevent things like this.

Ugh, you know better. Would it shock you to know that Apple themselves shipped a patching hack from 10.3 to 10.3.2 (it was removed becuase it was a license violation). Does this mean I believe Apple sanctions haxies? Nope, it just means that attempting a call to authority is a bad argument to make from either side of the debate.


Alex

[Person Man]

Originally posted by Basilisk:
Ugh, you know better. Would it shock you to know that Apple themselves shipped a patching hack from 10.3 to 10.3.2 (it was removed becuase it was a copyright violation).

It wouldn't shock me, but this seriously intrigues me. What exactly did Apple include, and why? What did it do? Whose copyright was it to begin with?

[CharlesS]

Originally posted by yukon:
CharlesS, RE: Apple fix- I don't want to see extensions, I'd like to see Apple create some kind of method of theming that doesn't hack stuff (I have no idea if this is feasible for non-system applications or requires redoing interfaces per application), some nice and clean way of adding things to the menubar....adding the things good modules do as features at least...they've been responding to my requests actually, I was really happy to see a contrast slider in Universal Access ;-)

Oh, ok. Sure, we're in agreement then. I wouldn't have any problem with Apple providing a method for theming or menu extras. Since they have the original code to the items in question, there would be absolutely no need for them to inject code to do that. I really wish Apple would let third parties write Menu Extras, because I agree, Basilisk's are quite nice, and it would be great to be able to use them without needing to have code-injecting stuff on my system.

I understand Apple's reasoning to not include these, because they are trying to avoid every third-party application like AIM, MS Office, etc. polluting the menu bar with lots of menu extras. However, this can already be done with background apps using NSStatusItem, and menu items put up in such a way are more difficult to remove since you can't just command-drag them off the menu bar...

[CharlesS]

Originally posted by Basilisk:
Code or data inside the same memory space as your application don't break memory protection. Code loaded from other sources (wanted or not) don't violate memory protection _unless_ they actually change or patch memory?

Isn't that just saying that patching is wrong? Where did the memory protection argument come in? What precisely does memory protection mean to you? That you have complete control over your memory space? My point in this regard has always been that you don't control it completely. If I send you deliberately corrupt data over IPC and you crash as a result have I violated memory protection?

Sorry, I didn't state that very well. Yeah, memory protection has nothing to do with it in the case of a plug-in doing things it shouldn't. However, an app patching code in a completely different app definitely violates the spirit of memory protection, meaning that it does the sort of thing that MP is meant to prevent. We had to put up with this kind of stuff for a long time; now it's finally better, and people are trying to bring back the old way.

Ugh, you know better. Would it shock you to know that Apple themselves shipped a patching hack from 10.3 to 10.3.2 (it was removed becuase it was a copyright violation). Does this mean I believe Apple sanctions haxies? Nope, it just means that attempting a call to authority is a bad argument to make from either side of the debate.

Documentation, please?

[CharlesS]

Originally posted by Basilisk:
Hell, its bad if only because the analogy doesn't hold together. Its not your house. Its _my_ house, and I invited you and another developer in. Their precense in the same room with you isn't yours to control.

Look, I understand that we're just arguing terminology at this point. You have a different view of what "memory protection" means in terms of guarantees about your application runtime environment. All I can point out (repeating as necessary) is that your definition of the term doesn't actually exist on MacOS X.

According to Apple's own definition, memory protection is "a system of memory management in which programs are prevented from being able to modify or corrupt the memory partition of another program. Mac OS 9 does not have memory protection; Mac OS X does."

What did you think it meant? Programs are prevented from modifying other processes' memory space unless they really, really want to change the window color?

I compare this to a house that other processes are kept out of via a locked door. Programs can invite things in like plug-ins, since they load them themselves. Also, programs can talk to each other via the telephone, but you shouldn't be able to just break in without permission.

Don't like that? Well, let's look at this with my user hat on. I use a bunch of programs for production work, and I depend on them to work exactly as they are advertised to. I install some other app, and unbeknownst to me, it includes code which injects code into my other apps, causing them to behave erratically. Even from a user's standpoint, I didn't invite it, it broke in. Plain and simple.

[rjenkinson]

Originally posted by CharlesS:
Well, let's look at this with my user hat on. I use a bunch of programs for production work, and I depend on them to work exactly as they are advertised to. I install some other app, and unbeknownst to me, it includes code which injects code into my other apps, causing them to behave erratically. Even from a user's standpoint, I didn't invite it, it broke in. Plain and simple.

uh, no. when you installed that program, you invited it in. you installed it because you knew what the program does and wanted it on your system. it did not break in. you handed it the key. if what the program did was unknown to you, you foolishly handed your house key to a perfect stranger. the bottom line is that if a user wants to modify how applications behave on their system, they're free to do that whether the original developer likes that or not.

-r.

[Chuckit]

Originally posted by CharlesS:
Well, let's look at this with my user hat on. I use a bunch of programs for production work, and I depend on them to work exactly as they are advertised to. I install some other app, and unbeknownst to me, it includes code which injects code into my other apps, causing them to behave erratically. Even from a user's standpoint, I didn't invite it, it broke in. Plain and simple.

Do you mean to say that most people install APE under the impression that it doesn't do anything at all? Surely if somebody installs APE, it isn't "unbeknownst" to them that it's going to perform its primary function of affecting other apps. They may be a little naive when it comes to troubleshooting, but I don't think Unsanity are exactly being sneaky about what APE does. It's not as though they advertise it as a coffee-maker only to secretly patch the apps on your computer.

[CharlesS]

Originally posted by Chuckit:
Do you mean to say that most people install APE under the impression that it doesn't do anything at all? Surely if somebody installs APE, it isn't "unbeknownst" to them that it's going to perform its primary function of affecting other apps. They may be a little naive when it comes to troubleshooting, but I don't think Unsanity are exactly being sneaky about what APE does. It's not as though they advertise it as a coffee-maker only to secretly patch the apps on your computer.

Did you have a look at that list of apps that use mach_inject that was linked to in this thread?

How many users of QuicKeys X do you suppose know that it uses mach_inject?

[Basilisk]

Yeah, memory protection has nothing to do with it in the case of a plug-in doing things it shouldn't.

Well I'm glad we can agree on that.

Documentation, please?

On a 10.3 through 10.3.2 system, "strings /Applications/Utilities/Keychain Access.app/Contents/Resources/Enable.menu/Contents/MacOS/Enable" is very informative.

I also should note (and editted my post above to reflect this) that I misspoke earlier. It wasn't a copyright issue but it was a license issue.

What did you think it meant? Programs are prevented from modifying other processes' memory space unless they really, really want to change the window color?

I always understood what you mean, my objection is to the "APE kills baby seals, steals your car keys, strangles your children, etc. etc." language used.

You arguing a principle (the "spirit"), I'm arguing reality. That's all. The reality is that whatever definition you use it doesn't match the actual implementation. Programs aren't prevented from modifying other process memory within some well defined constrints. APE didn't create this situation, and if Unsanity withdrew it tomorrow that wouldn't change the reality.

Well, let's look at this with my user hat on.

I think rjenkinson pretty much explained the user point of view on this.

Alex

[goMac]

Originally posted by CharlesS:
Did you have a look at that list of apps that use mach_inject that was linked to in this thread?

How many users of QuicKeys X do you suppose know that it uses mach_inject?

Sorry, but I have to disagree. I doubt most users care, or even if they cared, would know what that means. I see no reason why they should have to advertise that.

[CharlesS]

Originally posted by goMac:
Sorry, but I have to disagree. I doubt most users care, or even if they cared, would know what that means. I see no reason why they should have to advertise that.

Yeah, but they would notice and care if the rest of their apps started crashing or doing strange things. They don't have to know the reason, but they will know it sucks.

Because they don't know about mach_inject, they'll probably blame it on the app developer or on Mac OS X itself. They'll have no way of isolating the real problem, and therefore no way of fixing it.

I think it's really suspect for those apps to use dirty hacks without telling anyone about it.

[CharlesS]

Originally posted by Basilisk:
You arguing a principle (the "spirit"), I'm arguing reality. That's all. The reality is that whatever definition you use it doesn't match the actual implementation. Programs aren't prevented from modifying other process memory within some well defined constrints. APE didn't create this situation, and if Unsanity withdrew it tomorrow that wouldn't change the reality.

The problem is, Mac OS X has things like memory protection for a reason. It is to make the system and applications more stable and prevent things from conflicting and messing with each other. If people are going to continue to find ways to hack around it, then it is all thrown out the window. And that makes me

[Chuckit]

Originally posted by goMac:
Sorry, but I have to disagree. I doubt most users care, or even if they cared, would know what that means. I see no reason why they should have to advertise that.

In this case, I'm actually inclined to agree with Charles. Many users probably don't realize that there's a possibility QuicKeys X could cause instability or incompatibilities. With APE and many mach_inject programs, this isn't really an issue, because it's pretty obvious what you're installing, but I think QuicKeys X was a good example of a program that might sneak in under the radar.

[goMac]

Originally posted by CharlesS:
Yeah, but they would notice and care if the rest of their apps started crashing or doing strange things. They don't have to know the reason, but they will know it sucks.

Because they don't know about mach_inject, they'll probably blame it on the app developer or on Mac OS X itself. They'll have no way of isolating the real problem, and therefore no way of fixing it.

I think it's really suspect for those apps to use dirty hacks without telling anyone about it.

This is handled the same way that APE problems would be. Ask the user if he/she is running anything funny, and isolate the problem to QuicKeys. A user isn't going to go "Oh... this program is using mach_inject, it must be the source of my problems". I know its easy to ask the user if they are using any programs that use mach_inject, but if the user doesn't know that QuicKeys could be the source of their problems due to how it alters the system, they probably won't remember which apps of theirs use mach_inject.

The best thing to do is just trace it back to QuicKeys like you would with APE.

I didn't hear of any QuickKey's disaster but it sounds like there was one, so obviously people may have bigger opinions on it than I.

[CharlesS]

Originally posted by goMac:
This is handled the same way that APE problems would be. Ask the user if he/she is running anything funny, and isolate the problem to QuicKeys. A user isn't going to go "Oh... this program is using mach_inject, it must be the source of my problems". I know its easy to ask the user if they are using any programs that use mach_inject, but if the user doesn't know that QuicKeys could be the source of their problems due to how it alters the system, they probably won't remember which apps of theirs use mach_inject.

That's the entire problem! How am I, or a user, supposed to keep track of every single program that uses a dirty hack like this, so I can ask if they have a billion programs installed in order to troubleshoot a problem?! What a waste of time!

The best thing to do is just trace it back to QuicKeys like you would with APE.

I didn't hear of any QuickKey's disaster but it sounds like there was one, so obviously people may have bigger opinions on it than I.

I have no idea if there was a QuicKeys disaster or not. It just torques me off that they would be relying on dangerous hacks without even saying anything about it or making it known. The annoying thing with an app like QuicKeys is, a lot of what it does could just be done with AppleScript GUI Scripting anyway (which, I believe, is how iKey works).

[CharlesS]

Originally posted by Basilisk:
Well I'm glad we can agree on that.

BTW, how convenient of you to quote me so selectively. I'll say it again: Plug-ins don't break memory protection, but having apps modify each other during runtime certainly does.

[Basilisk]

BTW, how convenient of you to quote me so selectively

Sorry, it was necessary. It really is just about the only thing you've said that I felt was moderate in its response to the discussion at hand.

I'll say it again: Plug-ins don't break memory protection, but having apps modify each other during runtime certainly does.

If plugins aren't a memory protection violation (even when unwanted), what about if I redirect your framework load using external mechanisms (environment vars, on disk replacement, etc)? I can give your app a custom version of AppKit that can do anything it wants. Is that within the "spirit" of memory protection? In either case the entry points for the calls are different than what you think, but I didn't have to execute any code in-process to do it. How is this different if the net effect is the same?

Alex

[CharlesS]

Originally posted by Basilisk:
If plugins aren't a memory protection violation (even when unwanted), what about if I redirect your framework load using external mechanisms (environment vars, on disk replacement, etc)? I can give your app a custom version of AppKit that can do anything it wants. Is that within the "spirit" of memory protection? In either case the entry points for the calls are different than what you think, but I didn't have to execute any code in-process to do it. How is this different if the net effect is the same?

Because you are using unsavory hacks to work around the memory protection.

[goMac]

I think the good way to put it is plugins are like someone knocking on your door, and you nicely open it and let them in. Programs like APE (or Duality admittedly) come to your door, break it down with a battering ram, and then join the party.

[King Bob On The Cob]

Originally posted by CharlesS:
Well, the trouble is that the only way to really, completely be sure that APE is not the cause of a problem is to ask the user to remove it completely and see if the problem still occurs. Otherwise, the daemon is still running, and could still theoretically be responsible if there's a bug somewhere. And I don't know about you, but I want to make sure that a bug is actually mine before I spend tons of time working with a user to figure out and fix a bug that I can't reproduce on my machine!

Tell them to log in holding shift down. (It will keep the daemon from launching too)

[Developer]

Originally posted by King Bob On The Cob:
Tell them to log in holding shift down.

What about users that don't tell you? If your app crashes users are first going to blame it on you. And if it's shareware most won't bother to tell you and you land in the trash.

APE and other stuff that injects code in your app are extremely annoying. It's difficult enough to keep your work bug free; you don't need someone else messing around in your app as well.

[Basilisk]

Because you are using unsavory hacks to work around the memory protection.

And that's pretty much where we end up. It seems to me that you're overly concerned with the mechanism and not the effects (the risks). In-process patching is "unsavory" but using something else (undocumented or not) isn't as bad (or at least seems to be less heinous in your mind).

I'll agree that patching is outside the "spirit" of memory protection, though I think that's true regardless of mechanism. Which is why I don't think the argument should revolve around the claim of memory protection.

Focusing on the mechanism and drawing a line between one mechanism and the other gives folks a free ride. Notice in this very thread we had someone discover SIMBL for the first time. They all belong in one bucket together (yes, mach_inject belongs here too, its not any "safer").

Recall that I orginally joined this thread it was in response to:

With a plug-in like a QuickTime codec, the author of the host app has deliberately coded his app to accept plug-ins. The author has taken into consideration the things that the plug-ins might do and has coded the rest of the app appropriately. Also, there are often limitations on what plug-ins can do, how many things they can mess with, and usually there's enough separation between them that they can't really conflict with each other.

Hearing that users might conclude that plugins are "safer" than APE. However, since then we've established that:

- For some kinds of plugins the author doesn't deliberately code, they load automatically.
- The author may or may not be aware of this.
- It is easy to create plugins that modify or patch code at runtime. This applies to all plugins, not just input managers, one can do this with QT components or CMMs (witness Ittec's Finder modifications). In short, plugin code is not meaningfully sandboxed.

Focus on APE's use of mach_ports to patch is (using the tortured metaphor again) like complaining that the person in your living room came in through the back window instead of the front window. Its ignoring that the problem (and risks) are that he's in the house in the first place.

Alex

[CharlesS]

Originally posted by Basilisk:
And that's pretty much where we end up. It seems to me that you're overly concerned with the mechanism and not the effects (the risks). In-process patching is "unsavory" but using something else (undocumented or not) isn't as bad (or at least seems to be less heinous in your mind).

Argh, why are you deliberately twisting my words? Here is my position in very simple terms that you can understand.

1. Patching - bad!

2. Abusing plugins - bad!

3. Normal use of plugins - good!

When did I ever say that abusing and exploiting plug-ins was "not as bad" or "less heinous" than patching by any other means?

I'll agree that patching is outside the "spirit" of memory protection, though I think that's true regardless of mechanism. Which is why I don't think the argument should revolve around the claim of memory protection.

The point is very simple - the developers built memory protection in there for a reason - to stop things like this from happening. If you work around it, you are abusing the system.

Focusing on the mechanism and drawing a line between one mechanism and the other gives folks a free ride. Notice in this very thread we had someone discover SIMBL for the first time. They all belong in one bucket together (yes, mach_inject belongs here too, its not any "safer").

Hearing that users might conclude that plugins are "safer" than APE. However, since then we've established that:

I do not care what mechanism is used. And I certainly have not said that mach_inject or abusing plug-ins is "safer" than APE!

- For some kinds of plugins the author doesn't deliberately code, they load automatically.
- The author may or may not be aware of this.
- It is easy to create plugins that modify or patch code at runtime. This applies to all plugins, not just input managers, one can do this with QT components or CMMs (witness Ittec's Finder modifications). In short, plugin code is not meaningfully sandboxed.

- For some kinds of protocols that aren't explicitly mapped to some application, the OS may cache some app as a protocol on first viewing.
- The user may or may not be aware of this.
- It is easy to create a disk image containing an evil application which claims to support a nonexistent protocol, then get a user to unknowingly launch the application by clicking a link. In short, the URL handling mechanism is not meaningfully sandboxed.

Therefore, using the help: exploit to erase your home folder isn't that bad, right? Since there are other means to do the same thing using official Apple mechanisms (LaunchServices!).

In other words, what the hell does the fact that there's another way to do the same thing have to do with anything? Don't abuse the system.

[Mike S.]

It's fun reading the two of you debate technical philosophies

Let me pose a very simple question: You both agree that code injection is bad but code injection seems to be the only way to provide certain features that users desire.

Which is better, give the user the features they want even though it's not technically ideal or deny the features because there is a technical possibility that they can cause trouble for some apps and/or the system?

This really seems to be the only issue a user would really care about. All this hypothetical stuff is fascinating but if there is no right/safe way to do these things than what other choice is there?

[gorickey]

I'm so proud of the madness this thread has created...



Continue.

[CharlesS]

Originally posted by Mike S.:
It's fun reading the two of you debate technical philosophies

Let me pose a very simple question: You both agree that code injection is bad but code injection seems to be the only way to provide certain features that users desire.

Which is better, give the user the features they want even though it's not technically ideal or deny the features because there is a technical possibility that they can cause trouble for some apps and/or the system?

This really seems to be the only issue a user would really care about. All this hypothetical stuff is fascinating but if there is no right/safe way to do these things than what other choice is there?

Sometimes there's no other way to do it. Sometimes the developers are just not being creative, though. For example, QuicKeys doesn't need to patch anything to click on a button in the UI. It could just use AppleScript GUI Scripting to do that, like iKey does.

Maybe Apple should build a warning system into the OS that detects when something is getting patched and puts a dialog box saying "Warning: The application 'L33T Black Windows Hack!!!' is trying to modify this application. If the application starts acting up, get rid of the hack before you start complaining to CharlesS about it!"

[yukon]

One more thing I'll mention or try to clear up. Patching this way is evil because it's concidered evil by generally accepted principles of programming well, because of, Two, patching applications in memory, applications probably unknown at the time of writing the patch, can cause undesirable results like crashing and other random bugs, which is bad. The "hidden bugs" argument is kinda funny in a way, without screwing with the application, there's no bug, hidden bugs would be where someone uses an uncommon API function that has a bug no one noticed causing a problem with the OS (like VPC's kernel panic years ago), not when someone gets an application to do something it wasn't going to do and it gets confused.

Just wanted to clear that up. This kind of patching (not like "here linus, here's a patch to the source that fixes blibbity blah") is concidered evil, because it leads to bad things like crashing and reliance on hacks upon hacks upon crufty patched code, people call it evil because they want to avoid it like the plague. It's not bad if done perfectly with total knowedge and control of everything, but it won't be.....APE might be less bad if it's done well, but it's still not good.

Maybe I've just been hanging out with the *NIX type guys too much ;-)

[Basilisk]

Argh, why are you deliberately twisting my words?

Do you understand that it is possible for someone to agree with you technically but take issue with how you present the risks?

You keep insisting on conflating a bunch of different arguments together and that leads to misrepresentations. Users don't get the subtle distinctions and then the wives tales start.

Its not about memory protection, its not about mechanism, its about patching.

I agree with all of:

1. Patching - bad!

2. Abusing plugins - bad!

3. Normal use of plugins - good!

And that's really where the discussion should end. The problem I have is that these conversations keep getting all sorts of extras and bad analogies thrown in. The home breakin analogy will get passed around long after the rest of the content is forgotten. Users will remember that APE is like a breakin and will never know that Quickeys is like a carjacking (or whatever).

Case in point:

Therefore, using the help: exploit to erase your home folder isn't that bad, right? Since there are other means to do the same thing using official Apple mechanisms (LaunchServices!).

Are you really trying to link security exploits with the rest of the discussion? Its shrill and unnecessary, but I doubt that was your intent.

That said, do you think less-technical readers of this thread are more or less likely to believe or misremember that APE is a security exploit when you use this (bad) example? This is how the wives tales start. When stuff like this gets posted users will pick some nonsense up and in a week I'll be doing one of:

- Explaining to my mother-in-law that APE isn't breaking into her computer.
- Explaining to some user that MenuCracker doesn't have anything to do with security "cracking".
- Explaining to my mother-in-law that her memory protection isn't "broken" and therefore in need of replacement.

Finally, I should clarify:

And I certainly have not said that mach_inject or abusing plug-ins is "safer" than APE!

Sorry, I should have been clearer that the mach_inject vs. APE point was intended for goMac.

This really seems to be the only issue a user would really care about. All this hypothetical stuff is fascinating but if there is no right/safe way to do these things than what other choice is there?

Developers don't get to choose, and in truth I think that's where the house analogy really collapses. Its a safe bet that if something is technically possible someone will figure out a way to do it if there's user demand (I can think of no better example than the various theming tools). Users will invite into their house whoever they damn please and often have a not entirely unreasonable expectation that their houseguests will get along.

In short, there is no decision to make at all, someone will do it, right or wrong. And lets remember that "right" and "wrong" here are pretty arbitrary distinctions based on technical opinions. Developers are contentious creatures (myself included), and like black and white terms. The right thing and the wrong thing are "religious" issues. Users don't seem to care .

The comments here and in the Unsanity blog are mostly developers who feel that runtime hacks are the wrong thing, but its also pretty clear that users want those features. Even well-informed users in this thread admit that they want the features despite the risks.

One unfortunate consequence of religious issues is that it tends to lead to spiraling arguments with progressively more aggressive terminology. Half-complete arguments are made, or strongly worded analogies are created. On the Unsanity blog comments we're already to the point where APE is compared to arson. I object to that spiral becuase I think its misleading, and its pretty much why I've stuck around in this thread so long.

Alex

[CharlesS]

Originally posted by Basilisk:
The problem I have is that these conversations keep getting all sorts of extras and bad analogies thrown in. The home breakin analogy will get passed around long after the rest of the content is forgotten. Users will remember that APE is like a breakin and will never know that Quickeys is like a carjacking (or whatever).

Any analogy I bring up about APE includes QuicKeys as well and any other app that uses similar methods.

That said, do you think less-technical readers of this thread are more or less likely to believe or misremember that APE is a security exploit when you use this (bad) example? This is how the wives tales start. When stuff like this gets posted users will pick some nonsense up and in a week I'll be doing one of:

- Explaining to my mother-in-law that APE isn't breaking into her computer.
- Explaining to some user that MenuCracker doesn't have anything to do with security "cracking".
- Explaining to my mother-in-law that her memory protection isn't "broken" and therefore in need of replacement.

If your mother-in-law doesn't understand what APE is, what it does, and what dangers it presents, and how to resolve issues that may come up, she should not be using APE. APE is not a tool for novice users.

Developers don't get to choose, and in truth I think that's where the house analogy really collapses. Its a safe bet that if something is technically possible someone will figure out a way to do it if there's user demand (I can think of no better example than the various theming tools). Users will invite into their house whoever they damn please and often have a not entirely unreasonable expectation that their houseguests will get along.

The reason for the house analogy is because that is what memory protection is designed to provide - separation between apps. This is part of the way the system is supposed to work, by design. Hence the metaphor of a house with four walls - walls being a feature designed to keep others out. Unless the program which lives in the house invites something in, other programs should not be able to enter, and should only be able to communicate via the IPC telephone. The metaphor works, but you have to keep switching the players around. The program lives in the house, not the user. The user is like the mayor, or like a policeman or something. If he chooses, he can turn a blind eye to programs breaking into other program's houses, but that will cause the social order to break down. Really, the whole town is better off if the law is enforced against house-breaking programs.

[BoulderDash]

Originally posted by Arkham_c:
It may be the case that the framework is not the problem, but if you cannot use modules that utilize the framework without problems, what's the point?

Umm,
Wouldn't this be like saying that you should completely stop using Safari (framework) because someone coded some pages wrong (modules) that cause it to crash? If the blame isn't in the framework, as you even suggest it might not be, it seems flippant to discredit it because of developers developing poor modules for it.

BD

[CharlesS]

Originally posted by BoulderDash:
Umm,
Wouldn't this be like saying that you should completely stop using Safari (framework) because someone coded some pages wrong (modules) that cause it to crash? If the blame isn't in the framework, as you even suggest it might not be, it seems flippant to discredit it because of developers developing poor modules for it.

BD

1. If Safari were crashing when loading poorly written pages, that would be a bug in Safari since it should handle errors more gracefully than that. If it were crashing all the time in response to badly written web pages, damn straight I'd stop using it and switch to something else.

2. This analogy doesn't work at all anyway, because Safari isn't messing with other apps. The problem with APE is the task that it is designed to do. It is designed to patch other apps. Without APE, mach_inject, or some similar hack, OS X is designed so that one poorly-written app can't affect other apps, or the system. Using APE breaks that down. Yeah, if you had God APE modules that were perfectly written and had no bugs, then this wouldn't be a problem, but unfortunately that's never going to be the case.

In OS 9, badly written apps were able to screw up other apps, and crash the whole OS. Result: OS 9 crashed all the time. "Oh, it's just the the poorly written apps' fault!" Well, yeah, but it's also OS 9's fault for letting them do that in the first place.

[Basilisk]

Well I'm sad to say that readers here have proven CharlesS correct, I owe him an apology. Sorry, CharlesS, I had placed more faith in the readers than was warranted.

Because a part of one of my earlier posts was taken out of context it runs the risk of becoming the same sort of "old wives tale" that both he and I bemoan.

To "A Fan" posting on the Unsanity blog... Charles and I disagree about what is guaranteed by memory protection in a runtime environment. This does not mean that haxies are perfect or blameless for your applications crashing. My original post about memory protection had two points:

1. Memory protection is not absolute, and this doesn't make memory protection "broken" (though Charles would say the "spirit" is broken).
2. Plugins can do the same thing, and that's not a literal violation of memory protection.

PATCHING, in whatever its form, has risks. The point of my conversation with Charles was to try to shift the coversation away from "violation of memory protection" as a argument (and the resulting house analogy) and simply to say that patching has risks. This is a broader statement, and its an important distinction to me, because it drives the focus away from mechanism and to the thing that actually creates the risks. I and Charles agree about the fundamentals, I was taking issue with his presentation of the risks.

I'm sad to see that you took that out of context and turned it into an argument that haxies cannot cause harm. That's not true. All patching has risks. Those risks are the result of patching regardless of mechanism.

Alex

[Developer]

Originally posted by Basilisk:
Plugins can do the same thing, and that's not a literal violation of memory protection.

Plug-ins can make an applications crash when they are buggy, but they are intended to provide functionality within a certain specification. Haxies on the other hand by their nature are intended to provide functionality that is out of spec for the app. That's their purpose. This can cause inconsistencies in apps - even for a totally bug free haxie - that reduce stability.

No application for example needs to assume that a font menu looks different than what it constructs. If you change that or other things behind the app's back, and it crashes, then it's not the apps fault.

Therefore Unsanity's claim that an APE module is not at fault if it's not an APE thread that crashed is false.

[Basilisk]

Plug-ins can make an applications crash when they are buggy, but they are intended to provide functionality within a certain specification.

Please read back in the thread. I think this assertion is misleading (it was why I got into the thread in the first place). Plugins are not limited in any meaningful sense, and that fact has been exploited by SIMBL and others to change app behavior.

Focus on APE (or if you prefer, cross-process injection in whatever form) shifts the discussion in unnecessary ways (memory protection, gdb access, whatever). The rule of thumb for users should be that if the program claims to modify default application behavior it doesn't matter if its a plugin, APE or app. Its probably a patch and patches have risks.

Quick example, a while back I recall a thread (can't find it now) with a user insisting that Ittec was safe because it _wasn't_ an APE (he was contrasting it with FruitMenu). CMM's are a plugin, plugin = safe was his thinking.

Therefore Unsanity's claim that an APE module is not at fault if it's not an APE thread that crashed is false.

At no point have I ever claimed otherwise,


Alex

[CharlesS]

Originally posted by Developer:
Plug-ins can make an applications crash when they are buggy, but they are intended to provide functionality within a certain specification. Haxies on the other hand by their nature are intended to provide functionality that is out of spec for the app. That's their purpose. This can cause inconsistencies in apps - even for a totally bug free haxie - that reduce stability.

No application for example needs to assume that a font menu looks different than what it constructs. If you change that or other things behind the app's back, and it crashes, then it's not the apps fault.

Therefore Unsanity's claim that an APE module is not at fault if it's not an APE thread that crashed is false.

Thank you. That's what I've been trying to say the whole time, but in a concise and elegant form. Well said.

[CharlesS]

Okay, Basilisk:

Originally posted by Developer:
Plug-ins can make an applications crash when they are buggy, but they are [look! ->]***INTENDED***[<-look!] to provide functionality within a certain specification.

Originally posted by Basilisk:
Please read back in the thread. I think this assertion is misleading (it was why I got into the thread in the first place). Plugins are not limited in any meaningful sense, and that fact has been exploited by SIMBL and others to change app behavior.

Plug-ins are limited by design. They can only do more than what they are supposed to do by exploits like this that do something other than the plug-in's intended function. A specific case where a plug-in has been exploited does not mean that, as a rule, plug-ins have unlimited power and are designed to do so!

I cannot tell you how this makes me feel. It's like saying that having a lock on a door in general is exactly the same as leaving the door wide open because one particular type of lock is able to be picked.

[Basilisk]

Plug-ins are limited by design. They can only do more than what they are supposed to do by exploits like this that do something other than the plug-in's intended function. A specific case where a plug-in has been exploited does not mean that, as a rule, plug-ins have unlimited power and are designed to do so!

Plugins have unlimited power, including the power to crash the app. Its not a specific case, its the general case. Plugin developers have to make the effort to be well-behaved in the broadest terms (like, for example, don't crash because you'll take down the app).

I cannot tell you how this makes me feel. It's like saying that having a lock on a door in general is exactly the same as leaving the door wide open because one particular type of lock is able to be picked.

No, its like saying that having a lock on your door is not an absolute guarantee that your house won't be broken into. This isn't a unique fault in InputManagers, CMMs, or anything else. Its the reality of loading code into other applications. They can do anything they damn please from the risky (patching) to the dumb (nil dereference crash).

Why is saying that so objectionable? If someone's Finder is crashing its not a bad thing to tell them to disable CMMs.

I understand that you're trying to say that 99.9% of plugins don't patch code, and that many (if not most) don't cause crashes, but I don't understand why you're defending plugins as some unique riskless mechanism except when "exploited". Isn't the bad thing the patch?

Alex

[Developer]

Originally posted by Basilisk:
I understand that you're trying to say that 99.9% of plugins don't patch code, and that many (if not most) don't cause crashes, but I don't understand why you're defending plugins as some unique riskless mechanism except when "exploited". Isn't the bad thing the patch?

But plug-ins are not intended to exploit or patch the app. Plug-ins are intended to behave according to specifications the application developer set.
APE modules on the other are intended to patch applications. By their nature they are out of specification of the app. They are out of the scope of what the application developer could possibly ever foresee. It's like someone is throwing dices in your app. That's a nightmare.

And yes, plug-ins that exploit a plug-in API to do unspecified things are as bad as APE modules that exploit a debugger API to do unspecified things. But a plug-in's purpose isn't to do that (and the vast majority don't) while the purpose of all APE modules is to do it.

Plug-ins are intended to extend the functionality of an app according to defined specifications.
APE modules are intended to extend the functionality of an app out of specifications.

[Basilisk]

And yes, plug-ins that exploit a plug-in API to do unspecified things are as bad as APE modules that exploit a debugger API to do unspecified things. But a plug-in's purpose isn't to do that (and the vast majority don't) while the purpose of all APE modules is to do it.

Sure, my point is that they can, and thus are not absolutely safe.

Simply said, there's no sandboxing on plugins. I don't think that's a radical assertion (since its obviously technically true).

Again, the Ittec example holds. Users would be well advised to watch out for patches regardless of loading mechanism.

Plug-ins are intended to extend the functionality of an app according to defined specifications.
APE modules are intended to extend the functionality of an app out of specifications.

Fair enough, I'm just encouraging users not to assume that the mechanism matters. A user who has uninstalled APE isn't automatically safe from runtime patches installed.

Whether "bad apple" plugins are the 0.01% case or not they do exist and they are no safer than any other mechanism. Its a mistake real users make on this board and while we can argue "intent" of plugins all day long, its the reality that there are "exploits" in widespread use (PithHelmet comes to mind).

Alex

[Developer]

I didn't say that the mechanism matters. It was Unsanity that argued like that ("We're using official debugger APIs"). Their whole article is misleading and trying to shift blame to the application developers.

Whenever you mess around in an application behind its back bad things are prone to happen. As application developer there is no way to deal with this if every function call could be patched. It's simply impossible.

[CharlesS]

Originally posted by Basilisk:
Plugins have unlimited power, including the power to crash the app. Its not a specific case, its the general case. Plugin developers have to make the effort to be well-behaved in the broadest terms (like, for example, don't crash because you'll take down the app).

This is just not true. Yes, plug-ins can crash the app, since they live in the same memory space. But, it is not true that all plug-ins have unlimited power. The reason you're able to do this with InputManagers is because of the dynamic nature of the Cocoa runtime, and because the things are run early enough in the loading process to override things using poseAsClass: and the like. With any other type of plug-in, for example a QuickTime codec, running in plain old C or C++, you'd be more limited in what you could do.