8ae57fb027f43538412376ac1c4435b247d95f75
max
  Thu Aug 8 07:20:50 2024 -0700
typos, refs #34166

diff --git src/product/mirrorManual.txt src/product/mirrorManual.txt
index a11e0dc..452a1ee 100644
--- src/product/mirrorManual.txt
+++ src/product/mirrorManual.txt
@@ -1362,46 +1362,47 @@
 
 The Genome Browser is a complicated piece of software of more than 2 million
 lines of code that have been developed over 20 years. When running security
 scanners on it, false positives are likely. At UCSC, we run a security scan
 on the Genome Browser ourselves once a month and it is easy to see why the scanners 
 find problems in the Genome Browser that are not actual problems:
 
 * The Genome Browser draws remote genome annotation files that are streamed on
   the fly through https.
   This means that parts of these files appear in our user interface. Various
   features of custom tracks and track hubs specifically reference external html
   file via URLs that the user can define and we place no restrictions on these URLs
   for various reasons. These features
   predate the introduction of CORS to the internet protocols by at least five
   years, and the servers from where these files are loaded by the Genome Browser
-  do not need to specifcally allow the requests. As a result, this is not a security
-  exploit but an intentional feature, similar to a webservice that check files entered via a
+  do not need to specifically allow the requests. As a result, this is not a security
+  exploit but an intentional feature, similar to a webservice that checks files entered via a
   URL (e.g. a robots.txt analyzer) that then show the content of the URLs on their web pages. 
   Security scanners will find these features and flag them as SSRF exploits 
   (Server-side request forgery), but they are a result of our features and not
   a problem of our software and not a problem in the context of our public web servers.
 * Conversely, when running a local Genome Browser at your institution, do not assume that the
   Genome Browser web server can be granted access to internal files that should not be shared
   with the outside world. The Genome Browser is not a secure gateway, 
   and anything that the Genome Browser can access may be displayable by any 
   Genome Browser user. For example, if you restrict internal files to access from only the
   Genome Browser IP address, as with most other servers without dedicated security layers,
   assume that these can be accessed by anyone who is using the browser.
-* On both our webservers at UCSC and your own internal mirror, even though the
-  data from external URLs is shown, and even HTML tags are interpreted, Javascript in them is not executed. 
-  We use CSP and a nounce to this end. CSP/nounce is a system that many
+* On our webservers at UCSC and your own internal mirror, even though the
+  data from external URLs is shown, and even though the HTML tags are interpreted, Javascript in these pages is not executed,
+  so an XSS exploit is not possible through these. 
+  We use CSP and a nounce to block Javascript in these pages. CSP/nounce is a system that many
   security scanners do not recognize. You can disregard XSS warnings from the
   security scanners, and refer your IT department to our CSP declarations in
   the HTML headers, unless you can think that you found a case where it is possible to get
   through the CSP/nounce system. Feel free to send us the security report from
   your scanner when in doubt.
 * Our CSP/nounce system also secures the Javascript libraries. We use customized jquery libraries 
   from the mid-2000s, some of them are outdated, so some security scanners deem
   these as unsafe. But CSP and the nounce means that possible XSS problems cannot be exploited. The 
   security scanners also cannot detect that. To reduce these warnings, are are in the process of upgrading our 
   Javascript dependencies, where possible.
 
 # Proxy support
 
 net.c now has support for http(s) proxy servers
 which may be required by some installations