Thursday, July 26, 2012

Theory vs Practice

A recent article lead me on a thread of discovery to a "battle" between Noam Chomsky (who I admire for his activisim) and Peter Norvig (who I've had as a teacher in an AI class).   I'm already to weigh in on the experimentalist side (Norvig) because of this quote from an article in MIT's Technology Review.

Chomsky derided researchers in machine learning who use purely statistical methods to produce behavior that mimics something in the world, but who don't try to understand the meaning of that behavior. Chomsky compared such researchers to scientists who might study the dance made by a bee returning to the hive, and who could produce a statistically based simulation of such a dance without attempting to understand why the bee behaved that way. "That's a notion of [scientific] success that's very novel. I don't know of anything like it in the history of science," said Chomsky.
Technology Review.


My take on this is to do a simple substitution of terms and see how this view works out:

Chomsky derided researchers in machine learning who use purely statistical methods to produce behavior that mimics something in the world, but who don't try to understand the meaning of that behavior. Chomsky compared such researchers to scientists who might study the motion made by an electron in a magnetic field, and who could produce a statistically based simulation of such a motion without attempting to understand why the electron behaved that way. "That's a notion of [scientific] success that's very novel. I don't know of anything like it in the history of science," said Chomsky. -- Substitutions Mike Warot

I think that it's very useful to know how to model something, even if you don't know the exact reasons of why. Science is the process of building increasingly accurate models (theories) of the world that fit all available evidence. If evidence is found that doesn't fit the model, and can't be explained by errors, new models must be sought. This is why we praise both Isaac Newton and Albert Einstein, as they both improved our models of the universe.

Tuesday, July 17, 2012

Secure programming - good intentions

I recently read a good article about security practices in applications and software as a service. The author lays out some very good rules to help keep users information secure in today's threat environment. However, it strikes me strong reminder of the vast amount of effort we're wasting by trusting applications programs at all.

We should never completely trust any programs, services, or drivers outside of the very kernel of an operating system. We shouldn't have to.  The millions of lines of code that are required to do even a basic database with a web front end are bound to have bugs which can lead to unintended and unwelcome side effects. The effects can be subtle to disastrous depending on what cascade of events happens.

The application programmer has no tools to prevent his program from exceeding its scope at a given task. Current operating system design holds that the user is the proper level of granularity for deciding what access a given task is to be allowed. All of the responsibility is then thrust upon programmers to keep things safe as a result. The programmer and/or install package is then responsible for setting all of the permissions on all of the the objects (files, pipes, registry entries, ports, etc) in the end system to be appropriate for the given tasks.


This is an impossible task, given that there can be literally millions of such permissions to set, and it only takes one mistake to let things pass through. 


It doesn't have to be this way.

Capability based security is an approach that uses the principle of least access to enforce security in a much more appropriate manner.  The millions of choices about what to deny are replaced with a much shorter list of what things to allow. This list is per process, not per user.  It tells which files, folders, ports are to be allowed, and which mode (read only, write only, append only, full, etc).

This is a much more natural way to handle risk, as you simple decide what side-effects you are going to allow a given process to have, and the operating system enforces your decision. You don't have to trust your code, nor does the user. If something goes wrong, the maximum extent of damage is already known. You don't have to worry about the entire system shattering.

Isn't it time we stop spending so much effort on making our programs safe, when it could be better spent building better programs?  Help support efforts which will deliver operating systems with capability based security, such as Genode, which provides a choice of 8 microkernels, capability based security, and runs native Linux applications.

Thanks for your time and attention.