In fact I do know what I am talking about. The java security model is not based on OO encapsulation private/public directives, although in Java these are no only compiler directives as they are know in the runtime (not so in ObjC/C/C++). The J2ME security is quite a lot more elaborate and founded on the Java security manager model, although it need not be implemented in that way on particular environments. Midlets can never ever escape, or reach APIs, data, or threads outside the J2ME defined scope, according to the spec. I am not saying this means end of all problems but the theoretical strength of this is beyond anything Apple can do with what they got. I personally think it should be appreciated that the original Java design team nailed this on the first try 1.0 java in 1992.
Obj C is old (which is no problem for old me) but more seriously lacks a strict memory/concurrency model which is an inherited trait from C, (so sinks C++ as well). It has pointers that can be arbitrarily set so the declared outcomes of programs are very hard to prove. Modern language has adoped these "safe" things for many good reasons, one being that it is possible to construct at provable safe closed environment like a j2me like sandbox with little means.
Again, the "Java security model" that you keep bringing up has absolutely no bearing at all on private methods. In Java you can still call these private methods using reflection. Which further adds weight to ny assertion that the public and private keywords are in reality nothing more than compiler directives of sorts.
Still, age is of no consequence. Ruby is newer than Java, but that isn't strongly typed either, although it is interpreted, not compiled.
And J2ME supports reflection too. The API reachability isn't really relevant, as all the methods regardless of intention can be accessed via reflection.
Java sandboxing is only intended to prevent a programming escaping from it's Java environment, again nothing to do with APIs and their "privateness".
Midlets can never ever escape, or reach APIs, data, or threads outside the J2ME defined scope, according to the spec. I am not saying this means end of all problems but the theoretical strength of this is beyond anything Apple can do with what they got.
LLVM (the VM stands for Virtual Machine, as with JVM) as is used by Apple in the iPhone OS provides (again to quote Wikipedia) "front-ends including Objective C, Fortran, Ada, Java bytecode, Python, Ruby, ActionScript, GLSL, and others."
So the sandboxing you are preaching about is being used by Apple quite adequetely.
Again though, sandboxing is a completely separate issue to dynamic typing and compile-time restrictions (such as private) for methods.
Again, the "Java security model" that you keep bringing up has absolutely no bearing at all on private methods. In Java you can still call these private methods using reflection. Which further adds weight to ny assertion that the public and private keywords are in reality nothing more than compiler directives of sorts.
Still, age is of no consequence. Ruby is newer than Java, but that isn't strongly typed either, although it is interpreted, not compiled.
And J2ME supports reflection too. The API reachability isn't really relevant, as all the methods regardless of intention can be accessed via reflection.
Java sandboxing is only intended to prevent a programming escaping from it's Java environment, again nothing to do with APIs and their "privateness".
Got your point, you are (most of the time) right about reflection, but if Apple really cares about security that much, they can try harder and prevent reflection on non-public methods, so they are really unreachable by the third party software. So this is really technicalities, they own entire tool chain, they can implement this.
Point is that it would be ultimately better that applications are safe as there is zero chance they can use any unstable private method, instead of the screening process. Previous post labeled this behavior as "Microsoft anti-virus strategy" and it is quite accurate.
No. You are just plain wrong here. Your claims about OO languages are not generally true. Firstly there is nothing that enforce that reflection should allow calling private methods although this is common.
Secondly, in the case of Java, the java security model lets you provable exclude any api you want (as container/platform provider). Specifically for Midlets they can only access a few well specified apis, notably not reflection. In addition they cannot access memory, threads, other app's storage, code, etc. even if you allow reflection calls to no-access apis would fail. With no reflection you can only access public methods of the APIs provided to your program, and more specifically you can only access certain instances handed to you via the environment. There is no way to break this no matter how clever you are or how many CPU hours you can spend, providing the platform is implemented according to the specification.
The LLVM: it does not have this scope at all. LLVM does not (cannot) add any protection to C language because it must allow pointer arithmetic to support C/ObjC/C++. Thus a rouge memory call/access in iPhone code or any other C languge code will transform right through LLVM. That is why this new automated static analysis is introduced in the first place; but it can never be proven to catch every bad thing due to language definition. In the end apple people have to manually test programs... LLVM could fix this if you restrict Obj C according to a new spec. This would be a good thing and could be done without loosing much power.
This subject is all very well researched so there is no point in replicating all the reason for C lang insecurity here. The power you get from a safe type/memory model/virtual runtime/machine that keeps program from unbounded access to physical memory, etc. is well documented. Using the old C lang model and still achieve safe tamper resistent systems will mean putting all forbidden APIs in protected kernel area (the hardware way) and tracking call stack to validate calls which kills performance.
Got your point, you are (most of the time) right about reflection, but if Apple really cares about security that much, they can try harder and prevent reflection on non-public methods, so they are really unreachable by the third party software. So this is really technicalities, they own entire tool chain, they can implement this.
Sigh!!! I'm getting sick of saying it!
APPLE CANNOT PREVENT REFLECTION AS IT IS A FUNDAMENTAL EXTENSION TO OBJECT-ORIENTED PROGRAMMING
Even checking for reflection won't be that easy as the calls can be basically made referencing the method signatures via a string. This is going to be a lot more difficult to check for and require a ton of extra processing overhead.
Quote:
Point is that it would be ultimately better that applications are safe as there is zero chance they can use any unstable private method
Private methods and methods which are private due to stability issues are two completely different things.
Quote:
Previous post labeled this behavior as "Microsoft anti-virus strategy" and it is quite accurate.
The whole anti-virus strategy argument isn't really that relevant to be honest, either. Mainly because no software HAS TO inherit functionality from other pieces of software.
The whole "anti-virus" argument being used is rather moot. As it is detracting from the FACT that object messaging, calling [so called] private methods etc. are all fundamental concepts and properties of a fully object oriented programming methodology and architecture.
Correctly, when you call a method in Objective-C, it is either handled or passed up the object hierarchy until it is either executed, or you reach the top of the chain.
Also, it is 100% acceptable to expect a method sent to a "nil" object to do nothing and not fail. This is much better than the "managed" way of doing things and coupled with other things, this makes Objective-C a way more powerful language to work with.
It will always be a trade-off of either performance or hand-holding. Every language ever released is a perfect example of these trade-offs.
No. You are just plain wrong here. Your claims about OO languages are not generally true. Firstly there is nothing that enforce that reflection should allow calling private methods although this is common.
I stand corrected on J2ME and reflection, my bad. Must have read it wrong.
Quote:
Secondly, in the case of Java, the java security model lets you provable exclude any api you want (as container/platform provider). Specifically for Midlets they can only access a few well specified apis, notably not reflection. In addition they cannot access memory, threads, other app's storage, code, etc. even if you allow reflection calls to no-access apis would fail. With no reflection you can only access public methods of the APIs provided to your program, and more specifically you can only access certain instances handed to you via the environment. There is no way to break this no matter how clever you are or how many CPU hours you can spend, providing the platform is implemented according to the specification.
However I can assure 100% Java (j2SE/J2EE) allows reflection.
Quote:
This subject is all very well researched so there is no point in replicating all the reason for C lang insecurity here. The power you get from a safe type/memory model/virtual runtime/machine that keeps program from unbounded access to physical memory, etc. is well documented. Using the old C lang model and still achieve safe tamper resistent systems will mean putting all forbidden APIs in protected kernel area (the hardware way) and tracking call stack to validate calls which kills performance.
Well, the dynamically typed and unmanaged code was chosen for a reason. The performance hit taken with garbage collected code is quite significant, especially on a mobile platform.
Also with GC, there is a tendency to hold onto memory longer than is necessary to wait for it to be collected, again an overhead that cannot really be afforded in the mobile space.
As a result, Apple has a faster, more snappy and responsive experience for the user. You only have to look at the jerky/clunky Java-based phone UIs to see this, although a little of that may be down to bad programming on the developers part.
At the end of the day it's six of one and half a dozen of the other. Technical decisions have been made, with their merits and disadvantages. Apple has chosen a way that primarily benefits BOTH the user and the developer, and not just the developer (as with Java and C# with the managed code "crutch").
Yes I do see the benefits and ease of bug free code from managed code, but in my experience it leads to a little more complacency and "exception" error messages on display to the user as developers tend to implement less error handling because the runtime stops them from becoming really bad errors for them.
Comments
Obj C is old (which is no problem for old me) but more seriously lacks a strict memory/concurrency model which is an inherited trait from C, (so sinks C++ as well). It has pointers that can be arbitrarily set so the declared outcomes of programs are very hard to prove. Modern language has adoped these "safe" things for many good reasons, one being that it is possible to construct at provable safe closed environment like a j2me like sandbox with little means.
Still, age is of no consequence. Ruby is newer than Java, but that isn't strongly typed either, although it is interpreted, not compiled.
And J2ME supports reflection too. The API reachability isn't really relevant, as all the methods regardless of intention can be accessed via reflection.
Java sandboxing is only intended to prevent a programming escaping from it's Java environment, again nothing to do with APIs and their "privateness".
Midlets can never ever escape, or reach APIs, data, or threads outside the J2ME defined scope, according to the spec. I am not saying this means end of all problems but the theoretical strength of this is beyond anything Apple can do with what they got.
LLVM (the VM stands for Virtual Machine, as with JVM) as is used by Apple in the iPhone OS provides (again to quote Wikipedia) "front-ends including Objective C, Fortran, Ada, Java bytecode, Python, Ruby, ActionScript, GLSL, and others."
So the sandboxing you are preaching about is being used by Apple quite adequetely.
Again though, sandboxing is a completely separate issue to dynamic typing and compile-time restrictions (such as private) for methods.
Again, the "Java security model" that you keep bringing up has absolutely no bearing at all on private methods. In Java you can still call these private methods using reflection. Which further adds weight to ny assertion that the public and private keywords are in reality nothing more than compiler directives of sorts.
Still, age is of no consequence. Ruby is newer than Java, but that isn't strongly typed either, although it is interpreted, not compiled.
And J2ME supports reflection too. The API reachability isn't really relevant, as all the methods regardless of intention can be accessed via reflection.
Java sandboxing is only intended to prevent a programming escaping from it's Java environment, again nothing to do with APIs and their "privateness".
Got your point, you are (most of the time) right about reflection, but if Apple really cares about security that much, they can try harder and prevent reflection on non-public methods, so they are really unreachable by the third party software. So this is really technicalities, they own entire tool chain, they can implement this.
Point is that it would be ultimately better that applications are safe as there is zero chance they can use any unstable private method, instead of the screening process. Previous post labeled this behavior as "Microsoft anti-virus strategy" and it is quite accurate.
Secondly, in the case of Java, the java security model lets you provable exclude any api you want (as container/platform provider). Specifically for Midlets they can only access a few well specified apis, notably not reflection. In addition they cannot access memory, threads, other app's storage, code, etc. even if you allow reflection calls to no-access apis would fail. With no reflection you can only access public methods of the APIs provided to your program, and more specifically you can only access certain instances handed to you via the environment. There is no way to break this no matter how clever you are or how many CPU hours you can spend, providing the platform is implemented according to the specification.
The LLVM: it does not have this scope at all. LLVM does not (cannot) add any protection to C language because it must allow pointer arithmetic to support C/ObjC/C++. Thus a rouge memory call/access in iPhone code or any other C languge code will transform right through LLVM. That is why this new automated static analysis is introduced in the first place; but it can never be proven to catch every bad thing due to language definition. In the end apple people have to manually test programs... LLVM could fix this if you restrict Obj C according to a new spec. This would be a good thing and could be done without loosing much power.
This subject is all very well researched so there is no point in replicating all the reason for C lang insecurity here. The power you get from a safe type/memory model/virtual runtime/machine that keeps program from unbounded access to physical memory, etc. is well documented. Using the old C lang model and still achieve safe tamper resistent systems will mean putting all forbidden APIs in protected kernel area (the hardware way) and tracking call stack to validate calls which kills performance.
Got your point, you are (most of the time) right about reflection, but if Apple really cares about security that much, they can try harder and prevent reflection on non-public methods, so they are really unreachable by the third party software. So this is really technicalities, they own entire tool chain, they can implement this.
Sigh!!! I'm getting sick of saying it!
APPLE CANNOT PREVENT REFLECTION AS IT IS A FUNDAMENTAL EXTENSION TO OBJECT-ORIENTED PROGRAMMING
Even checking for reflection won't be that easy as the calls can be basically made referencing the method signatures via a string. This is going to be a lot more difficult to check for and require a ton of extra processing overhead.
Point is that it would be ultimately better that applications are safe as there is zero chance they can use any unstable private method
Private methods and methods which are private due to stability issues are two completely different things.
Previous post labeled this behavior as "Microsoft anti-virus strategy" and it is quite accurate.
The whole anti-virus strategy argument isn't really that relevant to be honest, either. Mainly because no software HAS TO inherit functionality from other pieces of software.
The whole "anti-virus" argument being used is rather moot. As it is detracting from the FACT that object messaging, calling [so called] private methods etc. are all fundamental concepts and properties of a fully object oriented programming methodology and architecture.
Correctly, when you call a method in Objective-C, it is either handled or passed up the object hierarchy until it is either executed, or you reach the top of the chain.
Also, it is 100% acceptable to expect a method sent to a "nil" object to do nothing and not fail. This is much better than the "managed" way of doing things and coupled with other things, this makes Objective-C a way more powerful language to work with.
It will always be a trade-off of either performance or hand-holding. Every language ever released is a perfect example of these trade-offs.
C# performs worse than Objective-C
Java performs worse than Objective-C
C++ performs worse than Objective-C
Objective-C performs worse than Assembly Language
No. You are just plain wrong here. Your claims about OO languages are not generally true. Firstly there is nothing that enforce that reflection should allow calling private methods although this is common.
I stand corrected on J2ME and reflection, my bad. Must have read it wrong.
Secondly, in the case of Java, the java security model lets you provable exclude any api you want (as container/platform provider). Specifically for Midlets they can only access a few well specified apis, notably not reflection. In addition they cannot access memory, threads, other app's storage, code, etc. even if you allow reflection calls to no-access apis would fail. With no reflection you can only access public methods of the APIs provided to your program, and more specifically you can only access certain instances handed to you via the environment. There is no way to break this no matter how clever you are or how many CPU hours you can spend, providing the platform is implemented according to the specification.
However I can assure 100% Java (j2SE/J2EE) allows reflection.
This subject is all very well researched so there is no point in replicating all the reason for C lang insecurity here. The power you get from a safe type/memory model/virtual runtime/machine that keeps program from unbounded access to physical memory, etc. is well documented. Using the old C lang model and still achieve safe tamper resistent systems will mean putting all forbidden APIs in protected kernel area (the hardware way) and tracking call stack to validate calls which kills performance.
Well, the dynamically typed and unmanaged code was chosen for a reason. The performance hit taken with garbage collected code is quite significant, especially on a mobile platform.
Also with GC, there is a tendency to hold onto memory longer than is necessary to wait for it to be collected, again an overhead that cannot really be afforded in the mobile space.
As a result, Apple has a faster, more snappy and responsive experience for the user. You only have to look at the jerky/clunky Java-based phone UIs to see this, although a little of that may be down to bad programming on the developers part.
At the end of the day it's six of one and half a dozen of the other. Technical decisions have been made, with their merits and disadvantages. Apple has chosen a way that primarily benefits BOTH the user and the developer, and not just the developer (as with Java and C# with the managed code "crutch").
Yes I do see the benefits and ease of bug free code from managed code, but in my experience it leads to a little more complacency and "exception" error messages on display to the user as developers tend to implement less error handling because the runtime stops them from becoming really bad errors for them.