Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Apple puts DRM on for the user's safety.

Nope. Guess again!

It'd be trivial to redesign the bootloader so it could flash any image from the USB port. This would make it easier for Apple techs to restore a known-good state (say if a new exploit was used to install a rootkit rather than one-click jailbreak)

> There should be something between the GPL and the BSD licences, GPL with an exception for whatever DRM the first party agrees to.

This is called BSD. There is no middle ground - either the end user can tweak the software running on their device, or they cannot.



How is being able to restore a security feature? How is something for Apple techs only (or even tech users) a security feature?


Any jailbreak exploit is capable of bricking the phone or even installing a rootkit so that the phone appears to function normally, but is instead running code from an unknown third party. The first stage bootloader has to be writable like this, as it's responsible for verifying input from the internet so that it can be legitimately updated in case of bugs.

If instead, the first stage bootloader were much simpler and only took input from USB, it could be read-only and always available to easily-reflash the entire phone. The second stage bootloader could then do all the signature verification it wanted, while itself being updateable through USB/stage1 in case of a rootkit.

(and once again, the only reason to require USB-loaded updates to be signed would be to restrict how consumers use their devices)


That still doesn't address any of the problems I stated. the best of both worlds are that anyone can restore, but only Apple can sign apps to be added.


The second stage bootloader would contain an Apple signing key for verification. However, users who considered it an anti-feature could reflash through USB and add whatever keys they'd like. It's not setup this way because Apple desires more than just security for users - they want control over users.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: