A uniprocess is a stateless piece of software that encapsulates a process, seen from a business perspective, of which it is known at all times what data enter and what data comes out of the process.

The main reason the concept of uniprocesses were conceived, was to provide the possibility to comply with the Directive 95/46/EC, General Data Protection Regulation or just EU GDPR, from a technical point of view. For more information on the EU GDPR, please read the Legislation section of the About tab.

The main goals of this project are:

1. Ensure that the fundamental rights of EU citizens, which are strengthen by the EU GDPR concerning the protection of natural persons with regard to the processing of personal data and the free circulation of these data, are being enforced in software applications by technical means.

2. Help institutions, both public and private, to develop applications that comply with the Regulation by technical measures and thus meet goal number 1.

3. Provide tools to the Authorities, among others the EU Data Protection Agencies, to corroborate that the created applications, see goal number 2, comply with the Regulation from a technical point-of-view.

The following analogy will showcase what problems are being solved:

In Denmark it is allowed to drive scooters on the bike lane. A requirement is that the speed limit does not exceed 45 km/h for the scooters. All companies that sell scooters in Denmark limit the engine to ensure that they do not exceed that speed (technical measure). If this were not the case, the Danish authorities could fine, very heavily, brands that don’t comply with the law. For officials, in this case the police, it is very easy to inspect if the scooter complies with the law or not, since they have in the trunk of their vehicles a speedometer (another technical measure).

And this is where the concept of uniprocess enter the scene. Using this concept, we can help brands ensure that their applications do not exceed the speed limit while providing tools to the relevant authorities to ensure that the law is followed.

# Talks

# foss-north 2019 (Chalmers, Göteborg, Sweden)

• Limiting side-effects of applications at compile-time

# BornHack 2019 (Gelsted, Funen, Denmark)

• Limiting side-effects of applications at compile-time (+demo)

# Basics

# Isolation of side-effects

• Restriction of effects: Only specific effects are allowed in a uniprocess:

  • Write to the console. For maintenance purposes.

  • Date and time. For the purpose of timestamps.

  • Random values generated by the operating system. For the generation of unique identifiers and data anonymization.

  • Secure network communication: All communication with a uniprocess must be done over TLS.

• Granulation of effects: It must be possible to further restrict the effects of certain branches of the code, recursively, to limit to a subset of the restricted effects. For example:

  • Only the part of the code handling the HTTPS server, is able to output logs to the console.

  • We have limited a code branch so it can only retrieve data the following service: https://example.service.com:8443. Once received, the data can then be used by some of the other code branches which can’t access the mentioned service.

  For more information, Please click on the Effects tab in the menu section above.

# Reproducible builds

• Binaries: For Audit purposes, it’s mandatory to be able to generate the same bits from a given uniprocess code base. A hash value, at least SHA-256, of the bits must be produced on build.

• Distribution containers: Also for Audit purposes, it’s must also be possible to generate a reproducible build hash for a distribution image and container. It must also be possible to generate an equivalent image and container, with the same hash, from a given code base.

By having a unique hash for both binaries as well as the distributed container it would be trivial to convince Authorities, performing the audits, that the running software actually maps directly to the code base.

# Communication

# Security

• TLS: A uniprocess can only communicate over the Transport Layer Security, more specifically, the version 1.2. This will ensure that all message exchange between the uniprocess and other services, is secured by design and default.

# Incoming

• HTTPS server: A uniprocess will run a lightweight HTTPS server, that will only respond to GET and POST requests. Connections aren’t held alive as once a request is served, the server will close the connection afterwards.

• Secure WebSocket server: The only way to keep a connection alive with a uniprocess, is if the client provides an Upgrade header to the server so the HTTPS connection will be replaced by a Secure WebSocket.

# Outgoing

• HTTPS client: Only GET and POST are the only supported request. The header Connection: close is always added to these request.

• Secure WebSocket client: The WebSocket Upgrade header is supported as well.

# Data

• Both the HTTP and WebSocket server / client are limited to send / receive data in JSON format, which means that it is the only supported format.

• Consistency and correctness: can be enforced by using parser-combinators, which will allows us to ensure that, for example, a name shouldn’t contain a number "John 42 Doe".

# Documentation

• The ideal scenario is that the documentation is derived directly from the side-effects as well as a graphical representation, sunburst diagram.

• This would allow the semantics of the process to be kept hidden and thus respect the intellectual property (IP) of the companies.

• As a result, by having a direct link between the code and the documentation, it would ease audits and make them trustworthy.