diff options
| -rw-r--r-- | proposals/326-tor-relay-well-known-uri-rfc8615.md | 2 | ||||
| -rw-r--r-- | proposals/327-pow-over-intro.txt | 4 | ||||
| -rw-r--r-- | proposals/341-better-oos.md | 6 |
3 files changed, 6 insertions, 6 deletions
diff --git a/proposals/326-tor-relay-well-known-uri-rfc8615.md b/proposals/326-tor-relay-well-known-uri-rfc8615.md index 7648162..075aa6d 100644 --- a/proposals/326-tor-relay-well-known-uri-rfc8615.md +++ b/proposals/326-tor-relay-well-known-uri-rfc8615.md @@ -12,7 +12,7 @@ This is a specification for a well-known [registry](https://www.iana.org/assignm This resource identifier can be used for serving and finding proofs related to [Tor](https://www.torproject.org/) relay and bridge contact information. It can also be used for autodiscovery of Tor relays run by a given entity, if the entity's domain is known. -It solves the issue that Tor relay/bridge contact information is an unidirectional and unverified claim by nature. +It solves the issue that Tor relay/bridge contact information is a unidirectional and unverified claim by nature. This well-known URI aims to allow the verification of the unidirectional claim. It aims to reduce the risk of impersonation attacks, where a Tor relay/bridge claims to be operated by a certain entity, but actually isn't. The automated verification will also support the [visualization of relay/bridge groups](https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001). diff --git a/proposals/327-pow-over-intro.txt b/proposals/327-pow-over-intro.txt index 0fb528f..ca7f7cd 100644 --- a/proposals/327-pow-over-intro.txt +++ b/proposals/327-pow-over-intro.txt @@ -339,7 +339,7 @@ Status: Draft tuple. For this reason a replay protection mechanism must be employed. The simplest way is to use a simple hash table to check whether a (seed, - nonce) tuple has been used before for the actiev duration of a + nonce) tuple has been used before for the active duration of a seed. Depending on how long a seed stays active this might be a viable solution with reasonable memory/time overhead. @@ -439,7 +439,7 @@ Status: Draft Every HS_UPDATE_PERIOD seconds the service should upload a new descriptor with a new suggested-effort value. - The service should avoid uploading descriptors too often to avoid overwheming + The service should avoid uploading descriptors too often to avoid overwhelming the HSDirs. The service SHOULD NOT upload descriptors more often than HS_UPDATE_PERIOD. The service SHOULD NOT upload a new descriptor if the suggested-effort value changes by less than 15%. diff --git a/proposals/341-better-oos.md b/proposals/341-better-oos.md index 0715c14..8ddf7fd 100644 --- a/proposals/341-better-oos.md +++ b/proposals/341-better-oos.md @@ -56,7 +56,7 @@ other words, when you see "A - B" below, read it as "MAX(A-B, 0)". ## Phase 1: Deciding how many connections to close -When we are find that we are low on sockets, we pick a number of sockets +When we find that we are low on sockets, we pick a number of sockets that we want to close according to our existing algorithm. (That is, we try to close 1/4 of our maximum sockets if we have reached our upper limit, or 1/10 of our maximum sockets if we have encountered a failure @@ -133,8 +133,8 @@ until we have closed at least our target number of exit connections. > This approach probabilistically favors closing circuits with a large > number of sockets open, regardless of how long those sockets have been > open. This defeats the easiest way of opening a large number of exit -> streams ("open them all on once circuit") without making the -> counter-approach ("open each exit stream on a its own circuit") much +> streams ("open them all on one circuit") without making the +> counter-approach ("open each exit stream on its own circuit") much > more attractive. ## Phase 3: Closing OR connections. |