commit 536ce69287ce17e09938623fcbb2227fda1dc2ff Author: Ingo Blechschmidt iblech@speicherleck.de Date: Sun Dec 10 14:20:39 2017 +0100

Use English "singular they" where appropriate

Signed-off-by: hiro hiro@torproject.org --- 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>.