The search through the literature and Internet resources produces very few Security-related materials for the Erlang language or the Erlang-OTP platform. Nevertheless, it focuses our attention on what we expect to find.
As I am considering Erlang primarily as a programming language, it is necessary to direct the search towards the attributes of secure computing. To further refine our focus we should start with a definition of computing, so that there is no confusion about we want to see.
By computing I understand any human to machine and any machine to machine interaction (either in a public or private context) where data (i.e. signals) are conveyed between the participants. These signals may be copied, stored, replicated, re-transmitted, transformed, etc., but ultimately the goal of these exchanges is the “communication” (“Mitteilung”) of states between the participants. Each participant holds a belief (or assumes a meaning) of its own states but only the interactions allow the other participants to form beliefs (to attribute a meaning) to those states. Conversely, only interaction allows a participant to “transmit” its states to others. In the last instance, computation is a process not only of communication but of control, i.e. of mutual control of the participants insomuch as these are able to stabilise both the “meaning” they form of themselves, and attempt to ensure the “meaning” others form about them.
This definition of computation assumes that mechanical and human participants effect some “mathematical computations” as part of their exchanges and the preparations and preconditions of their exchanges. This definition also assumes that the entities participating in computation are associated by some consensual or agreed protocol whereby the signals transmitted have an appropriate sequence, format and level of redundancy so that the entities can “meet” at a well-defined ground state.
So, “computation2 includes mathematical (essentially binary arithmetical) operations but is not reduced to these, and includes every moment (“Glied”) of the communication operation. I call this an “articulation” (“Gliederung”) of four modes or moments: Person, Subject, Agent and Number.
Following this definition, we can now introduce an additional term: “secure computation.”
If computation were reduced to the slim “mathematical” component (“Number”), secure computation would also be reduced to it. I do not follow this tendency to express security only in terms of numerical capabilities, for example, to anchor security only on computational hardness of encryption schemes. Differently, looking at computation with a systemic view, the hardness of encryption and any other number-computational related aspects become dependent on the previous moments of the articulation, i.e.: Person, Subject and Agent.
What we can immediately see, though, is that the attributes of “secure computing” will be much wider than those that can be “represented” or “expressed” by a technology. In this case, by a programming language.
From a programming language we should expect capabilities that allow us at least to materialise the last articulation (that of Number) and ideally offer support and resources to articulate the other levels of computation. For example, at the numerical level, we should expect a language to provide a rich set of data types and type safety; at the level of the Agent we would expect the ability to support standard protocols and process definitions; and at the level of the Subject we would desire semantic capabilities for communication. Finally, at the level of the Person, we would require pragmatic capabilities to manifest the user’s intentions.
Considering those levels, it would be an error to expect that a numerical-mathematical set of capabilities would be enough to give us a complete coverage of attributes of secure computing. So, for example, while the Number and Agent levels may be able to address encrypted communication protocols together, they are insufficient to sustain the semantics and pragmatics of a secure environment. More concretely, while an encryption arrangement *uses* mathematical operations, implementing security around encryption is not a mathematical but an organisational operation (for example: certificate management).
In this sense, “programming securely” is not only developing code in a secure manner or ensuring that the code is not vulnerable. Complying with “secure programming” requires also supporting, enabling and developing specific functions for the numeric, the syntactic, the semantic and the pragmatic levels of the whole system. It demands from the language and its tools the ability to support type safety, encryption, secure protocols, input validation, output filtering, memory protection, immutable objects, session management and access controls (for machines and people).
In the current context we must add to these attributes those of cross-platform mobility, concurrency, asynchronous messaging, multi-domain authentication/authorisation, and other factors that stem from the expansion of the global networks and “Cloud” computing.
When Erlang is presented, various attributes are highlighted, including its power to address distributed, concurrent and mobile scenarios. I have not found (yet) Erlang positioned as a secure language or as a language which is intrinsically more secure or more adept at Security tasks than others. There is a strong focus on performance and distribution, and the main values and philosophy of the language seem to be associated with concurrency and fault-tolerance.
Nothing detracts from those excellent features if we look at how Erlang supports Security objectives and how it covers the desirable attributes of “secure computing.” We can certainly highlight the abilities of Erlang for representing communicating processes, and the fact that it does not need the conventional “shared memory” approach for concurrency (i.e. the use of semaphores for multi-threading). But we may be missing more important aspects, perhaps more decisive in defining which language is truly “the language of the future.”