5 ms·

One thing I've never understood about situations like this: why doesn't the platform manufacturer just make it technically impossible to call private classes/me

One thing I've never understood about situations like this: why doesn't the platform manufacturer just make it technically impossible to call private classes/methods without some kind of signed key? White list the OS classes/methods that all apps are generally allowed to call, and require some kind of signed key to call anything else. Why try to fix this with policy rather than some technical block? I am sure I am missing something here, so any insight is greatly appreciated.

schrodinger 11y ago
I'm sure that'd be preferable, there's just no easy way to do that with objective-c, because of how dynamic it is. You can pass any message (call any function by name) on any object. Changing that would be a really significant effort.
- Benjammer 11y ago
  Yeah it's kind of impossible when you basically have full control of the method dispatch system at runtime.
asveikau 11y ago
That seems like a paranoid waste of engineering resources. Keep in mind Apple likely needs to access these components in the same address space as an app, and this fool's errand will only make everybody's work more annoying. Also keep in mind that 99% of internal methods and objects will never lead to a harmful "misuse", and you can't predict ahead of time which one will be a real problem.
- kybernetyk 11y ago
  >That seems like a paranoid waste of engineering resources. And if someone _really_ wanted to get around it they could by simply bypassing the "key checking" trampoline and jumping directly to where the wanted to end up in the first place. (Obj-C is still C).
Benjammer 11y ago
That would technically make it a little bit harder for them to let Facebook use all their internal APIs.
jamestnz 11y ago
One reason is that it's only App Store apps which are subject to individual approval by Apple. If you are an individual developer simply wanting to learn/dissect/play with the inherent flexibility of the obj-c runtime, restricting access to private methods/subclasses would be incredibly counterproductive and demoralising. If you are a registered Enterprise Developer (which requires a DUNS number, a phone call with Apple Dev Relations, and a few hundred dollars) you gain additional distribution options. For example you can sign your own apps and distribute them within your organisation "over-the-air" using emailed links or a custom web portal. In general I think Apple are more concerned with the integrity of their mass-market public platform (App Store etc) -- avoiding vast numbers of App Store apps all failing at once because they make some internal framework changes -- than they are about other use cases.

schrodinger 11y ago

I'm sure that'd be preferable, there's just no easy way to do that with objective-c, because of how dynamic it is. You can pass any message (call any function by name) on any object. Changing that would be a really significant effort.

Benjammer 11y ago
Yeah it's kind of impossible when you basically have full control of the method dispatch system at runtime.

asveikau 11y ago

That seems like a paranoid waste of engineering resources. Keep in mind Apple likely needs to access these components in the same address space as an app, and this fool's errand will only make everybody's work more annoying. Also keep in mind that 99% of internal methods and objects will never lead to a harmful "misuse", and you can't predict ahead of time which one will be a real problem.

kybernetyk 11y ago
>That seems like a paranoid waste of engineering resources. And if someone _really_ wanted to get around it they could by simply bypassing the "key checking" trampoline and jumping directly to where the wanted to end up in the first place. (Obj-C is still C).

Benjammer 11y ago

That would technically make it a little bit harder for them to let Facebook use all their internal APIs.

jamestnz 11y ago

One reason is that it's only App Store apps which are subject to individual approval by Apple. If you are an individual developer simply wanting to learn/dissect/play with the inherent flexibility of the obj-c runtime, restricting access to private methods/subclasses would be incredibly counterproductive and demoralising. If you are a registered Enterprise Developer (which requires a DUNS number, a phone call with Apple Dev Relations, and a few hundred dollars) you gain additional distribution options. For example you can sign your own apps and distribute them within your organisation "over-the-air" using emailed links or a custom web portal. In general I think Apple are more concerned with the integrity of their mass-market public platform (App Store etc) -- avoiding vast numbers of App Store apps all failing at once because they make some internal framework changes -- than they are about other use cases.