Tweak text about targets

Tweak text, mostly minor typo issues and clarifications.

Signed-off-by: David A. Wheeler <[email protected]>

Author: david-a-wheeler

secure_software_development_fundamentals.md

@@ -3487,23 +3487,23 @@ This is true! The problem is not redirection, it is *unvalidated* redirection. O
 
 [Web application]
 
-There is a peculiar problem with some special uses of the HTML **target** attribute and JavaScript `window.open()` that web developers are not aware of. Let’s explain the problem, and some partial solutions.
+There is a peculiar problem with some special uses of the HTML **target** attribute and JavaScript `window.open()` that many web developers are not aware of. Let’s explain the problem and some solutions.
 
-In HTML, **<a href=...>** creates a hyperlink. The HTML construct **<a href=... target=...>** creates a hyperlink where, if you click on it, it creates a new named “target”. Using **target="_blank”** creates the target in a new tab. Historically setting **target="_blank”** could be a vulnerability, but the [HTML specification has been modified so **_blank** is no longer a problem](https://html.spec.whatwg.org/#following-hyperlinks) and modern browsers implement this fix.
+In HTML, **<a href=...>** creates a hyperlink. The HTML construct **<a href=... target=...>** creates a hyperlink where, if you click on it, it creates a new named “target”. Using **target="_blank”** creates the target in a new tab. Historically setting **target="_blank”** could be a vulnerability, but the [HTML specification has been modified so **_blank** is no longer a problem](https://html.spec.whatwg.org/#following-hyperlinks) and modern browsers implement this fix.
 
 However, there's a special case you still need to worry about. If you do *all* of these things at the same time you may have a security problem:
 
-1. The new page being loaded is from some (other) system you don't totally trust.
-2. Use HTML tag "a" with a named target or use JavaScript **window.open()** with named target,
-3. The named target is something *other* than **_self** (the default for HTML's a tag), **_blank** (the default for JavaScript's **window.open()**), **_parent**, or **_top**, *and*
+1. The new page being loaded is from some (other) system that you don't totally trust.
+2. Use HTML tag "a" with a named target or use JavaScript **window.open()** with a named target, *and*
+3. The named target is something *other* than the safe values **_self** (the default for HTML's a tag), **_blank** (the default for JavaScript's **window.open()**), **_parent**, or **_top**.
 
 Where possible, when loading pages from other sites, don't use named targets (other than the safe ones listed above). If you really must use this unusual circumstance, fix this in HTML by adding **rel="noopener"** to the "a" tag.
 
-Explaining why this odd combination is a security problem is complicated. The underlying problem is that web browsers need to support legacy systems. Fundamentally, when there is a named target, the browser will re-use an existing window by that name, or create one if there aren't any. The browser will then provide that window with an "opener" value set to its requestor. This was a common pattern for older websites to implement pop-ups. This approach is fine if the named window was trusted and cooperative. However, this provides a mechanism for the newer page to manipulate the web page of its caller. This enables, for example, "tabnapping", where the new site tricks the user by controlling another tab. If no countermeasure is taken, The receiving page can do things like force the *calling* page to navigate to a different page (e.g., **window.opener.location.href = newURL**), provide a new page that looks like the old one (even though it is in a different place), and fool the user into doing something on the “same” page that is not the same at all.
+Explaining why this odd combination is a security problem is complicated. The underlying problem is that web browsers need to support legacy systems. Fundamentally, when there is a named target, the browser will re-use an existing window by that name, or create one if there aren't any. The browser will then provide that window with an "opener" value set to its requestor. This was a common pattern for older websites to implement pop-ups. This approach is fine if the named window is trusted by the requestor. However, this provides a mechanism for the newer page to manipulate the web page of its caller. This enables, for example, "tabnapping", where the new site tricks the user by controlling another tab. If no countermeasure is taken, The receiving page can do things like force the *calling* page to navigate to a different page (e.g., **window.opener.location.href = newURL**), provide a new page that looks like the old one (even though it is in a different place), and fool the user into doing something on the “same” page that is not the same at all.
 
-This used to be a more common problem, because at one time this also impacted **_blank**. Today browsers automatically add **rel="noopener"** when **_blank** is the target. The other named targets listed above are from the same origin, so again the problem can't happen. But developers must handle these other less-common cases themselves.
+This used to be a more common problem, because at one time this also impacted **_blank**. Today browsers automatically add **rel="noopener"** when **_blank** is the target. The other "safe" named targets (listed above) are from the same origin, so again the problem can't happen. But if you use one of these less-common cases, you must handle it yourself.
 
-You may see some documents recommending the use of **rel="noreferrer"**, though there's no known problem today if you don't change the browser's referrer default. Modern browsers by default now have a setting of "strict-origin-when-cross-origin"; that means that when a different origin is loaded, the new origin sees the domain but *not* the path or other details about the page the user was viewing before. As long as you're happy with that default, or set an even stricter one, you're fine. However, if you set a looser value (and be careful before doing that), **rel="noreferrer"** will prevent that detailed information from getting to the other site. You can combine **noopener** and **noreferrer* as **rel="noopener noreferrer"**.
+You may see some older documents recommending the use of **rel="noreferrer"**. You don't need to do that any more as long as you don't change the browser's default referrer value. Modern browsers by default now have a setting of "strict-origin-when-cross-origin"; that means that when a different origin is loaded, the new origin sees the domain but *not* the path or other details about the page the user was viewing before. As long as you're happy with that default, or set an even stricter one, you're fine. However, if you set a looser value (and be careful before doing that), **rel="noreferrer"** will prevent that detailed information from getting to the other site in that specific case. You can combine **noopener** and **noreferrer* as **rel="noopener noreferrer"**. You should, in general, try to use secure defaults instead of trying to separately set a secure value on each use.
 
 A historical discussion of these problems, before the defaults were changed, can be found in ([*Security Vulnerability and Browser Performance Impact of Target=”_blank”*](https://medium.com/@darrensimio/security-vulnerability-and-browser-performance-impact-of-target-blank-80e5e67db547) by Darren Sim, 2019).