[pull] main from mdn:main

.github/CODEOWNERS

@@ -36,21 +36,23 @@
 /files/en-us/web/mathml/ @mdn/content-mathml
 
 # Templates and sidebars (rari)
-/files/jsondata/L10n-Template.json @mdn/core-dev
+/files/jsondata/L10n-Template.json @mdn/engineering
 
 # ============================= CONTROL FILES ============================= #
 # The CODEOWNERS file must end with these matches: Any pull request changing
 # one or more of these files should be escalated to the owners specified here.
 
 # mdn/content GitHub configuration
-/.github/ @mdn/core-dev
+/.github/ @mdn/engineering
 # Issue templates in .github
 /.github/ISSUE_TEMPLATE/ff-project-issue.md @mdn/core-yari-content
 
 # Root directory
-/* @mdn/core-dev
+/* @mdn/engineering
 # Markdown files in root directory
 /*.md @mdn/core-yari-content
+# Filecheck
+/scripts @mdn/engineering
 
 # These are @mdn-bot because the auto-merge GHA workflow uses the PAT of this account.
 # If another reviewer is specified, update the PAT token or auto-merge will cease to be automatic.

.github/labeler.yml

@@ -10,7 +10,6 @@ system:
           - .*
           - scripts/**
           - tests/**
-          - jest.config.json
           - front-matter-config.json
 
 Content:Accessibility:

.github/workflows/interfacedata-updater.yml

@@ -20,6 +20,7 @@ jobs:
         with:
           path: mdn-content
           ref: main
+          persist-credentials: false
 
       - name: Setup node.js
         uses: actions/setup-node@v4
@@ -32,6 +33,7 @@ jobs:
           repository: w3c/webref
           path: webref
           ref: "@webref/idl@latest"
+          persist-credentials: false
 
       - name: Extract data from webref
         working-directory: mdn-content

.github/workflows/pr-check-lint_content.yml

@@ -24,6 +24,8 @@ jobs:
     steps:
       - name: Checkout BASE
         uses: actions/checkout@v5
+        with:
+          persist-credentials: false
 
       - name: Get changed files
         id: check
@@ -59,6 +61,7 @@ jobs:
         with:
           ref: ${{ github.event.pull_request.head.sha }}
           path: pr_head
+          persist-credentials: false
 
       - name: Get changed content from HEAD
         if: steps.check.outputs.HAS_FILES == 'true'

.github/workflows/pr-review-companion.yml

@@ -97,6 +97,7 @@ jobs:
         if: steps.check.outputs.HAS_ARTIFACT
         with:
           path: content
+          persist-credentials: false
 
       - name: Setup (mdn/content)
         uses: actions/setup-node@v4

.github/workflows/pr-test.yml

@@ -154,13 +154,9 @@ jobs:
           # be able to use this raw diff file for the benefit of analyzing.
           wget https://github.com/${{ github.repository }}/compare/${BASE_SHA}...${HEAD_SHA}.diff -O ${BUILD_OUT_ROOT}/DIFF
 
-      - name: Merge static assets with built documents
+      - name: Show final disk usage size of build
         if: steps.check.outputs.HAS_MD_FILES == 'true'
-        run: |
-          # Exclude the .map files, as they're used for debugging JS and CSS.
-          rsync -a --exclude "*.map" node_modules/@mdn/yari/client/build/ $BUILD_OUT_ROOT
-          # Show the final disk usage size of the build.
-          du -sh $BUILD_OUT_ROOT
+        run: du -sh $BUILD_OUT_ROOT
 
       - uses: actions/upload-artifact@v4
         if: steps.check.outputs.HAS_MD_FILES == 'true'

.lefthook.yml

@@ -22,7 +22,7 @@ pre-commit:
       stage_fixed: true
 
     - name: Run 'yarn filecheck'
-      glob: "*.{svg,png,jpeg,jpg,gif}"
+      glob: "files/*.{svg,png,jpeg,jpg,gif}"
       run: yarn filecheck {staged_files}
 
     - name: Check URL issues

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

@@ -7,15 +7,15 @@ sidebar: glossarysidebar
 
 **Authentication** is in general the process of proving that some fact is genuine. More specifically, in web security, it is the process of verifying the claimed identity of some entity, such as a user. This then makes it possible to decide whether to grant the user the access that they are requesting, such as being signed into a particular account.
 
-Authentication is typically performed by having a user present a user identifier along with a {{glossary("credential")}}, such as a password, a one-time SMS code, or an assertion signed with a private key. The system then checks the binding between the user identifier and the credential, so it can decide whether or not to authenticate the user.
+Authentication is typically performed by having a user present a user identifier along with a {{glossary("credential")}}, such as a password, a one-time code, or an assertion signed with a private key. The system then checks the binding between the user identifier and the credential, so it can decide whether or not to authenticate the user.
 
 Types of authentication information, also called _authentication factors_, are commonly presented in three categories:
 
 - Something the user knows, such as a password.
 - Something the user has, such as a phone.
 - Something the user is, such as a thumbprint.
 
-Multi-factor authentication (MFA) systems require the user to provide more than one factor: for example, a password combined with a one-time code sent to the user's phone.
+{{glossary("Multi-factor authentication")}} (MFA) systems require the user to provide more than one factor: for example, a password combined with a one-time code generated using an authenticator app on the user's phone.
 
 ## See also
 

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

@@ -0,0 +1,16 @@
+---
+title: Continuous integration
+slug: Glossary/Continuous_integration
+page-type: glossary-definition
+sidebar: glossarysidebar
+---
+
+Continuous integration (CI) is a software development practice in which changes to the source are frequently integrated into the main codebase.
+
+It's an important practice whenever a team of developers is working on a shared codebase. In this situation, different developers might be making overlapping changes to the code at the same time, each in their personal branches. Frequent integration of each developer's changes makes it much less likely that conflicts will occur, and much easier to resolve them when they do.
+
+As [Martin Fowler observes](https://martinfowler.com/articles/continuousIntegration.html#EveryonePushesCommitsToTheMainlineEveryDay):
+
+> Integration is primarily about communication. Integration allows developers to tell other developers about the changes they have made. Frequent communication allows people to know quickly as changes develop.
+
+A major aspect of CI is automated build and test: typically, in a CI system, as soon as a developer opens a pull request to commit their changes to the main branch, an automated process builds the product and runs tests. Once all the tests pass, the change can be peer-reviewed.

files/en-us/glossary/multi-factor_authentication/index.md

@@ -0,0 +1,18 @@
+---
+title: Multi-factor authentication
+slug: Glossary/Multi-factor_authentication
+page-type: glossary-definition
+sidebar: glossarysidebar
+---
+
+Multi-factor authentication (MFA) is an authentication method in which the user has to present more than one type of evidence to a system in order to be authenticated.
+
+Most commonly, three different types of evidence (or _factors_) are distinguished:
+
+- Something you know, such as a password or PIN
+- Something you have, such as a cellphone or a hardware security token
+- Something you are: a biometric such as a fingerprint
+
+If an authentication system requires the user to provide more than one of these factors in order to authenticate, then it is a multi-factor system.
+
+For example, the system might ask the user for a password as well as a code generated by the authenticator app on their phone.

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

@@ -0,0 +1,12 @@
+---
+title: Principle of least privilege
+slug: Glossary/Principle_of_least_privilege
+page-type: glossary-definition
+sidebar: glossarysidebar
+---
+
+The principle of least privilege is a design consideration in computer security, according to which entities (including users, system processes, or programs) should be granted the minimum amount of access that they need in order to do their jobs.
+
+For example, in a software development team, all members might need the ability to write to the source code repository, but only a subset of the team might need the ability to alter the repository's security settings.
+
+Applying the principle of least privilege reduces the potential damage when an entity is compromised by an attacker: so for example, if a team member's account is compromised, then the damage that the attacker can do is limited by the privileges that were granted to that team member.

files/en-us/learn_web_development/core/frameworks_libraries/svelte_typescript/index.md

@@ -215,7 +215,7 @@ And if you pass something that is not a number, it will complain about it:
 
 ![Type checking in VS Code - the ms variable has been given a non-numeric value](06-vscode-type-checking-in-components.png)
 
-The application template has a `check` script configured that runs `svelte-check` against your code. This package allows you to detect errors and warnings normally displayed by a code editor from the command line, which makes it pretty useful for running it in a continuous integration (CI) pipeline. Just run `npm run check` to check for unused CSS, and return A11y hints and TypeScript compile errors.
+The application template has a `check` script configured that runs `svelte-check` against your code. This package allows you to detect errors and warnings normally displayed by a code editor from the command line, which makes it pretty useful for running it in a {{glossary("continuous integration")}} (CI) pipeline. Just run `npm run check` to check for unused CSS, and return A11y hints and TypeScript compile errors.
 
 In this case, if you run `npm run check` (either in the VS Code console or terminal) you will get the following error:
 

files/en-us/learn_web_development/extensions/server-side/express_nodejs/skeleton_website/index.md

@@ -401,7 +401,7 @@ npm install
 ```
 
 > [!NOTE]
-> It is a good idea to regularly update to the latest compatible versions of your dependency libraries — this may even be done automatically or semi-automatically as part of a continuous integration setup.
+> It is a good idea to regularly update to the latest compatible versions of your dependency libraries — this may even be done automatically or semi-automatically as part of a {{glossary("continuous integration")}} setup.
 >
 > Usually library updates to the minor and patch version remain compatible.
 > We've prefixed each version with `^` above so that we can automatically update to the latest `minor.patch` version by running:

files/en-us/learn_web_development/extensions/testing/introduction/index.md

@@ -130,7 +130,7 @@ Finally, you can get smarter with your testing using auditing or automation tool
 - see if a button click causes something to happen successfully (like for example, a map displaying), displaying the results once the tests are completed
 - take a screenshot of each, allowing you to see if a layout is consistent across the different browsers.
 
-If you wish to invest money in testing, there are also commercial tools that can automate much of the setup and testing for you (such as [Sauce Labs](https://saucelabs.com/) and [Browser Stack](https://www.browserstack.com/)). These kinds of tools usually enable a continuous integration workflow, where code changes are automatically tested before they are allowed to be submitted into your code repository.
+If you wish to invest money in testing, there are also commercial tools that can automate much of the setup and testing for you (such as [Sauce Labs](https://saucelabs.com/) and [Browser Stack](https://www.browserstack.com/)). These kinds of tools usually enable a {{glossary("continuous integration")}} workflow, where code changes are automatically tested before they are allowed to be submitted into your code repository.
 
 #### Testing on prerelease browsers
 

files/en-us/learn_web_development/extensions/testing/your_own_automation_environment/index.md

@@ -795,7 +795,7 @@ So this is pretty cool. We have tested this locally, but you could set this up o
 
 ## Integrating Selenium with CI tools
 
-As another point, it is also possible to integrate Selenium and related tools like LambdaTest, and Sauce Labs with continuous integration (CI) tools — this is useful, as it means you can run your tests via a CI tool, and only commit new changes to your code repository if the tests pass.
+As another point, it is also possible to integrate Selenium and related tools like LambdaTest, and Sauce Labs with {{glossary("continuous integration")}} (CI) tools — this is useful, as it means you can run your tests via a CI tool, and only commit new changes to your code repository if the tests pass.
 
 It is out of scope to look at this area in detail in this article, but we'd suggest getting started with Travis CI — this is probably the easiest CI tool to get started with and has good integration with web tools like GitHub and Node.
 

files/en-us/learn_web_development/getting_started/environment_setup/command_line/index.md

@@ -464,7 +464,7 @@ With Prettier there's a number of ways automation can be achieved and though the
 
 - Before you commit your code into a git repository using [Husky](https://github.com/typicode/husky).
 - Whenever you hit "save" in your code editor, be it [VS Code](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode), or [Sublime Text](https://packagecontrol.io/packages/JsPrettier).
-- As part of continuous integration checks using tools like [GitHub Actions](https://github.com/features/actions).
+- As part of {{glossary("continuous integration")}} checks using tools like [GitHub Actions](https://github.com/features/actions).
 
 Our personal preference is the second one — while using say VS Code, Prettier kicks in and cleans up any formatting it needs to do every time we hit save. You can find a lot more information about using Prettier in different ways in the [Prettier docs](https://prettier.io/docs/).
 

files/en-us/web/accessibility/guides/information_for_web_authors/index.md

@@ -41,7 +41,7 @@ Tools to integrate into your build process, programmatically adding accessibilit
 - [Lighthouse Audits](https://github.com/GoogleChrome/lighthouse/blob/main/docs/readme.md#using-programmatically)
 - [AccessLint.js](https://github.com/accesslint/accesslint.js/tree/master)
 
-Continuous integration tools to find accessibility issues in your GitHub pull requests:
+{{glossary("Continuous integration")}} tools to find accessibility issues in your GitHub pull requests:
 
 - [AccessLint](https://accesslint.com/)
 

files/en-us/web/api/mediadevices/getdisplaymedia/index.md

@@ -24,7 +24,7 @@ getDisplayMedia(options)
 ### Parameters
 
 - `options` {{optional_inline}}
-  - : An optional object specifying requirements for the returned {{domxref("MediaStream")}}.
+  - : An object specifying requirements for the returned {{domxref("MediaStream")}}.
     The options for `getDisplayMedia()` work in the same as the [constraints](/en-US/docs/Web/API/MediaDevices/getUserMedia#parameters) for the {{domxref("MediaDevices.getUserMedia()")}} method, although in that case only `audio` and `video` can be specified.
     The list of possible option properties for `getDisplayMedia()` is as follows:
     - `video` {{optional_inline}}
@@ -39,32 +39,43 @@ getDisplayMedia(options)
     - `monitorTypeSurfaces` {{Experimental_Inline}} {{optional_inline}}
       - : An enumerated value specifying whether the browser should offer entire screens in the screen capture options presented to the user alongside tab and window options.
         This option is intended to protect companies from leakage of private information through employee error when using video conferencing apps.
-        Possible values are `include`, which hints that the browser should include screen options, and `exclude`, which hints that they should be excluded.
-        A default value is not mandated by the spec; see the [Browser compatibility](#browser_compatibility) section for browser-specific defaults.
+        Possible values are:
+        - `include`: Hints that the browser should include screen options.
+        - `exclude`: Hints that screen options should be excluded.
 
         > [!NOTE]
         > You cannot set `monitorTypeSurfaces: "exclude"` at the same time as [`displaySurface: "monitor"`](/en-US/docs/Web/API/MediaTrackConstraints/displaySurface) as the two settings are contradictory.
         > Trying to do so will result in the `getDisplayMedia()` call failing with a `TypeError`.
 
     - `preferCurrentTab` {{non-standard_inline}} {{Experimental_Inline}} {{optional_inline}}
-      - : A boolean; a value of `true` instructs the browser to offer the current tab as the most prominent capture source, i.e., as a separate "This Tab" option in the "Choose what to share" options presented to the user.
+      - : A boolean; a value of `true` instructs the browser to offer the current tab as the most prominent capture source, that is, as a separate "This Tab" option in the "Choose what to share" options presented to the user.
         This is useful as many app types generally just want to share the current tab.
         For example, a slide deck app might want to let the user stream the current tab containing the presentation to a virtual conference.
-        A default value is not mandated by the spec; see the [Browser compatibility](#browser_compatibility) section for browser-specific defaults.
     - `selfBrowserSurface` {{Experimental_Inline}} {{optional_inline}}
       - : An enumerated value specifying whether the browser should allow the user to select the current tab for capture.
         This helps to avoid the "infinite hall of mirrors" effect experienced when a video conferencing app inadvertently shares its own display.
-        Possible values are `include`, which hints that the browser should include the current tab in the choices offered for capture, and `exclude`, which hints that it should be excluded.
-        A default value is not mandated by the spec; see the [Browser compatibility](#browser_compatibility) section for browser-specific defaults.
+        Possible values are:
+        - `include`: Hints that the browser should include the current tab in the choices offered for capture.
+        - `exclude`: Hints that the current tab should be excluded from the choices.
     - `surfaceSwitching` {{Experimental_Inline}} {{optional_inline}}
       - : An enumerated value specifying whether the browser should display a control to allow the user to dynamically switch the shared tab during screen-sharing.
-        This is much more convenient than having to go through the whole sharing process again each time a user wants to switch the shared tab.
-        Possible values are `include`, which hints that the browser should include the control, and `exclude`, which hints that it should not be shown.
-        A default value is not mandated by the spec; see the [Browser compatibility](#browser_compatibility) section for browser-specific defaults.
+        This is more convenient than having to go through the whole sharing process again each time a user wants to switch the shared tab.
+        Possible values are:
+        - `include`: Hints that the browser should include the control.
+        - `exclude`: Hints that the control should not be shown.
     - `systemAudio` {{Experimental_Inline}} {{optional_inline}}
       - : An enumerated value specifying whether the browser should include the system audio among the possible audio sources offered to the user.
-        Possible values are `include`, which hints that the browser should include the system audio in the list of choices, and `exclude`, which hints that it should be excluded.
-        A default value is not mandated by the spec; see the [Browser compatibility](#browser_compatibility) section for browser-specific defaults.
+        Possible values are:
+        - `include`: Hints that the browser should include the system audio in the list of choices.
+        - `exclude`: Hints that system audio should be excluded from the choices shown.
+    - `windowAudio` {{Experimental_Inline}} {{optional_inline}}
+      - : An enumerated value that hints to the browser what audio sharing option the user should be presented with alongside window sharing options. Possible values are:
+        - `exclude`: Hints that audio should not be shareable when a window sharing option is chosen.
+        - `window`: Hints that when a window sharing option is chosen, only audio originating from that window should be shared.
+        - `system`: Hints that when a window sharing option is chosen, all system audio should be shared.
+
+> [!NOTE]
+> For most of these options, a default value is not mandated by the spec. For standalone options, where a default is not mentioned, see the [Browser compatibility](#browser_compatibility) section for browser-specific defaults.
 
 > [!NOTE]
 > See the article [Capabilities, constraints, and settings](/en-US/docs/Web/API/Media_Capture_and_Streams_API/Constraints) for a lot more detail on how these options work.