Anyone who's had any good training in object-oriented programming knows about the concept of Information Hiding. Information hiding is done to prevent access to information from anyone who doesn't need to know what it is. A concept that fewer people have heard of is Capability Hiding. Capability hiding is preventing access to methods or actions from anyone who doesn't need to do that action.
- Information hiding: Need to know
- Capability hiding: Need to do
There should only be 3 ways to obtain a reference to an object. If your application is implemented in way that prevents access except via these three ways, your application may be secure. However, if there are other means to obtain access, your application is not secure. Here are the 3 ways:
- Creation: If you created the object, then you should have access to it.
- Construction: If your constructor created the object, you should have access to it.
- Introduction: If someone gave you the object, you should have access to it.
Let's use some diagrams straight from Crockford's speech to demonstrate how you can hide and grant access to actions via introduction. To start out, Image 1 below shows three objects: A, B, and C.
You can assume that A probably got access to B and C via either creation or construction. B and C, however, have no reference to A, nor do they have references to each other, so they have no way to communicate without those referenced.
In Image 2 below, A is calling B, and passing C in as an argument. In this way, A is introducing B to C.
For those of you who may be having a slightly difficult time mapping diagrams to code in your head, the simplest way to represent this code is shown in Script 1 below. It's extremely simple.
// Script 1: This call is made within A B(C);
Now that B has been given a reference to C, it has the capability to communicate with C any time that it wants to, as show in Image 3.
C still has no access to B or A, nor does B have access to A. However, A has the ability to grant access to B and itself and B has the ability to grant access to itself.
Another problem arises, though, when you only want B to be able to access C one time. In his speech, Crockford shows off some powerful code that allows A to revoke B's access to C at any point.
The Global Problem
This model gives you the ability to create a secure system... almost. There's one problem left: the global object. If you declare anything outside of a function, it'll be attached to the global
window object. This allows it to be accessed by anyone because everyone has access to the global object.
There is one pattern that can help with this, though. It's called the anonymous self-invoking function. It's looks a little bit like this:
As it says in the code comments, it executes right away, just like all of your other code outside of functions, so it's just like normal code, except it's all inside of a function so that every variable declared within it is private to that function. I'm sure you can do a search for "anonymous self-invoking function" and you'll find more information.
Coming to a Close
He also recommended a couple other resources within the video:
- On the Criteria to Be Used in Decomposing Systems into Modules by David Parnas
- The Lazy Programmer’s Guide to Secure Computing by Marc Stiegler