There is a difference between security and control. You can have security without control but once you have control then security is less of an issue.
Since philosophy is my gig, let's examine it from first principles. We will define data security as: protecting data from destructive forces and from the unwanted actions of unauthorized users. We will define control as: the ability to determine which specific set of actions a person gets to perform. Now, we must also further separate this from privacy, which we will define as: the ability to determine what data in a computer system is shared with third parties. Security then is about the prevention of action against a target by an unauthorized actor. Whereas control is about being able to determine what action the actor can take with regard to the target.
Even at the definition level we can see a fundamental shift in which element of the schema we are affecting. Here, a schema is a model that helps organize and interpret information. A schema is a way to define the structure of something at it’s most basic level. At the most basic level then we have three ontologically distinct entities: the actor, the target and actions.
In the security formulation we are trying to secure the target by preventing what actions can be taken against the target. We must therefore predict all the possible actions an actor can take and construct the necessary defenses. In the real world this is a large and complex task. We must account for the real possibility that the actor may come up with actions that we never anticipated and have no defense for. We must therefore incorporate a method of accounting that, at the very least, keeps a record of all the actions that were taken against the target. In this manner we can analyze and discover when novel actions occur, learn from them and incorporate this learning into our defense strategy.
In the control formulation, we focus on the actor in the system, as opposed to the target. We define instead what actions the actor can take, irrespective of the target. We therefore exclude all other possible actions. The target is not burdened with the complex tasks and overhead needed for prediction, analysis, and learning. This also greatly reduces the accounting function.
Now, this is all well and good in a closed ecosystem. But it is problematic to implement a control schema in an open-system where the role of the actor is undefinable. In order to implement control there are other conditions that must also be realized. For example: actions of the actor must be quantifiable and definable; actions must be excludable; the actor credentials must be unforgeable; and the target interaction must retain it’s integrity. To implement a control schema one must address each of these requirements. Should the actor credentials be forgeable then they may impersonate another actor and therefore be able to realize unauthorized actions. Should the integrity of the interaction be compromised, then unauthorized actions may be realized through cloning a request and injecting a modified action. And so on.
The control schema is also unrealizable in a hierarchically modeled environment where inheritance is an inert property. A hierarchy is an organizational structure where every entity in the organization, except one ("the root"), is subordinate to a single other entity. An example of a hierarchical model is the hierarchical file system (HFS). The subordination of a hierarchy implicitly embodies inheritance as one entity inherits the properties of the thing it is subordinate to. In order to implement control, all entities or targets must be organized in a model where every entity is on the same level– thus eliminating forced inheritance of properties. There are some concrete reasons why security and not control is the function of permissions in a computing system.
The CloudMoDe Operating Stack (OS) is different from the ground up because all data is stored in a semantic system, where everything is on the same level. CloudMoDe OS uses an irreversible cryptographic chain of blocks to record transactions, where transactions are defined as the result of an instance of interaction. Transactions can describe the credentials of the actor and be used to make all instances of interaction unique, thus making them unforgeable. Transactions can also be used to describe actions, thus making them quantifiable and definable. Once you eliminate the subordination problem with a new data structure, use a uniqueness quantification method for transactions, and meet the other requirements of an effective control schema, implementing such a control system becomes elementary. Every great invention is obvious after it has been made.
Security and control are not the same thing. There are fundamental differences and having control opens up a new space on the internet. You can have security without control but once you have control then security is less of an issue. It’s like the old adage that being married gives you security, but being single gives you control. It’s just a question of which state you are after.