Security issues

Our base API supports the minimum functionality which will allow our applications to make themselves secure and reliable.

It's a general truth that security and reliability come with an associated cost. Different applications have different criteria, and the end-to-end argument applies. We don't want to impose high security on applictions that don't need it (and don't want to pay for it). Conversely, we don't want to prevent applications from implementing it, or impose lower security standards than required.

Security generally involves the following issues:

1. Application integrity

   We don't want unauthorised parties to be able to look at or affect our code and data. We need to be able to control the type of system that is used to run our applications.

2. Performance and reliability

   We are classing reliability and performance in with security because the same principles apply to both aspects of a system. Applications provide services, and continued and timely provision of that service may be compromised either by security breaches or by failure. Reliability of an application may well affect the security of another.

3. Auditing to detect compromise and provide data for correction or punishment

   In the event of a security violation, we want to know that it happened, and we want to know what happened, and how. This may enable us to prevent it happening in the future, repair the effects of the violation, and find the responsible party.

4. Paying for the damage done

   Security violations cost money. The waste of time spent correcting them, the costs associated with loss of data, reparations to those who have been damaged in turn by the violation.

5. Control of risk

   Insecure and unreliable resources will exist, and may not be suitable for applications with security constraints. A key feature of Jtrix must be to allow applications to control their exposure to risk. Applications can determine the potential exposure which will arise from the use of a particular resource, and are able to avoid using it or adapt their operation to enable the safe use of that resource.

6. Hosting security

   This applies in particular to hosting resources. A program running on a machine can be only as secure as the machine itself. The potential exposure can be evaluated before anything is deployed to the host in question. Depending on the results of the evaluation, code may not be transmitted, or its function may be changed to suit the new environment. An insecure platform may be quite usable for some applications, but not for others, at least without special precautions.