[pull] main from mdn:main

files/en-us/_redirects.txt

@@ -3616,6 +3616,7 @@
 /en-US/docs/Glossary/XHR_(XMLHttpRequest)	/en-US/docs/Glossary/XMLHttpRequest
 /en-US/docs/Glossary/XSS	/en-US/docs/Glossary/Cross-site_scripting
 /en-US/docs/Glossary/block-level	/en-US/docs/Glossary/Block-level_content
+/en-US/docs/Glossary/eTLD	/en-US/docs/Glossary/Registrable_domain
 /en-US/docs/Glossary/entities	/en-US/docs/Glossary/Entity
 /en-US/docs/Glossary/inline-level	/en-US/docs/Glossary/Inline-level_content
 /en-US/docs/Glossary/l10n	/en-US/docs/Glossary/Localization

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

@@ -0,0 +1,42 @@
+---
+title: Registrable domain
+slug: Glossary/Registrable_domain
+page-type: glossary-definition
+sidebar: glossarysidebar
+---
+
+A **registrable domain** is a domain that can be (or has already been) registered by an individual or an organization through a domain name registrar. It's the highest level domain for a single {{glossary("site")}} on the web.
+
+Registrable domains are created directly underneath an _effective top-level domain_ (eTLD), such as `.org`, `.com`, or `.ac.uk`. For this reason a registrable domain is sometimes called an "eTLD+1".
+
+For example, all of the following are registrable domains:
+
+```plain
+crookedtimber.org
+theguardian.com
+sussex.ac.uk
+```
+
+All domains under a registrable domain belong to the same organization. For example:
+
+```plain
+ film.theguardian.com
+music.theguardian.com
+```
+
+```plain
+      news.sussex.ac.uk
+      blog.sussex.ac.uk
+admissions.sussex.ac.uk
+```
+
+Note that not all eTLDs are top-level domains, because many registrars allow organizations to register domains at levels below the top level. In the example above, `.ac.uk` is a subdomain of the top-level `.uk` domain, so `sussex.ac.uk` and `aber.ac.uk` can be registered to different organizations.
+
+Because this is a matter of the registrar's policies, it's impossible to tell algorithmically whether a given domain name suffix (like `.ac.uk`) is publicly registrable or not. The [Public Suffix List](https://publicsuffix.org/) is a list of all suffixes under which organizations can directly register names: that is, it is a list of eTLDs.
+
+## See also
+
+- Related glossary terms:
+  - {{Glossary("Site")}}
+- [Registrable domain definition in the URL specification](https://url.spec.whatwg.org/#host-registrable-domain)
+- [Public Suffix List](https://publicsuffix.org/)

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

@@ -5,7 +5,7 @@ page-type: glossary-definition
 sidebar: glossarysidebar
 ---
 
-Informally, a _site_ is a website, which is a collection of web pages, served from the same domain and maintained by a single organization, defined by {{Glossary("eTLD#etld1", "eTLD+1")}}.
+Informally, a _site_ is a website, which is a collection of web pages, served from the same domain and maintained by a single organization, defined by its {{Glossary("registrable domain")}}.
 
 Browsers sometimes need to distinguish precisely between different sites. For example, the browser must only send [`SameSite`](/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value) cookies to the same site that set them.
 
@@ -45,4 +45,5 @@ These are the same site, or different sites if the scheme is considered:
 - [What is a URL](/en-US/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_URL)
 - Related glossary terms:
   - {{Glossary("Origin")}}
+  - {{Glossary("Registrable domain")}}
 - [Same-origin policy](/en-US/docs/Web/Security/Defenses/Same-origin_policy)

files/en-us/mozilla/firefox/releases/92/index.md

@@ -28,7 +28,7 @@ No changes
 ### JavaScript
 
 - {{jsxref("Object.hasOwn()")}} can be used to test whether a property was defined on an object or inherited ([Firefox bug 1721149](https://bugzil.la/1721149)).
-- The default 5MB storage quota is now available to each origin. The quota previously applied to an entire domain group (also known as {{Glossary("eTLD", "eTLD+1")}} domain; e.g., `*.wikipedia.org`). ([Firefox bug 1064466](https://bugzil.la/1064466)).
+- The default 5MB storage quota is now available to each origin. The quota previously applied to an entire domain group (also known as {{Glossary("registrable domain")}}; e.g., `*.wikipedia.org`). ([Firefox bug 1064466](https://bugzil.la/1064466)).
 - Storage quotas for {{domxref("Window.localStorage")}} are now shared with [IndexedDB API](/en-US/docs/Web/API/IndexedDB_API) and {{domxref("Cache")}} ([Firefox bug 742822](https://bugzil.la/742822)).
 
 ### HTTP

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

@@ -45,7 +45,7 @@ The steps involved are as follows:
    - A link. In this case, the interaction is the user clicking on the link (directly via an {{htmlelement("a")}} element, or via a {{domxref("Window.open()")}} call). The source is registered via the response to the navigation request.
    - An image such as an advertising banner or a 1x1 transparent tracking pixel. In this case, the interaction is the user visiting the page. The source is registered when the image loads, i.e., when the server responds to the image request.
    - A fetch request (i.e., a {{domxref("Window/fetch", "fetch()")}} or {{domxref("XMLHttpRequest")}}). In this case the interaction can be specified as whatever makes sense for your app — for example the fetch request could be invoked by a `click` or `submit` event. The source is registered once the response comes back.
-2. When the attribution source interaction occurs, the source data returned in the {{httpheader("Attribution-Reporting-Register-Source")}} header is stored in a private local cache accessible only by the browser. This data includes the contextual and first-party data available to the page and the advertiser, the origin of the ad tech company that is collecting the conversion data, and one or more destinations ([eTLD+1](/en-US/docs/Glossary/eTLD)s) where you expect the conversion from that ad to occur (i.e., the advertiser's site(s), for example `shop.example`).
+2. When the attribution source interaction occurs, the source data returned in the {{httpheader("Attribution-Reporting-Register-Source")}} header is stored in a private local cache accessible only by the browser. This data includes the contextual and first-party data available to the page and the advertiser, the origin of the ad tech company that is collecting the conversion data, and one or more destinations ({{glossary("registrable domain", "registrable domains")}}) where you expect the conversion from that ad to occur (i.e., the advertiser's site(s), for example `shop.example`).
 3. When the user later visits `shop.example`, this site can register an **attribution trigger** when an interaction indicates that a conversion has occurred (for example, the user clicks the "Add to cart" button on `shop.example`). The browser will then send a request along with an {{httpheader("Attribution-Reporting-Eligible")}} header to indicate that the response is eligible to register an attribution trigger, and registration will be completed if the response includes an appropriate {{httpheader("Attribution-Reporting-Register-Trigger")}} header. The attribution trigger can be, for example:
    - An image such as a shopping cart icon or a 1x1 transparent tracking pixel. In this case, the interaction is the user visiting the page. The trigger is registered when the image loads, i.e., when the server responds to the image request.
    - A fetch request (i.e., a {{domxref("Window/fetch", "fetch()")}} or {{domxref("XMLHttpRequest")}}). In this case the interaction can be specified as whatever makes sense for your app — for example the fetch request could be invoked by a `click` or `submit` event. The trigger is registered once the response comes back.

files/en-us/web/api/attribution_reporting_api/registering_triggers/index.md

@@ -86,7 +86,7 @@ However, what happens behind the scenes to register triggers, look for matches,
 
    Again, see {{httpheader("Attribution-Reporting-Register-Trigger")}} for a detailed description of all the available fields.
 
-3. When the user interacts with the attribution trigger, the browser attempts to match the trigger against any attribution source entries stored in the browser's private local cache. For a successful match, the `Attribution-Reporting-Register-Trigger`'s [`"trigger_data"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Trigger#trigger_data) must match one of the values provided in the {{httpheader("Attribution-Reporting-Register-Source")}}'s [`"trigger_data"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#trigger_data), and the site (scheme + [eTLD+1](/en-US/docs/Glossary/eTLD)) of the top-level page on which the trigger is being registered must:
+3. When the user interacts with the attribution trigger, the browser attempts to match the trigger against any attribution source entries stored in the browser's private local cache. For a successful match, the `Attribution-Reporting-Register-Trigger`'s [`"trigger_data"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Trigger#trigger_data) must match one of the values provided in the {{httpheader("Attribution-Reporting-Register-Source")}}'s [`"trigger_data"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#trigger_data), and the site (scheme + {{glossary("registrable domain")}}) of the top-level page on which the trigger is being registered must:
    - match the site of at least one of the `destination`s specified in the source's associated data.
    - be same-origin with the request that specified the source registration.
 

files/en-us/web/api/fedcm_api/idp_integration/index.md

@@ -22,7 +22,7 @@ There is a potential privacy issue whereby an [IdP is able to discern whether a
 
 The well-known file is requested via an uncredentialed [`GET`](/en-US/docs/Web/HTTP/Reference/Methods/GET) request, which doesn't follow redirects. This effectively prevents the IdP from learning who made the request and which {{glossary("Relying party", "RP")}} is attempting to connect.
 
-The well-known file must be served from the [eTLD+1](https://web.dev/articles/same-site-same-origin#site) of the IdP at `/.well-known/web-identity`. For example, if the IdP endpoints are served under `https://accounts.idp.example/`, they must serve a well-known file at `https://idp.example/.well-known/web-identity`. The well-known file's content should have the following JSON structure:
+The well-known file must be served from the {{glossary("registrable domain")}} of the IdP at `/.well-known/web-identity`. For example, if the IdP endpoints are served under `https://accounts.idp.example/`, they must serve a well-known file at `https://idp.example/.well-known/web-identity`. The well-known file's content should have the following JSON structure:
 
 ```json
 {

files/en-us/web/api/fedcm_api/rp_sign-in/index.md

@@ -74,7 +74,7 @@ The flow is as follows:
 1. The RP invokes {{domxref("CredentialsContainer.get", "navigator.credentials.get()")}} to start off the sign-in flow.
 
 2. From the `configURL` provided for each IdP, the browser requests two files:
-   1. The well-known file (`/.well-known/web-identity`), available from `/.well-known/web-identity` at the [eTLD+1](https://web.dev/articles/same-site-same-origin#site) of the `configURL`.
+   1. The well-known file (`/.well-known/web-identity`), available from `/.well-known/web-identity` at the {{glossary("registrable domain")}} of the `configURL`.
    2. The [IdP config file](/en-US/docs/Web/API/FedCM_API/IDP_integration#provide_a_config_file_and_endpoints) (`/config.json`), available at the `configURL`.
 
    These are both [`GET`](/en-US/docs/Web/HTTP/Reference/Methods/GET) requests, which don't have cookies and don't follow redirects. This effectively prevents IdPs from learning who made the request and which RP is attempting to connect.

files/en-us/web/api/private_state_token_api/using/index.md

@@ -76,7 +76,7 @@ In the example implementation:
 
 As per the Privacy Pass protocol, you will need to implement at least two HTTP endpoints in your issuer server:
 
-- Key commitment: This endpoint is where your encryption public key details will be available to browsers to confirm that your server is legitimate. This endpoint must be inside a well-known directory located at the [eTLD+1](https://web.dev/articles/same-site-same-origin#site) of the issuer server at `/.well-known/private-state-token/key-commitment`. Check out the [Key-commitment endpoint example](https://github.com/GoogleChromeLabs/private-state-token-demo/blob/bf173919620f2b8203a628c3a1094c8846e6aff1/src/index.js#L55).
+- Key commitment: This endpoint is where your encryption public key details will be available to browsers to confirm that your server is legitimate. This endpoint must be inside a well-known directory located at the {{glossary("registrable domain")}} of the issuer server at `/.well-known/private-state-token/key-commitment`. Check out the [Key-commitment endpoint example](https://github.com/GoogleChromeLabs/private-state-token-demo/blob/bf173919620f2b8203a628c3a1094c8846e6aff1/src/index.js#L55).
 - Token issuance: The token issuing endpoint is where all token requests will be handled. This endpoint will be the integration point for the token issuer component. It must be located on the issuer server at `/.well-known/private-state-token/issuance`. Check out the [Token issuance endpoint example](https://github.com/GoogleChromeLabs/private-state-token-demo/blob/bf173919620f2b8203a628c3a1094c8846e6aff1/src/index.js#L81).
 
 Due to the high traffic expected on such a server, we recommend you deploy it using a scalable infrastructure (for example, in a cloud environment) to be able to adjust your backend based on a variable demand.

files/en-us/web/api/storage_api/storage_quotas_and_eviction_criteria/index.md

@@ -86,13 +86,13 @@ Each browser determines, using whatever mechanism it chooses, the maximum amount
 In Firefox, the maximum storage space an origin can use in best-effort mode is whichever is the smaller of:
 
 - 10% of the total disk size where the profile of the user is stored.
-- Or 10 GiB, which is the _group limit_ that Firefox applies to all origins that are part of the same {{Glossary("eTLD", "eTLD+1 domain")}}.
+- Or 10 GiB, which is the _group limit_ that Firefox applies to all origins that are part of the same {{Glossary("site")}}.
 
-Origins for which persistent storage has been granted can store up to 50% of the total disk size, capped at 8 TiB, and are not subject to the eTLD+1 group limit.
+Origins for which persistent storage has been granted can store up to 50% of the total disk size, capped at 8 TiB, and are not subject to the group limit.
 
 For example, if the device has a 500 GiB hard drive, Firefox will allow an origin to store up to:
 
-- In best-effort mode: 10 GiB of data, which is the eTLD+1 group limit.
+- In best-effort mode: 10 GiB of data, which is the group limit.
 - In persistent mode: 250 GiB, which is 50% of the total disk size.
 
 Note that it might not actually be possible for the origin to reach its quota because it is calculated based on the hard drive **total** size, not the currently available disk space. This is done for security reasons, to avoid {{Glossary("fingerprinting")}}.

files/en-us/web/api/ui_events/keyboard_event_key_values/index.md

@@ -3845,6 +3845,8 @@ These keys control documents. In the specification, they're included in other se
       <th scope="col">Linux</th>
       <th scope="col">Android</th>
     </tr>
+  </thead>
+  <tbody>
     <tr>
       <td><code>"Close"</code> [1]</td>
       <td>
@@ -3948,7 +3950,7 @@ These keys control documents. In the specification, they're included in other se
       </td>
       <td></td>
     </tr>
-  </thead>
+  </tbody>
 </table>
 
 \[1] Prior to Firefox 37, this key generated the key value `"Unidentified"`.

files/en-us/web/http/reference/headers/attribution-reporting-register-source/index.md

@@ -47,7 +47,7 @@ Attribution-Reporting-Register-Source: <json-string>
     - `"source_event_id"` {{optional_inline}}
       - : A string representing an ID for the attribution source, which can be used to map it to other information when the attribution source is interacted with, or aggregate information at the reporting endpoint. The string must consist solely of a base-10-formatted 64-bit unsigned integer.
     - `"destination"`
-      - : A single string or an array of 1–3 strings. These strings must contain a complete URL corresponding to the site (scheme + [eTLD+1](/en-US/docs/Glossary/eTLD)) on which a trigger is expected to occur. These are used to match the attribution trigger to the source when a trigger is interacted with.
+      - : A single string or an array of 1–3 strings. These strings must contain a complete URL corresponding to the {{glossary("site")}}, including the scheme, on which a trigger is expected to occur. These are used to match the attribution trigger to the source when a trigger is interacted with.
     - `"aggregation_keys"` {{optional_inline}}
       - : An object containing user-provided keys representing different data points to aggregate report values under.
     - `"aggregatable_report_window"` {{optional_inline}}

files/en-us/web/privacy/guides/bounce_tracking_mitigations/index.md

@@ -65,7 +65,7 @@ The process works as follows:
 2. The browser periodically examines its list of flagged sites and checks to see if the user has actively used the site by interacting with it within the last 45 days. Example interactions include clicking a button, entering data into a form, and scrolling the site. The interaction can occur before, during, or after the bounce was detected.
 3. If the site does not have any user interaction and third-party cookies are blocked, then its state will be deleted.
 
-The heuristic operates on {{glossary("site", "sites")}} defined by {{Glossary("eTLD#etld1", "eTLD+1")}}. As a result, both `foo.site1.example` and `bar.site1.example` are treated as `site1.example`.
+The heuristic operates on {{glossary("site", "sites")}}. As a result, both `foo.site1.example` and `bar.site1.example` are treated as `site1.example`.
 
 ### Stateful versus stateless bounces
 

files/en-us/web/privacy/guides/privacy_sandbox/partitioned_cookies/index.md

@@ -33,7 +33,7 @@ Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
 > [!NOTE]
 > Partitioned cookies must be set with `Secure`. In addition, you can use the `__Host` prefix when setting partitioned cookies to bind them only to the current domain or subdomain, and this is recommended if you don't need to share cookies between subdomains.
 
-With `Partitioned` set, third-party cookies are stored using two keys, the host key and a new **partition key**. The partition key is based on the scheme and {{Glossary("eTLD", "eTLD+1")}} of the top-level URL the browser was visiting when the request was made to the URL endpoint that set the cookie.
+With `Partitioned` set, third-party cookies are stored using two keys, the host key and a new **partition key**. The partition key is based on the {{glossary("site")}}, including the scheme, of the top-level URL the browser was visiting when the request was made to the URL endpoint that set the cookie.
 
 Revisiting our example: