small edits

Author: llpeterson

intro.rst

@@ -266,14 +266,14 @@ behave. For example, if you plan to transmit messages over Wi-Fi on an
 open campus, you would likely identify an eavesdropper that can
 intercept messages as a threat (and adopt some of the methods
 discussed in this book as a countermeasure). But if you are planning
-to transmit messages over a fiber link between two machines in a
+to transmit messages over a fiber link between two servers in a
 locked machine room, you might trust that channel is secure, and so
 take no additional steps. Every system makes trust assumptions. The
 key is to be as explicit as possible about those assumptions, because
 they may change over time.
 
 Taking this thought process a step further, trust assumptions aren't
-always as clear-cut as this strawman suggests. For example, most of us
+always as clear-cut as our strawman suggests. For example, most of us
 implicitly trust that the computer we just bought from a reputable
 vendor does not forward our data to an adversary, but for some use
 cases, the hardware supply chain is a consideration. Buying time on

principles.rst

@@ -78,15 +78,15 @@ to mitigate such attacks.
 
 .. sidebar:: Picking Your Battles
 
-   *In Chapter 1 we talked about trust and threats being two sides of the
-   same coin, but another way to frame the discussion is that every secure
-   system design starts with two lists: (1) those elements you trust,
-   and so can build upon; and (2) those elements you do not trust, and
-   so must treat as a threat that you defend against. But this is no
-   different than for any system you build: you first identify the
-   building blocks you plan to take as a given, and then you design a
-   solution that fills the "gap" between those building blocks and the
-   requirements you are trying to meet.*
+   *In Chapter 1 we talked about trust and threats being two sides of
+   the same coin, but another way to frame the discussion is that
+   every secure system design starts with two lists: (1) those elements
+   you trust, and so can build upon; and (2) those elements you do not
+   trust, and so must treat as a source of threats that you defend
+   against. But this is no different than for any system you build:
+   you first identify the building blocks you plan to take as a given,
+   and then you design a solution that fills the "gap" between those
+   building blocks and the requirements you are trying to meet.*
 
    *One way in which security is unique is that over time you may
    discover that you need to move items from the first list to the