diff options
author | elijah <elijah@riseup.net> | 2013-07-25 02:21:21 -0700 |
---|---|---|
committer | elijah <elijah@riseup.net> | 2013-07-25 02:21:21 -0700 |
commit | 703b97f8e2697d55cd6ab070b711aa3a9d8deccb (patch) | |
tree | 3d75b9dc4091f5bf81cc2e123c5dc7d9ca6117de /pages | |
parent | dcae23368303b8205a363998e1ae0a21a2288363 (diff) |
minor edit to infosec page
Diffstat (limited to 'pages')
-rw-r--r-- | pages/about-us/infosec/en.haml | 6 |
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: |