Merge branch 'main' into clipboard-supports

files/en-us/_wikihistory.json

@@ -11728,7 +11728,7 @@
       "nasifmdtanjim"
     ]
   },
-  "MDN/Writing_guidelines/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file": {
+  "MDN/Writing_guidelines/Howto/Write_an_api_reference/Information_contained_in_a_WebIDL_file": {
     "modified": "2019-10-01T06:57:46.015Z",
     "contributors": [
       "chrisdavidmills",
@@ -11744,7 +11744,7 @@
       "jryans"
     ]
   },
-  "MDN/Writing_guidelines/Howto/Write_an_API_reference/Sidebars": {
+  "MDN/Writing_guidelines/Howto/Write_an_api_reference/Sidebars": {
     "modified": "2020-09-30T09:04:08.085Z",
     "contributors": [
       "chrisdavidmills",
@@ -30245,7 +30245,7 @@
       "JesseW"
     ]
   },
-  "Web/API/Document_object_model/How_to_create_a_DOM_tree": {
+  "Web/API/Document_Object_Model/How_to_create_a_DOM_tree": {
     "modified": "2019-03-24T00:17:33.140Z",
     "contributors": [
       "SphinxKnight",
@@ -30264,7 +30264,7 @@
       "ericjung"
     ]
   },
-  "Web/API/Document_object_model/Locating_DOM_elements_using_selectors": {
+  "Web/API/Document_Object_Model/Locating_DOM_elements_using_selectors": {
     "modified": "2020-12-06T22:57:45.352Z",
     "contributors": [
       "jordan-git",
@@ -30282,7 +30282,7 @@
       "asadotzler"
     ]
   },
-  "Web/API/Document_object_model/Using_the_Document_Object_Model": {
+  "Web/API/Document_Object_Model/Using_the_Document_Object_Model": {
     "modified": "2020-12-09T01:05:18.504Z",
     "contributors": [
       "skkiennhtg2327",
@@ -30308,7 +30308,7 @@
       "Gor1"
     ]
   },
-  "Web/API/Document_object_model/Using_the_Document_Object_Model/Example": {
+  "Web/API/Document_Object_Model/Using_the_Document_Object_Model/Example": {
     "modified": "2019-03-23T23:40:45.010Z",
     "contributors": [
       "mk7087",
@@ -64969,7 +64969,7 @@
     "modified": "2019-06-17T09:14:48.783Z",
     "contributors": ["Sheppy", "beaulac", "now-raymond", "chrisdavidmills"]
   },
-  "Web/API/WebRTC_API/build_a_phone_with_peerjs/connect_peers/End_a_call": {
+  "Web/API/WebRTC_API/Build_a_phone_with_peerjs/Connect_peers/End_a_call": {
     "modified": "2020-12-10T13:59:26.911Z",
     "contributors": ["lolaodelola"]
   },
@@ -71762,7 +71762,7 @@
       "JesseW"
     ]
   },
-  "Web/API/window/getDefaultComputedStyle": {
+  "Web/API/Window/getDefaultComputedStyle": {
     "modified": "2020-10-15T21:20:40.098Z",
     "contributors": [
       "mfluehr",
@@ -71779,7 +71779,7 @@
       "Bzbarsky"
     ]
   },
-  "Web/API/window/requestAnimationFrame": {
+  "Web/API/Window/requestAnimationFrame": {
     "modified": "2020-11-28T11:54:08.634Z",
     "contributors": [
       "bulk88",

files/en-us/games/techniques/3d_on_the_web/building_up_a_basic_demo_with_three.js/index.md

@@ -113,7 +113,7 @@ You should experiment with these values and see how they change what you see in
 
 ## Rendering the scene
 
-Everything is ready, but we still can't see anything. Although we've set up the renderer, we still need to render everything. Our `render()` function will do this job, with a little help from [`requestAnimationFrame()`](/en-US/docs/Web/API/window/requestAnimationFrame), which causes the scene to be re-rendered constantly on every frame:
+Everything is ready, but we still can't see anything. Although we've set up the renderer, we still need to render everything. Our `render()` function will do this job, with a little help from [`requestAnimationFrame()`](/en-US/docs/Web/API/Window/requestAnimationFrame), which causes the scene to be re-rendered constantly on every frame:
 
 ```js
 function render() {

files/en-us/games/techniques/control_mechanisms/desktop_with_mouse_and_keyboard/index.md

@@ -71,7 +71,7 @@ function draw() {
 }
 ```
 
-The `draw` function first clears the whole Canvas — we draw everything from scratch on every single frame. Then the pressed key variables are checked and the `playerX` and `playerY` variables (that we define earlier just after `leftPressed` and the others) holding the position of the ship are adjusted by a given amount, let's say 5 pixels. Then the player's ship is drawn on the screen and the next draw is called from within the [requestAnimationFrame](/en-US/docs/Web/API/window/requestAnimationFrame).
+The `draw` function first clears the whole Canvas — we draw everything from scratch on every single frame. Then the pressed key variables are checked and the `playerX` and `playerY` variables (that we define earlier just after `leftPressed` and the others) holding the position of the ship are adjusted by a given amount, let's say 5 pixels. Then the player's ship is drawn on the screen and the next draw is called from within the [requestAnimationFrame](/en-US/docs/Web/API/Window/requestAnimationFrame).
 
 We could write our own `KeyCode` object containing the key codes. For example:
 

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

@@ -8,7 +8,7 @@ page-type: glossary-definition
 
 The **accessibility tree** contains {{Glossary("accessibility")}}-related information for most HTML elements.
 
-Browsers convert markup into an internal representation called the _[DOM tree](/en-US/docs/Web/API/Document_object_model/How_to_create_a_DOM_tree)_. The DOM tree contains objects representing all the markup's elements, attributes, and text nodes. Browsers then create an accessibility tree based on the DOM tree, which is used by platform-specific Accessibility APIs to provide a representation that can be understood by assistive technologies, such as screen readers.
+Browsers convert markup into an internal representation called the _[DOM tree](/en-US/docs/Web/API/Document_Object_Model/How_to_create_a_DOM_tree)_. The DOM tree contains objects representing all the markup's elements, attributes, and text nodes. Browsers then create an accessibility tree based on the DOM tree, which is used by platform-specific Accessibility APIs to provide a representation that can be understood by assistive technologies, such as screen readers.
 
 There are four properties in an accessibility tree object:
 

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

@@ -6,8 +6,16 @@ page-type: glossary-definition
 
 {{GlossarySidebar}}
 
-**BiDi** (BiDirectional) refers to a document containing both right-to-left and left-to-right text. Even when both directionalities occur in the same paragraph, the text in each language must appear in its proper directionality.
+**BiDi** (BiDirectional) describes a document that contains both right-to-left (RTL) and left-to-right (LTR) text.
+
+User Interfaces should display BiDi content correctly, but many fail. An example is the Hebrew translation of the name Sarah: שרה, spelled (from right-to-left) sin (ש), resh (ר), heh (ה). Many programs would display the letters in the opposite order.
+
+It is possible to flip the left-to-right display order to a right-to-left display order, but doing this sacrifices the ability to display BiDi scripts correctly — at least one is always incorrectly displayed. With bidirectional script support, it is possible to mix characters from different scripts on the same page, regardless of writing direction.
+
+The Unicode standard provides foundations for complete BiDi support, with detailed rules as to how mixtures of left-to-right and right-to-left scripts are to be encoded and displayed.
 
 ## See also
 
+- {{glossary("Unicode")}}
 - [Bi-directional text](https://en.wikipedia.org/wiki/Bi-directional_text) on Wikipedia
+- [UAX#9: Unicode Bi-directional Algorithm](https://www.unicode.org/reports/tr9)

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

@@ -0,0 +1,29 @@
+---
+title: Digital signature
+slug: Glossary/Digital_signature
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+A **digital signature** is an object that can be used to {{glossary("authentication", "authenticate")}} the author of a document or message.
+
+Digital signatures are usually based on {{glossary("public-key cryptography")}}, in which a key is created as a pair of keys, with the property that, if some input is encrypted with one key, it can only be decrypted with the other key, and vice versa.
+
+The creator of the key pair makes one of the keys public and keeps the other one private. To sign a document, the key pair's owner creates a {{glossary("hash")}} of the document and encrypts it with the private key.
+
+The document and signature are sent to the verifier, who hashes the document, retrieves the public key, and decrypts the signature: if this matches the hash, then the signature has been verified, and the verifier can be confident that it was created by an entity with access to the private key.
+
+The security of a digital signature system depends (among other things) on:
+
+- The private key's owner keeping it safe: if other entities can access the private key, they can impersonate the owner.
+
+- The public key used by the verifier being the genuine counterpart of the owner's private key: if an attacker could trick the verifier into trusting the wrong public key, they could impersonate the owner.
+
+Verifiers often use {{glossary("digital certificate", "digital certificates")}} to check that public keys are genuine.
+
+## See also
+
+- {{glossary("Digital certificate")}}
+- {{glossary("Hash")}}
+- {{glossary("Public-key cryptography")}}

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

@@ -0,0 +1,30 @@
+---
+title: Federated identity
+slug: Glossary/Federated_identity
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+A **federated identity** system is one in which an {{glossary("identity provider", "identity provider (IdP)")}} acts as an intermediary between users and {{glossary("relying party", "relying parties")}}, enabling a user to use a single set of {{glossary("credential", "credentials")}} to authenticate with a number of different relying parties.
+
+Traditionally, on the web, a user will sign into a website with a username and a password, and the password is verified by the website against a (properly {{glossary("hash", "hashed")}} and {{glossary("salt", "salted")}}) copy stored on the website's backend.
+
+In this model, if users have multiple accounts with different websites, they have to remember many passwords, and this encourages bad password practices such as using the same password for multiple accounts.
+
+In a federated identity system, an identity provider:
+
+- manages a user's credentials and can authenticate users
+- is trusted by multiple websites to make assertions about a user's identity.
+
+A user can then authenticate with the identity provider, which will return a token to the user's browser if authentication is successful. The user's browser will send the token to the website, which can verify that it was issued by the IdP. If the verification succeeds, the website can sign the user in.
+
+Federated identity is often provided as a service by corporations: for example, users who have Google, Microsoft, or Facebook accounts can use them to sign in to many websites. Websites typically have to implement a process for verifying tokens that is specific to an identity provider. However, open standards such as [OpenID](https://en.wikipedia.org/wiki/OpenID), [OAuth](https://en.wikipedia.org/wiki/OAuth), and [SAML](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language) are widely used in the implementation of federated identity systems.
+
+Although federated identity makes logging into multiple different accounts much easier for users and can greatly improve security, it can have serious implications for a user's privacy. If not carefully designed, a federated identity system can allow identity providers to track users across the web as they sign into multiple different sites. Early federated identity systems on the web were built on technologies such as third-party cookies, which are intrinsically privacy-invasive. As these technologies are being deprecated by browsers, new approaches are needed. The [Federated Credential Management (FedCM) API](/en-US/docs/Web/API/FedCM_API) provides a standardized privacy-preserving mechanism for federated identity on the web.
+
+## See also
+
+- {{glossary("Relying party")}}
+- {{glossary("Identity provider")}}
+- [Federated Credential Management (FedCM) API](/en-US/docs/Web/API/FedCM_API)

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

@@ -15,4 +15,4 @@ HMAC is used to ensure both integrity and authentication.
 ## See also
 
 - [HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code) on Wikipedia
-- [RFC 2104](https://www.ietf.org/rfc/rfc2104.txt) on IETF
+- [RFC 2104](https://datatracker.ietf.org/doc/html/rfc2104) on IETF

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

@@ -0,0 +1,19 @@
+---
+title: Identity provider (IdP)
+slug: Glossary/Identity_provider
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+An **identity provider** (IdP) is an entity in a {{glossary("federated identity")}} system that manages a user's {{glossary("credential", "credentials")}} and can {{glossary("authentication", "authenticate")}} users.
+
+In federated identity systems, {{glossary("relying party", "relying parties")}}, that need to control access to a resource (for example, a website deciding whether to sign a user in) outsource the act of authenticating users to a third party, which they trust to make authentication decisions. These third parties are called identity providers.
+
+Examples of identity providers on the web include Google, Microsoft, and Facebook. This enables websites to allow users to sign in using the user's Google, Microsoft, or Facebook account.
+
+## See also
+
+- {{glossary("Federated identity")}}
+- {{glossary("Relying party")}}
+- [Federated Credential Management (FedCM) API](/en-US/docs/Web/API/FedCM_API)

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

@@ -0,0 +1,16 @@
+---
+title: Relying party
+slug: Glossary/Relying_party
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+A **relying party** is an entity that needs to control access to a resource and, to do so, needs to {{glossary("authentication", "authenticate")}} other entities that are trying to access that resource. On the web, a relying party is usually a website that allows users to sign in and needs to authenticate users (for example by checking a password) before deciding whether to grant them access.
+
+The website _relies on_ the validity of the credentials the browser presents when it grants access to its resources.
+
+## See also
+
+- {{glossary("Federated identity")}}
+- {{glossary("Identity provider")}}

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

@@ -0,0 +1,25 @@
+---
+title: Salt
+slug: Glossary/Salt
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+In cryptography, **salt** is random data added to a password before it is {{glossary("hash", "hashed")}}. This makes it impossible for an attacker to derive passwords from their hashes using precomputed tables of passwords and the corresponding hashes.
+
+Passwords should never be stored in their plaintext form, because of the risk that an attacker might break into the database where they are stored. Typically, the password is hashed, and the resulting hash is stored. If the hash function is cryptographically secure, then even if an attacker can get access to the stored hashes, it is impractical for them to reverse the function.
+
+To derive a password from a hash, attackers can look up the password corresponding to a hash in a precomputed table (also known as a [rainbow table](https://en.wikipedia.org/wiki/Rainbow_table)) mapping possible passwords to their hashes:
+
+| Password | Hash        |
+| -------- | ----------- |
+| pa55w0rd | 56965E2A... |
+| abcdef   | BEF57EC7... |
+| letmein  | 1C8BFE8F... |
+
+Although these tables may be very large, such attacks can be effective because table lookup is a fast operation.
+
+Adding random salt to passwords before hashing them stops this attack from working because the hash is not calculated based on the password alone but on the password combined with the salt.
+
+Unlike the password, the salt does not need to be kept secret: it can be stored alongside the salted and hashed password in the server's database.

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

@@ -10,4 +10,4 @@ An {{Glossary("object", "object's")}} stringifier is any {{Glossary("attribute")
 
 ## See also
 
-- Stringifiers in [Information contained in a WebIDL file](/en-US/docs/MDN/Writing_guidelines/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file#stringifiers)
+- Stringifiers in [Information contained in a WebIDL file](/en-US/docs/MDN/Writing_guidelines/Howto/Write_an_api_reference/Information_contained_in_a_WebIDL_file#stringifiers)

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

@@ -12,5 +12,5 @@ page-type: glossary-definition
 
 - [TURN](https://en.wikipedia.org/wiki/TURN) on Wikipedia
 - [WebRTC protocols](/en-US/docs/Web/API/WebRTC_API/Protocols)
-- [Specification](https://www.ietf.org/rfc/rfc5766.txt)
-- [Specification update for IPv6](https://www.ietf.org/rfc/rfc6156.txt)
+- [Specification](https://datatracker.ietf.org/doc/html/rfc5766)
+- [Specification update for IPv6](https://datatracker.ietf.org/doc/html/rfc6156.txt)

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

@@ -6,7 +6,7 @@ page-type: glossary-definition
 
 {{GlossarySidebar}}
 
-URN (Uniform Resource Name) is a {{Glossary("URI")}} in a standard format, referring to a resource without specifying its location or whether it exists. This example comes from [RFC3986](https://www.ietf.org/rfc/rfc3986.txt): `urn:oasis:names:specification:docbook:dtd:xml:4.1.2`
+URN (Uniform Resource Name) is a {{Glossary("URI")}} in a standard format, referring to a resource without specifying its location or whether it exists. This example comes from [RFC3986](https://datatracker.ietf.org/doc/html/rfc3986): `urn:oasis:names:specification:docbook:dtd:xml:4.1.2`
 
 ## See also
 

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

@@ -70,7 +70,7 @@ window.requestAnimationFrame =
   window.msRequestAnimationFrame;
 ```
 
-If you encounter the above code in a code base, you can safely remove all but the first line. All browsers support [`requestAnimationFrame`](/en-US/docs/Web/API/window/requestAnimationFrame#browser_compatibility) without vendor prefixes, and without `window`:
+If you encounter the above code in a code base, you can safely remove all but the first line. All browsers support [`requestAnimationFrame`](/en-US/docs/Web/API/Window/requestAnimationFrame#browser_compatibility) without vendor prefixes, and without `window`:
 
 ```js
 requestAnimationFrame(callback);

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

@@ -13,6 +13,6 @@ WebIDL is used in nearly every API {{Glossary("specification")}} for the Web, an
 ## See also
 
 - [Specification](https://webidl.spec.whatwg.org/)
-- [Information contained in a WebIDL file](/en-US/docs/MDN/Writing_guidelines/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file)
+- [Information contained in a WebIDL file](/en-US/docs/MDN/Writing_guidelines/Howto/Write_an_api_reference/Information_contained_in_a_WebIDL_file)
 - [Gecko WebIDL bindings](https://firefox-source-docs.mozilla.org/dom/webIdlBindings/index.html)
 - [WebIDL](https://en.wikipedia.org/wiki/WebIDL)

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

@@ -6,7 +6,7 @@ page-type: glossary-definition
 
 {{GlossarySidebar}}
 
-**WebM** is royalty-free and is an open web video format natively supported in Mozilla Firefox.
+**[WebM](/en-US/docs/Web/Media/Formats/Containers#webm)** is a royalty-free and open web video format, which is natively supported in all modern browsers.
 
 ## See also
 

files/en-us/learn/common_questions/tools_and_setup/what_are_browser_developer_tools/index.md

@@ -26,7 +26,7 @@ How do you pull it up? Three ways:
 
 - **_Menu bar:_**
 
-  - **Firefox:** Menu ![Firefox hamburger menu icon that has more options to customize and control Firefox.](2014-01-10-13-08-08-f52b8c.png) _➤ Web Developer ➤ Toggle Tools,_ or _Tools ➤_ _Web Developer ➤ Toggle Tools_
+  - **Firefox:** Menu ![Firefox hamburger menu icon that has more options to customize and control Firefox.](2014-01-10-13-08-08-f52b8c.png) _➤ More tools ➤ Web Developer Tools_
   - **Chrome:** _More tools ➤ Developer tools_
   - **Safari:** _Develop ➤ Show Web Inspector._ If you can't see the _Develop_ menu, go to _Safari ➤ Preferences ➤ Advanced_, and check the _Show Develop menu in menu bar_ checkbox.
   - **Opera**: _Developer ➤ Developer tools_