[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [tor-browser-spec/master] Full spell check.



commit 593110b026b1e6c823d1cf96af73aa2d87abb900
Author: Mike Perry <mikeperry-git@xxxxxxxxxxxxxx>
Date:   Tue May 5 17:38:22 2015 -0700

    Full spell check.
---
 design-doc/design.xml |   72 ++++++++++++++++++++++++-------------------------
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/design-doc/design.xml b/design-doc/design.xml
index 96a232b..5765a51 100644
--- a/design-doc/design.xml
+++ b/design-doc/design.xml
@@ -23,7 +23,7 @@
      <address><email>sjmurdoch#torproject org</email></address>
     </affiliation>
    </author>
-   <pubdate>April 30th, 2015</pubdate>
+   <pubdate>May 5th, 2015</pubdate>
  </articleinfo>
 
 <sect1>
@@ -241,9 +241,9 @@ to prefer one browser over another.
 
 For the purposes of the unlinkability requirements of this section as well as
 the descriptions in the <link linkend="Implementation">implementation
-section</link>, a <command>url bar origin</command> means at least the
+section</link>, a <command>URL bar origin</command> means at least the
 second-level DNS name.  For example, for mail.google.com, the origin would be
-google.com. Implementations MAY, at their option, restrict the url bar origin
+google.com. Implementations MAY, at their option, restrict the URL bar origin
 to be the entire fully qualified domain name.
 
    </para>
@@ -253,8 +253,8 @@ to be the entire fully qualified domain name.
 Identifier Unlinkability</command></link> 
   <para>
 
-User activity on one url bar origin MUST NOT be linkable to their activity in
-any other url bar origin by any third party automatically or without user
+User activity on one URL bar origin MUST NOT be linkable to their activity in
+any other URL bar origin by any third party automatically or without user
 interaction or approval. This requirement specifically applies to linkability
 from stored browser identifiers, authentication tokens, and shared state. The
 requirement does not apply to linkable information the user manually submits
@@ -268,8 +268,8 @@ login in a substantial way.
 Fingerprinting Unlinkability</command></link> 
   <para>
 
-User activity on one url bar origin MUST NOT be linkable to their activity in
-any other url bar origin by any third party. This property specifically applies to
+User activity on one URL bar origin MUST NOT be linkable to their activity in
+any other URL bar origin by any third party. This property specifically applies to
 linkability from fingerprinting browser behavior.
 
   </para>
@@ -345,7 +345,7 @@ Therefore, if plugins are to be enabled in private browsing modes, they must
 be restricted from running automatically on every page (via click-to-play
 placeholders), and/or be sandboxed to restrict the types of system calls they
 can execute. If the user agent allows the user to craft an exemption to allow
-a plugin to be used automatically, it must only apply to the top level url bar
+a plugin to be used automatically, it must only apply to the top level URL bar
 domain, and not to all sites, to reduce cross-origin fingerprinting
 linkability.
 
@@ -367,10 +367,10 @@ system-wide and/or operating system provided addons or plugins.
 Instead of global browser privacy options, privacy decisions should be made
 <ulink
 url="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI";>per
-url bar origin</ulink> to eliminate the possibility of linkability
+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
+allowing that plugin object for that URL bar origin only. The same
 goes for exemptions to third party cookie policy, geolocation, and any other
 privacy permissions.
      </para>
@@ -397,7 +397,7 @@ third parties, rather than a list of specific URLs or hosts.
      <para>
 Filter-based addons can also introduce strange breakage and cause usability
 nightmares, and will also fail to do their job if an adversary simply
-registers a new domain or creates a new url path. Worse still, the unique
+registers a new domain or creates a new URL path. Worse still, the unique
 filter sets that each user creates or installs will provide a wealth of
 fingerprinting targets.
       </para>
@@ -534,7 +534,7 @@ In some cases, the adversary may opt for a heavy-handed approach, such as
 seizing the computers of all Tor users in an area (especially after narrowing
 the field by the above two pieces of information). History records and cache
 data are the primary goals here. Secondary goals may include confirming
-on-disk identifiers (such as hostname and disk-logged spoofed MAC adddress
+on-disk identifiers (such as hostname and disk-logged spoofed MAC address
 history) obtained by other means.
 
      </para>
@@ -699,7 +699,7 @@ AdBlock and other privacy filters can be used to fingerprint request patterns
 
 Javascript can reveal a lot of fingerprinting information. It provides DOM
 objects such as window.screen and window.navigator to extract information
-about the useragent. 
+about the user agent. 
 
 Also, Javascript can be used to query the user's timezone via the
 <function>Date()</function> object, <ulink
@@ -931,7 +931,7 @@ activity in the source tree that did not use the browser proxy settings.
 
 We have verified that these settings and patches properly proxy HTTPS, OCSP,
 HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all JavaScript
-activity, including HTML5 audio and video objects, addon updates, wifi
+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
 connections are not attempted, through the proxy or otherwise (Tor does not
@@ -1126,10 +1126,10 @@ referred to as "double-keying".
 
 The benefit of this approach comes not only in the form of reduced
 linkability, but also in terms of simplified privacy UI. If all stored browser
-state and permissions become associated with the url bar origin, the six or
+state and permissions become associated with the URL bar origin, the six or
 seven different pieces of privacy UI governing these identifiers and
 permissions can become just one piece of UI. For instance, a window that lists
-the url bar origin for which browser state exists, possibly with a
+the URL bar origin for which browser state exists, possibly with a
 context-menu option to drill down into specific types of state or permissions.
 An example of this simplification can be seen in Figure 1.
 
@@ -1144,7 +1144,7 @@ An example of this simplification can be seen in Figure 1.
 
 This example UI is a mock-up of how isolating identifiers to the URL bar
 origin can simplify the privacy UI for all data - not just cookies. Once
-browser identifiers and site permissions operate on a url bar basis, the same
+browser identifiers and site permissions operate on a URL bar basis, the same
 privacy window can represent browsing history, DOM Storage, HTTP Auth, search
 form history, login values, and so on within a context menu for each site.
 
@@ -1167,11 +1167,11 @@ date:
     <listitem><command>Cookies</command>
      <para><command>Design Goal:</command>
 
-All cookies MUST be double-keyed to the url bar origin and third-party
+All cookies MUST be double-keyed to the URL bar origin and third-party
 origin. There exists a <ulink
 url="https://bugzilla.mozilla.org/show_bug.cgi?id=565965";>Mozilla bug</ulink>
 that contains a prototype patch, but it lacks UI, and does not apply to modern
-Firefoxes.
+Firefox versions.
 
      </para>
      <para><command>Implementation Status:</command>
@@ -1203,7 +1203,7 @@ property prepended, which will list the FQDN that was used to source it.
 Additionally, because the image cache is a separate entity from the content
 cache, we had to patch Firefox to also <ulink
 url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=d8b98a75fb200268c40886d876adc19e00b933bf";>isolate
-this cache per url bar domain</ulink>.
+this cache per URL bar domain</ulink>.
 
      </para>
     </listitem>
@@ -1222,7 +1222,7 @@ to nsHTTPChannel</ulink>.
     <listitem><command>DOM Storage</command>
      <para>
 
-DOM storage for third party domains MUST be isolated to the url bar origin,
+DOM storage for third party domains MUST be isolated to the URL bar origin,
 to prevent linkability between sites. This functionality is provided through a
 <ulink
 url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=97490c4a90ca1c43374486d9ec0c5593d5fe5720";>patch
@@ -1252,7 +1252,7 @@ file on Windows, so Flash remains difficult to enable.
     <listitem><command>SSL+TLS session resumption</command>
      <para><command>Design Goal:</command>
 
-TLS session resumption tickets and SSL Session IDs MUST be limited to the url
+TLS session resumption tickets and SSL Session IDs MUST be limited to the URL
 bar origin.
 
      </para>
@@ -1355,8 +1355,8 @@ To prevent attacks aimed at subverting the Cross-Origin Identifier
 Unlinkability <link linkend="privacy">privacy requirement</link>, the browser
 MUST NOT store any identifiers (cookies, cache, DOM storage, HTTP auth, etc)
 for cross-origin redirect intermediaries that do not prompt for user input.
-For example, if a user clicks on a bit.ly url that redirects to a
-doubleclick.net url that finally redirects to a cnn.com url, only cookies from
+For example, if a user clicks on a bit.ly URL that redirects to a
+doubleclick.net URL that finally redirects to a cnn.com URL, only cookies from
 cnn.com should be retained after the redirect chain completes.
 
     </para>
@@ -1393,7 +1393,7 @@ that utilize this property to function, we reset the window.name property of
 tabs in Torbutton every time we encounter a blank Referer. This behavior
 allows window.name to persist for the duration of a click-driven navigation
 session, but as soon as the user enters a new URL or navigates between
-https/http schemes, the property is cleared.
+HTTPS/HTTP schemes, the property is cleared.
 
      </para>
     </listitem>
@@ -1425,7 +1425,7 @@ cookies based on stored HSTS state.
 
 There appears to be three options for us: 1. Disable HSTS entirely, and rely
 instead on HTTPS-Everywhere to crawl and ship rules for HSTS sites. 2.
-Restrict the number of HSTS-enabled third parties allowed per url bar origin.
+Restrict the number of HSTS-enabled third parties allowed per URL bar origin.
 3. Prevent third parties from storing HSTS rules. We have not yet decided upon
 the best approach.
 
@@ -1607,7 +1607,7 @@ method is instead relying on API behavior.
 
 In cases where simple spoofing is not enough to properly conceal underlying
 device characteristics or operating system details, the underlying
-susbsystem that provides the functionality for a feature or API may need
+subsystem that provides the functionality for a feature or API may need
 to be completely reimplemented. This is most common in cases where
 customizable or version-specific aspects of the user's operating system are
 visible through the browser's featureset or APIs, usually because the browser
@@ -1625,7 +1625,7 @@ Virtualization is needed when simply reimplementing a feature in a different
 way is insufficient to fully conceal the underlying behavior. This is most
 common in instances of device and hardware fingerprinting, but since the
 notion of time can also be virtualized, it also can apply to any instance
-where an accurate measure of wallclock time is required for a fingerprinting
+where an accurate measure of wall clock time is required for a fingerprinting
 vector to attain high accuracy.
 
    </para>
@@ -1635,7 +1635,7 @@ vector to attain high accuracy.
 
 In the event that virtualization is too expensive in terms of performance or
 engineering effort, and the relative expected usage of a feature is rare, site
-permissions can be used to prevent the usage of a feature execpt in cases
+permissions can be used to prevent the usage of a feature except in cases
 where the user actually wishes to use it. Unfortunately, this mechanism
 becomes less effective once a feature becomes widely overused and abused by
 many websites, as warning fatigue quickly sets in for most users.
@@ -1645,7 +1645,7 @@ many websites, as warning fatigue quickly sets in for most users.
   <listitem><command>Feature/Functionality Removal</command>
    <para>
 
-When extremely invasive features serve only a narrow domain or usecase, or
+When extremely invasive features serve only a narrow domain or use case, or
 there are alternate ways of accomplishing the same task, features and/or
 certain aspects of their functionality may be simply removed.
 
@@ -1721,7 +1721,7 @@ sense of security. When a fingerprinting attempt makes naive use of randomized
 information, a fingerprint will appear unstable, but may not actually be
 sufficiently randomized to prevent a dedicated adversary.  Sophisticated
 fingerprinting mechanisms may either ignore randomized information, or
-incorportate knowledge of the distribution and range of randomized values into
+incorporate knowledge of the distribution and range of randomized values into
 the creation of a more stable fingerprint (by either removing the randomness,
 modeling it, or averaging it).
 
@@ -1916,7 +1916,7 @@ We simply disable it via the pref <command>dom.gamepad.enabled</command>.
      <para>
 
 According to the Panopticlick study, fonts provide the most linkability when
-they are provided as an enumerable list in filesystem order, via either the
+they are provided as an enumerable list in file system order, via either the
 Flash or Java plugins. However, it is still possible to use CSS and/or
 Javascript to query for the existence of specific fonts. With a large enough
 pre-built list to query, a large amount of fingerprintable information may
@@ -1936,7 +1936,7 @@ and <ulink url="https://fedorahosted.org/lohit/";>Lohit fonts</ulink>. The Droid
 font set is fairly complete by itself, but Nanum and Lohit have smaller
 versions of many South Asian languages. When combined in a way that chooses the
 smallest font implementations for each locale, these three font sets provide
-poverage for the all languages used on Wikipedia with more than
+coverage for the all languages used on Wikipedia with more than
 10,000 articles, and several others as well, in approximately 3MB of compressed
 overhead. The <ulink url="https://www.google.com/get/noto/";>Noto font
 set</ulink> is another font set that aims for complete coverage, but is
@@ -2461,7 +2461,7 @@ encrypted website activity.
 We want to deploy a mechanism that reduces the accuracy of <ulink
 url="https://en.wikipedia.org/wiki/Feature_selection";>useful features</ulink> available
 for classification. This mechanism would either impact the true and false
-positive accuracy rates, <emphasis>or</emphasis> reduce the number of webpages
+positive accuracy rates, <emphasis>or</emphasis> reduce the number of web pages
 that could be classified at a given accuracy rate.
 
      </para>
@@ -2655,7 +2655,7 @@ address the following additional sources of non-determinism:
 The most prevalent source of non-determinism in the components of Tor Browser
 by far was various ways that archives (such as zip, tar, jar/ja, DMG, and
 Firefox manifest lists) could be reordered. Many file archivers walk the
-filesystem in inode structure order by default, which will result in ordering
+file system in inode structure order by default, which will result in ordering
 differences between two different archive invocations, especially on machines
 of different disk and hardware configurations.
 
@@ -3166,7 +3166,7 @@ non-trivial number of sites that rely on the Referer header to "authenticate"
 image requests and deep-link navigation on their sites. Furthermore, there
 seems to be no real privacy benefit to taking this action by itself in a
 vacuum, because many sites have begun encoding Referer URL information into
-GET parameters when they need it to cross http to https scheme transitions.
+GET parameters when they need it to cross HTTP to HTTPS scheme transitions.
 Google's +1 buttons are the best example of this activity.
 
   </para>

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