Update text to better describe the security issues.

1 files changed, 20 insertions, 25 deletions

diff --git a/README b/README
index ee83e78..021135d 100644
--- a/README
+++ b/README
@@ -1,24 +1,19 @@
 Introduction
 ------------
 
-The session broadcast service exists to provide a way for the greeter
-to be able to communicate back to the user session information about
-the user's desires without having to connect to the session and provide
-access to all that it would contain.  This is because the greeter is
-untrusted in a multi-user system, and thus shouldn't connect to the user's
-session.  While this does allow more access than most multi-user systems
-would allos, it is designed for cases of single user systems that have
-multi-user for security and thus is about limiting the interaction
-more than providing complete security around the session.
+The session broadcast service provides a way for the greeter to communicate
+information back to user sessions without requiring special privileges.
+In a multi-user system, the greeter is untrusted, and shouldn't directly
+connect to a user session.
 
 How it works
 ------------
 
-The greeter session can send a message to a service that exists on the system
-DBus.  That messages is then rebroadcast as a signal coming from the well-known
-name of the system service.  Each user session that is currently active has a
-listener for that well known signal and acts on it taking into account the current
-settings of the session.
+The greeter session can send a message to a service that exists on the
+system DBus. That messages is then rebroadcast as a signal coming from the
+well-known name of the system service. Each user session that is currently
+active has a listener for that well known signal and can act on it taking
+into account the current settings and user preferences of the session.
 
 
             Greeter Session                                    User Session
@@ -52,15 +47,15 @@ settings of the session.
 Security
 --------
 
-As noted in the introduction we're not creating something that is completely
-secure, but that doesn't mean we can't take some measures to ensure that security
-isn't forgotten.  So the following policies are in place:
-
- * Messages are only accepted from the lightdm user.  All other messages from
-   other folks on the bus are rejected.
- * The User session will have a configuration option to whether the events will
-   be acted on.  This allows for configuring user sessions to be more secure if
-   needed for particular uses (enterprise, government, etc.)
- * Each message and feature will be well defined without dictionaries or other
-   extension mechanisms.
+All active user session receive greeter broadcasted signals. The following
+security policies are in place:
+
+ * Messages are only accepted from the lightdm user. All other messages
+   from other folks on the bus are rejected.
+ * The User session will have configuration options to determine which
+   events will be acted on. This allows for users to configure their
+   session with an appropriate security policy (complete privacy,
+   enterprise or government users, etc.)
+ * Each message and feature will be well defined without dictionaries or
+   other extension mechanisms.