1 files changed, 3 insertions, 3 deletions

diff --git a/pages/about-us/infosec/en.haml b/pages/about-us/infosec/en.haml
index 8fd1efe..19ce908 100644
--- a/pages/about-us/infosec/en.haml
+++ b/pages/about-us/infosec/en.haml
@@ -12,7 +12,7 @@
   %b Table 1. Information security of common messaging architectures
   = render_local_template 'table', :table_type => :big
 
-%p Reasonable people may disagree: this table represents one defensible assessment of the various architecture categories. Many people would adjust one or two cells, but on the whole we believe this table is a fair and accurate comparison.
+%p Reasonable people may disagree: this table represents one defensible assessment of the various architecture categories. Many people would adjust one or two cells, but on the whole we believe this table is a fair and accurate comparison. Some squares get low marks because of user error. For example, peer-to-peer systems have a hard time with user friendly keys, leading to high user error and low effective authenticity.
 
 %p In table 2 we see a simplified representation that highlights the relative differences between the encrypted architectures:
 
@@ -20,9 +20,9 @@
   %b Table 2. Relative trade-offs of encrypted messaging architectures
   = render_local_template 'table', :table_type => :small
 
-%p Relatively better is not necessarily good. For example, federated and peer-to-peer models have better authenticity than silo models, but usability problems make it so that their authenticity is often poor in practice.
+%p Relatively better is not necessarily good. For example, federated and peer-to-peer models have better authenticity than silo models, but still in practice have many authenticity problems.
 
-%h1 The LEAP strategy (you can have it all)
+%h1 The LEAP strategy
 
 %p In a nutshell, the LEAP strategy is this: take a federated architecture and improve the authenticity, unmappability, and usability. In table form, that looks like this: