[tor-commits] [webwml/master] Use English "singular they" where appropriate

[hiro@xxxxxxxxxxxxxx]

commit 536ce69287ce17e09938623fcbb2227fda1dc2ff
Author: Ingo Blechschmidt <iblech@xxxxxxxxxxxxxxx>
Date:   Sun Dec 10 14:20:39 2017 +0100

    Use English "singular they" where appropriate
    
    Signed-off-by: hiro <hiro@xxxxxxxxxxxxxx>
---
 docs/en/faq-abuse.wml      |  4 ++--
 docs/en/faq.wml            | 16 ++++++++--------
 docs/en/onion-services.wml |  4 ++--
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/docs/en/faq-abuse.wml b/docs/en/faq-abuse.wml
index d916bf97..c9cac5ba 100644
--- a/docs/en/faq-abuse.wml
+++ b/docs/en/faq-abuse.wml
@@ -204,8 +204,8 @@ using technology?</a></li>
 
     <p>But the real answer is to implement application-level auth systems,
     to let in well-behaving users and keep out badly-behaving users. This
-    needs to be based on some property of the human (such as a password he
-    knows), not some property of the way his packets are transported. </p>
+    needs to be based on some property of the human (such as a password they
+    know), not some property of the way their packets are transported. </p>
 
     <p>Of course, not all IRC networks are trying to ban Tor nodes. After
     all, quite a few people use Tor to IRC in privacy in order to carry
diff --git a/docs/en/faq.wml b/docs/en/faq.wml
index 4a63ccb3..0a9b38ee 100644
--- a/docs/en/faq.wml
+++ b/docs/en/faq.wml
@@ -2453,8 +2453,8 @@ exit
     policies are propagated to Tor clients via the directory, so clients
     will automatically avoid picking exit relays that would refuse to
     exit to their intended destination. This way each relay can decide
-    the services, hosts, and networks he wants to allow connections to,
-    based on abuse potential and his own situation. Read the FAQ entry
+    the services, hosts, and networks it wants to allow connections to,
+    based on abuse potential and its own situation. Read the FAQ entry
 on
     <a href="<page docs/faq-abuse>#TypicalAbuses">issues you might
 encounter</a>
@@ -2931,14 +2931,14 @@ Yes, you do get better anonymity against some attacks.
     </p>
     <p>
 The simplest example is an attacker who owns a small number of Tor relays.
-He will see a connection from you, but he won't be able to know whether
+They will see a connection from you, but they won't be able to know whether
 the connection originated at your computer or was relayed from somebody else.
     </p>
     <p>
 There are some cases where it doesn't seem to help: if an attacker can
-watch all of your incoming and outgoing traffic, then it's easy for him
+watch all of your incoming and outgoing traffic, then it's easy for them
 to learn which connections were relayed and which started at you. (In
-this case he still doesn't know your destinations unless he is watching
+this case they still don't know your destinations unless they are watching
 them too, but you're no better off than if you were an ordinary client.)
     </p>
     <p>
@@ -2948,7 +2948,7 @@ signal to an attacker that you place a high value on your anonymity.
 Second, there are some more esoteric attacks that are not as
 well-understood or well-tested that involve making use of the knowledge
 that you're running a relay -- for example, an attacker may be able to
-"observe" whether you're sending traffic even if he can't actually watch
+"observe" whether you're sending traffic even if they can't actually watch
 your network, by relaying traffic through your Tor relay and noticing
 changes in traffic timing.
     </p>
@@ -3475,7 +3475,7 @@ keys,
     locations, exit policies, and so on. So unless the adversary can
 control
     a majority of the directory authorities (as of 2012 there are 8
-    directory authorities), he can't trick the Tor client into using
+    directory authorities), they can't trick the Tor client into using
     other Tor relays.
     </p>
 
@@ -4213,7 +4213,7 @@ only solution is to have no opinion.
     Like all anonymous communication networks that are fast enough for web
     browsing, Tor is vulnerable to statistical "traffic confirmation"
     attacks, where the adversary watches traffic at both ends of a circuit
-    and confirms his guess that they're communicating. It would be really
+    and confirms their guess that those endpoints are communicating. It would be really
     nice if we could use cover traffic to confuse this attack. But there
     are three problems here:
     </p>
diff --git a/docs/en/onion-services.wml b/docs/en/onion-services.wml
index a73ff7d3..c35b76c3 100644
--- a/docs/en/onion-services.wml
+++ b/docs/en/onion-services.wml
@@ -107,9 +107,9 @@
     the same set of <a
     href="<wikifaq>#Whatsthisaboutentryguardformerlyknownashelpernodes">entry
     guards</a> when creating new circuits. Otherwise an attacker
-    could run his own relay and force an onion service to create an arbitrary
+    could run their own relay and force an onion service to create an arbitrary
     number of circuits in the hope that the corrupt relay is picked as entry
-    node and he learns the onion server's IP address via timing analysis. This
+    node and they learn the onion server's IP address via timing analysis. This
     attack was described by &Oslash;verlier and Syverson in their paper titled
     <a href="http://freehaven.net/anonbib/#hs-attack06";>Locating Hidden
     Servers</a>.

_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits