[pull] main from mdn:main

files/en-us/glossary/hpkp/index.md

@@ -5,7 +5,7 @@ page-type: glossary-definition
 sidebar: glossarysidebar
 ---
 
-**HTTP Public Key Pinning** (**HPKP**) is an obsolete security feature that tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of {{Glossary("MITM")}} attacks with forged certificates.
+**HTTP Public Key Pinning** (**HPKP**) is an obsolete security feature that tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attacks with forged certificates.
 
 ## See also
 

files/en-us/glossary/mitm/index.md

@@ -5,7 +5,7 @@ page-type: glossary-definition
 sidebar: glossarysidebar
 ---
 
-A **manipulator-in-the-middle attack** (MitM) intercepts a communication between two systems. For example, a Wi-Fi router can be compromised.
+A **manipulator in the middle attack** (MitM) intercepts a communication between two systems. For example, a Wi-Fi router can be compromised.
 
 Comparing this to physical mail: If you're writing letters to each other, the mail carrier can intercept each letter you mail. They open it, read it, eventually modify it, and then repackage the letter and only then send it to whom you intended to sent the letter for. The original recipient would then mail you a letter back, and the mail carrier would again open the letter, read it, eventually modify it, repackage it, and give it to you. You wouldn't know there's a manipulator in the middle in your communication channel – the mail carrier is invisible to you and to your recipient.
 
@@ -17,5 +17,7 @@ In physical mail and in online communication, MITM attacks are tough to defend.
 
 ## See also
 
-- OWASP: [Manipulator-in-the-middle attack](https://owasp.org/www-community/attacks/Manipulator-in-the-middle_attack)
+- [Manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM)
+- [Attacks](/en-US/docs/Web/Security/Attacks)
+- OWASP: [Manipulator in the middle attack](https://owasp.org/www-community/attacks/Manipulator-in-the-middle_attack)
 - Wikipedia: [Man-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)

files/en-us/glossary/placeholder_names/index.md

@@ -5,10 +5,16 @@ page-type: glossary-definition
 sidebar: glossarysidebar
 ---
 
-Placeholder names are commonly used in cryptography to indicate the participants in a conversation, without resorting to terminology such as "Party A," "eavesdropper," and "malicious attacker."
+**Placeholder names** are commonly used in cryptography to indicate the participants in a conversation, without resorting to terminology such as "Party A," "eavesdropper," and "malicious attacker."
 
 The most commonly used names are:
 
 - _Alice_ and _Bob_, two parties who want to send messages to each other, occasionally joined by _Carol_, a third participant
 - _Eve_, a passive attacker who is eavesdropping on Alice and Bob's conversation
-- _Mallory_, an active attacker ("man-in-the-middle") who is able to modify their conversation and replay old messages
+- _Mallory_, an active attacker ("[manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM)") who is able to modify their conversation and replay old messages
+
+## See also
+
+- [Manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM)
+- [Attacks](/en-US/docs/Web/Security/Attacks)
+- [Security](/en-US/docs/Web/Security)

files/en-us/glossary/session_hijacking/index.md

@@ -22,7 +22,7 @@ Most authentication occurs only at the start of a {{glossary("TCP")}} session. I
 
 ## Session hijacking process
 
-1. **Sniff**, that is perform a man-in-the-middle (MITM) attack, place yourself between victim and server.
+1. **Sniff**, that is perform a [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attack, place yourself between victim and server.
 2. **Monitor** packets flowing between server and user.
 3. **Break** the victim machine's connection.
 4. **Take control** of the session.

files/en-us/web/api/service_worker_api/index.md

@@ -20,7 +20,7 @@ Service workers run in a worker context: they therefore have no DOM access and r
 
 Service workers can't import JavaScript modules dynamically, and [`import()`](/en-US/docs/Web/JavaScript/Reference/Operators/import) will throw an error if it is called in a service worker global scope. Static imports using the [`import`](/en-US/docs/Web/JavaScript/Reference/Statements/import) statement are allowed.
 
-Service workers are only available in [secure contexts](/en-US/docs/Web/Security/Defenses/Secure_Contexts): this means that their document is served over HTTPS, although browsers also treat `http://localhost` as a secure context, to facilitate local development. HTTP connections are susceptible to malicious code injection by {{Glossary("MitM", "man in the middle")}} attacks, and such attacks could be worse if allowed access to these powerful APIs.
+Service workers are only available in [secure contexts](/en-US/docs/Web/Security/Defenses/Secure_Contexts): this means that their document is served over HTTPS, although browsers also treat `http://localhost` as a secure context, to facilitate local development. HTTP connections are susceptible to malicious code injection by [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attacks, and such attacks could be worse if allowed access to these powerful APIs.
 
 > [!NOTE]
 > On Firefox, for testing you can run service workers over HTTP (insecurely); simply check the **Enable Service Workers over HTTP (when toolbox is open)** option in the Firefox DevTools options/gear menu.

files/en-us/web/api/web_authentication_api/authenticator_data/index.md

@@ -20,7 +20,7 @@ Authenticator data is made available to the browser as an {{jsxref("ArrayBuffer"
 An authenticator data {{jsxref("ArrayBuffer")}} is at least 37 bytes in length, and contains the following fields:
 
 - **rpIdHash** (32 bytes)
-  - : The SHA-256 hash of the [Relying Party ID](https://w3c.github.io/webauthn/#relying-party-identifier) that the credential is scoped to. The server will ensure that this hash matches the SHA256 hash of its own relying party ID in order to prevent phishing or other man-in-the-middle attacks.
+  - : The SHA-256 hash of the [Relying Party ID](https://w3c.github.io/webauthn/#relying-party-identifier) that the credential is scoped to. The server will ensure that this hash matches the SHA256 hash of its own relying party ID in order to prevent phishing or other [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attacks.
 - **flags** (1 bytes)
   - : A bitfield that indicates various attributes that were asserted by the authenticator. The bits are as follows, where Bit 0 is the least significant bit and all bits not specifically mentioned below are "reserved for future use":
     - Bit 0, User Presence (UP): If set (i.e., to `1`), the authenticator validated that the user was present through some Test of User Presence (TUP), such as touching a button on the authenticator.

files/en-us/web/api/web_crypto_api/non-cryptographic_uses_of_subtle_crypto/index.md

@@ -10,7 +10,7 @@ This article will focus on uses of the [`digest`](/en-US/docs/Web/API/SubtleCryp
 
 This article does not discuss the cryptographic uses of the [SubtleCrypto interface](/en-US/docs/Web/API/SubtleCrypto). An important thing to take away from this article is **don't use this API** for production cryptographic purposes because it is powerful and low level. To use it correctly you will need to take many context specific steps to accomplish cryptographic tasks correctly. If any of those steps are taken incorrectly at best your code won't run, at worse it _will_ run and you will unknowingly be putting your users at risk with an insecure product.
 
-You may not even need to use the [Web Crypto API](/en-US/docs/Web/API/Web_Crypto_API) at all. Many of the things you would want to use cryptography for are already solved and part of the Web platform. For example, if you are worried about man-in-the-middle attacks, such as Wi-Fi hotspots reading the information between the client and the server, this is solved by ensuring correct use of [HTTPS](/en-US/docs/Glossary/HTTPS). Do you want to securely send information between users? Then you can set up a data connection between users using [WebRTC Data Channels](/en-US/docs/Web/API/WebRTC_API/Using_data_channels) which is encrypted as part of the standard.
+You may not even need to use the [Web Crypto API](/en-US/docs/Web/API/Web_Crypto_API) at all. Many of the things you would want to use cryptography for are already solved and part of the Web platform. For example, if you are worried about [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attacks, such as Wi-Fi hotspots reading the information between the client and the server, this is solved by ensuring correct use of [HTTPS](/en-US/docs/Glossary/HTTPS). Do you want to securely send information between users? Then you can set up a data connection between users using [WebRTC Data Channels](/en-US/docs/Web/API/WebRTC_API/Using_data_channels) which is encrypted as part of the standard.
 
 The [SubtleCrypto interface](/en-US/docs/Web/API/SubtleCrypto) provides low level primitives for working with cryptography, but implementing a system using these tools is a complicated task. Mistakes are hard to notice and the results can mean your user's data is not as secure as you think it is. Which could have catastrophic results if your users are sharing sensitive or valuable data.
 

files/en-us/web/html/reference/elements/input/hidden/index.md

@@ -7,14 +7,14 @@ browser-compat: html.elements.input.type_hidden
 sidebar: htmlsidebar
 ---
 
-{{HTMLElement("input")}} elements of type **`hidden`** let web developers include data that cannot be seen or modified by users when a form is submitted. For example, the ID of the content that is currently being ordered or edited, or a unique security token. Hidden inputs are completely invisible in the rendered page, and there is no way to make it visible in the page's content.
+{{HTMLElement("input")}} elements of type **`hidden`** allow web developers to include data in a form that is not visually accessible to users when a form is submitted. For example, the ID of the content that is currently being ordered or edited, or a unique security token. Hidden inputs are completely invisible in the rendered page, but are still submitted as any other form input. While the data is not presented to users in the rendered content, it is still accessible in the HTML output and is editable to users using tools such as their [browser's developer tools](/en-US/docs/Learn_web_development/Howto/Tools_and_setup/What_are_browser_developer_tools).
 
 > [!NOTE]
 > The {{domxref("Element/input_event", "input")}} and {{domxref("HTMLElement/change_event", "change")}} events do not apply to this input type. Hidden inputs cannot be focused even using JavaScript (e.g., `hiddenInput.focus()`).
 
 ## Value
 
-The {{HTMLElement("input")}} element's [`value`](/en-US/docs/Web/HTML/Reference/Elements/input#value) attribute holds a string that contains the hidden data you want to include when the form is submitted to the server. This specifically can't be edited or seen by the user via the user interface, although you could edit the value via browser developer tools.
+The {{HTMLElement("input")}} element's [`value`](/en-US/docs/Web/HTML/Reference/Elements/input#value) attribute holds a string that contains the hidden data you want to include when the form is submitted to the server. This value is not presented to the user via the user interface.
 
 > [!WARNING]
 > While the value isn't displayed to the user in the page's content, it is visible—and can be edited—using any browser's developer tools or "View Source" functionality. Do not rely on `hidden` inputs as a form of security.
@@ -29,7 +29,7 @@ This is actually one of the common attributes, but it has a special meaning avai
 
 ## Using hidden inputs
 
-As mentioned above, hidden inputs can be used anywhere that you want to include data the user can't see or edit along with the form when it's submitted to the server. Let's look at some examples that illustrate its use.
+As mentioned above, hidden inputs can be used anywhere that you want to include data the user can't see along with the form when it's submitted to the server. Let's look at some examples that illustrate its use.
 
 ### Tracking edited content
 
@@ -45,12 +45,10 @@ You can see a full example of what this might look like in the [Examples](#examp
 
 ### Improving website security
 
-Hidden inputs are also used to store and submit security tokens or _secrets_, for the purposes of improving website security. The basic idea is that if a user is filling in a sensitive form, such as a form on their banking website to transfer some money to another account, the secret they would be provided with would prove that they are who they say they are, and that they are using the correct form to submit the transfer request.
-
-This would stop a malicious user from creating a fake form, pretending to be a bank, and emailing the form to unsuspecting users to trick them into transferring money to the wrong place. This kind of attack is called a [Cross Site Request Forgery (CSRF)](/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Website_security#cross-site_request_forgery_csrf); pretty much any reputable server-side framework uses hidden secrets to prevent such attacks.
+One common use of hidden input fields is to store Cross-Site Request Forgery (CSRF) tokens, which help protect websites against [CSRF attacks](/en-US/docs/Web/Security/Attacks/CSRF).
 
 > [!NOTE]
-> Placing the secret in a hidden input doesn't inherently make it secure. The key's composition and encoding would do that. The value of the hidden input is that it keeps the secret associated with the data and automatically includes it when the form is sent to the server. You need to use well-designed secrets to actually secure your website.
+> Data placed in a hidden input is not inherently secured. Its value is still observable by the end user. You need to use well-designed secrets to actually secure your website.
 
 ## Validation
 

files/en-us/web/http/guides/cookies/index.md

@@ -156,7 +156,7 @@ You can ensure that cookies are sent securely and aren't accessed by unintended
 Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly
 ```
 
-- A cookie with the `Secure` attribute is only sent to the server with an encrypted request over the HTTPS protocol. It's never sent with unsecured HTTP (except on localhost), which means {{Glossary("MitM", "man-in-the-middle")}} attackers can't access it easily. Insecure sites (with `http:` in the URL) can't set cookies with the `Secure` attribute. However, don't assume that `Secure` prevents all access to sensitive information in cookies. For example, someone with access to the client's hard disk (or JavaScript if the `HttpOnly` attribute isn't set) can read and modify the information.
+- A cookie with the `Secure` attribute is only sent to the server with an encrypted request over the HTTPS protocol. It's never sent with unsecured HTTP (except on localhost), which means [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attackers can't access it easily. Insecure sites (with `http:` in the URL) can't set cookies with the `Secure` attribute. However, don't assume that `Secure` prevents all access to sensitive information in cookies. For example, someone with access to the client's hard disk (or JavaScript if the `HttpOnly` attribute isn't set) can read and modify the information.
 
 - A cookie with the `HttpOnly` attribute can't be accessed by JavaScript, for example using {{domxref("Document.cookie")}}; it can only be accessed when it reaches the server. Cookies that persist user sessions for example should have the `HttpOnly` attribute set — it would be really insecure to make them available to JavaScript. This precaution helps mitigate cross-site scripting ([XSS](/en-US/docs/Web/Security/Attacks/XSS)) attacks.
 

files/en-us/web/http/reference/headers/set-cookie/index.md

@@ -149,7 +149,7 @@ Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnl
         The `Secure` attribute must also be set when using this value.
 
 - `Secure` {{optional_inline}}
-  - : Indicates that the cookie is sent to the server only when a request is made with the `https:` scheme (except on localhost), and therefore, is more resistant to [man-in-the-middle](/en-US/docs/Glossary/MitM) attacks.
+  - : Indicates that the cookie is sent to the server only when a request is made with the `https:` scheme (except on localhost), and therefore, is more resistant to [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) attacks.
 
     > [!NOTE]
     > Do not assume that `Secure` prevents all access to sensitive information in cookies (session keys, login details, etc.).

files/en-us/web/http/reference/headers/strict-transport-security/index.md

@@ -61,7 +61,7 @@ the intention of strict security.
 
 > [!NOTE]
 > The host must send the `Strict-Transport-Security` header over HTTPS only, not insecure HTTP.
-> Browsers ignore the header if sent over HTTP to prevent a [manipulator-in-the-middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM)
+> Browsers ignore the header if sent over HTTP to prevent a [manipulator in the middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM)
 > from altering the header to expire prematurely or adding it for a host that doesn't support HTTPS.
 
 ### Expiration

files/en-us/web/http/reference/resources_and_specifications/index.md

@@ -53,6 +53,7 @@ HTTP was first specified in the early 1990s. Designed with extensibility in mind
 | [Draft spec](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-expect-ct-01)                                                                | Expect-CT Extension for HTTP                                                                                                                                                                                                                          | IETF Draft               |
 | {{rfc(7486)}}                                                                                                                                      | HTTP Origin-Bound Auth (HOBA)                                                                                                                                                                                                                         | Experimental             |
 | {{rfc(7240)}}                                                                                                                                      | Prefer Header for HTTP                                                                                                                                                                                                                                | Proposed Standard        |
+| {{rfc(3229)}}                                                                                                                                      | Delta encoding in HTTP                                                                                                                                                                                                                                | Proposed Standard        |
 
 ## See also
 

files/en-us/web/javascript/reference/global_objects/promise/index.md

@@ -21,7 +21,7 @@ A `Promise` is in one of these states:
 - _rejected_: meaning that the operation failed.
 
 The _eventual state_ of a pending promise can either be _fulfilled_ with a value or _rejected_ with a reason (error).
-When either of these options occur, the associated handlers queued up by a promise's `then` method are called. If the promise has already been fulfilled or rejected when a corresponding handler is attached, the handler will be called, so there is no race condition between an asynchronous operation completing and its handlers being attached.
+When either of these options occurs, the associated handlers queued up by a promise's `then` method are called. If the promise has already been fulfilled or rejected when a corresponding handler is attached, the handler will be called, so there is no race condition between an asynchronous operation completing and its handlers being attached.
 
 A promise is said to be _settled_ if it is either fulfilled or rejected, but not pending.