minor edit to infosec page
authorelijah <elijah@riseup.net>
Thu, 25 Jul 2013 09:21:21 +0000 (02:21 -0700)
committerelijah <elijah@riseup.net>
Thu, 25 Jul 2013 09:21:21 +0000 (02:21 -0700)
pages/about-us/infosec/en.haml

index 8fd1efe..19ce908 100644 (file)
@@ -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: