goals: Clarify that unlocked systems are possible (#12)

I don't forsee us *ever* getting to a state where every single
use case has the end user owning their own builds; I think there will
be widespread "unlocked" system usage especially for "standalone"
systems like Linux desktops as well as small scale servers.

Signed-off-by: Colin Walters <[email protected]>

index.md

@@ -26,6 +26,6 @@ This default behavior can be adapted or controlled by a larger management system
 
 1. It should always be possible to factory reset back to either the known built behavior of the system or roll back to previous behavior if an updated image does not function correctly.
 
-1. A cryptographic trust chain that runs from the hardware, through the boot loader, through the operating system all the way to the applications ensures that only the expected code is run, and the contents of the operating system and applications have not been changed unexpectedly.
+1. It should be supported to create a cryptographic trust chain that runs from the hardware, through the boot loader, through the operating system all the way to the applications ensures that only the expected code is run, and the contents of the operating system and applications have not been changed unexpectedly.
 If something has been changed, or changes at runtime unexpectedly, the system can alert or stop.
-The builder of the images can sign the images with keys that are under their own control, or of course build images and deploy systems without a trust chain.
+The builder of the images can sign the images with keys that are under their own control, or of course build images and deploy systems without a trust chain.  But, it also continues to be supported by system builders to create "unlocked" systems where the end user can make local unsigned changes.