Update README.md

Update README.md after merging the fork.

README.md

@@ -6,14 +6,14 @@ A simple monitoring dashboard for Docker in Swarm Mode.
 
 ## About
 
-Swarm dashboard shows you all the tasks running on a Docker Swarm organised
-by service and node. It provides a visualisation that's space efficient
+Swarm dashboard shows you all the tasks running on a Docker Swarm organized
+by service and node. It provides a visualization that's space-efficient
 and works well at a glance.
 
 You can use it as a simple live dashboard of the state of your Swarm.
 
 The Dashboard has a node.js server which streams swarm updates to an Elm client
-over a websocket.
+over a WebSocket.
 
 ### Prior art
 
@@ -68,13 +68,11 @@ $ docker stack deploy -c compose.yml svc
 
 ## Security
 
-In this fork we have added some security measures:
++ We redact docker event data before sending them to the client. The previous version was sending the whole docker event data, including environment variables (someone might have stored some passwords in them, by mistake!). So, please consider using the newer version.
 
-+ We don't send the whole docker event data. The [main repo](https://github.com/charypar/swarm-dashboard) sends everything, including environment variables (someone might have stored some passwords in them, by mistake!).
++ Using the `ENABLE_AUTHENTICATION` environment variable, there is an option to use `Basic Auth`. The WebSocket server will close the connection if it does not receive a valid authentication token. See the example in the above section for more info.
 
-+ Using the `ENABLE_AUTHENTICATION` environment variable, there is an option to use `Basic Auth`. The WebSocket server will close the connection if it does not receive a valid authentication token.
-
-+ Using the `ENABLE_HTTPS` environment variable, there is an option to use `HTTPS` and `WSS`. We have Let’s Encrypt integration with the DNS challenge.
++ Using the `ENABLE_HTTPS` environment variable, there is an option to use `HTTPS` and `WSS`. We have Let’s Encrypt integration with the DNS challenge. See the example in the above section for more info.
 
 
 ## Production use
@@ -85,15 +83,15 @@ There are two considerations for any serious deployment of the dashboard:
    and runs on the manager, which makes it a significant attack surface (i.e. compromising
    the dashboard's node server would give an attacker full control of the swarm)
 1. The interaction with docker API is a fairly rough implementation and
-   is not very optimised. The server polls the API every 500 ms, publishing the
-   response data to all open websockets if it changed since last time. There
+   is not very optimized. The server polls the API every 500 ms, publishing the
+   response data to all open WebSockets if it changed since last time. There
    is probably a better way to look for changes in the Swarm that could be used
    in the future.
 
 
 ## Rough roadmap
 
-* Show more service details (published port, image name and version)
+* Show more service details (published port, image name, and version)
 * Node / Service / Task details panel
 * Show node / task resources (CPU & Memory)
 * Improve security for potential production use