Index: openacs-4/packages/acs-core-docs/www/security-design.html
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/security-design.html,v
diff -u -r1.37.2.1 -r1.37.2.2
--- openacs-4/packages/acs-core-docs/www/security-design.html	2 Mar 2019 19:30:06 -0000	1.37.2.1
+++ openacs-4/packages/acs-core-docs/www/security-design.html	3 Sep 2021 09:15:27 -0000	1.37.2.2
@@ -34,7 +34,7 @@
 automatically issued to users who authenticate themselves over insecure
 connections. This means that users will need to reauthenticate themselves
 over SSL when performing some action that requires secure authentication.</p><p>Although this makes the site less user friendly, this design significantly
-increases the security of the system because this insures that the
+increases the security of the system because this ensures that the
 authentication tokens presented to a secure section of the web site were not
 sniffed. The system is not entirely secure, since the actual authentication
 password can be sniffed from the system, after which the sniffer can apply
@@ -101,7 +101,7 @@
 <code class="computeroutput">sec_setup_session</code>, which is called either to
 create a new session from <code class="computeroutput">sec_handler</code> or from
 <code class="computeroutput">ad_user_login</code> when there is a change in
-authorization level. The session management code must do two things: insure that
+authorization level. The session management code must do two things: ensure that
 session-level data does not float between users, and update the users table
 which has columns for <code class="computeroutput">n_sessions</code>,
 <code class="computeroutput">last_visit</code>, and
@@ -112,8 +112,8 @@
 is continued, simply with a higher authorization state. This allows for data
 associated with a session to be carried over when a user logs in.</p><p>The users table is updated by
 <code class="computeroutput">sec_update_user_session_info</code> which is called
-when an existing session is assigned a non-zero user_id, or when a session is
-created with a non-zero user_id.</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a name="passwords"></a>Passwords</h4></div></div></div><p><code class="computeroutput">ad_user_login</code> assumes a password check has already been
+when an existing session is assigned a nonzero user_id, or when a session is
+created with a nonzero user_id.</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a name="passwords"></a>Passwords</h4></div></div></div><p><code class="computeroutput">ad_user_login</code> assumes a password check has already been
 performed (this will change in the future). The actual check is done by
 <code class="computeroutput">ad_check_password</code>. The database stores a salt and a hash of the
 password concatenated with the salt. Updating the password
@@ -141,7 +141,7 @@
 these values are used to dynamically generate a procedure that returns a
 constant. This approach avoids (relatively) expensive calls to
 <code class="computeroutput">ad_parameter</code> in <code class="computeroutput">sec_handler</code>. The impact of this
-approach is that these parameters cannot be dynamically changed at runtime
+approach is that these parameters cannot be dynamically changed at run time
 and require a server restart.</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a name="session-properties"></a>Session Properties</h4></div></div></div><p>
 Session properties are stored in a single table that maps session IDs to
 named session properties and values. This table is periodically purged. For
@@ -295,7 +295,7 @@
 life, properties have a maximum life. It would be nice to expand the
 interface to allow for more persistent properties. In the past, there was a
 sec_browser_properties table that held permanent properties about each unique
-visitor (for logged in users, these are just user properties). This was
+visitor (for logged-in users, these are just user properties). This was
 unscalable because there was no way to delete these properties, and the table
 tended to grow to millions of rows. It would be nice to view browser and
 session properties as two types of client properties, but with different
@@ -313,7 +313,7 @@
 it into the database at all is probably too big a hammer. Certainly putting
 it into the database on every hit is too big a hammer. 
 </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a name="cookieless-sessions"></a>Cookieless Sessions</h4></div></div></div><p>Two trends drive the requirement for removing cookie dependence. WAP
-browsers that do not have cookies, and publc perceptions of cookies as an
+browsers that do not have cookies, and public perceptions of cookies as an
 invasion of privacy. The rely on the cookies mechanism in HTTP to distinguish
 one request from the next, and we trust it to force requests from the same
 client to carry the same cookie headers. The same thing can be accomplished by