On Wed, Jun 21, 2006 at 08:19:15PM +0900, Robert D. wrote:
On 6/21/06, Juergen S. [email protected] wrote:
In no language private/protected (or final) is a fool proof security
I doubt this strongly, Ada springs into mind.
Disassemblers/source extractors. Debuggers. Special kernel
modules. Running in a VM with outside tracing mechanisms
attached. Need I continue? This may take the attacker to an
outside-the-language level, but is still very practical.
The best feature of Ada is probably its obscurity outside some special
user groups.
measure. It is there to provide some safety nets against errors, and
to help design, not for security. It is quite easy in C++ to get at
any function in memory via pointers. In Java people can use AOP to
accomplish this.
In theory I hate it, in practice it is frequently sufficent.
Ruby is not doing that bad either, in practice I will often not care if
somebody redefines the access rights of my methods, I feel that this is a
theoretical discussion, though, right ?
Yes. But practical work is not far behind, and it usually suffices if
one of your users breaks your defenses and distributes a “crack”
around. You sit on the wrong side of a long lever here, hence my
advice to not waste effort in a lost battle.
Your most economical bet is to just document the class (or whatever)
to be “private, not to be used directly” in Ruby. Sometimes the
low-tech effort is simply the best, especially if any high-tech effort
is going to put you to much more troubles than the attacker, who will
circumvent it fast any way.
I appreciate your defence of ruby 
but the ability to completely hide
implementation from the interface user is a feature not a bug.
Most people who would consider this a feature would also consider
static typing a feature – ruby is different. It is a feature of ruby
to be dynamic and reflective. Don’t misunderstand me, I am all for
encapsulation, but as a design not a security/obscurity device.
I dare you to show me a system that manages to completely hide away,
apart from secure hardware (like smartcards).
It does not seem a good idea to me to allow everything with the perfect
excuse of following the “enabeling approach”, because it does not allow me
to implement some of the more basic principles of modern Software Design
(Data Hiding for instance).
Encapsulation <> data hiding, and the former counts IMHO. I’d contend
that hiding in your sense is a basic software design principle, that
is a not so uncommon misunderstanding about OOP.
All this is on a philosophical base, in practice Ruby gives me what I need
However, I is not the world, as has been pointed out to me frequently and
recently, quite a rude message BTW
Cheers
Robert
I hope that wasn’t me. I am opiniated, but I never intended to be rude.
-Jürgen