[tor-commits] [tor-browser-spec/master] All your spells are checked to us!

[mikeperry at torproject.org]

commit 629233c1965860f535ccfe1678cf4b5ca2ae59f9
Author: Mike Perry <mikeperry-git at torproject.org>
Date:   Thu Apr 30 21:10:25 2015 -0700

    All your spells are checked to us!
---
 position-papers/HTTP3/HTTP3.tex |   28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/position-papers/HTTP3/HTTP3.tex b/position-papers/HTTP3/HTTP3.tex
index 720bc25..6040902 100644
--- a/position-papers/HTTP3/HTTP3.tex
+++ b/position-papers/HTTP3/HTTP3.tex
@@ -101,12 +101,12 @@ point how complicated this isolation will be.
 We feel that it is very important that mechanisms for identifier usage,
 storage, and connection-related state keeping be cleanly abstracted and
 narrowly scoped within the HTTP protocol. However, we also recognize that to a
-large degree identifier usage and the resulting linkability is primarly an
+large degree identifier usage and the resulting linkability is primarily an
 implementation detail, and not specific to the protocol itself.
 
 Identifier linkability will become a problem if instances arise where the
 server is allowed to specify a setting or configuration property for a client
-that must presist beyond the duration of the session. In these cases, care
+that must persist beyond the duration of the session. In these cases, care
 must be taken to ensure that this data is cleared or isolated upon entry to
 private browsing mode, or when the user attempts to clear their private data.
 
@@ -149,7 +149,7 @@ User agent fingerprinting arises from four sources: end-user configuration
 details, device and hardware characteristics, operating system vendor and
 version differences, and browser vendor and version differences.
 
-The Tor Project is primarily concerned with minimzing the ability of websites
+The Tor Project is primarily concerned with minimizing the ability of websites
 to obtain or infer end user configuration details and device characteristics.
 We concern ourselves with operating system fingerprinting only to the point of
 removing ways of detecting a specific operating system version. We make no
@@ -171,7 +171,7 @@ alter our implementation's behavior accordingly.
 
 \subsection{Avoiding Future Fingerprinting Linkability}
 
-It is concievable that more fingerprinting vectors could arise in future,
+It is conceivable that more fingerprinting vectors could arise in future,
 especially if flow control and stream multiplexing decisions are delegated to
 the client, and depend on things like available system memory, available CPU
 cores, or other details. Care should be taken to avoid these situations,
@@ -188,12 +188,12 @@ the Let's Encrypt Project should eliminate the remaining barriers to requiring
 authenticated encryption, as opposed to deploying opportunistic mechanisms.
 
 We are also interested in efforts to encrypt the ClientHello and ServerHello
-messages in an initial forward-secure handshake, as described in the Encrytped
+messages in an initial forward-secure handshake, as described in the Encrypted
 TLS Handshake proposal. If SNI, ALPN, and the ServerHello can be encrypted
 using an ephemeral exchange that is authenticated later in the handshake,
 the adversary loses a great deal of information about the user's intended
 destination site. When large scale CDNs and multi-site load balancers are
-involved, the ulimate destination would be impossible to determine with this
+involved, the ultimate destination would be impossible to determine with this
 type of handshake in place. This will aid in defenses against traffic
 fingerprinting and traffic analysis, which we describe detail in the next
 section.
@@ -209,13 +209,13 @@ classification domain is limited by knowledge of the specific site being
 visited.
 
 Tor's fixed 512 byte packet size and large classification domain go a long way
-to imede this attack for minimal overhead. The 512 byte packet size helps to
+to impede this attack for minimal overhead. The 512 byte packet size helps to
 obscure some amount of length information, and Tor's link encryption conceals
 the destination website reduces classifier accuracy and capabilities, due
 largely to the Base Rate Fallacy. There was some initial controversy in the
 literature as to the exact degree to which this was the case, but after
 publicly requesting that these effects be studied in closer detail, recent
-results have confirmed and quantized the benefits conferred by Tor's unique
+results have confirmed and quantified the benefits conferred by Tor's unique
 link encryption.
 
 For this reason, we have been encouraging continued study of low-overhead
@@ -249,11 +249,11 @@ purpose (such as redirects or Javascript), but these mechanisms can either be
 disabled by the user, reflected in UI activity, or otherwise mitigated by Tor
 Browser
 
-In Tor Browser, we will likely close the connection after recieving some rate
-of unsolicitied PING or SETTINGS updates, and introduce delay or jitter before
+In Tor Browser, we will likely close the connection after receiving some rate
+of unsolicited PING or SETTINGS updates, and introduce delay or jitter before
 responding to these requests before that point. However, lack of explicit
 guidance in the specification about this issue raises concerns about what
-frequencies of these frames are likely to contitute attacks, or instead
+frequencies of these frames are likely to constitute attacks, or instead
 represent normal server behavior in the wild due to overly-aggressive HTTP/2
 implementations.
 
@@ -267,7 +267,7 @@ frame size.
 
 In combination with researchers at the University of Leuven, the Tor Project
 has also developed a protocol and prototype implementation for communicating
-statistical schedules for asynchonous padding from Tor clients to Tor relays.
+statistical schedules for asynchronous padding from Tor clients to Tor relays.
 The research community is currently in the process of evaluating the efficacy
 of this protocol against traffic fingerprinting and other traffic analysis
 attacks.
@@ -297,7 +297,7 @@ full network transition to UDP is at least five years away.
 % FIXME: Site Murdoch's UDP study
 
 While it will be technically possible to support the transit of UDP inside our
-existing TCP overlay network without signficant anonymity risks within a
+existing TCP overlay network without significant anonymity risks within a
 year's time or sooner, it is unlikely that this level of support will be
 sufficient to warrant the use of a finely-tuned UDP version of HTTP rather
 than a TCP variant.
@@ -308,7 +308,7 @@ a UDP version of HTTP/3 may still end up performing poorly over higher-latency
 overlay networks such as ours. We are especially interested in ensuring that
 overlay networks are taken in to account in the design of any UDP-based future
 versions of HTTP, and would also prefer to retain the ability to use future
-HTTP versions over TCP, should the UDP implementations prove suboptimal for
+HTTP versions over TCP, should the UDP implementations prove sub-optimal for
 our use case.