This distinction becomes important when you want to install that customization on a device for which the stock launcher is not open source but has been customized to fit with other apps, or simply when you want multiple customizations from different people.

However, if you insist on something a little more concrete: what if you want to add new buttons to the Android notification center, add new features to the status bar, or affect the behavior of the lock screen? These are not apps you can replace.

There are many processes, then, where there is no sandbox configured even on a stock iPhone. When you use Cydia (no sandbox) to install sshd (no sandbox) that is orthogonal to the behavior of other third-party applications that are still restricted to their sandboxes.

(As a quick aside on OpenSSH, as you mention that the root user "may" required a password: all users require passwords. However, the default password for both the mobile and root accounts is "alpine". If you install something like OpenSSH you should change these passwords.)

In the specific case of iBooks, the fairplay DRM checks are not checking that the sandboxes were damaged, but more generally that the system was jailbroken at all: the new checks verify that the kernel memory has not been modified by comparing hashes of critical code, and the old ones from this article that unsigned code runs (orthogonal to a sandbox).

Finally, the fact that the jailbreak works indicates that the pre-jailbroken system was insecure, not that the jailbroken system now has less security. In fact, for more serious exploits, the opposite is true: until Apple releases a patch, you should jailbreak to be safe.

As an example, the exploits that are launched from jailbreakme.com take advantage of bugs in the web browser (v1 attacked TIFF, v2 and v3 attacked TTF). These bugs were already there: any web page anywhere on the Internet could have used these to compromise MobileSafari.

Once in MobileSafari, bugs in the kernel are used that, again, were already there. These bugs could have been used by any code running on your system, including code running inside of a third-party App Store app (despite the sandbox) to jailbreak and possibly even rootkit your device.

However, once you were jailbroken, we offered (in all three of those cases; sometimes as packages and sometimes just by default as part of the process), patches to MobileSafari that would correct the ingress attack vector. Thereby, once jailbroken, you were protected from that exploit.

As to your separate (valid) point about jailbreaks not describing what they do, sadly the different jailbreaks that are available often use specific (as in, not shared; I'm failing to find the right word) kernel patches that are often even incompatible with each other (having different behavior).

Thereby, I can't tell you exactly what any specific jailbreak does. :( However, the overall game plan that they follow is fairly constant, and I can tell you what the "best practice" patches that jailbreaks install by default are in a short list here.

1) AFC2: allows you to access, over USB, all of / as root instead of just /var/mobile/Media as mobile. (Some people, including myself, do not like this patch; it is just an entry in a config file and is easy to remove.)

2) fstab / rw: makes / be mounted read-write. Normally the partition that holds the system software is read-only. As the files on this partition are owned by root, this does not affect the abilities of App Store applications (which run as mobile).

3) fstab /var suid dev: allows setuid executables and device nodes on the user data partition. You have to already have elevated permissions to create these files, so again this does not affect the abilities of App Store applications.

4) codesign: allow code that has not been signed by anyone to execute. This patch allows you to install code from third-party sources on your device, but does not affect the content you obtain from the App Store: they will only give you binaries that they have signed and verified.

5) codehash: allow processes with "corrupt" pages of code to execute. I disagree with this patch (and many jailbreaks do not include it), but it does not affect the abilities of App Store applications as they do not have write access to modify any executables.

6) rw->rx: supports changing a page of memory from writable to executable. Combined with earlier patches, this allows you to build JIT compilers, and is needed for Substrate's MSHookFunction to modify the behavior of a C function. This does affect all process security.

This sixth patch does not, as some people will claim, remove all the advantages of non-executable data or other stack protections. These pages still load as rw and are not executable: you cannot just overflow into them and then jump to them to execute their contents.

However, you can first re-mark the memory region as rx before jumping to it. To do so would require a return-to-libc attack. However, if you already know enough about the target process to do a return-to-libc you may as well just do a return-oriented-programming attack.

It also should be noted that even if you consider the return-to-libc followed by the jump to the now-executable region to be a security hazard, it must be noted that there could be any manner of non-memory security-related mistakes in the App Store applications you have installed.

I will thereby argue that you are really, in the end, relying on the application sandboxes to provide security: the App Store developer probably left tons of gaping holes in their code, and may have even included an entire interpreter-VM... this patch does not increase the magnitude of an attack, only the probability.

7) rwx: allows memory to be marked for write and execute at the same time. This is dangerous, conceptually, but it is required for high-performance JITs. Otherwise, you find yourself having to flip the page from write to execute back constantly, which has performance and safety ramifications.

Applications that choose to mark their pages rwx will end up with lowered security with this patch. However, such processes are normally virtual machines that have numerous other security mitigation strategies, and should therefore, in the end, be much safer than stricter native applications.

However, I will argue that this patch does not offer an attacker anything over the sixth patch: to attack a normal process you will still need to use mmap/mprotect to manually get some rwx pages, at which point you already have return-to-libc and probably just need rx, not rwx.

8) sandbox: allow processes to access files that are outside of their sandbox based on Unix permissions rather than the normal sandbox rules. This affects the security of App Store applications, but there is much more nuance to it.

This, then, is the last and most important patch to our discussion. In some jailbreaks this patch sucks: it literally just turns off the sandbox entirely. You can normally tell that this happened because nothing works ;P (the sandboxes also mediate shared keychain access).

Most jailbreaks instead make targeted modifications to the sandbox restrictions. The "best practice" that I laid out for this patch a while back (and which planetbeing and comex both implemented for various jailbreaks, and which I believe is being used in redsn0w and Absinthe currently) is:

"Add an exception that if a file being accessed is not stored in /var/mobile (the user's home directory) then rather than do not have the sandbox intercept or affect the access check: allow the normal Unix permissions to (probably deny) the access."

This allows you to get read access to files stored on the system permission (not write access, as that would require root). It also allows developers to specifically create scratch storage that is writable by mobile (if they need) somewhere on the filesystem.

While I can come up with some theoretical reasons why there might be a security risk in having read access to files that, thanks to any single person having jailbroken their device, anyone can just download from the Internet anyway, I consider this a far and difficult stretch.

Instead, I will argue that all of the important data is stored in the user's home directory (/var/mobile), and that the parts of the sandbox that "work for the user" protect the files in that folder, while the other parts of the sandbox are more "working for Apple".

(This is detectable because if you install some extensions, such as "file:// for MobileSafari", you can get Safari to read from static web pages stored anywhere on the filesystem but your home directory. This causes a lot of confusion to some people, as that is an obvious place to put things ;P.)

So, AFAIK, none of the major jailbreaks that you find deactivate the sandbox on these personal files. When developers really consider the ability to access these files important, they build daemons (running in the background outside of sandboxes) to mediate access.

Hopefully this goes to some length to help you with your concerns (and I guess I'll now go tell Britta that I wrote this, so she can use content from it or refer people to it as required in the future). I'd still love to get better references for where you see random misinformation ;P.

(edit: I just thought of another patch that is included. 9) crazeles: a ludicrously complicated hack by planetbeing that neuters the FairPlay DRM checks that cause iBooks to refuse to operate correctly on jailbroken devices. This specifically addresses the earlier paragraph on iBooks.)