# <a name="How_Much_Confinement_Do_We_Want_"> How Much Confinement Do We Want? </a>

**_NOTE:_** **I am absolutely sure this is incredibely incomplete and/or wrong.**

## <a name="Introduction"> Introduction </a>

There has been a lot of traffic on the l4-hurd list lately. A good bit of this is related to the question this entry is about: How much confinement do we want? The idea not to implement the full confinement was (accidently?) raised by marcus, who planned to raise it _somewhen_, but not yet. Still, he did, and now we have to manage the situation.

## <a name="Terminology"> Terminology </a>

In this section I try to sketch some terminology that came up _during_ the discussion.

### <a name="Creator"> Creator </a>

Creator we call the creator of the confined (constructor) object.[2]

### <a name="Instantiator"> Instantiator </a>

Instantiator we call the user of the confined (constructor) object. [2]

### <a name="Encapsulation"> Encapsulation </a>

Encapsulation means that information (including authority) cannot be extracted from a program without its consent. This is a restriction on "read in" behavior. [3]

### <a name="Confinement"> Confinement </a>

Confinement means that a program cannot communicate outward through unauthorized channels. This is a restriction on "write out" behavior. [3]

### <a name="non_trivial_confinement"> non-trivial confinement </a>

Marcus: \`\`[non-trivial confinement] is the confined constructor design pattern.'' [1]

We speak about non-trivial confinement when creator != instantiator. [2]

### <a name="trivial_confinement"> trivial confinement </a>

Marcus: \`\`[trivial confinement] is what the Hurd will do'' [1]

We speak about trivial confinement when creator == instantiator [2]

### <a name="principle_of_user_freedom_autono"> principle of user freedom/autonomity </a>

The principle of user freedom and autonomity means the right to use, inspect, alter and copy all resources attributed to/owned by the user.[4]

### <a name="freedom_of_digital_information"> freedom of digital information </a>

TBD

## <a name="The_Positions"> The Positions </a>

Here I try to sketch the different positions.

### <a name="Use_and_Implement_Only_Trivial_C"> Use and Implement Only Trivial Confinement by Default </a>

#### <a name="Pros"> Pros </a>

* Follows the principle of user freedom
* **add more here**

#### <a name="Cons"> Cons </a>

* Possibly use cases for non-trivial confinement exist we cannot yet think of.
* **add more here**

### <a name="Implement_Full_Confinement_and_U"> Implement Full Confinement and Utilize It </a>

#### <a name="Pros"> Pros </a>

* There are many years of experience with confinement.
* **add more here**

#### <a name="Cons"> Cons </a>

* It does not follow the principle of user freedom.
* **add more here**

## <a name="Preliminary_Summary_Statements"> Preliminary Summary Statements </a>

* [Jonathan](http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00018.html)

## <a name="A_Try_to_Push_the_Discussion_int"> A Try to Push the Discussion into a Constructive Direction </a>

Marcus started a challenge [5] to find a use case for non-trivial confinement that is interesting for the Hurd and cannot be implemented otherwise. The exact challenge definition can be found in the mail.

----

* [1] <http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00339.html>
* [2] <http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00383.html>
* [3] <http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00415.html>
* [4] <http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00012.html>
* [5] <http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00407.html>

-- [[Main/TomBachmann]] - 01 May 2006