I never understand this sentiment. Jailbreak tools thrive on the knowledge that there's always another flaw out there waiting to be discovered. How would comex rid Apple's entire development process of error?

Plus, if he jailbreaks devices because he believes people should be free to do with their hardware as they please why on earth would he effectively join the dark side?

> "why on earth would he effectively join the dark side?"

Money.

> "How would comex rid Apple's entire development process of error?"

It wouldn't - but finding exploits and security holes isn't a matter of course. There aren't altogether that many people who have the talents for it, much less the ability to package it into a coherent tool that normal joes can actually download and use.

I have a feeling that there are few enough people who fit this description that Apple can effectively buy them all out.

> How would comex rid Apple's entire development process of error?

That's why I hedged with "temporarily". If he's the best that's working on jailbreaking now, just taking him off that project would already help. And asking him to work to secure phones would be a great help, too - he could spot potential vulnerabilities before they're shipped.

This won't make the iPhone into a space-shuttle, but it will make jailbreaking harder, perhaps significantly so.

> Plus, if he jailbreaks devices because he believes people should be free to do with their hardware as they please why on earth would he effectively join the dark side?

They'll drive a dump-truck full of money up to his house. Or maybe there's something else he values more than the belief in free hardware.

I am pretty sure Apple is capable to solve jailbreak problem temporarily themselves.

Recent history proves that Apple is not capable of solving the jail breaking problems with their current security organization. If they were, then their Operating Systems wouldn't be broken so quickly.

I think the issue is not their security team, who seem to do quite a good job securing iOS (which I'd consider one of, if not the most, secure consumer operating systems out there). The issue is that securing an OS is hard. It's hard to make it that someone with physical access to the device cannot just run code on it, which is what jailbreaking (in its purest form, on iOS devices) is.

Arbitrary code execution is different than requiring physical access to the device. The JailbreakMe site could have run malicious code and it could have spread itself and run without the user knowing.

I was talking about the majority of jailbreaks, not JailbreakMe. Most jailbreaks are done at the low-level bootloader level, which does require physical access to the device (as well as pressing a bunch of buttons in a certain way); and even that doesn't get you access to the keychain or anything it protects.

Also, even if JailbreakMe was malicious (or somebody used the same code or exploits in a malicious way), it could not "spread itself": it was a browser exploit (although it would be possible to run without the user knowing).

> Also, even if JailbreakMe was malicious (or somebody used the same code or exploits in a malicious way), it could not "spread itself": it was a browser exploit (although it would be possible to run without the user knowing).

It could certainly spread. Maybe it could SMS a link to a malicious download to your most frequently contacted contacts? Being able to run arbitrary code on a device that knows how to contact all your friends certainly introduces some vectors for attack.

FYI, it is a PDF-based exploit, meaning all users have to do is open a malicious PDF.

It's a font-based exploit, not PDF. The particular implementation on JailbreakMe used a PDF, but it could easily work in @font-face with CSS on any webpage (or, as we did on JailbreakMe, just hiding an <iframe> to the PDF).

Actually, in the long run it is impossible to make it that someone with physical access to the device cannot run arbitrary code on it.

See the first of the 10 Immutable Laws of Security: http://technet.microsoft.com/en-us/library/cc722487.aspx