Apple appears to relax ban on apps fetching, running extra code – remains aloof as always In conjunction with the commencement of its Worldwide Developer Conference and the release of developer builds of planned operating system updates, Apple has revised its Developer Program license agreement, for better or worse. It could be either, given that Apple itself decides when its rules get applied and how they get …
How do you figure that? The only code it could insert is stuff like Javascript that shouldn't (unless there's a security bug in Apple's Javascript interpreter) be able to do anything nasty. Ditto for other frameworks like Lua. It isn't as though they're going to allow downloading arbitrary .so files and dynamically loading them into the executable.
This change seems rather common sense, because you've always been able to execute arbitrary Javascript - you point Safari at a site containing it!
Self-modifying code is known to be a bad thing. Yes, it might be used for some good purpose. But it can result in horrible messes that are difficult to debug. Then much worse it can be used for nefarious purposes that undermines a user's security.
Apple is right to treat this with all seriousness and make security the rule. Other companies make laissez faire the rule and some misguided notion of freedom.
It is here that often the Unix used by Apple (Mach-based Darwin) is compared with Linux. The fundamental security problem is how processes communicate. In Linux they can communicate directly, unchecked. This achieves speed, but not security. That is good in a well-managed server system, but not for end users.
Mach-based Darwin examines all the inter-process calls - they must be brokered through Mach. However, this results in slower IPC. So, very cleverly, Apple makes exceptions to the rule for really well-known processes to directly communicate with each other.
Relaxing the ban on fetching new code is just an example of that - making an exception to the rule of security in well-known cases.
I hope that answers some of the other negative comments made here to which I resist responding for now.
Securing something then drilling holes in it because it's too slow isn't clever, it's insecure. MS used to do very similar things to favour their own products over third parties. I don't remember it ever being called clever when they did it....
Also, there's a big difference between a patching mechanism and code that dynamically modifies itself while running. It's the code that dynamically modifies itself that is nearly always a shit idea. Patching software to remove bugs/vulnerabilities is considered a good thing by most users.
>>Securing something then drilling holes in it because it's too slow isn't clever, it's insecure. MS used to do very similar things to favour their own products over third parties<<
No, Apple carefully considers the exceptions. MS just did it for ... well who knows why?
If they don't allow download and execution of code they are accused of being too draconian. Conversely, if they do allow it and something goes awry they are also castigated.
Personally, I'd go with not allowing hot-patching. As noted elsewhere, this often causes more problems than it solves. I'd rather not have to rely wholly on developer' ethics or QA diligence.
Security is one issue.
Another is modifying previously reviewed Apps to do something different than expected. (Which may be related to security, or just massively annoying, such as draining the battery.)
At least my i-thing stuff doesn't suddenly drain the battery for no apparent reason, whereas with my Android things there is no such guarantee. Apps misbehave on a regular basis -some I can't even kill with blunt force (and just the constant need to monitor their behaviour is a major pain).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
