[PATCH] Documentation: reword the distinctive feature of shared state

[PATCH] Documentation: reword the distinctive feature of shared state

[Valentin Gagarin]

This changes front-page wording in load-bearing ways, for reasons that
may be non-obvious:

- Split into shorter sentences

  Each one is focused on describing a separate idea.  The second idea is
  more complex and warrants more words, so having a dedicated sentence
  avoids losing the reader.

- s/several dozen/many/

  The particular number doesn't matter, and may be arbitrarily wrong in
  practice.  The point is that there's fragmentation.  The snark about
  any large number is unnecessary if we put the real problem in the
  foreground.

- s/mixed up in//

  It could be that entanglement is an issue, but fragmentation seems to
  be the bigger issue.  In any case, the original sentence was awkward
  grammatically, because it tried putting together how a system is
  handled with what the system is like.

- s/managed as a whole/still treated as a whole/

  We're already saying "managed" in the first sentence.  Managing
  the system is very different from managing state.  We need to be
  careful with using words without prior definitions, so the best we can
  do here is avoid inadvertent conflation.  There is enough potential
  for confusion as it is.

  "still" acknowledges the traditional single-system experience that
  Spectrum preserves by design.

- s/backed up and//

  The difficulty of backing up is a specific instance of the
  fragmentation problem.  But this is likely only evident to Qubes
  users.  We can expect most readers to know about it theoretically at
  best.  While it's not wrong to have this sort of anchor, keeping it
  risks diluting the main message.

- "each becoming a system of its own"

  This captures the Qubes failure mode Spectrum avoids, where per-VM state
  accumulation forces operators into what amounts to orchestrating
  a cluster on one's desktop.

  In the original, the contrast to Qubes would not be as strong for
  people only familiar with it superficially.  Being more explicit about
  the nature of the problem helps establishing the narrative frame and
  original motivation of Spectrum early on, part of which is overcoming
  Qubes limitations.
---
 Documentation/index.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/index.html b/Documentation/index.html
index 6d6faf7..0ea0a2f 100644
--- a/Documentation/index.html
+++ b/Documentation/index.html
@@ -23,9 +23,9 @@ such systems.
 
 <p>
 User data and application state will be managed centrally, while
-remaining isolated, meaning that the system can be backed up and
-managed as a whole, rather than mixed up in several dozen virtual
-machines.
+remaining isolated.  This means that the system can be
+treated as a whole, rather than many virtual
+machines each becoming a system of its own.
 
 <p>
 Spectrum is an upstream-first project.  Wherever possible, we aim to
-- 
2.54.0

Re: [PATCH] Documentation: reword the distinctive feature of shared state

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]

Valentin Gagarin <valentin@gagarin.work> writes:

> This changes front-page wording in load-bearing ways, for reasons that
> may be non-obvious:

Wow, I love the explanation/diff ratio here!

> - Split into shorter sentences
>
>   Each one is focused on describing a separate idea.  The second idea is
>   more complex and warrants more words, so having a dedicated sentence
>   avoids losing the reader.
>
> - s/several dozen/many/
>
>   The particular number doesn't matter, and may be arbitrarily wrong in
>   practice.  The point is that there's fragmentation.  The snark about
>   any large number is unnecessary if we put the real problem in the
>   foreground.
>
> - s/mixed up in//
>
>   It could be that entanglement is an issue, but fragmentation seems to
>   be the bigger issue.  In any case, the original sentence was awkward
>   grammatically, because it tried putting together how a system is
>   handled with what the system is like.
>
> - s/managed as a whole/still treated as a whole/
>
>   We're already saying "managed" in the first sentence.  Managing
>   the system is very different from managing state.  We need to be
>   careful with using words without prior definitions, so the best we can
>   do here is avoid inadvertent conflation.  There is enough potential
>   for confusion as it is.
>
>   "still" acknowledges the traditional single-system experience that
>   Spectrum preserves by design.

The "still" appears to have got lost from the actual diff.  Should I put
it back in?

> - s/backed up and//
>
>   The difficulty of backing up is a specific instance of the
>   fragmentation problem.  But this is likely only evident to Qubes
>   users.  We can expect most readers to know about it theoretically at
>   best.  While it's not wrong to have this sort of anchor, keeping it
>   risks diluting the main message.

I'm concerned that removing the more specific verbs here might make it
more difficult to understand /why/ treating the system as a whole is
desirable.  We don't have to be so specific as to call out backups or
management, but I think without talking about something more specific,
even if that's just "thinking", as in "one only needs to think about a
single system", it loses its motivation.

> - "each becoming a system of its own"
>
>   This captures the Qubes failure mode Spectrum avoids, where per-VM state
>   accumulation forces operators into what amounts to orchestrating
>   a cluster on one's desktop.
>
>   In the original, the contrast to Qubes would not be as strong for
>   people only familiar with it superficially.  Being more explicit about
>   the nature of the problem helps establishing the narrative frame and
>   original motivation of Spectrum early on, part of which is overcoming
>   Qubes limitations.

Missing Signed-off-by.

> ---
>  Documentation/index.html | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/index.html b/Documentation/index.html
> index 6d6faf7..0ea0a2f 100644
> --- a/Documentation/index.html
> +++ b/Documentation/index.html
> @@ -23,9 +23,9 @@ such systems.
>  
>  <p>
>  User data and application state will be managed centrally, while
> -remaining isolated, meaning that the system can be backed up and
> -managed as a whole, rather than mixed up in several dozen virtual
> -machines.
> +remaining isolated.  This means that the system can be
> +treated as a whole, rather than many virtual
> +machines each becoming a system of its own.
>  
>  <p>
>  Spectrum is an upstream-first project.  Wherever possible, we aim to
> -- 
> 2.54.0

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: [PATCH] Documentation: reword the distinctive feature of shared state

[Valentin Gagarin]

> The "still" appears to have got lost from the actual diff.  Should I put
> it back in?

Oh yes, please.  Sorry, apparently I dropped it while changing it back 
and forth.


>> - s/backed up and//
>>
>>    The difficulty of backing up is a specific instance of the
>>    fragmentation problem.  But this is likely only evident to Qubes
>>    users.  We can expect most readers to know about it theoretically at
>>    best.  While it's not wrong to have this sort of anchor, keeping it
>>    risks diluting the main message.
> 
> I'm concerned that removing the more specific verbs here might make it
> more difficult to understand /why/ treating the system as a whole is
> desirable.  We don't have to be so specific as to call out backups or
> management, but I think without talking about something more specific,
> even if that's just "thinking", as in "one only needs to think about a
> single system", it loses its motivation.

Yes, what we're trying to convey here feels tricky to get right.  Not 
sure "thinking of" is more specific than "treating", but maybe it better 
gets across a sentiment of "conceptualising" (in the sense of: mentally 
grasping).  In my drafting I was mainly focused on the interaction with 
the system, since I came from the original which worked with examples of 
handling the system and thus *implied* some thinking.  Maybe thinking is 
just the right thing.  At least this sounds perfectly fine to me:

     This means that the system can be thought of as a whole, rather than
     many virtual machines each becoming a system of its own.

One could argue that thinking about a system is a very specific 
interaction we perform very often...

Feel free to fix it up like that, otherwise I'll give it another round 
of ideas.

Signed-off-by: Valentin Gagarin <valentin@gagarin.work>
> 
>> - "each becoming a system of its own"
>>
>>    This captures the Qubes failure mode Spectrum avoids, where per-VM state
>>    accumulation forces operators into what amounts to orchestrating
>>    a cluster on one's desktop.
>>
>>    In the original, the contrast to Qubes would not be as strong for
>>    people only familiar with it superficially.  Being more explicit about
>>    the nature of the problem helps establishing the narrative frame and
>>    original motivation of Spectrum early on, part of which is overcoming
>>    Qubes limitations.
> 
> Missing Signed-off-by.
> 
>> ---
>>   Documentation/index.html | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/index.html b/Documentation/index.html
>> index 6d6faf7..0ea0a2f 100644
>> --- a/Documentation/index.html
>> +++ b/Documentation/index.html
>> @@ -23,9 +23,9 @@ such systems.
>>   
>>   <p>
>>   User data and application state will be managed centrally, while
>> -remaining isolated, meaning that the system can be backed up and
>> -managed as a whole, rather than mixed up in several dozen virtual
>> -machines.
>> +remaining isolated.  This means that the system can be
>> +treated as a whole, rather than many virtual
>> +machines each becoming a system of its own.
>>   
>>   <p>
>>   Spectrum is an upstream-first project.  Wherever possible, we aim to
>> -- 
>> 2.54.0

Re: [PATCH] Documentation: reword the distinctive feature of shared state

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]

Valentin Gagarin <valentin@gagarin.work> writes:

>>> - s/backed up and//
>>>
>>>    The difficulty of backing up is a specific instance of the
>>>    fragmentation problem.  But this is likely only evident to Qubes
>>>    users.  We can expect most readers to know about it theoretically at
>>>    best.  While it's not wrong to have this sort of anchor, keeping it
>>>    risks diluting the main message.
>> 
>> I'm concerned that removing the more specific verbs here might make it
>> more difficult to understand /why/ treating the system as a whole is
>> desirable.  We don't have to be so specific as to call out backups or
>> management, but I think without talking about something more specific,
>> even if that's just "thinking", as in "one only needs to think about a
>> single system", it loses its motivation.
>
> Yes, what we're trying to convey here feels tricky to get right.  Not 
> sure "thinking of" is more specific than "treating", but maybe it better 
> gets across a sentiment of "conceptualising" (in the sense of: mentally 
> grasping).  In my drafting I was mainly focused on the interaction with 
> the system, since I came from the original which worked with examples of 
> handling the system and thus *implied* some thinking.  Maybe thinking is 
> just the right thing.  At least this sounds perfectly fine to me:
>
>      This means that the system can be thought of as a whole, rather than
>      many virtual machines each becoming a system of its own.
>
> One could argue that thinking about a system is a very specific 
> interaction we perform very often...
>
> Feel free to fix it up like that, otherwise I'll give it another round 
> of ideas.

Thinking about it some more, I wonder if maybe my emphasis on verbs was
misplaced.  The underlying thing I wanted to communicate is the feeling,
and I was relying on the verbs to connote those feelings to the reader.
The relevant feelings here are "burdened" and "overwhelmed".  Perhaps
there's a better way to get those across, either directly or indirectly.
What do you think?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[PATCH v2 1/2] Documentation: reword the distinctive feature of shared state

[Valentin Gagarin]

This changes front-page wording in load-bearing ways, for reasons that
may be non-obvious.

The overarching idea is to reduce the textual surface area, for instance
by replacing arbitrary examples with subsuming terms, while
staying very specific with what is to be conveyed and where possible
making it more relatable to the intended audience.

- Split into shorter sentences

  Each one is focused on describing a separate idea.  The second idea is
  more complex and warrants more words, so having a dedicated sentence
  avoids losing the reader.

- s/User data and application state/Persistent data/

  The focus of the sentence is the central management.  By being a bit
  more general while technically still very specific (all persistent
  data is the same from the perspective of the system) we save the
  attention for the important part.

- s/remaining isolated/applications remain isolated/

  The data being isolated never made sense; it's the applications'
  access to it that is isolated. The phrasing chosen is more compact but
  still correct, and leaves room for expanding on the isolation in
  a separate paragraph.

- s/several dozen/many/

  The particular number doesn't matter, and may be arbitrarily wrong in
  practice.  The point is that there's fragmentation.  The snark about
  any large number is unnecessary if we put the real problem in the
  foreground.

- s/mixed up in//

  It could be that entanglement is an issue, but fragmentation seems to
  be the bigger issue.  In any case, the original sentence was awkward
  grammatically, because it tried putting together how a system is
  handled with what the system is like.

- s/managed as a whole/still treated as a whole/

  We're already saying "managed" in the first sentence.  Managing
  the system is very different from managing state.  We need to be
  careful with using words without prior definitions, so the best we can
  do here is avoid inadvertent conflation.  There is enough potential
  for confusion as it is.

  "still" acknowledges the traditional single-system experience that
  Spectrum preserves by design.

- s/backed up and//

  The difficulty of backing up is a specific instance of the
  fragmentation problem.  But this is likely only evident to Qubes
  users.  We can expect most readers to know about it theoretically at
  best.  While it's not wrong to have this sort of anchor, keeping it
  risks diluting the main message.

- "each becoming a system of its own"

  This captures the Qubes failure mode Spectrum avoids, where per-VM state
  accumulation forces operators into what amounts to orchestrating
  a cluster on one's desktop.

  In the original, the contrast to Qubes would not be as strong for
  people only familiar with it superficially.  Being more explicit about
  the nature of the problem helps establishing the narrative frame and
  original motivation of Spectrum early on, part of which is overcoming
  Qubes limitations.

Signed-off-by: Valentin Gagarin <valentin@gagarin.work>
---
 Documentation/index.html | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/index.html b/Documentation/index.html
index a717d2c..6d4f07b 100644
--- a/Documentation/index.html
+++ b/Documentation/index.html
@@ -22,10 +22,10 @@ lower barrier to entry and to be easier to use and maintain than other
 such systems.
 
 <p>
-User data and application state will be managed centrally, while
-remaining isolated, meaning that the system can be backed up and
-managed as a whole, rather than mixed up in several dozen virtual
-machines.
+Persistent data will be managed centrally, while
+applications remain isolated. This means that the system can still be
+thought of as a whole, rather than many virtual
+machines each becoming a system of its own.
 
 <h2>Design philosophy</h2>
 
-- 
2.54.0

[PATCH v2 2/2] Documentation: sketch the threat model on the front page

[Valentin Gagarin]

Also capture the poking-holes security model and hint at the trust
boundary.

This way of phrasing it intentionally doesn't go into any detail.
Proper exposition in dedicated documents would still be fruitful,
especially for readers less experienced with the domain.  But this way
we already mention all the most important ideas in the first few
paragraphs, which should be more likely to capture attention of experts.

Signed-off-by: Valentin Gagarin <valentin@gagarin.work>
---
 Documentation/index.html | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/index.html b/Documentation/index.html
index 6d4f07b..e1c5ebb 100644
--- a/Documentation/index.html
+++ b/Documentation/index.html
@@ -21,9 +21,14 @@ the principle of security by compartmentalization.  It aims to have a
 lower barrier to entry and to be easier to use and maintain than other
 such systems.
 
+<p>
+By isolating each application in a virtual machine, Spectrum prevents untrusted
+software from accessing what you haven't explicitly allowed or disrupting other
+applications.
+
 <p>
 Persistent data will be managed centrally, while
-applications remain isolated. This means that the system can still be
+preserving boundaries between compartments. This means that the system can still be
 thought of as a whole, rather than many virtual
 machines each becoming a system of its own.
 
-- 
2.54.0

Re: [PATCH v2 1/2] Documentation: reword the distinctive feature of shared state

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 4201 bytes --]

Valentin Gagarin <valentin@gagarin.work> writes:

> This changes front-page wording in load-bearing ways, for reasons that
> may be non-obvious.
>
> The overarching idea is to reduce the textual surface area, for instance
> by replacing arbitrary examples with subsuming terms, while
> staying very specific with what is to be conveyed and where possible
> making it more relatable to the intended audience.
>
> - Split into shorter sentences
>
>   Each one is focused on describing a separate idea.  The second idea is
>   more complex and warrants more words, so having a dedicated sentence
>   avoids losing the reader.
>
> - s/User data and application state/Persistent data/
>
>   The focus of the sentence is the central management.  By being a bit
>   more general while technically still very specific (all persistent
>   data is the same from the perspective of the system) we save the
>   attention for the important part.
>
> - s/remaining isolated/applications remain isolated/
>
>   The data being isolated never made sense; it's the applications'
>   access to it that is isolated. The phrasing chosen is more compact but
>   still correct, and leaves room for expanding on the isolation in
>   a separate paragraph.
>
> - s/several dozen/many/
>
>   The particular number doesn't matter, and may be arbitrarily wrong in
>   practice.  The point is that there's fragmentation.  The snark about
>   any large number is unnecessary if we put the real problem in the
>   foreground.
>
> - s/mixed up in//
>
>   It could be that entanglement is an issue, but fragmentation seems to
>   be the bigger issue.  In any case, the original sentence was awkward
>   grammatically, because it tried putting together how a system is
>   handled with what the system is like.
>
> - s/managed as a whole/still treated as a whole/
>
>   We're already saying "managed" in the first sentence.  Managing
>   the system is very different from managing state.  We need to be
>   careful with using words without prior definitions, so the best we can
>   do here is avoid inadvertent conflation.  There is enough potential
>   for confusion as it is.
>
>   "still" acknowledges the traditional single-system experience that
>   Spectrum preserves by design.
>
> - s/backed up and//
>
>   The difficulty of backing up is a specific instance of the
>   fragmentation problem.  But this is likely only evident to Qubes
>   users.  We can expect most readers to know about it theoretically at
>   best.  While it's not wrong to have this sort of anchor, keeping it
>   risks diluting the main message.
>
> - "each becoming a system of its own"
>
>   This captures the Qubes failure mode Spectrum avoids, where per-VM state
>   accumulation forces operators into what amounts to orchestrating
>   a cluster on one's desktop.
>
>   In the original, the contrast to Qubes would not be as strong for
>   people only familiar with it superficially.  Being more explicit about
>   the nature of the problem helps establishing the narrative frame and
>   original motivation of Spectrum early on, part of which is overcoming
>   Qubes limitations.
>
> Signed-off-by: Valentin Gagarin <valentin@gagarin.work>
> ---
>  Documentation/index.html | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/index.html b/Documentation/index.html
> index a717d2c..6d4f07b 100644
> --- a/Documentation/index.html
> +++ b/Documentation/index.html
> @@ -22,10 +22,10 @@ lower barrier to entry and to be easier to use and maintain than other
>  such systems.
>  
>  <p>
> -User data and application state will be managed centrally, while
> -remaining isolated, meaning that the system can be backed up and
> -managed as a whole, rather than mixed up in several dozen virtual
> -machines.
> +Persistent data will be managed centrally, while
> +applications remain isolated. This means that the system can still be
> +thought of as a whole, rather than many virtual
> +machines each becoming a system of its own.

I'm convinced, I think.  Lines are a bit ragged though so I'll rewrap
when applying.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: [PATCH v2 2/2] Documentation: sketch the threat model on the front page

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

Valentin Gagarin <valentin@gagarin.work> writes:

> Also capture the poking-holes security model and hint at the trust
> boundary.
>
> This way of phrasing it intentionally doesn't go into any detail.
> Proper exposition in dedicated documents would still be fruitful,
> especially for readers less experienced with the domain.  But this way
> we already mention all the most important ideas in the first few
> paragraphs, which should be more likely to capture attention of experts.
>
> Signed-off-by: Valentin Gagarin <valentin@gagarin.work>

Good addition.

> ---
>  Documentation/index.html | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/index.html b/Documentation/index.html
> index 6d4f07b..e1c5ebb 100644
> --- a/Documentation/index.html
> +++ b/Documentation/index.html
> @@ -21,9 +21,14 @@ the principle of security by compartmentalization.  It aims to have a
>  lower barrier to entry and to be easier to use and maintain than other
>  such systems.
>  
> +<p>
> +By isolating each application in a virtual machine, Spectrum prevents untrusted
> +software from accessing what you haven't explicitly allowed or disrupting other
> +applications.
> +
>  <p>
>  Persistent data will be managed centrally, while
> -applications remain isolated. This means that the system can still be
> +preserving boundaries between compartments. This means that the system can still be

Do you think it's already understandable by this point what a
compartment is, to a reader that is learning about security by
compartmentalization for the first time?

>  thought of as a whole, rather than many virtual
>  machines each becoming a system of its own.
>  
> -- 
> 2.54.0

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: [PATCH v2 1/2] Documentation: reword the distinctive feature of shared state

[Alyssa Ross]

This patch has been committed as 1e746f2b283f0d4964131e80b6a4f1def99f7510,
which can be viewed online at
https://spectrum-os.org/git/spectrum/commit/?id=1e746f2b283f0d4964131e80b6a4f1def99f7510.

This is an automated message.  Send comments/questions/requests to:
Alyssa Ross <hi@alyssa.is>

Re: [PATCH v2 2/2] Documentation: sketch the threat model on the front page

[Valentin Gagarin]

On 6/22/26 15:26, Alyssa Ross wrote:
> Valentin Gagarin <valentin@gagarin.work> writes:
> 
>> Also capture the poking-holes security model and hint at the trust
>> boundary.
>>
>> This way of phrasing it intentionally doesn't go into any detail.
>> Proper exposition in dedicated documents would still be fruitful,
>> especially for readers less experienced with the domain.  But this way
>> we already mention all the most important ideas in the first few
>> paragraphs, which should be more likely to capture attention of experts.
>>
>> Signed-off-by: Valentin Gagarin <valentin@gagarin.work>
> 
> Good addition.
> 
>> ---
>>   Documentation/index.html | 7 ++++++-
>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/index.html b/Documentation/index.html
>> index 6d4f07b..e1c5ebb 100644
>> --- a/Documentation/index.html
>> +++ b/Documentation/index.html
>> @@ -21,9 +21,14 @@ the principle of security by compartmentalization.  It aims to have a
>>   lower barrier to entry and to be easier to use and maintain than other
>>   such systems.
>>   
>> +<p>
>> +By isolating each application in a virtual machine, Spectrum prevents untrusted
>> +software from accessing what you haven't explicitly allowed or disrupting other
>> +applications.
>> +
>>   <p>
>>   Persistent data will be managed centrally, while
>> -applications remain isolated. This means that the system can still be
>> +preserving boundaries between compartments. This means that the system can still be
> 
> Do you think it's already understandable by this point what a
> compartment is, to a reader that is learning about security by
> compartmentalization for the first time?

My gut feel is it will be alright, because the intuitive notion of 
compartment maps good enough to what's really going on.  Open to 
suggestions for further improvement of course.

Re: [PATCH v2 2/2] Documentation: sketch the threat model on the front page

[Alyssa Ross]

This patch has been committed as bb0878d5c4537c92f4659b0f1373d8d6b7f76c79,
which can be viewed online at
https://spectrum-os.org/git/spectrum/commit/?id=bb0878d5c4537c92f4659b0f1373d8d6b7f76c79.

This is an automated message.  Send comments/questions/requests to:
Alyssa Ross <hi@alyssa.is>

Re: [PATCH v2 2/2] Documentation: sketch the threat model on the front page

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

Valentin Gagarin <valentin@gagarin.work> writes:

> Also capture the poking-holes security model and hint at the trust
> boundary.
>
> This way of phrasing it intentionally doesn't go into any detail.
> Proper exposition in dedicated documents would still be fruitful,
> especially for readers less experienced with the domain.  But this way
> we already mention all the most important ideas in the first few
> paragraphs, which should be more likely to capture attention of experts.
>
> Signed-off-by: Valentin Gagarin <valentin@gagarin.work>
> ---
>  Documentation/index.html | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/index.html b/Documentation/index.html
> index 6d4f07b..e1c5ebb 100644
> --- a/Documentation/index.html
> +++ b/Documentation/index.html
> @@ -21,9 +21,14 @@ the principle of security by compartmentalization.  It aims to have a
>  lower barrier to entry and to be easier to use and maintain than other
>  such systems.
>  
> +<p>
> +By isolating each application in a virtual machine, Spectrum prevents untrusted
> +software from accessing what you haven't explicitly allowed or disrupting other
> +applications.
> +
>  <p>
>  Persistent data will be managed centrally, while
> -applications remain isolated. This means that the system can still be
> +preserving boundaries between compartments. This means that the system can still be
>  thought of as a whole, rather than many virtual
>  machines each becoming a system of its own.

FYI: this is getting to the point where it needs a copyright header
update.  Next time please. :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]