make capitalization more consistent

i2p2www/blog/2024/03/29/many-masks-one-mind.draft.rst

@@ -17,17 +17,17 @@ Author's note: the attacks referred to in this article are not possible against
 As a self-organizing peer-to-peer network, I2P relies on the routers participating in the network to have a way to share information about what is on the network and how to reach it.
 I2P routers achieve this information sharing using the NetDB, a DHT based on Kademlia but modified to work for I2P.
 The NetDB needs to share two main kinds of entries, "RouterInfos" which peers will use to communicate with other routers directly, and "LeaseSets" which other peers will use to communicate with I2P clients through anonymous tunnels.
-Routers are frequently commmunicating NetDB entries with eachother, either by sending the information to a Router or Client, or requesting information from a Router or Client.
+Routers are frequently commmunicating NetDB entries with eachother, either by sending the information to a router or client, or requesting information from a router or client.
 This means that the entries can arrive directly or indirectly, anonymously or non-anonymously, depending on the needs of the network and the capabilities of the client.
 However, as an anonymizing network, it's also important that it remain impossible for information sent anonymously to be requested back non-anonymously.
 It is also important and for information sent non-anonymously to be impossible to request back anonymously.
 If it becomes possible for either of those situations to occur, then a linking attack may be carried out which allows an attacker to determine if a clients and routers are sharing a common view of the NetDB.
 If it can be reliably determined that the 2 targets share a common view of the NetDB, then there's a very good chance they are on the same router, weakening the target's anonymity drastically.
-Because there are so few anonymyzing networks, and I2P is the only one where the routing table is shared via the operation of a DHT, this class of attack is all but unique to I2P and it's resolution is important to I2P's success.
+Because there are so few anonymizing networks, and I2P is the only one where the routing table is shared via the operation of a DHT, this class of attack is all but unique to I2P and it's resolution is important to I2P's success.
 {%- endtrans %}
 
 {% trans -%}
-Consider the following scenario: There is an I2P Router hosting an I2P client.
+Consider the following scenario: There is an I2P router hosting an I2P client.
 The router publishes a RouterInfo, and the I2P client publishes it's LeaseSet.
 Because they are both published in the NetDB, other I2P routers can query the NetDB to discover how to communicate with them.
 This is normal and essential to the operation of an overlay network of the type implemented by I2P.
@@ -35,13 +35,13 @@ An attacker runs an I2P router and queries the NetDB for the target RouterInfo a
 It then crafts a new LeaseSet which is unique and and potentially even fake, and sends it down a tunnel to the LeaseSet for the client it is targeting for attack.
 The client processes the crafted LeaseSet and adds it to it's own NetDB.
 The attacker then requests the crafted LeaseSet back directly, from the router, using the RouterInfo it got from the NetDB.
-If the crafted LeaseSet is recieved back as a reply, then the attacker can conclude that the target client and the target Router share a common view of the NetDB.
+If the crafted LeaseSet is recieved back as a reply, then the attacker can conclude that the target client and the target router share a common view of the NetDB.
 {%- endtrans %}
 
 {% trans -%}
 That is a simple example of a NetDB deanonymization attack class which relies on adding an entry into another person's NetDB with one identity, and then requesting it back out with another identity.
-In this case, the identities in question are the "Router" and the "Client" identity.
-However, Client-to-Client linking, which is less damaging, is also possible in some designs.
+In this case, the identities in question are the "router" and the "client" identity.
+However, client-to-client linking, which is less damaging, is also possible in some designs.
 Designing a defense against this class of attack requires giving the router a way of determining whether or not it is safe to communicate a piece of information with a potential identity.
 {%- endtrans %}
 
@@ -71,8 +71,8 @@ It must be able to recall:
 
 * {% trans -%}Whether a NetDB Entry was recieved directly, or recieved down a client tunnel{%- endtrans %}
 * {% trans -%}Whether a NetDB Entry was sent by a peer in response to our lookup, or sent unsolicited{%- endtrans %}
-* {% trans -%}Which NetDB Entry was recieved down Which Client Tunnel{%- endtrans %}
-* {% trans -%}Multiple versions of the same entry for different Client tunnels{%- endtrans %}
+* {% trans -%}Which NetDB Entry was recieved down Which client Tunnel{%- endtrans %}
+* {% trans -%}Multiple versions of the same entry for different client tunnels{%- endtrans %}
 
 {% trans -%}
 Structurally, the most understandable and reliable way to handle this pattern is to use "Sub-DBs."