incorporate feedback

x4.md

@@ -70,26 +70,31 @@ The well-defined format also makes it possible to support multiple types of conv
 
 Please refer to [Initial Message Payload Specification](x8.md) for more details.
 
-# Security layer
+# Conversational Security Layer
 
-Security layer provides various cryptographical properties to the Status Protocol:
+Conversational Security Layer provides various cryptographical properties to the Status Protocol:
-* encryption
+* confidentiality
-* assurance of the origin
+* integrity
-* forward secrecy
+* authentication
+* forward secrecy.
 
-Encryption makes sure that only author and the recipient can read the content of the message.
+Confidetiality makes sure that only intended recipients are able to read a message.
 
-Assurance of the origin using a digital signature ensures that the message was actually sent by the owner of a given public key and the message has not been changed induring the transport over the wire.
+Integrity means that no honest party will accept a message modified in the transit.
 
-Note: exchange and verification of the public keys is not a trivial problem. Read more about this problem in [Initial Trust Establishment Specification](x5.md).
+Authentication means that each participant in the conversation receives a proof of possession of a known long-term secret from all other participants. In addition, each participant is able to verify that a message was sent from the claimed source.
 
-Note: The Status Procol can work with PFS enabled and disabled. In the case of disabled PFS, the encryption is moved to the Privacy Layer and handled by Whisper. Whisper does **not** provide forward secrecy. This is a flaw of the original design which mixes security and private layer responsibilities.
+This assumes trust has already been established. Initial trust establishment is detailed in [Initial Trust Establishment Specification](x5.md).
+
+Forward secrecy, known also as perfect forwardsecrecy (PFS), gives assurance that session keys will not be compromised even if the private key is compromised. Also, compromising one session key will not result in compromising other sessions.
+
+Note: The Status Procol can work with PFS enabled and disabled. In the case of disabled PFS, the encryption is moved to the Privacy Layer and handled by Whisper. Whisper does **not** provide forward secrecy. This is a flaw of the original design which mixes security and private layer responsibilities. With PFS enabled, a message is encrypted twice.
 
 Please refer to [Initial Conversational Security Specification](x6.md) for more details.
 
-# Privacy layer
+# Transport privacy layer
 
-The purpose of the privacy layer is to hide metadata (provide darkness) that are always sent when communicating over the internet. In some cases, leaked metadata might be as dangerous as leaking the actual payload so it's important to reduce that.
+The purpose of the transport privacy layer is to hide metadata (provide darkness) that are always sent when communicating over the internet. In some cases, leaked metadata might be as dangerous as leaking the actual payload so it's important to reduce that.
 
 The Status Protocol uses [Whisper in version 6](https://github.com/ethereum/wiki/wiki/Whisper) as a privacy protection protocol. Whisper routes messages by broadcasting them to all connected peers so that identifying of the recipient is almost impossible (the sender is not equally protected, though). [Read more](https://github.com/ethereum/go-ethereum/wiki/Achieving-Darkness) about how Whisper achieves darkness.
 
@@ -99,26 +104,14 @@ Please refer to [Initial Transport Privacy through Whisper Specification](x7.md)
 
 # P2P layer
 
-P2P layer allows various clients to securely communicate with each other through the internet in a decetralized fashion, envetually forming a peer-to-peer network. Due to our close relationship to Ethereum and the fact that Whisper is built on top of [devp2p](https://github.com/ethereum/devp2p), we selected [devp2p](https://github.com/ethereum/devp2p) as a P2P layer.
+P2P layer allows various clients to securely communicate with each other through the internet in a decetralized fashion, envetually forming a peer-to-peer network. Due to our close relationship to Ethereum and the fact that Whisper is built on top of [devp2p](https://github.com/ethereum/devp2p), we use [devp2p](https://github.com/ethereum/devp2p) as a P2P layer.
 
-A client in order to rely a message needs to first find other clients within the peer-to-peer network (this is called node discovery). Then, the message needs to be properly routed handling obstacles like NAT traversal. All these things are handled by devp2p.
+A client in order to rely a message needs to first find other clients (this process is called node discovery and is out of scope of this specification) within the peer-to-peer network. Then, the message needs to be properly routed handling obstacles like NAT traversal. All these things are handled by devp2p.
 
 # Censorship resistance
 
 TODO
 
-# Availability/Robustness
-
-TODO
-
-# Continuance
-
-TODO
-
-# Existing implementations
-
-TODO
-
 # Known issues
 
 ## Dependencies between layers
@@ -128,14 +121,3 @@ As it was mentioned above, there are cases when two layers depend on one another
 * the privacy layer needs to know some details of the payload to properly route it.
 
 In the next version of the protocol, we will try to remove these dependencies so that all layers are orthogonal and if necessary there is a clean interface between one and another.
-
-# TODO
-
-## Review each section
-
-Each section, if possible, should follow this structure:
-- Current protocl
-- How we use it
-- Future considerations
-- Desired by Status
-- The ethereum txn viewpoint