[tor-commits] [tor-browser-spec/master] Speel check.

[mikeperry at torproject.org]

commit d856497cb5e0b5f51ecf642edbc1c2053b00d0f8
Author: Mike Perry <mikeperry-git at torproject.org>
Date:   Wed Oct 29 21:15:01 2014 -0700

    Speel check.
---
 design-doc/design.xml |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/design-doc/design.xml b/design-doc/design.xml
index a49de34..7c89257 100644
--- a/design-doc/design.xml
+++ b/design-doc/design.xml
@@ -372,7 +372,7 @@ url bar origin</ulink> to eliminate the possibility of linkability
 between domains. For example, when a plugin object (or a Javascript access of
 window.plugins) is present in a page, the user should be given the choice of
 allowing that plugin object for that url bar origin only. The same
-goes for exemptions to third party cookie policy, geo-location, and any other
+goes for exemptions to third party cookie policy, geolocation, and any other
 privacy permissions.
      </para>
      <para>
@@ -494,7 +494,7 @@ choosing.</para>
      <para>If direct proxy bypass is not possible, the adversary will likely
 happily settle for the ability to correlate something a user did via Tor with
 their non-Tor activity. This can be done with cookies, cache identifiers,
-javascript events, and even CSS. Sometimes the fact that a user uses Tor may
+Javascript events, and even CSS. Sometimes the fact that a user uses Tor may
 be enough for some authorities.</para>
      </listitem>
      <listitem><command>History disclosure</command>
@@ -626,7 +626,7 @@ with cookies as well.
 
 These types of attacks are attempts at subverting our <link
 linkend="identifier-linkability">Cross-Origin Identifier Unlinkability</link> and <link
-linkend="new-identity">Long-Term Unlikability</link> design requirements.
+linkend="new-identity">Long-Term Unlinkability</link> design requirements.
 
      </para>
      </listitem>
@@ -640,7 +640,7 @@ uniquely fingerprint individual users. Attacks of this nature are typically
 aimed at tracking users across sites without their consent, in an attempt to
 subvert our <link linkend="fingerprinting-linkability">Cross-Origin
 Fingerprinting Unlinkability</link> and <link
-linkend="new-identity">Long-Term Unlikability</link> design requirements.
+linkend="new-identity">Long-Term Unlinkability</link> design requirements.
 
 </para>
 
@@ -792,7 +792,7 @@ are large numbers of dynamically generated pages, partially cached content,
 and also the non-web activity of entire Tor network. This yields an effective
 number of "web pages" many orders of magnitude larger than even <ulink
 url="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf">Panchenko's
-"Open World" scenario</ulink>, which suffered continous near-constant decline
+"Open World" scenario</ulink>, which suffered continuous near-constant decline
 in the true positive rate as the "Open World" size grew (see figure 4). This
 large level of classification complexity is further confounded by a noisy and
 low resolution featureset - one which is also relatively easy for the defender
@@ -929,7 +929,7 @@ activity in the source tree that did not use the browser proxy settings.
  <para>
 
 We have verified that these settings and patches properly proxy HTTPS, OCSP,
-HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all javascript
+HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all JavaScript
 activity, including HTML5 audio and video objects, addon updates, wifi
 geolocation queries, searchbox queries, XPCOM addon HTTPS/HTTP activity,
 WebSockets, and live bookmark updates. We have also verified that IPv6
@@ -1584,7 +1584,7 @@ We simply disable it via the pref <command>dom.gamepad.enabled</command>.
     </listitem>
     <listitem>Invasive Authentication Mechanisms (NTLM and SPNEGO)
      <para>
-Both NTLM and SPNEGO authentication mechansisms can leak the hostname, and in
+Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in
 some cases the machine username. These authentication mechanisms should either
 be disabled, or placed behind a site permission before their use. We simply
 disable them.
@@ -1716,7 +1716,7 @@ popups to open in new tabs (via
 <command>browser.link.open_newwindow.restriction</command>), to avoid
 full-screen popups inferring information about the browser resolution. In
 addition, we prevent auto-maximizing on browser start, and are investigating a
-user-friendly way of informing users that maximized windows are deterimental
+user-friendly way of informing users that maximized windows are detrimental
 to privacy in this mode.
 
      </para>
@@ -2609,7 +2609,7 @@ libraries, and discarding the private portion of that key. Because there are
 many other ways to intercept the crypto outside of modifying the actual DLL
 images, we opted to simply remove these signature files from distribution.
 There simply is no way to verify code integrity on a running system without
-both OS and coprocessor assistance. Download package signatures make sense of
+both OS and co-processor assistance. Download package signatures make sense of
 course, but we handle those another way (as mentioned above).