diff --git a/hr-repos.json b/hr-repos.json
index b87f512..1041ea5 100644
--- a/hr-repos.json
+++ b/hr-repos.json
@@ -93,6 +93,7 @@
   "w3c/dxwg",
   "w3c/edit-context",
   "w3c/editing",
+  "w3c/element-timing",
   "w3c/encrypted-media",
   "w3c/epub-specs",
   "w3c/event-timing",
@@ -426,7 +427,6 @@
   "WICG/direct-sockets",
   "WICG/display-override",
   "WICG/document-policy",
-  "WICG/element-timing",
   "WICG/entries-api",
   "WICG/eyedropper-api",
   "WICG/file-handling",
diff --git a/report.json b/report.json
index 1b92603..1b57b76 100644
--- a/report.json
+++ b/report.json
@@ -778,6 +778,11 @@
         "error": "doesn't match SW or DOC contributing",
         "contributing": "# Web Editing Working Group\n\nContributions to this repository are intended to become part of Recommendation-track documents governed by the\n[W3C Patent Policy](http://www.w3.org/Consortium/Patent-Policy-20040205/) and\n[Software and Document License](http://www.w3.org/Consortium/Legal/copyright-software). To make substantive contributions to specifications, you must participate\nin this W3C Working Group or make a non-member patent licensing commitment.\n\nIf you are not the sole contributor to a contribution (pull request), please identify all \ncontributors in the pull request comment.\n\nTo add a contributor (other than yourself, that's automatic), mark them one per line as follows:\n\n```\n+@github_username\n```\n\nIf you added a contributor by mistake, you can remove them in a comment with:\n\n```\n-@github_username\n```\n\nIf you are making a pull request on behalf of someone else but you had no part in designing the \nfeature, you can remove yourself with the above syntax.\n"
       },
+      {
+        "repo": "w3c/element-timing",
+        "error": "doesn't match CG contributing",
+        "contributing": "# Web Platform Incubator Community Group\n\nThis repository is being used for work in the W3C Web Platform Incubator Community Group, governed by the [W3C Community License\nAgreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To make substantive contributions,\nyou must join the CG.\n\nIf you are not the sole contributor to a contribution (pull request), please identify all\ncontributors in the pull request comment.\n\nTo add a contributor (other than yourself, that's automatic), mark them one per line as follows:\n\n```\n+@github_username\n```\n\nIf you added a contributor by mistake, you can remove them in a comment with:\n\n```\n-@github_username\n```\n\nIf you are making a pull request on behalf of someone else but you had no part in designing the\nfeature, you can remove yourself with the above syntax.\n\n# Tests\n\nFor normative changes, a corresponding\n[web-platform-tests](https://github.com/web-platform-tests/wpt) PR is highly appreciated. Typically,\nboth PRs will be merged at the same time. Note that a test change that contradicts the spec should\nnot be merged before the corresponding spec change. If testing is not practical, please explain why\nand if appropriate [file a web-platform-tests issue](https://github.com/web-platform-tests/wpt/issues/new)\nto follow up later. Add the `type:untestable` or `type:missing-coverage` label as appropriate.\n"
+      },
       {
         "repo": "w3c/encrypted-media",
         "error": "doesn't match SW or DOC contributing",
@@ -1411,7 +1416,7 @@
       {
         "repo": "w3c/sustyweb",
         "error": "doesn't match CG contributing",
-        "contributing": "> [!WARNING]\n> This Community Group's activities are now under the direction of the [W3C Sustainable Web Interest Group](https://www.w3.org/groups/ig/sustainableweb/). This includes the curation of the [Web Sustainability Guidelines](https://w3c.github.io/sustyweb/). Thank you for supporting us as we reached this stage in our journey and we hope you will continue to support our work as it develops at our new home (where you are welcome to get involved).\n\n# Contributing\n\nThis repository is being used for work in the **W3C Sustainable Web Design Community Group**, governed by the [W3C Community License\nAgreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To make substantive contributions,\nyou must join the [CG](https://www.w3.org/community/sustyweb/).\n\n## Overview\n\nThis repository is used to develop content for the Web Sustainability Guidelines (WSGs), as well as any supplementary documents.\n\n## Collaboration\n\nWe welcome content from individuals as well as group efforts and understand that this may pose difficulties for those either unfamiliar with pull requests (on a technical level) or with collaborative efforts (wishing to discuss progress before submitting results). In such cases, members can (if they choose) work with any open format they prefer to collaborate (referring to the specification and its supplements), and submit an issue request containing the URL to the document in question. A moderator (lead or chair) will help translate these requested updates into the living draft specification.\n\n## File Structure\n\nThe structure of the repository has been created to ensure ease of maintenance. The base directory contains all of the compiled files that are public facing such as the specification, supplementary documents, the JSON API, and other materials such as the finalized Test Suite. The \"drafts\" folder contains all of the pre-exported W3C ReSpec sources including the living editions of the [specification](https://w3c.github.io/sustyweb/drafts/), [at-a-glance](https://w3c.github.io/sustyweb/drafts/glance.html), [introduction](https://w3c.github.io/sustyweb/drafts/intro.html), [laws & policies](https://w3c.github.io/sustyweb/drafts/policies.html), [quick reference](https://w3c.github.io/sustyweb/drafts/quickref.html), [STAR](https://w3c.github.io/sustyweb/drafts/star.html), [JSON API](https://w3c.github.io/sustyweb/drafts/guidelines.json) and other supplements such as our draft Test Suite.\n\n```\n\n/ig/charter.html\t\t\t- Working Group Draft Charter\n/drafts/test-suite/\t\t\t- Test Suite & Assets (Source)\n/drafts/checklist.pages\t\t\t- PDF Checklist (Source)\n/drafts/glance.html\t\t\t- At-A-Glance (Source)\n/drafts/guidelines.json\t\t\t- WSG JSON API (Source)\n/drafts/index.html\t\t\t- WSG Specification (Source)\n/drafts/intro.html\t\t\t- Introduction (Source)\n/drafts/policies.html\t\t\t- Laws & Policies (Source)\n/drafts/quickref.html\t\t\t- Quick Reference (Source)\n/drafts/star.html\t\t\t- STAR (Source)\n\n/test-suite/\t\t\t\t- READ ONLY - Test Suite & Assets (Public)\nchecklist.pdf\t\t\t\t- READ ONLY - PDF Checklist (Public)\nglance.html\t\t\t\t- READ ONLY - At-A-Glance (Public)\nguidelines.json\t\t\t\t- READ ONLY - WSG JSON API (Public)\nindex.html\t\t\t\t- READ ONLY - WSG Specification (Public)\nintro.html\t\t\t\t- READ ONLY - Introduction (Public)\noverview.pdf\t\t\t\t- READ ONLY - Project Progress Tracker (Public)\npolicies.html\t\t\t\t- READ ONLY - Laws & Policies (Public)\nquickref.html\t\t\t\t- READ ONLY - Quick Reference (Public)\nstar.html\t\t\t\t- READ ONLY - STAR (Public)\nTPAC_Slides.pdf\t\t\t\t- READ ONLY - W3C TPAC Slides\nWeb_Sustainability_GRI_Impact_est.ipynb\t- READ ONLY - GRI Impact Calculator\n```\n\nWhen you contribute to our repo, you **MUST** only make changes to documents within the \"drafts\" or \"ig\" folders (the sources). Once a PR submission has been reviewed by our group (for quality control purposes), it will either be accepted, or rejected, or further discussion will be required (an issue can be raised for example). Once a PR has been accepted it will be visible within the living draft documents immediately. When enough issues have been collated to warrant a release publication, the necessary documents will be exported through ReSpec into their final HTML form and will replace their static namesakes in the base directory to be versioned as the next public release. Release notes will also be generated by a chair who will verify all submissions before publication.\n\nYou will notice duplication within the content of our work (as the JSON API for example must reflect the specification). This work is not auto-generated so while we appreciate it if individuals choose to make adjustments to all affected files as required, time commitments may not allow for everyone to do so. As such, if you can only update a single document, as part of the approval process, a moderator (lead or chair) will update all necessary documents to ensure parity with your change.\n\n## Pull Requests\n\nIf you would like to contribute towards this specification, our primary method is through Pull Requests (PRs).\n\nPull requests (PRs) should be made against the main branch.\n\nIf you are not the sole contributor to a contribution (pull request), please identify all contributors in the pull request comment.\n\nTo add a contributor (other than yourself, that's automatic), mark them one per line as follows:\n\n```\n+@github_username\n```\n\nIf you added a contributor by mistake, you can remove them in a comment with:\n\n```\n-@github_username\n```\n\nIf you are making a pull request on behalf of someone else but you had no part in designing the feature, you can remove yourself with the above syntax.\n\n## Issues\n\nIf you cannot submit a pull request, or if you cannot provide a direct solution, the preferred method is to create a [new issue](https://github.com/w3c/sustyweb/issues/new) with your public comments. You can also comment on any issue threads on [Github Issues](https://github.com/w3c/sustyweb/issues/). You could provide comments on technical errors (bugs) you have uncovered, new guidelines or success criteria you believe should be added, questions you have about existing or future content or an idea for a direction or feature we could utilize.\n\nPlease check that your question hasn't already been posted first, and provide as much detail as possible (if you have a solution or content to add, it would be very helpful). We're all volunteers so please keep this in mind and try to be civil when commenting about our work.\n\nIf filing issues in GitHub is not feasible, email our open discussion group [public-sustyweb@w3.org](public-sustyweb@w3.org) ([comment archive](https://lists.w3.org/Archives/Public/public-sustyweb/)).\n\n## Credit\n\nAll contributors will receive credit (in the specification and our GitHub release notes) if their feedback and ideas make it into the document. Certain exclusions will apply such as those who do not provide their full names or those whose feedback is deemed as invalid, duplicate, or general questions that don't add to the specification or its supplements.\n"
+        "contributing": "> [!WARNING]\n> This Community Group's activities are now under the direction of the [W3C Sustainable Web Interest Group](https://www.w3.org/groups/ig/sustainableweb/). This includes the curation of the [Web Sustainability Guidelines](https://w3c.github.io/sustainableweb-wsg/). Thank you for supporting us as we reached this stage in our journey and we hope you will continue to support our work as it develops at our new home (where you are welcome to get involved).\n\n# Contributing\n\nThis repository is being used for work in the **W3C Sustainable Web Design Community Group**, governed by the [W3C Community License\nAgreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To make substantive contributions,\nyou must join the [CG](https://www.w3.org/community/sustyweb/).\n\n## Overview\n\nThis repository is used to develop content for the Web Sustainability Guidelines (WSGs), as well as any supplementary documents.\n\n## Collaboration\n\nWe welcome content from individuals as well as group efforts and understand that this may pose difficulties for those either unfamiliar with pull requests (on a technical level) or with collaborative efforts (wishing to discuss progress before submitting results). In such cases, members can (if they choose) work with any open format they prefer to collaborate (referring to the specification and its supplements), and submit an issue request containing the URL to the document in question. A moderator (lead or chair) will help translate these requested updates into the living draft specification.\n\n## File Structure\n\nThe structure of the repository has been created to ensure ease of maintenance. The base directory contains all of the compiled files that are public facing such as the specification, supplementary documents, the JSON API, and other materials such as the finalized Test Suite. The \"drafts\" folder contains all of the pre-exported W3C ReSpec sources including the living editions of the [specification](https://w3c.github.io/sustyweb/drafts/), [at-a-glance](https://w3c.github.io/sustyweb/drafts/glance.html), [introduction](https://w3c.github.io/sustyweb/drafts/intro.html), [laws & policies](https://w3c.github.io/sustyweb/drafts/policies.html), [quick reference](https://w3c.github.io/sustyweb/drafts/quickref.html), [STAR](https://w3c.github.io/sustyweb/drafts/star.html), [JSON API](https://w3c.github.io/sustyweb/drafts/guidelines.json) and other supplements such as our draft Test Suite.\n\n```\n\n/ig/charter.html\t\t\t- Working Group Draft Charter\n/drafts/test-suite/\t\t\t- Test Suite & Assets (Source)\n/drafts/checklist.pages\t\t\t- PDF Checklist (Source)\n/drafts/glance.html\t\t\t- At-A-Glance (Source)\n/drafts/guidelines.json\t\t\t- WSG JSON API (Source)\n/drafts/index.html\t\t\t- WSG Specification (Source)\n/drafts/intro.html\t\t\t- Introduction (Source)\n/drafts/policies.html\t\t\t- Laws & Policies (Source)\n/drafts/quickref.html\t\t\t- Quick Reference (Source)\n/drafts/star.html\t\t\t- STAR (Source)\n\n/test-suite/\t\t\t\t- READ ONLY - Test Suite & Assets (Public)\nchecklist.pdf\t\t\t\t- READ ONLY - PDF Checklist (Public)\nglance.html\t\t\t\t- READ ONLY - At-A-Glance (Public)\nguidelines.json\t\t\t\t- READ ONLY - WSG JSON API (Public)\nindex.html\t\t\t\t- READ ONLY - WSG Specification (Public)\nintro.html\t\t\t\t- READ ONLY - Introduction (Public)\noverview.pdf\t\t\t\t- READ ONLY - Project Progress Tracker (Public)\npolicies.html\t\t\t\t- READ ONLY - Laws & Policies (Public)\nquickref.html\t\t\t\t- READ ONLY - Quick Reference (Public)\nstar.html\t\t\t\t- READ ONLY - STAR (Public)\nTPAC_Slides.pdf\t\t\t\t- READ ONLY - W3C TPAC Slides\nWeb_Sustainability_GRI_Impact_est.ipynb\t- READ ONLY - GRI Impact Calculator\n```\n\nWhen you contribute to our repo, you **MUST** only make changes to documents within the \"drafts\" or \"ig\" folders (the sources). Once a PR submission has been reviewed by our group (for quality control purposes), it will either be accepted, or rejected, or further discussion will be required (an issue can be raised for example). Once a PR has been accepted it will be visible within the living draft documents immediately. When enough issues have been collated to warrant a release publication, the necessary documents will be exported through ReSpec into their final HTML form and will replace their static namesakes in the base directory to be versioned as the next public release. Release notes will also be generated by a chair who will verify all submissions before publication.\n\nYou will notice duplication within the content of our work (as the JSON API for example must reflect the specification). This work is not auto-generated so while we appreciate it if individuals choose to make adjustments to all affected files as required, time commitments may not allow for everyone to do so. As such, if you can only update a single document, as part of the approval process, a moderator (lead or chair) will update all necessary documents to ensure parity with your change.\n\n## Pull Requests\n\nIf you would like to contribute towards this specification, our primary method is through Pull Requests (PRs).\n\nPull requests (PRs) should be made against the main branch.\n\nIf you are not the sole contributor to a contribution (pull request), please identify all contributors in the pull request comment.\n\nTo add a contributor (other than yourself, that's automatic), mark them one per line as follows:\n\n```\n+@github_username\n```\n\nIf you added a contributor by mistake, you can remove them in a comment with:\n\n```\n-@github_username\n```\n\nIf you are making a pull request on behalf of someone else but you had no part in designing the feature, you can remove yourself with the above syntax.\n\n## Issues\n\nIf you cannot submit a pull request, or if you cannot provide a direct solution, the preferred method is to create a [new issue](https://github.com/w3c/sustyweb/issues/new) with your public comments. You can also comment on any issue threads on [Github Issues](https://github.com/w3c/sustyweb/issues/). You could provide comments on technical errors (bugs) you have uncovered, new guidelines or success criteria you believe should be added, questions you have about existing or future content or an idea for a direction or feature we could utilize.\n\nPlease check that your question hasn't already been posted first, and provide as much detail as possible (if you have a solution or content to add, it would be very helpful). We're all volunteers so please keep this in mind and try to be civil when commenting about our work.\n\nIf filing issues in GitHub is not feasible, email our open discussion group [public-sustyweb@w3.org](public-sustyweb@w3.org) ([comment archive](https://lists.w3.org/Archives/Public/public-sustyweb/)).\n\n## Credit\n\nAll contributors will receive credit (in the specification and our GitHub release notes) if their feedback and ideas make it into the document. Certain exclusions will apply such as those who do not provide their full names or those whose feedback is deemed as invalid, duplicate, or general questions that don't add to the specification or its supplements.\n"
       },
       {
         "repo": "w3c/svgwg",
@@ -2063,11 +2068,6 @@
         "error": "doesn't match CG contributing",
         "contributing": "# Web Platform Incubator Community Group\n\nThis repository is being used for work in the W3C Web Platform Incubator Community Group, governed by the [W3C Community License\nAgreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To make substantive contributions,\nyou must join the CG.\n\nIf you are not the sole contributor to a contribution (pull request), please identify all\ncontributors in the pull request comment.\n\nTo add a contributor (other than yourself, that's automatic), mark them one per line as follows:\n\n```\n+@github_username\n```\n\nIf you added a contributor by mistake, you can remove them in a comment with:\n\n```\n-@github_username\n```\n\nIf you are making a pull request on behalf of someone else but you had no part in designing the\nfeature, you can remove yourself with the above syntax.\n"
       },
-      {
-        "repo": "WICG/element-timing",
-        "error": "doesn't match CG contributing",
-        "contributing": "# Web Platform Incubator Community Group\n\nThis repository is being used for work in the W3C Web Platform Incubator Community Group, governed by the [W3C Community License\nAgreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To make substantive contributions,\nyou must join the CG.\n\nIf you are not the sole contributor to a contribution (pull request), please identify all\ncontributors in the pull request comment.\n\nTo add a contributor (other than yourself, that's automatic), mark them one per line as follows:\n\n```\n+@github_username\n```\n\nIf you added a contributor by mistake, you can remove them in a comment with:\n\n```\n-@github_username\n```\n\nIf you are making a pull request on behalf of someone else but you had no part in designing the\nfeature, you can remove yourself with the above syntax.\n\n# Tests\n\nFor normative changes, a corresponding\n[web-platform-tests](https://github.com/web-platform-tests/wpt) PR is highly appreciated. Typically,\nboth PRs will be merged at the same time. Note that a test change that contradicts the spec should\nnot be merged before the corresponding spec change. If testing is not practical, please explain why\nand if appropriate [file a web-platform-tests issue](https://github.com/web-platform-tests/wpt/issues/new)\nto follow up later. Add the `type:untestable` or `type:missing-coverage` label as appropriate.\n"
-      },
       {
         "repo": "WICG/entries-api",
         "error": "doesn't match CG contributing",
@@ -3157,6 +3157,7 @@
       "w3c/edge-computing-web-exploration",
       "w3c/edit-context",
       "w3c/editing",
+      "w3c/element-timing",
       "w3c/elements-of-html",
       "w3c/elreq",
       "w3c/emma",
@@ -4052,7 +4053,6 @@
       "WICG/document-isolation-policy",
       "WICG/document-picture-in-picture",
       "WICG/document-policy",
-      "WICG/element-timing",
       "WICG/entries-api",
       "WICG/explicit-javascript-compile-hints-file-based",
       "WICG/eyedropper-api",
@@ -4515,6 +4515,11 @@
         "error": "doesn't match SW or DOC license",
         "license": "All documents in this Repository are licensed by contributors\nunder the \n[W3C Software and Document License](http://www.w3.org/Consortium/Legal/copyright-software).\n\n"
       },
+      {
+        "repo": "w3c/element-timing",
+        "error": "doesn't match CG license",
+        "license": "All Reports in this Repository are licensed by Contributors\nunder the\n[W3C Software and Document License](http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document).\n\nContributions to Specifications are made under the\n[W3C CLA](https://www.w3.org/community/about/agreements/cla/).\n\nContributions to Test Suites are made under the\n[W3C 3-clause BSD License](https://www.w3.org/Consortium/Legal/2008/03-bsd-license.html)\n\n"
+      },
       {
         "repo": "w3c/encrypted-media",
         "error": "doesn't match SW or DOC license",
@@ -5810,11 +5815,6 @@
         "error": "doesn't match CG license",
         "license": "All Reports in this Repository are licensed by Contributors\nunder the\n[W3C Software and Document License](http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document).\n\nContributions to Specifications are made under the\n[W3C CLA](https://www.w3.org/community/about/agreements/cla/).\n\nContributions to Test Suites are made under the\n[W3C 3-clause BSD License](https://www.w3.org/Consortium/Legal/2008/03-bsd-license.html)\n\n"
       },
-      {
-        "repo": "WICG/element-timing",
-        "error": "doesn't match CG license",
-        "license": "All Reports in this Repository are licensed by Contributors\nunder the\n[W3C Software and Document License](http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document).\n\nContributions to Specifications are made under the\n[W3C CLA](https://www.w3.org/community/about/agreements/cla/).\n\nContributions to Test Suites are made under the\n[W3C 3-clause BSD License](https://www.w3.org/Consortium/Legal/2008/03-bsd-license.html)\n\n"
-      },
       {
         "repo": "WICG/entries-api",
         "error": "doesn't match CG license",
@@ -6318,6 +6318,7 @@
       "w3c/dms",
       "w3c/dpv",
       "w3c/dwbp",
+      "w3c/element-timing",
       "w3c/equity-cg",
       "w3c/exi-specs",
       "w3c/gpc",
@@ -7781,6 +7782,10 @@
         "repo": "w3c/editing",
         "error": "gh-pages branch protection is not admin enforced"
       },
+      {
+        "repo": "w3c/element-timing",
+        "error": "main branch protection is not admin enforced"
+      },
       {
         "repo": "w3c/encrypted-media",
         "error": "main branch protection is not admin enforced"
@@ -8645,10 +8650,6 @@
         "repo": "WICG/digital-credentials",
         "error": "main branch protection is not admin enforced"
       },
-      {
-        "repo": "WICG/element-timing",
-        "error": "main branch protection is not admin enforced"
-      },
       {
         "repo": "WICG/entries-api",
         "error": "main branch protection is not admin enforced"
@@ -9015,6 +9016,10 @@
         "repo": "w3c/edit-context",
         "error": "gh-pages branch review is not required"
       },
+      {
+        "repo": "w3c/element-timing",
+        "error": "main branch review is not required"
+      },
       {
         "repo": "w3c/encrypted-media",
         "error": "main branch review is not required"
@@ -9699,10 +9704,6 @@
         "repo": "WICG/devtools-protocol",
         "error": "main branch review is not required"
       },
-      {
-        "repo": "WICG/element-timing",
-        "error": "main branch review is not required"
-      },
       {
         "repo": "WICG/entries-api",
         "error": "main branch review is not required"
@@ -9866,7 +9867,7 @@
       }
     ]
   },
-  "timestamp": "2024-12-17T00:24:29.920Z",
+  "timestamp": "2024-12-18T00:25:20.993Z",
   "repos": [
     {
       "id": "MDEwOlJlcG9zaXRvcnk4MTAyMTg2MA==",
@@ -10806,7 +10807,7 @@
       "license": null,
       "codeOfConduct": null,
       "readme": {
-        "text": "# Typescript Type Definitions for WebGPU\n\nThis package defines Typescript types (`.d.ts`) for the upcoming [WebGPU standard](https://github.com/gpuweb/gpuweb/wiki/Implementation-Status).\n\nUse this package to augment the ambient [`\"dom\"`](https://www.typescriptlang.org/docs/handbook/compiler-options.html#compiler-options) type definitions with the new definitions for WebGPU.\n\n## API style docs\n\nThis repo also generates typedoc docs here: https://gpuweb.github.io/types\n\n## What are declaration files?\n\nSee the [TypeScript handbook](http://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html).\n\n\n## How can I use them?\n\n### Install\n\n- npm: `npm install --save-dev @webgpu/types`\n- yarn: `yarn add --dev @webgpu/types`\n- pnpm: `pnpm add -D @webgpu/types`\n\nIf you are on TypeScript < 5.1, you will also need to install `@types/dom-webcodecs`\nas a sibling dependency. The version you need depends on the TypeScript version;\nsee the [tests](tests/) for examples.\n\n### Configure\n\nSince this package is outside DefinitelyTyped, the dependency won't be picked up automatically.\nThere are several ways to add a additional TypeScript type definition dependencies to your TypeScript project:\n\n#### TypeScript `tsc` and `tsc`-based bundlers\n\nIn `tsconfig.json`:\n\n```js\n{\n  // ...\n  \"compilerOptions\": {\n    // ...\n    \"types\": [\"@webgpu/types\"]\n  }\n}\n```\n\nOr you can use `typeRoots`:\n\n```js\n{\n  // ...\n  \"compilerOptions\": {\n    // ...\n    \"typeRoots\": [\"./node_modules/@webgpu/types\", \"./node_modules/@types\"]\n  }\n}\n```\n\n#### Inline in TypeScript\n\nThis may work better if your toolchain doesn't read `tsconfig.json`.\n\n```ts\n/// <reference types=\"@webgpu/types\" />\n```\n\n#### Webpack\n\nIf you use Webpack and the options above aren't sufficient (this has not been verified),\nyou may need the following in `webpack.config.js`:\n\n```js\n\"types\": [\"@webgpu/types\"]\n```\n\n#### Others?\n\nPlease contribute a PR to add instructions for other setups or improve existing instructions. :)\n\n\n## How to update these types\n\n- Make sure the submodule is checked out: `git submodule update --init`\n- Pull `gpuweb` changes: `pushd gpuweb && git checkout main && git pull && popd`\n- Install dependencies: `npm ci`\n- Bug workaround: paste the `copies.bs` contents in place of its include in `index.bs` (generator doesn't support includes).\n- Generate `generated/index.d.ts`: `npm run generate`\n- Open a diff between `generated/index.d.ts` and `dist/index.d.ts`.\n    The generated file is tracked by Git so you can see what has changed.\n    Update the latter according to changes from the former.\n    Note the `generated/` and `dist/` files are not the same.\n    See below for intentional differences.\n- Format the result: `npm run format`\n\n### Intentional differences between generator output and final result\n\nMost or all of these should be fixed in the generator over time.\n\n- `Array` changed to `Iterable` for WebIDL `sequence`s in argument positions (but not in return positions).\n- `any` changed to `object` for WebIDL `object`.\n- `| SharedArrayBuffer` added for `[AllowShared] BufferSource`.\n\nThe following differences are TODO: should be changed in the final result.\n\n- Deprecated items should be removed.\n\nThe following differences will remain.\n\n- `onuncapturederror` strongly typed.\n- `getContext` definitions.\n- `GPUExtent3DStrict` and `GPUOrigin2DStrict`.\n\n### Publish a new npm package version\n\n(only for people who have npm publish access)\n\n* One line cmd to copy-n-paste (for ssh git user, and you'd better know what you are doing, if it failed at certain steps, you might need to clean up git tags before trying again)\n  - `git checkout main && git pull git@github.com:gpuweb/types.git main && git submodule update --init && npm version patch && git push git@github.com:gpuweb/types.git main --tags && npm publish`\n* Separate steps (better for publishing for the first time)\n  * Make sure you are in the upstream repo, not your forked one. And make sure you are synced to latest commit intended for publish\n    - `git checkout main`\n    - `git pull https://github.com/gpuweb/types.git main`\n      - (If you are using HTTPS regularly. You can use remote names like `origin`, just make sure you are referring to the right repo)\n    - `git submodule update --init`\n  * Create the version tag and commit, and push\n    - `npm version patch`\n    - `git push https://github.com/gpuweb/types.git main --tags`\n  * publish the package\n    - `npm publish --otp=<code>`\n      - Replace `<code>` with the one-time password from your authenticator, since two-factors authentication is required to publish.\n      - If you are doing for the first time, you will do `npm adduser` first and it will guide you through adding the npm account.\n\n"
+        "text": "# Typescript Type Definitions for WebGPU\n\nThis package defines Typescript types (`.d.ts`) for the upcoming [WebGPU standard](https://github.com/gpuweb/gpuweb/wiki/Implementation-Status).\n\nUse this package to augment the ambient [`\"dom\"`](https://www.typescriptlang.org/docs/handbook/compiler-options.html#compiler-options) type definitions with the new definitions for WebGPU.\n\n## API style docs\n\nThis repo also generates typedoc docs here: https://gpuweb.github.io/types\n\n## What are declaration files?\n\nSee the [TypeScript handbook](http://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html).\n\n\n## How can I use them?\n\n### Install\n\n- npm: `npm install --save-dev @webgpu/types`\n- yarn: `yarn add --dev @webgpu/types`\n- pnpm: `pnpm add -D @webgpu/types`\n\nIf you are on TypeScript < 5.1, you will also need to install `@types/dom-webcodecs`\nas a sibling dependency. The version you need depends on the TypeScript version;\nsee the [tests](tests/) for examples.\n\n### Configure\n\nSince this package is outside DefinitelyTyped, the dependency won't be picked up automatically.\nThere are several ways to add a additional TypeScript type definition dependencies to your TypeScript project:\n\n#### TypeScript `tsc` and `tsc`-based bundlers\n\nIn `tsconfig.json`:\n\n```js\n{\n  // ...\n  \"compilerOptions\": {\n    // ...\n    \"types\": [\"@webgpu/types\"]\n  }\n}\n```\n\nOr you can use `typeRoots`:\n\n```js\n{\n  // ...\n  \"compilerOptions\": {\n    // ...\n    \"typeRoots\": [\"./node_modules/@webgpu/types\", \"./node_modules/@types\"]\n  }\n}\n```\n\n#### Inline in TypeScript\n\nThis may work better if your toolchain doesn't read `tsconfig.json`.\n\n```ts\n/// <reference types=\"@webgpu/types\" />\n```\n\n#### Webpack\n\nIf you use Webpack and the options above aren't sufficient (this has not been verified),\nyou may need the following in `webpack.config.js`:\n\n```js\n\"types\": [\"@webgpu/types\"]\n```\n\n#### Others?\n\nPlease contribute a PR to add instructions for other setups or improve existing instructions. :)\n\n\n## How to update these types\n\n- Make sure the submodule is checked out: `git submodule update --init`\n- Pull `gpuweb` changes: `pushd gpuweb && git checkout main && git pull && popd`\n- Install dependencies: `npm ci`\n- Bug workaround: paste the `copies.bs` contents in place of its include in `index.bs` (generator doesn't support includes).\n- Generate `generated/index.d.ts`: `npm run generate`\n- Open a diff between `generated/index.d.ts` and `dist/index.d.ts`.\n    The generated file is tracked by Git so you can see what has changed.\n    Update the latter according to changes from the former.\n    Note the `generated/` and `dist/` files are not the same.\n    See below for intentional differences.\n- Format the result: `npm run format`\n\n### Intentional differences between generator output and final result\n\nMost or all of these should be fixed in the generator over time.\n\n- `Array` changed to `Iterable` for WebIDL `sequence`s in argument positions (but not in return positions).\n- `any` changed to `object` for WebIDL `object`.\n- `| SharedArrayBuffer` added for `[AllowShared] BufferSource`.\n- `| null` changed to `| null | undefined` for WebIDL nullable items (`T?`).\n\nThe following differences are TODO: should be changed in the final result.\n\n- Deprecated items should be removed.\n\nThe following differences will remain.\n\n- `onuncapturederror` strongly typed.\n- `getContext` definitions.\n- `GPUExtent3DStrict` and `GPUOrigin2DStrict`.\n\n### Publish a new npm package version\n\n(only for people who have npm publish access)\n\n* One line cmd to copy-n-paste (for ssh git user, and you'd better know what you are doing, if it failed at certain steps, you might need to clean up git tags before trying again)\n  - `git checkout main && git pull git@github.com:gpuweb/types.git main && git submodule update --init && npm version patch && git push git@github.com:gpuweb/types.git main --tags && npm publish`\n* Separate steps (better for publishing for the first time)\n  * Make sure you are in the upstream repo, not your forked one. And make sure you are synced to latest commit intended for publish\n    - `git checkout main`\n    - `git pull https://github.com/gpuweb/types.git main`\n      - (If you are using HTTPS regularly. You can use remote names like `origin`, just make sure you are referring to the right repo)\n    - `git submodule update --init`\n  * Create the version tag and commit, and push\n    - `npm version patch`\n    - `git push https://github.com/gpuweb/types.git main --tags`\n  * publish the package\n    - `npm publish --otp=<code>`\n      - Replace `<code>` with the one-time password from your authenticator, since two-factors authentication is required to publish.\n      - If you are doing for the first time, you will do `npm adduser` first and it will guide you through adding the npm account.\n\n"
       }
     },
     {
@@ -18347,6 +18348,10 @@
       "isPrivate": false,
       "createdAt": "2023-11-27T19:20:15Z",
       "labels": [
+        {
+          "name": "agenda+",
+          "color": "1D76DB"
+        },
         {
           "name": "bug",
           "color": "d73a4a"
@@ -18411,7 +18416,7 @@
         "body": "As a W3C Community Group, all work and communication within the Privacy\nCG is covered by the\n[W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).\n"
       },
       "readme": {
-        "text": "# Storage Access Headers\n\n## Authors\n\n* Chris Fredrickson (cfredric@chromium.org)\n* Johann Hofmann (johannhof@chromium.org)\n\n## Goals\n\n* Enable authenticated embedded functionality with lower latency/overhead when possible, by supporting HTTP request response headers related to the Storage Access API.\n  * Provide a way to use existing permission grants during document load: https://github.com/privacycg/storage-access/issues/170.\n  * Provide a way for the User Agent to indicate whether a network request comes from a context that has opted-in/activated storage access already: https://github.com/privacycg/storage-access/issues/130.\n  * Provide a way for the User Agent to indicate whether a network request comes from a context that has `storage-access` permission already (but has not opted in yet).\n  * Provide a way for the server to indicate that the User Agent should retry the request after opting into storage access, if possible.\n* Ensure that security and privacy are not regressed as a result of this proposal.\n\n## Non-goals\n\n* Providing a non-JavaScript method of _requesting_ the `storage-access` permission is not a goal.\n\n## Introduction\n\nThe [Storage Access API](https://github.com/privacycg/storage-access) supports \"authenticated embeds\" by providing a way to opt in to accessing unpartitioned cookies in an embedded context. The API currently requires an explicit call to a JavaScript API to 1) potentially prompt the user for permission, and 2) explicitly indicate the embedded resource's interest in using unpartitioned cookies (as a protection against CSRF attacks by an embedder).\n\nThis requirement is unacceptable for some authenticated embed use cases, and imposes a cost on even the well-suited use cases after they have obtained permission:\n* Use of the Storage Access API may currently require multiple network round trips and multiple resource reloads before the embed can work as expected.\n* Embedded resources currently must execute JavaScript in order to benefit from this API. This effectively means that the embedded resource must be an iframe, or must be a subresource of an embedded iframe.\n\nThese costs and constraints can be avoided by supporting a few new headers.\n\n## Example\n\n### Embedded `<iframe>`\n\n#### Status quo\n\nAs an illustrative example, consider a calendar widget on calendar.com, embedded in example.com. During the user's first-ever visit to the example.com page, the flow of events is the following:\n\n1. The user agent requests the calendar widget's content.\n   * The fetch of this content is uncredentialed, as the user agent is blocking third-party cookies by default (by assumption). As a result, the server must respond with a placeholder.\n1. The user agent loads the placeholder widget, without giving access to unpartitioned cookies.\n1. The widget placeholder calls `document.requestStorageAccess()`.\n   * Note: this proposal does not include any changes to the existing requirements for obtaining permission.\n1. The widget refreshes itself, after `storage-access` permission has been granted.\n   * The fetch associated with this refresh is credentialed, per the [Storage Access API spec](https://privacycg.github.io/storage-access/#navigation), so the server responds with the \"real\" widget.\n1. The user agent loads the widget, this time with access to unpartitioned cookies.\n   * After this step, the widget can finally work as expected.\n\nThis is working as intended, since the user agent may choose to delegate the decision to grant `storage-access` permission to the user, and the user ought to have the benefit of context for that decision.\n\nHowever, consider a subsequent visit to the example.com page, after the `storage-access` permission has already been granted by the user or user agent. Without this proposal, the flow on the subsequent visit looks exactly the same as the flow on the first visit. However, the user does not need to grant permission this time, since they have already granted permission. This means that the latency and network traffic incurred by the first iframe load, the `document.requestStorageAccess()` script execution, and the subsequent reload are entirely unnecessary.\n\n#### New flow\n\nInstead, we can imagine a different flow, where the user agent recognizes that the calendar widget already has `storage-access` permission and somehow knows that the widget wants to opt in to using it, so it loads the iframe with access to unpartitioned cookies. This would avoid unnecessary latency and power drain due to network traffic and script execution, leading to a better user experience. So, the flow could be:\n\n```mermaid\nsequenceDiagram\n  Client->>Server: Sec-Fetch-Storage-Access: inactive\n  Server-->>Client: Activate-Storage-Access: retry<br/><fallback content>\n\n  note left of Client: Client activates the<br/>storage-access permission\n\n  Client->>Server: Sec-Fetch-Storage-Access: active<br/>Cookie: userid=123\n  Server-->>Client: Activate-Storage-Access: load<br/><content>\n\n  note left of Client: Client loads widget<br/>with SAA permission active\n```\n\n1. The user agent requests the calendar widget's content.\n    * This fetch is still uncredentialed, as before.\n    * Since the request is for calendar.com in the context of example.com, and the user has already granted the `storage-access` permission in <calendar.com, example.com> contexts, the fetch includes a `Sec-Fetch-Storage-Access: inactive` header, to indicate that unpartitioned cookie access is available but not in use.\n1. The server responds with a `Activate-Storage-Access: retry; allowed-origin=<origin>` header, to indicate that the resource fetch requires the use of unpartitioned cookies via the `storage-access` permission.\n1. The user agent retries the request, this time including unpartitioned cookies (activating the `storage-access` permission for this fetch).\n1. The server responds with the iframe content. The response includes a `Activate-Storage-Access: load` header, to indicate that the user agent should load the content with the `storage-access` permission activated (i.e. load with unpartitioned cookie access, as if `document.requestStorageAccess()` had been called).\n1. The user agent loads the iframe content with unpartitioned cookie access via the `storage-access` permission.\n    * After this step, the widget can work as expected.\n\nThis flow avoids loading the widget twice, and avoids executing script solely for the `document.requestStorageAccess()` call to activate the existing permission grant. It also avoids the network transmission of the \"placeholder\" version of the widget.\n\nAdditionally, the use of HTTP headers removes the requirement for JavaScript execution. This enables non-iframe resources to take full advantage of existing `storage-access` permission grants.\n\n### Embedded non-`<iframe>`\n\nConsider a document that includes an image (e.g.) which happens to be served by a different (unrelated) site.\n\nAt present, no web platform API allows loading this image via a credentialed fetch in browsers that block third-party cookies by default. So, if the image requires the user's credentials (i.e. unpartitioned cookies), then this is broken.\n\nHowever, if the browser supports the headers described below (and if the user has already granted the `storage-access` permission to the appropriate `<site, site>` pair somehow - e.g. via an iframe at some point in the recent past), then this scenario is supported by the browser as in the following sequence:\n\n```mermaid\nsequenceDiagram\n  note left of Client: Client is loading document...\n\n  note left of Client: Client begins fetching cross-site image\n  Client->>Server: Sec-Fetch-Storage-Access: inactive\n  Server-->>Client: HTTP/1.1 401 Unauthorized<br/>Activate-Storage-Access: retry\n\n  Client->>Server: Sec-Fetch-Storage-Access: active<br/>Cookie: userid=123\n  Server-->>Client: HTTP/1.1 200 OK<br/><image content>\n\n  note left of Client: Client loads image and continues loading document\n```\n\nBrowsers that do not support the proposed headers will still receive the appropriate `401 Unauthorized` response. However, browsers that do support the proposed headers are able to retry the fetch and can send the user's credentials, since the user has already given permission for this (by assumption).\n\n## Proposed headers\n\n### Request headers\n\n```\nSec-Fetch-Storage-Access: <access-status>\n```\nThis is a [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header) (with a [forbidden header name](https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name)), where the `<access-status>` directive is one of the following:\n* `none`: the fetch's context does not have access to unpartitioned cookies, and does not have the `storage-access` permission.\n* `inactive`: the fetch's context has the `storage-access` permission, but has not opted into using it; and does not have unpartitioned cookie access through some other means.\n* `active`: the fetch's context has unpartitioned cookie access.\n\nThe user agent may omit this header on same-site requests, since those requests cannot involve cross-site cookies. The user agent must include this header on cross-site requests.\n\nIf the user agent sends `Sec-Fetch-Storage-Access: inactive` on a given network request, it must also include the `Origin` header on that request.\n\n### Response headers\n\n```\nActivate-Storage-Access: retry; allowed-origin=\"https://foo.bar\"\nActivate-Storage-Access: retry; allowed-origin=*\nActivate-Storage-Access: load\n```\nThis is a [structured header](https://datatracker.ietf.org/doc/html/rfc8941) whose value is a [sf-item](https://datatracker.ietf.org/doc/html/rfc8941#section-3.3-3) (specifically a [token](https://datatracker.ietf.org/doc/html/rfc8941#section-3.3.4-3)) which is one of the following:\n* `load`: the server requests that the user agent activate the `storage-access` permission before continuing with the load of the resource.\n* `retry`: the server requests that the user agent activate the `storage-access` permission, then retry the request.\n  * The retried request must include the `Sec-Fetch-Storage-Access: active` header. (The user agent must ignore the token if permission is not already granted or if unpartitioned cookies are already accessible. In other words, the user agent must ignore the token if the previous request did not include the `Sec-Fetch-Storage-Access: inactive` header.)\n  * The `retry` token must be accompanied by the `allowed-origin` [parameter](https://datatracker.ietf.org/doc/html/rfc8941#section-3.1.2-4), which specifies the request initiator that should be allowed to retry the request. (A wildcard parameter, i.e. `allowed-origin=*`, is allowed.) If the request initiator does not match the `allowed-origin` value, the user agent may ignore this header.\n\nIf the request did not include `Sec-Fetch-Storage-Access: inactive` or `Sec-Fetch-Storage-Access: active`, the user agent may ignore this header (both tokens).\n\nIf the response includes this header, the user agent may renew the `storage-access` permission associated with the request context, since this is a clear signal that the embedded site is relying on the permission.\n\nNote: it is tempting to try to use [Critical-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Critical-CH) to retry the request, but this usage would be inconsistent with existing usage and patterns for Critical-CH. The `Activate-Storage-Access: retry; allowed-origin=<origin>` header requests that the user agent _change_ some details about the request before retrying; whereas Critical-CH is designed to allow the server to request more metadata about the request, without modifying it. This proposal therefore does not rely on Critical-CH.\n\n## Key scenarios\n\n### Revisiting a previously-allowed authenticated embed\n\nRelative to the Storage Access API's current specification, this proposal allows the user agent to elide some unnecessary network traffic, resource loads, and script execution when a user repeatedly visits a site with an authenticated embed. This results in a few benefits:\n* Less network usage\n* Less CPU usage (therefore lower power consumption)\n* Lower latency until the authenticated embed is usable\n* Avoids jarring UX from potentially noticeable intermediate document loads inside of the embed.\n\n### Preserving Storage Access state across (cross-site) navigation flows\n\nSimilar to the above, sites may utilize navigations to load different content or as mechanisms to authenticate users. For example, a site might want to preserve storage access status in its embeds while the user visits different top-level pages.\n\n### Enabling an authenticated embed that relies on non-iframe subresources in the top-level page\n\nOne ability that this proposal provides is the ability for a non-iframe resource to opt into using an existing `storage-access` permission (via a header instead of JavaScript).\n\nThat ability would enable use cases like the IIIF ([cultural heritage interoperability](https://github.com/privacycg/storage-access/issues/72)) to function with a relatively minor update: each \"viewer\" (top-level site) needs to include an embedded iframe from the \"publisher\" (embedded site), perhaps on the viewer's homepage, which calls `document.requestStorageAccess()` for the publisher. Once the permission has been granted, any of the viewer's pages can include embedded `<img>` tags from the publisher. The publisher server can then use the `Activate-Storage-Access: retry; allowed-origin=<origin>` mechanism to activate the user's existing `storage-access` permission grant without the use of JavaScript, and ask the user agent to reissue the subresource request with the appropriate cross-site auth credentials.\n\nAn important caveat: this proposal does not eliminate the need for a prior top-level interaction on the publisher (embedded) site, nor does it eliminate the need for _some_ call to `document.requestStorageAccess()` from a cross-site embedded iframe (or some other way to request the `storage-access` permission). Another proposal like [Top-Level Storage Access API Extension](https://github.com/bvandersloot-mozilla/top-level-storage-access) could help bridge that gap.\n\n## Browser interoperability\n\nUser agents that do not support these headers, or do not wish to allow header-based opt-in, do not have to send the `Sec-Fetch-Storage-Access` header at all; servers should interpret this as equivalent to `Sec-Fetch-Storage-Access: none`, in which case scripts will need to call `document.requestStorageAccess()` before cross-site cookies can become available. The Storage Access API does not rely on support for these headers.\n\nImportantly, this proposal does not introduce a new mechanism to _request_ storage access when an embed has not previously obtained permission, and so website developers must still implement the existing JS-based permission request flow (usually via `document.requestStorageAccess()`) to handle cases where storage access is not granted (or the browser does not reveal whether it is granted).\n\n## Security considerations\n\n### Opt-In signal\n\nThe biggest security concerns to keep in mind for this proposal are those laid out in https://github.com/privacycg/storage-access/issues/113. Namely: since the Storage Access API makes cross-site cookies available even after those cookies have been blocked by default, it is crucial that the Storage Access API **not** preserve the security concerns traditionally associated with cross-site cookies, like CSRF.\n\nThe principal way that the Storage Access API addresses these security concerns is by requiring an embedded cross-site resource (e.g. an iframe) to explicitly opt in to accessing cross-site cookies by calling a JavaScript API. This proposal continues in that vein by requiring embedded cross-site resources (or their servers) to explicitly opt-in to accessing cross-site cookies (by supplying an HTTP response header).\n\n### Forbidden header name\n\nThis proposal uses a new forbidden name for the `Sec-Fetch-Storage-Access` header to prevent programmatic modification of the header value. This is primarily for reasons of coherence, rather than security, but there is a security reason to make this choice. If a script could modify the value of the header, it could lie to a server about the state of the `storage-access` permission in the requesting context and indicate that the state is `active`, even if the requesting context has not opted in to using the permission grant. This could mislead the server into inferring that the request context is more trusted/safe than it actually is (e.g., perhaps the requesting context has intentionally _not_ opted into accessing its cross-site cookies because it cannot conclude it's safe to do so). This could lead the server to make different decisions than it would have if it had received the correct header value (`none` or `inactive`). Thus the value of this header ought to be trustworthy, so it ought to be up to the user agent to set it.\n\n## Privacy considerations\n\nThis proposal simplifies some ways in which developers can use an API that allows access to cross-site data. However, it does not meaningfully change the privacy characteristics of the Storage Access API: sites are still able to ask for the ability to access cross-site cookies; user agents are still able to handle those requests how they see fit.\n\nThe new header does expose some user-specific state in network requests which was not previously available there, namely the state of the `storage-access` permission. However, this information is not considered privacy-sensitive, for a few reasons:\n* The site could have learned this information anyway by calling `navigator.permissions.query({name: 'storage-access')` and/or `document.requestStorageAccess()` in an embedded iframe.\n    * Note that this information is now exposed to other kinds of embedded subresources that it wasn't previously available to, however.\n* The `Sec-Fetch-Storage-Access` header's value is always none unless the relevant context would be able to access unpartitioned state after calling `document.requestStorageAccess()` without triggering a user prompt. Thus, in the cases where the `Sec-Fetch-Storage-Access` header conveys interesting information, the site in question already has the ability to access unpartitioned state. So, there's no privacy benefit to omitting the `Sec-Fetch-Storage-Access` header altogether when it's not explicitly requested by `Activate-Storage-Access: retry; allowed-origin=<origin>`.\n    * Since the header only has one valid non-`active` and non-`inactive` state (namely `none`), there's no privacy benefit to omitting the `Sec-Fetch-Storage-Access` header when its value is `none`.\n\n## Deployment considerations\n\nServers that begin using the `Activate-Storage-Access` header should include `Sec-Fetch-Storage-Access` in the response's [Vary](https://www.rfc-editor.org/rfc/rfc9110#field.vary) header. This prevents user agents from receiving fallback content for requests that included `Sec-Fetch-Storage-Access: active`.\n\n## Alternative designs\n### Preflight requests\n\nIt is tempting to design a preflight mechanism, so that non-idempotent (or perhaps non-[simple](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests)) cross-site requests can avoid ambiguity (e.g. the server would support the request if it had just included cookies, so the server responds with the `Activate-Storage-Access: retry; allowed-origin=<origin>` header). However, this idea misinterprets the purpose of CORS preflights.\n\nCORS preflights are a security mechanism, to ensure that servers which *don't* support CORS (and likely don't expect cross-origin PUT/DELETE/etc. requests) don't receive those \"dangerous\" requests. In other words, the preflights play the role of a handshake, after which the server has shown that it knows how to handle non-simple cross-origin requests. (Beyond the rollout of CORS and upgrades of old non-CORS-aware servers, CORS preflights still have a role in ensuring that any cross-origin request with a custom header gets preflighted for security reasons, as well.) This is important because before CORS existed, the Same Origin Policy forbade user agents from sending non-simple cross-origin requests; so servers might reasonably assume that any non-simple request they receive must be same-origin. After CORS became available, non-simple cross-origin requests were allowed by the SOP, which breaks the server's assumption *unless* those non-simple cross-origin requests are preceded by a preflight \"handshake\", which older servers wouldn't support (and therefore the request would fail in a safe way).\n\nHowever, the `Sec-Fetch-Storage-Access` and `Activate-Storage-Access` headers do not enable the user agent to send novel, risky requests in the same way that CORS did. The `Sec-Fetch-Storage-Access` header is purely informational; it doesn't change the properties of the request. The `Activate-Storage-Access` header allows re-inclusion of cross-site cookies, which *does* have security implications - but since not all major browsers have made third-party cookies unavailable by default, servers are already written under the assumption that incoming requests may carry cross-site cookies. Therefore, no preceding preflight \"handshake\" is needed as a security protection.\n\n### CORS integration\n\nIt is tempting to design this functionality such that it piggy-backs and/or integrates with CORS directly, since CORS intuitively feels like it is meant to address a similar problem of enabling cross-origin functionality. However, this would be undesirable for a few reasons:\n\n* If CORS (and the relevant SAA permission, of course) were a \"sufficient\" condition for attaching unpartitioned cookies...\n  * Then this would allow the top-level site to attack the embedded site by sending (CORS-enabled) credentialed requests to arbitrary endpoints on the embedded site, without requiring any opt-in from the embedded site before it received those requests. This would make CSRF attacks against the embedded site more feasible. This is undesirable for security reasons.\n* If CORS were *required* for the user agent to attach unpartitioned cookies to the request...\n  * Then this would mean the embedded site would be required to allow the top-level site to read the bytes of its responses and response headers, just so that the user agent would include cookies when fetching the embedded resource. This is a more powerful capability than simply attaching unpartitioned cookies, so this would expose the embedded site to unnecessary attack vectors from the top-level site. This is undesirable for security reasons.\n  * This would also mean that in order to fix an embedded widget on some page, the top-level site must perform some action to enable CORS; the embedded site alone would be unable to update the page and fix the widget. This is undesirable from a developer usability / composability standpoint.\n\nTherefore, CORS ought to be neither necessary nor sufficient for attaching unpartitioned cookies to a cross-site request. We will therefore design the unpartitioned-cookies-opt-in mechanism as a new thing, completely indepedent from CORS.\n\n## Stakeholder feedback/opposition\n\n* Chrome: Implementing\n* Firefox: TBD\n* Safari: TBD\n* Edge: TBD\n* Web developers: Positive ([feature request](https://github.com/privacycg/storage-access/issues/170), [feature request](https://github.com/privacycg/storage-access/issues/130), [feature request](https://github.com/privacycg/storage-access/issues/189))\n\n## References & acknowledgements\n\nThe existing Storage Access API specification and discussions in its GitHub issues heavily inspired this document.\n"
+        "text": "# Storage Access Headers\n\n## Authors\n\n* Chris Fredrickson (cfredric@chromium.org)\n* Johann Hofmann (johannhof@chromium.org)\n\n## Goals\n\n* Expose metadata about the availability of unpartitioned cookies in a given network request.\n* Enable authenticated embedded functionality with lower latency/overhead when possible, by supporting HTTP request response headers related to the Storage Access API.\n  * Provide a way to use existing permission grants during document load: https://github.com/privacycg/storage-access/issues/170.\n  * Provide a way for the User Agent to indicate whether a network request comes from a context that has opted-in/activated storage access already: https://github.com/privacycg/storage-access/issues/130.\n  * Provide a way for the User Agent to indicate whether a network request comes from a context that has `storage-access` permission already (but has not opted in yet).\n  * Provide a way for the server to indicate that the User Agent should retry the request after opting into storage access, if possible.\n* Ensure that security and privacy are not regressed as a result of this proposal.\n\n## Non-goals\n\n* Providing a non-JavaScript method of _requesting_ the `storage-access` permission is not a goal.\n* Exposing metadata about the partitionedness of non-cookie storage is not a goal.\n* Exposing metadata about whether [partitioned cookies](https://github.com/privacycg/CHIPS) are available (and if so, what the partition key is) is not a goal.\n    * For this use case, see https://github.com/privacycg/storage-partitioning/issues/32 and in particular https://github.com/w3c/webappsec-fetch-metadata/pull/89.\n\n## Introduction\n\nThe [Storage Access API](https://github.com/privacycg/storage-access) supports \"authenticated embeds\" by providing a way to opt in to accessing unpartitioned cookies in an embedded context. The API currently requires an explicit call to a JavaScript API to 1) potentially prompt the user for permission, and 2) explicitly indicate the embedded resource's interest in using unpartitioned cookies (as a protection against CSRF attacks by an embedder).\n\nThis requirement is unacceptable for some authenticated embed use cases, and imposes a cost on even the well-suited use cases after they have obtained permission:\n* Use of the Storage Access API may currently require multiple network round trips and multiple resource reloads before the embed can work as expected.\n* Embedded resources currently must execute JavaScript in order to benefit from this API. This effectively means that the embedded resource must be an iframe, or must be a subresource of an embedded iframe.\n\nThese costs and constraints can be avoided by supporting a few new headers.\n\n## Example\n\n### Embedded `<iframe>`\n\n#### Status quo\n\nAs an illustrative example, consider a calendar widget on calendar.com, embedded in example.com. During the user's first-ever visit to the example.com page, the flow of events is the following:\n\n1. The user agent requests the calendar widget's content.\n   * The fetch of this content is uncredentialed, as the user agent is blocking third-party cookies by default (by assumption). As a result, the server must respond with a placeholder.\n1. The user agent loads the placeholder widget, without giving access to unpartitioned cookies.\n1. The widget placeholder calls `document.requestStorageAccess()`.\n   * Note: this proposal does not include any changes to the existing requirements for obtaining permission.\n1. The widget refreshes itself, after `storage-access` permission has been granted.\n   * The fetch associated with this refresh is credentialed, per the [Storage Access API spec](https://privacycg.github.io/storage-access/#navigation), so the server responds with the \"real\" widget.\n1. The user agent loads the widget, this time with access to unpartitioned cookies.\n   * After this step, the widget can finally work as expected.\n\nThis is working as intended, since the user agent may choose to delegate the decision to grant `storage-access` permission to the user, and the user ought to have the benefit of context for that decision.\n\nHowever, consider a subsequent visit to the example.com page, after the `storage-access` permission has already been granted by the user or user agent. Without this proposal, the flow on the subsequent visit looks exactly the same as the flow on the first visit. However, the user does not need to grant permission this time, since they have already granted permission. This means that the latency and network traffic incurred by the first iframe load, the `document.requestStorageAccess()` script execution, and the subsequent reload are entirely unnecessary.\n\n#### New flow\n\nInstead, we can imagine a different flow, where the user agent recognizes that the calendar widget already has `storage-access` permission and somehow knows that the widget wants to opt in to using it, so it loads the iframe with access to unpartitioned cookies. This would avoid unnecessary latency and power drain due to network traffic and script execution, leading to a better user experience. So, the flow could be:\n\n```mermaid\nsequenceDiagram\n  Client->>Server: Sec-Fetch-Storage-Access: inactive\n  Server-->>Client: Activate-Storage-Access: retry<br/><fallback content>\n\n  note left of Client: Client activates the<br/>storage-access permission\n\n  Client->>Server: Sec-Fetch-Storage-Access: active<br/>Cookie: userid=123\n  Server-->>Client: Activate-Storage-Access: load<br/><content>\n\n  note left of Client: Client loads widget<br/>with SAA permission active\n```\n\n1. The user agent requests the calendar widget's content.\n    * This fetch is still uncredentialed, as before.\n    * Since the request is for calendar.com in the context of example.com, and the user has already granted the `storage-access` permission in <calendar.com, example.com> contexts, the fetch includes a `Sec-Fetch-Storage-Access: inactive` header, to indicate that unpartitioned cookie access is available but not in use.\n1. The server responds with a `Activate-Storage-Access: retry; allowed-origin=<origin>` header, to indicate that the resource fetch requires the use of unpartitioned cookies via the `storage-access` permission.\n1. The user agent retries the request, this time including unpartitioned cookies (activating the `storage-access` permission for this fetch).\n1. The server responds with the iframe content. The response includes a `Activate-Storage-Access: load` header, to indicate that the user agent should load the content with the `storage-access` permission activated (i.e. load with unpartitioned cookie access, as if `document.requestStorageAccess()` had been called).\n1. The user agent loads the iframe content with unpartitioned cookie access via the `storage-access` permission.\n    * After this step, the widget can work as expected.\n\nThis flow avoids loading the widget twice, and avoids executing script solely for the `document.requestStorageAccess()` call to activate the existing permission grant. It also avoids the network transmission of the \"placeholder\" version of the widget.\n\nAdditionally, the use of HTTP headers removes the requirement for JavaScript execution. This enables non-iframe resources to take full advantage of existing `storage-access` permission grants.\n\n### Embedded non-`<iframe>`\n\nConsider a document that includes an image (e.g.) which happens to be served by a different (unrelated) site.\n\nAt present, no web platform API allows loading this image via a credentialed fetch in browsers that block third-party cookies by default. So, if the image requires the user's credentials (i.e. unpartitioned cookies), then this is broken.\n\nHowever, if the browser supports the headers described below (and if the user has already granted the `storage-access` permission to the appropriate `<site, site>` pair somehow - e.g. via an iframe at some point in the recent past), then this scenario is supported by the browser as in the following sequence:\n\n```mermaid\nsequenceDiagram\n  note left of Client: Client is loading document...\n\n  note left of Client: Client begins fetching cross-site image\n  Client->>Server: Sec-Fetch-Storage-Access: inactive\n  Server-->>Client: HTTP/1.1 401 Unauthorized<br/>Activate-Storage-Access: retry\n\n  Client->>Server: Sec-Fetch-Storage-Access: active<br/>Cookie: userid=123\n  Server-->>Client: HTTP/1.1 200 OK<br/><image content>\n\n  note left of Client: Client loads image and continues loading document\n```\n\nBrowsers that do not support the proposed headers will still receive the appropriate `401 Unauthorized` response. However, browsers that do support the proposed headers are able to retry the fetch and can send the user's credentials, since the user has already given permission for this (by assumption).\n\n## Proposed headers\n\n### Request headers\n\n```\nSec-Fetch-Storage-Access: <access-status>\n```\nThis is a [fetch metadata request header](https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header) (with a [forbidden header name](https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name)), where the `<access-status>` directive is one of the following:\n* `none`: the fetch's context does not have access to unpartitioned cookies, and does not have the `storage-access` permission.\n* `inactive`: the fetch's context has the `storage-access` permission, but has not opted into using it; and does not have unpartitioned cookie access through some other means.\n* `active`: the fetch's context has unpartitioned cookie access.\n\nThe user agent may omit this header on same-site requests, since those requests cannot involve cross-site cookies. The user agent must include this header on cross-site requests.\n\nIf the user agent sends `Sec-Fetch-Storage-Access: inactive` on a given network request, it must also include the `Origin` header on that request.\n\n### Response headers\n\n```\nActivate-Storage-Access: retry; allowed-origin=\"https://foo.bar\"\nActivate-Storage-Access: retry; allowed-origin=*\nActivate-Storage-Access: load\n```\nThis is a [structured header](https://datatracker.ietf.org/doc/html/rfc8941) whose value is a [sf-item](https://datatracker.ietf.org/doc/html/rfc8941#section-3.3-3) (specifically a [token](https://datatracker.ietf.org/doc/html/rfc8941#section-3.3.4-3)) which is one of the following:\n* `load`: the server requests that the user agent activate the `storage-access` permission before continuing with the load of the resource.\n* `retry`: the server requests that the user agent activate the `storage-access` permission, then retry the request.\n  * The retried request must include the `Sec-Fetch-Storage-Access: active` header. (The user agent must ignore the token if permission is not already granted or if unpartitioned cookies are already accessible. In other words, the user agent must ignore the token if the previous request did not include the `Sec-Fetch-Storage-Access: inactive` header.)\n  * The `retry` token must be accompanied by the `allowed-origin` [parameter](https://datatracker.ietf.org/doc/html/rfc8941#section-3.1.2-4), which specifies the request initiator that should be allowed to retry the request. (A wildcard parameter, i.e. `allowed-origin=*`, is allowed.) If the request initiator does not match the `allowed-origin` value, the user agent may ignore this header.\n\nIf the request did not include `Sec-Fetch-Storage-Access: inactive` or `Sec-Fetch-Storage-Access: active`, the user agent may ignore this header (both tokens).\n\nIf the response includes this header, the user agent may renew the `storage-access` permission associated with the request context, since this is a clear signal that the embedded site is relying on the permission.\n\nNote: it is tempting to try to use [Critical-CH](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Critical-CH) to retry the request, but this usage would be inconsistent with existing usage and patterns for Critical-CH. The `Activate-Storage-Access: retry; allowed-origin=<origin>` header requests that the user agent _change_ some details about the request before retrying; whereas Critical-CH is designed to allow the server to request more metadata about the request, without modifying it. This proposal therefore does not rely on Critical-CH.\n\n## Key scenarios\n\n### Revisiting a previously-allowed authenticated embed\n\nRelative to the Storage Access API's current specification, this proposal allows the user agent to elide some unnecessary network traffic, resource loads, and script execution when a user repeatedly visits a site with an authenticated embed. This results in a few benefits:\n* Less network usage\n* Less CPU usage (therefore lower power consumption)\n* Lower latency until the authenticated embed is usable\n* Avoids jarring UX from potentially noticeable intermediate document loads inside of the embed.\n\n### Preserving Storage Access state across (cross-site) navigation flows\n\nSimilar to the above, sites may utilize navigations to load different content or as mechanisms to authenticate users. For example, a site might want to preserve storage access status in its embeds while the user visits different top-level pages.\n\n### Enabling an authenticated embed that relies on non-iframe subresources in the top-level page\n\nOne ability that this proposal provides is the ability for a non-iframe resource to opt into using an existing `storage-access` permission (via a header instead of JavaScript).\n\nThat ability would enable use cases like the IIIF ([cultural heritage interoperability](https://github.com/privacycg/storage-access/issues/72)) to function with a relatively minor update: each \"viewer\" (top-level site) needs to include an embedded iframe from the \"publisher\" (embedded site), perhaps on the viewer's homepage, which calls `document.requestStorageAccess()` for the publisher. Once the permission has been granted, any of the viewer's pages can include embedded `<img>` tags from the publisher. The publisher server can then use the `Activate-Storage-Access: retry; allowed-origin=<origin>` mechanism to activate the user's existing `storage-access` permission grant without the use of JavaScript, and ask the user agent to reissue the subresource request with the appropriate cross-site auth credentials.\n\nAn important caveat: this proposal does not eliminate the need for a prior top-level interaction on the publisher (embedded) site, nor does it eliminate the need for _some_ call to `document.requestStorageAccess()` from a cross-site embedded iframe (or some other way to request the `storage-access` permission). Another proposal like [Top-Level Storage Access API Extension](https://github.com/bvandersloot-mozilla/top-level-storage-access) could help bridge that gap.\n\n## Browser interoperability\n\nUser agents that do not support these headers, or do not wish to allow header-based opt-in, do not have to send the `Sec-Fetch-Storage-Access` header at all; servers should interpret this as equivalent to `Sec-Fetch-Storage-Access: none`, in which case scripts will need to call `document.requestStorageAccess()` before cross-site cookies can become available. The Storage Access API does not rely on support for these headers.\n\nImportantly, this proposal does not introduce a new mechanism to _request_ storage access when an embed has not previously obtained permission, and so website developers must still implement the existing JS-based permission request flow (usually via `document.requestStorageAccess()`) to handle cases where storage access is not granted (or the browser does not reveal whether it is granted).\n\n## Security considerations\n\n### Opt-In signal\n\nThe biggest security concerns to keep in mind for this proposal are those laid out in https://github.com/privacycg/storage-access/issues/113. Namely: since the Storage Access API makes cross-site cookies available even after those cookies have been blocked by default, it is crucial that the Storage Access API **not** preserve the security concerns traditionally associated with cross-site cookies, like CSRF.\n\nThe principal way that the Storage Access API addresses these security concerns is by requiring an embedded cross-site resource (e.g. an iframe) to explicitly opt in to accessing cross-site cookies by calling a JavaScript API. This proposal continues in that vein by requiring embedded cross-site resources (or their servers) to explicitly opt-in to accessing cross-site cookies (by supplying an HTTP response header).\n\n### Forbidden header name\n\nThis proposal uses a new forbidden name for the `Sec-Fetch-Storage-Access` header to prevent programmatic modification of the header value. This is primarily for reasons of coherence, rather than security, but there is a security reason to make this choice. If a script could modify the value of the header, it could lie to a server about the state of the `storage-access` permission in the requesting context and indicate that the state is `active`, even if the requesting context has not opted in to using the permission grant. This could mislead the server into inferring that the request context is more trusted/safe than it actually is (e.g., perhaps the requesting context has intentionally _not_ opted into accessing its cross-site cookies because it cannot conclude it's safe to do so). This could lead the server to make different decisions than it would have if it had received the correct header value (`none` or `inactive`). Thus the value of this header ought to be trustworthy, so it ought to be up to the user agent to set it.\n\n## Privacy considerations\n\nThis proposal simplifies some ways in which developers can use an API that allows access to cross-site data. However, it does not meaningfully change the privacy characteristics of the Storage Access API: sites are still able to ask for the ability to access cross-site cookies; user agents are still able to handle those requests how they see fit.\n\nThe new header does expose some user-specific state in network requests which was not previously available there, namely the state of the `storage-access` permission. However, this information is not considered privacy-sensitive, for a few reasons:\n* The site could have learned this information anyway by calling `navigator.permissions.query({name: 'storage-access')` and/or `document.requestStorageAccess()` in an embedded iframe.\n    * Note that this information is now exposed to other kinds of embedded subresources that it wasn't previously available to, however.\n* The `Sec-Fetch-Storage-Access` header's value is always none unless the relevant context would be able to access unpartitioned state after calling `document.requestStorageAccess()` without triggering a user prompt. Thus, in the cases where the `Sec-Fetch-Storage-Access` header conveys interesting information, the site in question already has the ability to access unpartitioned state. So, there's no privacy benefit to omitting the `Sec-Fetch-Storage-Access` header altogether when it's not explicitly requested by `Activate-Storage-Access: retry; allowed-origin=<origin>`.\n    * Since the header only has one valid non-`active` and non-`inactive` state (namely `none`), there's no privacy benefit to omitting the `Sec-Fetch-Storage-Access` header when its value is `none`.\n\n## Deployment considerations\n\nServers that begin using the `Activate-Storage-Access` header should include `Sec-Fetch-Storage-Access` in the response's [Vary](https://www.rfc-editor.org/rfc/rfc9110#field.vary) header. This prevents user agents from receiving fallback content for requests that included `Sec-Fetch-Storage-Access: active`.\n\n## Alternative designs\n### Preflight requests\n\nIt is tempting to design a preflight mechanism, so that non-idempotent (or perhaps non-[simple](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests)) cross-site requests can avoid ambiguity (e.g. the server would support the request if it had just included cookies, so the server responds with the `Activate-Storage-Access: retry; allowed-origin=<origin>` header). However, this idea misinterprets the purpose of CORS preflights.\n\nCORS preflights are a security mechanism, to ensure that servers which *don't* support CORS (and likely don't expect cross-origin PUT/DELETE/etc. requests) don't receive those \"dangerous\" requests. In other words, the preflights play the role of a handshake, after which the server has shown that it knows how to handle non-simple cross-origin requests. (Beyond the rollout of CORS and upgrades of old non-CORS-aware servers, CORS preflights still have a role in ensuring that any cross-origin request with a custom header gets preflighted for security reasons, as well.) This is important because before CORS existed, the Same Origin Policy forbade user agents from sending non-simple cross-origin requests; so servers might reasonably assume that any non-simple request they receive must be same-origin. After CORS became available, non-simple cross-origin requests were allowed by the SOP, which breaks the server's assumption *unless* those non-simple cross-origin requests are preceded by a preflight \"handshake\", which older servers wouldn't support (and therefore the request would fail in a safe way).\n\nHowever, the `Sec-Fetch-Storage-Access` and `Activate-Storage-Access` headers do not enable the user agent to send novel, risky requests in the same way that CORS did. The `Sec-Fetch-Storage-Access` header is purely informational; it doesn't change the properties of the request. The `Activate-Storage-Access` header allows re-inclusion of cross-site cookies, which *does* have security implications - but since not all major browsers have made third-party cookies unavailable by default, servers are already written under the assumption that incoming requests may carry cross-site cookies. Therefore, no preceding preflight \"handshake\" is needed as a security protection.\n\n### CORS integration\n\nIt is tempting to design this functionality such that it piggy-backs and/or integrates with CORS directly, since CORS intuitively feels like it is meant to address a similar problem of enabling cross-origin functionality. However, this would be undesirable for a few reasons:\n\n* If CORS (and the relevant SAA permission, of course) were a \"sufficient\" condition for attaching unpartitioned cookies...\n  * Then this would allow the top-level site to attack the embedded site by sending (CORS-enabled) credentialed requests to arbitrary endpoints on the embedded site, without requiring any opt-in from the embedded site before it received those requests. This would make CSRF attacks against the embedded site more feasible. This is undesirable for security reasons.\n* If CORS were *required* for the user agent to attach unpartitioned cookies to the request...\n  * Then this would mean the embedded site would be required to allow the top-level site to read the bytes of its responses and response headers, just so that the user agent would include cookies when fetching the embedded resource. This is a more powerful capability than simply attaching unpartitioned cookies, so this would expose the embedded site to unnecessary attack vectors from the top-level site. This is undesirable for security reasons.\n  * This would also mean that in order to fix an embedded widget on some page, the top-level site must perform some action to enable CORS; the embedded site alone would be unable to update the page and fix the widget. This is undesirable from a developer usability / composability standpoint.\n\nTherefore, CORS ought to be neither necessary nor sufficient for attaching unpartitioned cookies to a cross-site request. We will therefore design the unpartitioned-cookies-opt-in mechanism as a new thing, completely indepedent from CORS.\n\n## Stakeholder feedback/opposition\n\n* Chrome: Implementing\n* Firefox: TBD\n* Safari: TBD\n* Edge: TBD\n* Web developers: Positive ([feature request](https://github.com/privacycg/storage-access/issues/170), [feature request](https://github.com/privacycg/storage-access/issues/130), [feature request](https://github.com/privacycg/storage-access/issues/189))\n\n## References & acknowledgements\n\nThe existing Storage Access API specification and discussions in its GitHub issues heavily inspired this document.\n"
       },
       "prpreview": {
         "src_file": "index.bs",
@@ -34932,6 +34937,10 @@
           "name": "css-forms-1",
           "color": "c5def5"
         },
+        {
+          "name": "css-gaps-1",
+          "color": "c5def5"
+        },
         {
           "name": "css-gcpm-3",
           "color": "c5def5"
@@ -44326,6 +44335,151 @@
         "text": "Moved to http://github.com/w3c/editing\n"
       }
     },
+    {
+      "id": "MDEwOlJlcG9zaXRvcnkxMzk4ODYwMTk=",
+      "name": "element-timing",
+      "owner": {
+        "login": "w3c"
+      },
+      "isArchived": false,
+      "homepageUrl": "https://w3c.github.io/element-timing/",
+      "description": "A proposal for an Element Timing specification.",
+      "isPrivate": false,
+      "createdAt": "2018-07-05T18:22:06Z",
+      "labels": [
+        {
+          "name": "a11y-needs-resolution",
+          "color": "ea7472"
+        },
+        {
+          "name": "a11y-tracker",
+          "color": "ea7472"
+        },
+        {
+          "name": "bug",
+          "color": "d73a4a"
+        },
+        {
+          "name": "discuss",
+          "color": "c2e0c6"
+        },
+        {
+          "name": "duplicate",
+          "color": "cfd3d7"
+        },
+        {
+          "name": "enhancement",
+          "color": "a2eeef"
+        },
+        {
+          "name": "good first issue",
+          "color": "7057ff"
+        },
+        {
+          "name": "help wanted",
+          "color": "008672"
+        },
+        {
+          "name": "i18n-needs-resolution",
+          "color": "F9C9FF"
+        },
+        {
+          "name": "i18n-tracker",
+          "color": "F9C9FF"
+        },
+        {
+          "name": "invalid",
+          "color": "e4e669"
+        },
+        {
+          "name": "privacy-needs-resolution",
+          "color": "d4af37"
+        },
+        {
+          "name": "privacy-tracker",
+          "color": "d4af37"
+        },
+        {
+          "name": "question",
+          "color": "d876e3"
+        },
+        {
+          "name": "security-needs-resolution",
+          "color": "ffff00"
+        },
+        {
+          "name": "security-tracker",
+          "color": "ffff00"
+        },
+        {
+          "name": "tag-needs-resolution",
+          "color": "7fff00"
+        },
+        {
+          "name": "tag-tracker",
+          "color": "7fff00"
+        },
+        {
+          "name": "wontfix",
+          "color": "ffffff"
+        }
+      ],
+      "defaultBranch": {
+        "name": "main"
+      },
+      "environments": {
+        "nodes": [
+          {
+            "name": "github-pages"
+          }
+        ]
+      },
+      "branchProtectionRules": {
+        "nodes": [
+          {
+            "pattern": "main",
+            "requiredApprovingReviewCount": null,
+            "requiredStatusCheckContexts": [],
+            "isAdminEnforced": false
+          }
+        ]
+      },
+      "w3cjson": {
+        "text": " {\n    \"group\":      [80485]\n,   \"contacts\":   [\"yoavweiss\"]\n,   \"repo-type\":  \"cg-report\"\n}\n"
+      },
+      "prpreviewjson": {
+        "text": "{\n    \"src_file\": \"index.bs\",\n    \"type\": \"bikeshed\"\n}\n"
+      },
+      "autoPublish": null,
+      "travis": null,
+      "contributing": {
+        "text": "# Web Platform Incubator Community Group\n\nThis repository is being used for work in the W3C Web Platform Incubator Community Group, governed by the [W3C Community License\nAgreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To make substantive contributions,\nyou must join the CG.\n\nIf you are not the sole contributor to a contribution (pull request), please identify all\ncontributors in the pull request comment.\n\nTo add a contributor (other than yourself, that's automatic), mark them one per line as follows:\n\n```\n+@github_username\n```\n\nIf you added a contributor by mistake, you can remove them in a comment with:\n\n```\n-@github_username\n```\n\nIf you are making a pull request on behalf of someone else but you had no part in designing the\nfeature, you can remove yourself with the above syntax.\n\n# Tests\n\nFor normative changes, a corresponding\n[web-platform-tests](https://github.com/web-platform-tests/wpt) PR is highly appreciated. Typically,\nboth PRs will be merged at the same time. Note that a test change that contradicts the spec should\nnot be merged before the corresponding spec change. If testing is not practical, please explain why\nand if appropriate [file a web-platform-tests issue](https://github.com/web-platform-tests/wpt/issues/new)\nto follow up later. Add the `type:untestable` or `type:missing-coverage` label as appropriate.\n"
+      },
+      "license": {
+        "text": "All Reports in this Repository are licensed by Contributors\nunder the\n[W3C Software and Document License](http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document).\n\nContributions to Specifications are made under the\n[W3C CLA](https://www.w3.org/community/about/agreements/cla/).\n\nContributions to Test Suites are made under the\n[W3C 3-clause BSD License](https://www.w3.org/Consortium/Legal/2008/03-bsd-license.html)\n\n"
+      },
+      "codeOfConduct": {
+        "body": "# Code of Conduct\n\nAll documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).\n"
+      },
+      "readme": {
+        "text": "# Element Timing: Explainer\n\nThe **Element Timing** API enables monitoring when developer-specified image elements or groups of text nodes are displayed on screen.\nThe way text nodes are grouped is described below.\n\n\n### Objectives\n\n1.  Inform developers when specific elements are first displayed on the screen.\nWe support the following types of images: \\<img\\>, \\<image\\> inside \\<svg\\>, and background-images.\nWe also support observing certain groups of text nodes. Web developers can better understand which are the critical images and text of their sites, so after annotating them the browser can provide timing information about those.\nThis image and text converage means that the majority of web content can be timed via this API.\n1.  Enable analytics providers to measure display time of key images or text, without explicit opt in from web developers.\nIn many cases it's not feasible for developers to modify their HTML just to get better performance insights, so it's important to provide basic information even for websites that cannot annotate their elements.\n\n\n### How do we register elements for observation?\n\nAn element can be registered for observation via the `elementtiming` HTML attribute.\nHaving this attribute set will signal the browser to expose render timing information for this element (its source image, background image, and/or text).\nIt should be noted that setting the `elementtiming` attribute does not work retroactively: once an element has loaded and is rendered, setting the attribute will have no effect.\nThus, it is strongly encouraged to set the attribute before the element is added to the document (in HTML, or if set on Javascript, before adding it to the document).\nHaving the attribute implies that:\n\n* If the element is an image, there will be an entry for the image.\n* If the element is affected by (possibly multiple) background images, there will be one entry for each of those background images.\n* If the element is associated to at least one text node, there will be one entry for the group of associated text nodes.\n\n### Image considerations\n\nWe define the <a name=\"image-time\">**image rendering timestamp**</a> as the next paint that occurs after the image has become fully loaded.\nThis is important to distinguish as progressively rendered images may have multiple initial renderings before the image has even been fully received by the user agent.\n\nAllowing third-party origins to measure the time an arbitrary image resource takes to render could expose sensitive information such as whether a user is logged into a website.\nTherefore, for privacy and security reasons, the [image rendering timestamp](#image-time) is only exposed in entries corresponding to resources that pass the [timing allow check](https://w3c.github.io/resource-timing/#dfn-timing-allow-check).\nHowever, to enable a more holistic picture, the rest of the information is exposed for arbitrary images.\n\n### Text considerations\n\nWe say that a text node <a name=\"belong\">**belongs to**</a> the closest block-level [Element](https://dom.spec.whatwg.org/#element) ancestor of the node.\nThis means that an element could have 0 or many associated text nodes with it.\n\nWe say that an element is *text-painted* if at least one text node [belongs to](#belong) and has been painted at least once.\nThus, the <a name=\"text-time\">**text rendering timestamp**</a> of an element is the time when it becomes *text-painted*.\n\nLet the *text rect* of a text node be the display rectangle of that node within the viewport.\nWe define the <a name=\"text-rect\">**text rect**</a> of an element as the smallest rectangle which contains the geometric union of the text rects of all text nodes which [belong to](#belong) the element.\n\n### What information is exposed?\n\nA `PerformanceElementTiming` entry has the following attributes:\n* `name`: for images, \"image-paint\". For text: \"text-paint\".\n* `entryType`: it will always be the string \"element\".\n* `startTime`: equal to `renderTime` if it is nonzero, otherwise equal to `loadTime`.\n* `duration`: always be set to 0.\n* `renderTime`: for images, the [image rendering timestamp](#image-time), or 0 when the resource does not pass the [timing allow check](https://w3c.github.io/resource-timing/#dfn-timing-allow-check). For text, the [text rendering timestamp](#text-time).\n* `loadTime`: for images, the latest between the time when the image resource is loaded and the time when the image resource is associated to the element. For text, 0.\n* `intersectionRect`: for images, the display rectangle of the image within the viewport. For text, the [text rect](#text-rect) of the associated text (only counting text nodes which have been painted at least once).\n* `identifier`: the value of the `elementtiming` attribute of the element.\n* `naturalWidth`: the [intrinsic](https://drafts.csswg.org/css2/conform.html#intrinsic) width of the image. It matches with the corresponding DOM [attribute](https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-naturalwidth) for img. 0 for text.\n* `naturalHeight`: the [intrinsic](https://drafts.csswg.org/css2/conform.html#intrinsic) height of the image. It matches with the corresponding DOM [attribute](https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-naturalheight) for img. 0 for text.\n* `id`: the element's ID.\n* `element`: points to the element. This will be \"null\" if the element is [disconnected](https://dom.spec.whatwg.org/#connected).\n* `url`: for images, the initial URL for the resource request. For text, this will be an empty string.\n\nNote: for background images, the element is the one being affected by the background image style.\n\nSample code:\n\n```javascript\n<img src=\"my_image.jpg\" elementtiming=\"foobar\">\n\nconst observer = new PerformanceObserver((list) => {\n  let perfEntries = list.getEntries().forEach(function(entry) {\n      // Send the information to analytics, or in this case just log it to console.\n      if (entry.identifier === 'foobar') {\n        if (entry.renderTime)\n          console.log(\"My image took \" + entry.renderTime + \" to render!\");\n        else\n          console.log(\"Rendering time not available. Image took \" + entry.loadTime + \" to load!\");\n      }\n   });\n});\nobserver.observe({entryTypes: ['element']});\n```\n\n### Questions\n\n#### What about Shadow DOM?\n\nUnfortunately Shadow DOM elements are not currently supported. \n\n#### What about invisible or occluded elements?\n\nThe entry creation might be affected by _visibility_: for instance, elements are not exposed if the style visibility is set to none, or the opacity is 0.\nHowever, occlusion will not affect entry creation: an entry is seen if the element is there, but hidden by a full-screen pop-up on the page.\n\n#### What are some differences between text and image observation?\n\n* Whereas for images it is OK to care only about those which are associated to a resource, for text that is definitely not the case.\nAn image not associated to a resource will need to be constructed manually and it is uncommon for such an image to be part of the key content of a website.\nNote that we consider inline images (those with data URIs) to have an associated resource, it is just inlined.\nOn the other hand, text is relevant regardless of whether it is associated to a webfont or not.\n\n* Image rendering steps are different from text rendering steps.\nFor images, initial paints may not include all of the image content and may be low quality.\nIt is only once we have fully loaded and decoded the image that we can be certain that the content being displayed is meaningful.\nIn contrast, any text painted is meaningful.\nIt should be noted that this is not perfect because there could be block level elements containing some text that renders quickly and some text that is blocked on webfonts.\nIn this case, for the purposes of Element Timing, the text blocked by webfonts will be completely ignored.\n\n* Text is actually simpler when it comes to security and privacy considerations.\nCross-origin images could reveal a lot of information about users, but text and webfonts embedded in a website do not.\nTherefore, whereas for images we had to consider resources that passed the timing allow check versus resources that did not, for text this distinction is not needed.\n\n"
+      },
+      "prpreview": {
+        "src_file": "index.bs",
+        "type": "bikeshed"
+      },
+      "w3c": {
+        "group": [
+          80485
+        ],
+        "contacts": [
+          "yoavweiss"
+        ],
+        "repo-type": [
+          "cg-report"
+        ]
+      }
+    },
     {
       "id": "MDEwOlJlcG9zaXRvcnkxODI4ODExNQ==",
       "name": "elements-of-html",
@@ -92135,7 +92289,7 @@
         "body": "# Code of Conduct\n\nAll documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).\n"
       },
       "readme": {
-        "text": "\n# Common files for RDF specifications\n\nThis repository is meant to be used as a submodule in multiple repository holding RDF and SPARQL specifications.\n\n## Retrieving group participants\n\nThe `participants.js` Node script can be used to retrieve the list of working group participants. It requires an API Key.\n\n    node participants.js <apikey> wg/rdf-star > participants.html\n"
+        "text": "\n# Common files for RDF specifications\n\nThis repository is meant to be used as a submodule in multiple repository holding RDF and SPARQL specifications.\n\n## Retrieving group participants\n\nThe `participants.js` Node script can be used to retrieve the list of working group participants. It takes  an optional API Key (use empty string to omit).\n\n    node participants.js <apikey> wg/rdf-star > participants.html\n"
       },
       "w3c": {
         "group": [
@@ -108141,7 +108295,7 @@
       "autoPublish": null,
       "travis": null,
       "contributing": {
-        "text": "> [!WARNING]\n> This Community Group's activities are now under the direction of the [W3C Sustainable Web Interest Group](https://www.w3.org/groups/ig/sustainableweb/). This includes the curation of the [Web Sustainability Guidelines](https://w3c.github.io/sustyweb/). Thank you for supporting us as we reached this stage in our journey and we hope you will continue to support our work as it develops at our new home (where you are welcome to get involved).\n\n# Contributing\n\nThis repository is being used for work in the **W3C Sustainable Web Design Community Group**, governed by the [W3C Community License\nAgreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To make substantive contributions,\nyou must join the [CG](https://www.w3.org/community/sustyweb/).\n\n## Overview\n\nThis repository is used to develop content for the Web Sustainability Guidelines (WSGs), as well as any supplementary documents.\n\n## Collaboration\n\nWe welcome content from individuals as well as group efforts and understand that this may pose difficulties for those either unfamiliar with pull requests (on a technical level) or with collaborative efforts (wishing to discuss progress before submitting results). In such cases, members can (if they choose) work with any open format they prefer to collaborate (referring to the specification and its supplements), and submit an issue request containing the URL to the document in question. A moderator (lead or chair) will help translate these requested updates into the living draft specification.\n\n## File Structure\n\nThe structure of the repository has been created to ensure ease of maintenance. The base directory contains all of the compiled files that are public facing such as the specification, supplementary documents, the JSON API, and other materials such as the finalized Test Suite. The \"drafts\" folder contains all of the pre-exported W3C ReSpec sources including the living editions of the [specification](https://w3c.github.io/sustyweb/drafts/), [at-a-glance](https://w3c.github.io/sustyweb/drafts/glance.html), [introduction](https://w3c.github.io/sustyweb/drafts/intro.html), [laws & policies](https://w3c.github.io/sustyweb/drafts/policies.html), [quick reference](https://w3c.github.io/sustyweb/drafts/quickref.html), [STAR](https://w3c.github.io/sustyweb/drafts/star.html), [JSON API](https://w3c.github.io/sustyweb/drafts/guidelines.json) and other supplements such as our draft Test Suite.\n\n```\n\n/ig/charter.html\t\t\t- Working Group Draft Charter\n/drafts/test-suite/\t\t\t- Test Suite & Assets (Source)\n/drafts/checklist.pages\t\t\t- PDF Checklist (Source)\n/drafts/glance.html\t\t\t- At-A-Glance (Source)\n/drafts/guidelines.json\t\t\t- WSG JSON API (Source)\n/drafts/index.html\t\t\t- WSG Specification (Source)\n/drafts/intro.html\t\t\t- Introduction (Source)\n/drafts/policies.html\t\t\t- Laws & Policies (Source)\n/drafts/quickref.html\t\t\t- Quick Reference (Source)\n/drafts/star.html\t\t\t- STAR (Source)\n\n/test-suite/\t\t\t\t- READ ONLY - Test Suite & Assets (Public)\nchecklist.pdf\t\t\t\t- READ ONLY - PDF Checklist (Public)\nglance.html\t\t\t\t- READ ONLY - At-A-Glance (Public)\nguidelines.json\t\t\t\t- READ ONLY - WSG JSON API (Public)\nindex.html\t\t\t\t- READ ONLY - WSG Specification (Public)\nintro.html\t\t\t\t- READ ONLY - Introduction (Public)\noverview.pdf\t\t\t\t- READ ONLY - Project Progress Tracker (Public)\npolicies.html\t\t\t\t- READ ONLY - Laws & Policies (Public)\nquickref.html\t\t\t\t- READ ONLY - Quick Reference (Public)\nstar.html\t\t\t\t- READ ONLY - STAR (Public)\nTPAC_Slides.pdf\t\t\t\t- READ ONLY - W3C TPAC Slides\nWeb_Sustainability_GRI_Impact_est.ipynb\t- READ ONLY - GRI Impact Calculator\n```\n\nWhen you contribute to our repo, you **MUST** only make changes to documents within the \"drafts\" or \"ig\" folders (the sources). Once a PR submission has been reviewed by our group (for quality control purposes), it will either be accepted, or rejected, or further discussion will be required (an issue can be raised for example). Once a PR has been accepted it will be visible within the living draft documents immediately. When enough issues have been collated to warrant a release publication, the necessary documents will be exported through ReSpec into their final HTML form and will replace their static namesakes in the base directory to be versioned as the next public release. Release notes will also be generated by a chair who will verify all submissions before publication.\n\nYou will notice duplication within the content of our work (as the JSON API for example must reflect the specification). This work is not auto-generated so while we appreciate it if individuals choose to make adjustments to all affected files as required, time commitments may not allow for everyone to do so. As such, if you can only update a single document, as part of the approval process, a moderator (lead or chair) will update all necessary documents to ensure parity with your change.\n\n## Pull Requests\n\nIf you would like to contribute towards this specification, our primary method is through Pull Requests (PRs).\n\nPull requests (PRs) should be made against the main branch.\n\nIf you are not the sole contributor to a contribution (pull request), please identify all contributors in the pull request comment.\n\nTo add a contributor (other than yourself, that's automatic), mark them one per line as follows:\n\n```\n+@github_username\n```\n\nIf you added a contributor by mistake, you can remove them in a comment with:\n\n```\n-@github_username\n```\n\nIf you are making a pull request on behalf of someone else but you had no part in designing the feature, you can remove yourself with the above syntax.\n\n## Issues\n\nIf you cannot submit a pull request, or if you cannot provide a direct solution, the preferred method is to create a [new issue](https://github.com/w3c/sustyweb/issues/new) with your public comments. You can also comment on any issue threads on [Github Issues](https://github.com/w3c/sustyweb/issues/). You could provide comments on technical errors (bugs) you have uncovered, new guidelines or success criteria you believe should be added, questions you have about existing or future content or an idea for a direction or feature we could utilize.\n\nPlease check that your question hasn't already been posted first, and provide as much detail as possible (if you have a solution or content to add, it would be very helpful). We're all volunteers so please keep this in mind and try to be civil when commenting about our work.\n\nIf filing issues in GitHub is not feasible, email our open discussion group [public-sustyweb@w3.org](public-sustyweb@w3.org) ([comment archive](https://lists.w3.org/Archives/Public/public-sustyweb/)).\n\n## Credit\n\nAll contributors will receive credit (in the specification and our GitHub release notes) if their feedback and ideas make it into the document. Certain exclusions will apply such as those who do not provide their full names or those whose feedback is deemed as invalid, duplicate, or general questions that don't add to the specification or its supplements.\n"
+        "text": "> [!WARNING]\n> This Community Group's activities are now under the direction of the [W3C Sustainable Web Interest Group](https://www.w3.org/groups/ig/sustainableweb/). This includes the curation of the [Web Sustainability Guidelines](https://w3c.github.io/sustainableweb-wsg/). Thank you for supporting us as we reached this stage in our journey and we hope you will continue to support our work as it develops at our new home (where you are welcome to get involved).\n\n# Contributing\n\nThis repository is being used for work in the **W3C Sustainable Web Design Community Group**, governed by the [W3C Community License\nAgreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To make substantive contributions,\nyou must join the [CG](https://www.w3.org/community/sustyweb/).\n\n## Overview\n\nThis repository is used to develop content for the Web Sustainability Guidelines (WSGs), as well as any supplementary documents.\n\n## Collaboration\n\nWe welcome content from individuals as well as group efforts and understand that this may pose difficulties for those either unfamiliar with pull requests (on a technical level) or with collaborative efforts (wishing to discuss progress before submitting results). In such cases, members can (if they choose) work with any open format they prefer to collaborate (referring to the specification and its supplements), and submit an issue request containing the URL to the document in question. A moderator (lead or chair) will help translate these requested updates into the living draft specification.\n\n## File Structure\n\nThe structure of the repository has been created to ensure ease of maintenance. The base directory contains all of the compiled files that are public facing such as the specification, supplementary documents, the JSON API, and other materials such as the finalized Test Suite. The \"drafts\" folder contains all of the pre-exported W3C ReSpec sources including the living editions of the [specification](https://w3c.github.io/sustyweb/drafts/), [at-a-glance](https://w3c.github.io/sustyweb/drafts/glance.html), [introduction](https://w3c.github.io/sustyweb/drafts/intro.html), [laws & policies](https://w3c.github.io/sustyweb/drafts/policies.html), [quick reference](https://w3c.github.io/sustyweb/drafts/quickref.html), [STAR](https://w3c.github.io/sustyweb/drafts/star.html), [JSON API](https://w3c.github.io/sustyweb/drafts/guidelines.json) and other supplements such as our draft Test Suite.\n\n```\n\n/ig/charter.html\t\t\t- Working Group Draft Charter\n/drafts/test-suite/\t\t\t- Test Suite & Assets (Source)\n/drafts/checklist.pages\t\t\t- PDF Checklist (Source)\n/drafts/glance.html\t\t\t- At-A-Glance (Source)\n/drafts/guidelines.json\t\t\t- WSG JSON API (Source)\n/drafts/index.html\t\t\t- WSG Specification (Source)\n/drafts/intro.html\t\t\t- Introduction (Source)\n/drafts/policies.html\t\t\t- Laws & Policies (Source)\n/drafts/quickref.html\t\t\t- Quick Reference (Source)\n/drafts/star.html\t\t\t- STAR (Source)\n\n/test-suite/\t\t\t\t- READ ONLY - Test Suite & Assets (Public)\nchecklist.pdf\t\t\t\t- READ ONLY - PDF Checklist (Public)\nglance.html\t\t\t\t- READ ONLY - At-A-Glance (Public)\nguidelines.json\t\t\t\t- READ ONLY - WSG JSON API (Public)\nindex.html\t\t\t\t- READ ONLY - WSG Specification (Public)\nintro.html\t\t\t\t- READ ONLY - Introduction (Public)\noverview.pdf\t\t\t\t- READ ONLY - Project Progress Tracker (Public)\npolicies.html\t\t\t\t- READ ONLY - Laws & Policies (Public)\nquickref.html\t\t\t\t- READ ONLY - Quick Reference (Public)\nstar.html\t\t\t\t- READ ONLY - STAR (Public)\nTPAC_Slides.pdf\t\t\t\t- READ ONLY - W3C TPAC Slides\nWeb_Sustainability_GRI_Impact_est.ipynb\t- READ ONLY - GRI Impact Calculator\n```\n\nWhen you contribute to our repo, you **MUST** only make changes to documents within the \"drafts\" or \"ig\" folders (the sources). Once a PR submission has been reviewed by our group (for quality control purposes), it will either be accepted, or rejected, or further discussion will be required (an issue can be raised for example). Once a PR has been accepted it will be visible within the living draft documents immediately. When enough issues have been collated to warrant a release publication, the necessary documents will be exported through ReSpec into their final HTML form and will replace their static namesakes in the base directory to be versioned as the next public release. Release notes will also be generated by a chair who will verify all submissions before publication.\n\nYou will notice duplication within the content of our work (as the JSON API for example must reflect the specification). This work is not auto-generated so while we appreciate it if individuals choose to make adjustments to all affected files as required, time commitments may not allow for everyone to do so. As such, if you can only update a single document, as part of the approval process, a moderator (lead or chair) will update all necessary documents to ensure parity with your change.\n\n## Pull Requests\n\nIf you would like to contribute towards this specification, our primary method is through Pull Requests (PRs).\n\nPull requests (PRs) should be made against the main branch.\n\nIf you are not the sole contributor to a contribution (pull request), please identify all contributors in the pull request comment.\n\nTo add a contributor (other than yourself, that's automatic), mark them one per line as follows:\n\n```\n+@github_username\n```\n\nIf you added a contributor by mistake, you can remove them in a comment with:\n\n```\n-@github_username\n```\n\nIf you are making a pull request on behalf of someone else but you had no part in designing the feature, you can remove yourself with the above syntax.\n\n## Issues\n\nIf you cannot submit a pull request, or if you cannot provide a direct solution, the preferred method is to create a [new issue](https://github.com/w3c/sustyweb/issues/new) with your public comments. You can also comment on any issue threads on [Github Issues](https://github.com/w3c/sustyweb/issues/). You could provide comments on technical errors (bugs) you have uncovered, new guidelines or success criteria you believe should be added, questions you have about existing or future content or an idea for a direction or feature we could utilize.\n\nPlease check that your question hasn't already been posted first, and provide as much detail as possible (if you have a solution or content to add, it would be very helpful). We're all volunteers so please keep this in mind and try to be civil when commenting about our work.\n\nIf filing issues in GitHub is not feasible, email our open discussion group [public-sustyweb@w3.org](public-sustyweb@w3.org) ([comment archive](https://lists.w3.org/Archives/Public/public-sustyweb/)).\n\n## Credit\n\nAll contributors will receive credit (in the specification and our GitHub release notes) if their feedback and ideas make it into the document. Certain exclusions will apply such as those who do not provide their full names or those whose feedback is deemed as invalid, duplicate, or general questions that don't add to the specification or its supplements.\n"
       },
       "license": {
         "text": "All Reports in this Repository are licensed by Contributors\nunder the\n[W3C Software and Document License](http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document).\n\nContributions to Specifications are made under the\n[W3C CLA](https://www.w3.org/community/about/agreements/cla/).\n\nContributions to Test Suites are made under the\n[W3C 3-clause BSD License](https://www.w3.org/Consortium/Legal/2008/03-bsd-license.html)\n\n"
@@ -108150,7 +108304,7 @@
         "body": "# Code of Conduct\n\nAll documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).\n"
       },
       "readme": {
-        "text": "> [!WARNING]\n> This Community Group's activities are now under the direction of the [W3C Sustainable Web Interest Group](https://www.w3.org/groups/ig/sustainableweb/). This includes the curation of the [Web Sustainability Guidelines](https://w3c.github.io/sustyweb/). Thank you for supporting us as we reached this stage in our journey and we hope you will continue to support our work as it develops at our new home (where you are welcome to get involved).\n\n# Web Sustainability Guidelines (WSGs)\n\nWelcome to the repository for the [Sustainable Web Design Community Group](https://www.w3.org/community/sustyweb/).\n\nIn this hub, you will find the draft specification for our [Web Sustainability Guidelines](https://w3c.github.io/sustyweb/) and any supplementary documentation, including [Sustainable Tooling And Reporting (STAR)](https://w3c.github.io/sustyweb/star.html), our [at-a-glance](https://w3c.github.io/sustyweb/glance.html) overview, our [introduction](https://w3c.github.io/sustyweb/intro.html) to Web Sustainability, our sustainability [laws & policies](https://w3c.github.io/sustyweb/policies.html) guide, our [quick reference](https://w3c.github.io/sustyweb/quickref.html) sheet, our [PDF checklist](https://w3c.github.io/sustyweb/checklist.pdf), our [JSON API](https://w3c.github.io/sustyweb/guidelines.json), and our [Test Suite](https://github.com/w3c/sustyweb/tree/main/test-suite). We also have a living implementation of the specification under active development called [Sustainable Web Design](https://sustainablewebdesign.org/).\n\nIf you would like a brief introduction to both our group and our specification, you may find [the slides](https://w3c.github.io/sustyweb/TPAC_Slides.pdf) from the presentation we gave at [TPAC 2023](https://www.w3.org/2023/09/breakouts/recording-32.html) useful. To learn more about our group, its goals, and our progress, check out our [wiki](https://www.w3.org/community/sustyweb/wiki/Main_Page), and [frequently asked questions](https://www.w3.org/community/sustyweb/wiki/Frequently_Asked_Questions) page.\n\n---\n\n## Progress\n\nWork is planned in accordance with our [overview](https://w3c.github.io/sustyweb/overview.pdf) of the [issues](https://github.com/w3c/sustyweb/issues) requiring resolution. Each [milestone](https://github.com/w3c/sustyweb/milestones) corresponds to a [release](https://github.com/w3c/sustyweb/releases) published.\n\n**Note:** W3C member feedback on our initial [proposed Working Group charter](https://w3c.github.io/sustyweb/ig/wg-charter.html) has lead to many [proposed and planned](https://docs.google.com/presentation/d/1dcuSMLcAF8jTHNCovOfs31zrjCr3rtrwzTXRLSy3lAk/edit?usp=sharing) updates.\n\nView current Interest Group chartering efforts:\n* The [Current AC Poll](https://www.w3.org/2002/09/wbs/33280/SustyWeb/). (W3C Members Only)\n* Our [Proposed charter](https://www.w3.org/2024/09/sustyweb-charter-202409.html). (Feedback Welcome)\n* The latest [editor's draft](https://w3c.github.io/sustyweb/ig/charter.html) of our charter. ([DIFF Changelog](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2024%2F09%2Fsustyweb-charter-202409.html&doc2=https%3A%2F%2Fw3c.github.io%2Fsustyweb%2Fig%2Fcharter.html))\n\n---\n\n## Contributing\n\nIf you would like to contribute towards this specification, please refer to the [CONTRIBUTING.md](CONTRIBUTING.md) document for details. It contains detailed information on pull requests (PRs), submitting issues, and other methods of feedback in relation to this repository.\n\n**Note:** Please make your pull requests (including any changes or edits) against files **ONLY** located within the \"drafts\" or \"ig\" folders. Also, to make substantive contributions,\nyou must join the [CG](https://www.w3.org/community/sustyweb/).\n\nYou can also contribute at our monthly meetings. For details, see our [calendar](https://www.w3.org/groups/cg/sustyweb/calendar/) and [meeting minutes](https://docs.google.com/document/d/1nrdxfB076c-91GEDFnZF3wb73QqjJ7rmCVVQiKRNnuY/edit).\n\n---\n\n## Living Drafts\n\nOur publishing process has two channels.\n\nThe first channel is the **stable** specification which is versioned with all changes documented in the [release notes](https://github.com/w3c/sustyweb/releases). Links to the stable specification and its supplements can be found above (at the top of this README document).\n\nThe second channel is the **unstable** or living edition specification in which issue resolutions, pull requests, new supplements, and community edits are immediately available before that version is finalized. The \"drafts\" folder contains all of the living editions of the [specification](https://w3c.github.io/sustyweb/drafts/), [STAR](https://w3c.github.io/sustyweb/drafts/star.html), [at-a-glance](https://w3c.github.io/sustyweb/drafts/glance.html), [introduction](https://w3c.github.io/sustyweb/drafts/intro.html), [laws & policies](https://w3c.github.io/sustyweb/drafts/policies.html), [quick reference](https://w3c.github.io/sustyweb/drafts/quickref.html), [JSON API](https://w3c.github.io/sustyweb/drafts/guidelines.json), [Test Suite](https://github.com/w3c/sustyweb/tree/main/drafts/test-suite), and other supplements.\n\n---\n\n## JSON API\n\nWe have a [JSON API](https://w3c.github.io/sustyweb/guidelines.json) which is kept in sync with the changes occurring within our specification.\n\nThis document is reachable via GitHub pages and can be queried using JavaScript to embed our data within your client of choice.\n\nThe structure of the API is identical to that of the specification in its numbering scheme:\n\n`category[1][0].guideline = \"Undertake Systemic Impacts Mapping\"`\n\n---\n\n## Test Suite\n\nWe have a [Test Suite](https://github.com/w3c/sustyweb/tree/main/test-suite) which is used to showcase machine testability (as denoted in [STAR](https://w3c.github.io/sustyweb/star.html)) for the Web Sustainability Guidelines (WSGs). The template structure for the file uses common W3C conventions for test cases to maintain interoperability for tooling that wishes to align our work with their own.\n\nKey concepts of note include:\n- Each title element contains a short identifier for the test.\n- The rel=\"author\" link element contains details of who created that test.\n- The rel=\"help\" link element links to the WSG guideline it relates to.\n- The name=\"flags\" meta element identifies any requirements the test may have such as an external file (**asset**), scripting (**JavaScript**), user-involvement (**interaction**), or if it's trying to disprove something (**invalid**).\n- The name=\"assert\" meta tag explains which **STAR** technique it relates to by title.\n- The conditions of passing are what requirements are necessary to pass the technique (and thus the success criteria).\n"
+        "text": "> [!WARNING]\n> This Community Group's activities are now under the direction of the [W3C Sustainable Web Interest Group](https://www.w3.org/groups/ig/sustainableweb/). This includes the curation of the [Web Sustainability Guidelines](https://w3c.github.io/sustainableweb-wsg/). Thank you for supporting us as we reached this stage in our journey and we hope you will continue to support our work as it develops at our new home (where you are welcome to get involved).\n\n# Web Sustainability Guidelines (WSGs)\n\nWelcome to the repository for the [Sustainable Web Design Community Group](https://www.w3.org/community/sustyweb/).\n\nIn this hub, you will find the draft specification for our [Web Sustainability Guidelines](https://w3c.github.io/sustyweb/) and any supplementary documentation, including [Sustainable Tooling And Reporting (STAR)](https://w3c.github.io/sustyweb/star.html), our [at-a-glance](https://w3c.github.io/sustyweb/glance.html) overview, our [introduction](https://w3c.github.io/sustyweb/intro.html) to Web Sustainability, our sustainability [laws & policies](https://w3c.github.io/sustyweb/policies.html) guide, our [quick reference](https://w3c.github.io/sustyweb/quickref.html) sheet, our [PDF checklist](https://w3c.github.io/sustyweb/checklist.pdf), our [JSON API](https://w3c.github.io/sustyweb/guidelines.json), and our [Test Suite](https://github.com/w3c/sustyweb/tree/main/test-suite). We also have a living implementation of the specification under active development called [Sustainable Web Design](https://sustainablewebdesign.org/).\n\nIf you would like a brief introduction to both our group and our specification, you may find [the slides](https://w3c.github.io/sustyweb/TPAC_Slides.pdf) from the presentation we gave at [TPAC 2023](https://www.w3.org/2023/09/breakouts/recording-32.html) useful. To learn more about our group, its goals, and our progress, check out our [wiki](https://www.w3.org/community/sustyweb/wiki/Main_Page), and [frequently asked questions](https://www.w3.org/community/sustyweb/wiki/Frequently_Asked_Questions) page.\n\n---\n\n## Progress\n\nWork is planned in accordance with our [overview](https://w3c.github.io/sustyweb/overview.pdf) of the [issues](https://github.com/w3c/sustyweb/issues) requiring resolution. Each [milestone](https://github.com/w3c/sustyweb/milestones) corresponds to a [release](https://github.com/w3c/sustyweb/releases) published.\n\n**Note:** W3C member feedback on our initial [proposed Working Group charter](https://w3c.github.io/sustyweb/ig/wg-charter.html) has lead to many [proposed and planned](https://docs.google.com/presentation/d/1dcuSMLcAF8jTHNCovOfs31zrjCr3rtrwzTXRLSy3lAk/edit?usp=sharing) updates.\n\nView current Interest Group chartering efforts:\n* The [Current AC Poll](https://www.w3.org/2002/09/wbs/33280/SustyWeb/). (W3C Members Only)\n* Our [Proposed charter](https://www.w3.org/2024/09/sustyweb-charter-202409.html). (Feedback Welcome)\n* The latest [editor's draft](https://w3c.github.io/sustyweb/ig/charter.html) of our charter. ([DIFF Changelog](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2024%2F09%2Fsustyweb-charter-202409.html&doc2=https%3A%2F%2Fw3c.github.io%2Fsustyweb%2Fig%2Fcharter.html))\n\n---\n\n## Contributing\n\nIf you would like to contribute towards this specification, please refer to the [CONTRIBUTING.md](CONTRIBUTING.md) document for details. It contains detailed information on pull requests (PRs), submitting issues, and other methods of feedback in relation to this repository.\n\n**Note:** Please make your pull requests (including any changes or edits) against files **ONLY** located within the \"drafts\" or \"ig\" folders. Also, to make substantive contributions,\nyou must join the [CG](https://www.w3.org/community/sustyweb/).\n\nYou can also contribute at our monthly meetings. For details, see our [calendar](https://www.w3.org/groups/cg/sustyweb/calendar/) and [meeting minutes](https://docs.google.com/document/d/1nrdxfB076c-91GEDFnZF3wb73QqjJ7rmCVVQiKRNnuY/edit).\n\n---\n\n## Living Drafts\n\nOur publishing process has two channels.\n\nThe first channel is the **stable** specification which is versioned with all changes documented in the [release notes](https://github.com/w3c/sustyweb/releases). Links to the stable specification and its supplements can be found above (at the top of this README document).\n\nThe second channel is the **unstable** or living edition specification in which issue resolutions, pull requests, new supplements, and community edits are immediately available before that version is finalized. The \"drafts\" folder contains all of the living editions of the [specification](https://w3c.github.io/sustyweb/drafts/), [STAR](https://w3c.github.io/sustyweb/drafts/star.html), [at-a-glance](https://w3c.github.io/sustyweb/drafts/glance.html), [introduction](https://w3c.github.io/sustyweb/drafts/intro.html), [laws & policies](https://w3c.github.io/sustyweb/drafts/policies.html), [quick reference](https://w3c.github.io/sustyweb/drafts/quickref.html), [JSON API](https://w3c.github.io/sustyweb/drafts/guidelines.json), [Test Suite](https://github.com/w3c/sustyweb/tree/main/drafts/test-suite), and other supplements.\n\n---\n\n## JSON API\n\nWe have a [JSON API](https://w3c.github.io/sustyweb/guidelines.json) which is kept in sync with the changes occurring within our specification.\n\nThis document is reachable via GitHub pages and can be queried using JavaScript to embed our data within your client of choice.\n\nThe structure of the API is identical to that of the specification in its numbering scheme:\n\n`category[1][0].guideline = \"Undertake Systemic Impacts Mapping\"`\n\n---\n\n## Test Suite\n\nWe have a [Test Suite](https://github.com/w3c/sustyweb/tree/main/test-suite) which is used to showcase machine testability (as denoted in [STAR](https://w3c.github.io/sustyweb/star.html)) for the Web Sustainability Guidelines (WSGs). The template structure for the file uses common W3C conventions for test cases to maintain interoperability for tooling that wishes to align our work with their own.\n\nKey concepts of note include:\n- Each title element contains a short identifier for the test.\n- The rel=\"author\" link element contains details of who created that test.\n- The rel=\"help\" link element links to the WSG guideline it relates to.\n- The name=\"flags\" meta element identifies any requirements the test may have such as an external file (**asset**), scripting (**JavaScript**), user-involvement (**interaction**), or if it's trying to disprove something (**invalid**).\n- The name=\"assert\" meta tag explains which **STAR** technique it relates to by title.\n- The conditions of passing are what requirements are necessary to pass the technique (and thus the success criteria).\n"
       },
       "w3c": {
         "group": [
@@ -123512,7 +123666,7 @@
       },
       "codeOfConduct": null,
       "readme": {
-        "text": "# W3C website template bundle & Design System\n\nThe Symfony website templates for [w3.org](https://github.com/w3c/w3c-website-frontend), this also generates the\nstatic HTML [design system website](https://design-system.w3.org/).\n\n## Design System\n\nThis repo contains the design system documentation, frontend assets and example Twig templates. \n\nDocumentation for implementing the W3C website design can be found on the [Design System website](https://design-system.w3.org/).\n\nTo make updates or to deploy the design system itself see [design system](design-system.md).\n\nPlease report any issues to the [w3c-website](https://github.com/w3c/w3c-website/issues) repo.\n\n## Template bundle\n\nThis repo also contains a Symfony bundle which loads the frontend assets and has a set of Twig templates available \nto build Symfony apps using the W3C website design system.\n\n### How to use the design system templates in Symfony\n\nThe design system contains [example Twig templates](design-system-templates) that cover all design patterns used\non the W3C website. These are simplified templates to help illustrate usage. \n\nTo actually use the design system Twig templates, you need to copy these to the [Symfony bundle templates](templates) \nand customise them for use in your application. At present we're building the \n[W3C frontend application](https://github.com/w3c/w3c-website-frontend) which will power \nw3.org. As we build pages we are copying the design system templates across to the bundle templates \nand modifying them for real-world usage. \n\nLong-term the plan is to be able to use the Symfony bundle templates in a range of different \nSymfony applications - though some refactoring may need to be done to ensure the templates work easily \nacross different applications.\n\n### Installation\n\nYou can install this in your Symfony app via:\n\n```bash\ncomposer require w3c/website-templates-bundle:dev-main\n```\n\nThis requires PHP 7.4+\n\nOn installation, front-end assets (CSS, JavaScript, fonts, etc.) will be copied into the public directory of the application.\nYou will find them in the folder `public/bundles/w3cwebsitetemplates/dist/assets`.\nYou will need to update the assets base URL to point to that folder. This can be done in your application `config/packages/assets.yaml` file for example.\n\nExample syntax (provided you have defined an `%app.app_url%` parameter):\n\n```yaml\nframework:\n    assets:\n        packages:\n            main:\n                base_urls: '%app.app_url%/bundles/w3cwebsitetemplates/dist/assets/'\n```\nYou can now use the W3C Twig templates and front-end assets in your application.\n\n### Usage\n\nThe templates available can be found in this bundle's 'templates' folder. You can reference them in your application using the\nhandle `@W3CWebsiteTemplates`. E.g.\n\n```twig\n{% extends '@W3CWebsiteTemplates/base.html.twig' %}\n```\n\n### Overriding the templates\n\nTemplates can be overridden in the `templates/bundles/w3cwebsitetemplates/` directory in your \nSymfony project, using the same name and path as the original templates.\n\n## Reporting issues\n\nPlease report any issues to the [w3c-website](https://github.com/w3c/w3c-website/issues) repo.\n"
+        "text": "# W3C website template bundle & Design System\n\nThe Symfony website templates for [w3.org](https://github.com/w3c/w3c-website-frontend). This also generates the\nstatic HTML [design system website](https://design-system.w3.org/).\n\n## Design System\n\nThis repo contains the design system documentation, frontend assets and example Twig templates. \n\nDocumentation for implementing the W3C website design can be found on the [Design System website](https://design-system.w3.org/).\n\nFor documentation on how to make updates to the design system itself see [design system README](design-system.md).\n\nPlease report any issues to the [w3c-website](https://github.com/w3c/w3c-website/issues) repo.\n\n## Template bundle\n\nThis repo also contains a Symfony bundle which loads the frontend assets and has a set of Twig templates available \nto build Symfony apps using the W3C website design system.\n\n### How to use the design system templates in Symfony\n\nThe design system contains [example Twig templates](design-system-templates) that cover all design patterns used\non the W3C website. These are simplified templates to help illustrate usage. \n\nTo actually use the design system Twig templates, you need to copy these to the [Symfony bundle templates](templates) \nand customise them for use in your application. At present we're building the \n[W3C frontend application](https://github.com/w3c/w3c-website-frontend) which will power \nw3.org. As we build pages we are copying the design system templates across to the bundle templates \nand modifying them for real-world usage. \n\nLong-term the plan is to be able to use the Symfony bundle templates in a range of different \nSymfony applications - though some refactoring may need to be done to ensure the templates work easily \nacross different applications.\n\n### Installation\n\nYou can install this in your Symfony app via:\n\n```bash\ncomposer require w3c/website-templates-bundle:dev-main\n```\n\nThis requires PHP 7.4+\n\nOn installation, front-end assets (CSS, JavaScript, fonts, etc.) will be copied into the public directory of the application.\nYou will find them in the folder `public/bundles/w3cwebsitetemplates/dist/assets`.\nYou will need to update the assets base URL to point to that folder. This can be done in your application `config/packages/assets.yaml` file for example.\n\nExample syntax (provided you have defined an `%app.app_url%` parameter):\n\n```yaml\nframework:\n    assets:\n        packages:\n            main:\n                base_urls: '%app.app_url%/bundles/w3cwebsitetemplates/dist/assets/'\n```\nYou can now use the W3C Twig templates and front-end assets in your application.\n\n### Usage\n\nThe templates available can be found in this bundle's 'templates' folder. You can reference them in your application using the\nhandle `@W3CWebsiteTemplates`. E.g.\n\n```twig\n{% extends '@W3CWebsiteTemplates/base.html.twig' %}\n```\n\n### Overriding the templates\n\nTemplates can be overridden in the `templates/bundles/w3cwebsitetemplates/` directory in your \nSymfony project, using the same name and path as the original templates.\n\n## Reporting issues\n\nPlease report any issues to the [w3c-website](https://github.com/w3c/w3c-website/issues) repo.\n"
       },
       "w3c": {
         "group": [
@@ -137874,6 +138028,10 @@
           "name": "Guideline Subgroups: Section headers",
           "color": "BFDADC"
         },
+        {
+          "name": "Guidelines Subgroups: Adjustable Viewport",
+          "color": "99BED3"
+        },
         {
           "name": "Guidelines Subgroups: Captions",
           "color": "BFDADC"
@@ -147108,7 +147266,7 @@
       "license": null,
       "codeOfConduct": null,
       "readme": {
-        "text": "# Webref\n\n## Description\n\nThis repository contains **machine-readable references of CSS properties, definitions, IDL, and other useful terms that can be automatically extracted from web browser specifications** (see a [list of projects known to use the data](#known-consumers)). The contents of the repository are updated automatically **every 6 hours** (although note information about published _[/TR/](https://www.w3.org/TR/)_ versions of specifications are updated only once per day).\n\nSpecifications covered by this repository are technical Web specifications that appear in [browser-specs](https://github.com/w3c/browser-specs).\n\nThe `main` branch of this repository contains **automatically-generated raw extracts** from web browser specifications. These extracts come with no guarantee on validity or consistency. For instance, if a specification defines invalid IDL snippets or uses an unknown IDL type, the corresponding IDL extract in this repository will be invalid as well.\n\nThe `curated` branch contains **curated extracts**. Curated extracts are generated from raw extracts in the [`ed`](ed) folder by applying manually-maintained patches to fix invalid content and provide [validity and consistency guarantees](#curation-guarantees). The `curated` branch is updated automatically whenever the `main` branch is updated, unless patches need to be modified (which requires manual intervention). Curated extracts are published under https://w3c.github.io/webref/ed/.\n\nAdditionally, subsets of the curated content get manually reviewed and published as **NPM [packages](https://github.com/w3c/webref/tree/main/packages)** on a weekly basis:\n- [`@webref/idl`](https://www.npmjs.com/package/@webref/idl) contains a [curated](packages/idl#guarantees) version of the [`ed/idl`](ed/idl) folder.\n- [`@webref/css`](https://www.npmjs.com/package/@webref/css) contains a [curated](packages/css#guarantees) version of the [`ed/css`](ed/css) folder.\n- [`@webref/elements`](https://www.npmjs.com/package/@webref/elements) contains a [curated](packages/elements#guarantees) version of the [`ed/elements`](ed/elements) folder.\n- [`@webref/events`](https://www.npmjs.com/package/@webref/events) contains a [curated](packages/events#guarantees) version of the [`ed/events`](ed/events) folder.\n\n**Important:** The curated extracts only contain data for specifications that are in [good standing](https://github.com/w3c/browser-specs/#standing) (to keep the number of manually-maintained patches minimal and manageable). The NPM packages only contain curated extracts of specifications that are in good standing and that [target web browsers](https://github.com/w3c/browser-specs/#categories).\n\n**Important:** Unless you are ready to deal with invalid content, we strongly recommend that you process contents of the `curated` branch or NPM packages instead of raw content in the `main` branch.\n\n\n## Available extracts\n\nThis repository contains raw and curated information about [nightly](https://github.com/w3c/browser-specs/#nightly) versions of Web specifications in the [`ed`](https://github.com/w3c/webref/tree/curated/ed) folder, as well as raw information about the [released](https://github.com/w3c/browser-specs/#release) version (for _[/TR/](https://www.w3.org/TR/)_ specifications) in the [`tr`](tr) folder.\n\n**Note:** The [`tr`](tr) folder only contains information about [released](https://github.com/w3c/browser-specs/#release) specifications. Specifications that have not been published as _[/TR/](https://www.w3.org/TR/)_ documents (such as WHATWG specifications or Community Group reports) do not appear under the [`tr`](tr) folder in particular.\n\nMore often than not, released versions of specifications are much older than their nightly version. Data in the [`tr`](tr) folder is more invalid/inconsistent than data in the [`ed`](ed) folder as a result. Additionally, no attempt is being made at curating data in the [`tr`](tr) folder, *use the [`tr`](tr) folder at your own risk!*\n\nThe following subfolders in the `curated` branch contain individual machine-readable JSON or text files generated from specifications:\n\n- [`ed/css`](https://github.com/w3c/webref/tree/curated/ed/css): CSS terms (properties, descriptors, value spaces). One file per specification [series](https://github.com/w3c/browser-specs/#series).\n- [`ed/dfns`](https://github.com/w3c/webref/tree/curated/ed/dfns): `<dfn>` terms, along with metadata such as linking text, access level, namespace. One file per specification.\n- [`ed/elements`](https://github.com/w3c/webref/tree/curated/ed/elements): Markup elements defined, along with the interface that they implement. One file per specification.\n- [`ed/headings`](https://github.com/w3c/webref/tree/curated/ed/headings): Section headings. One file per specification.\n- [`ed/idl`](https://github.com/w3c/webref/tree/curated/ed/idl): Raw WebIDL index. One file per specification [series](https://github.com/w3c/browser-specs/#series).\n- [`ed/idlnames`](https://github.com/w3c/webref/tree/curated/ed/idlnames): WebIDL definitions per referenceable IDL name. One file per IDL name.\n- [`ed/idlnamesparsed`](https://github.com/w3c/webref/tree/curated/ed/idlnamesparsed): Parsed WebIDL structure of definitions in the `idlnames` folder. One file per IDL name.\n- [`ed/idlparsed`](https://github.com/w3c/webref/tree/curated/ed/idlparsed): Parsed WebIDL structure of definitions in the `idl` folder. One file per specification.\n- [`ed/ids`](https://github.com/w3c/webref/tree/curated/ed/ids): Fragments defined in the specification. One file per specification.\n- [`ed/links`](https://github.com/w3c/webref/tree/curated/ed/links): Links to other documents, along with targeted fragments. One file per specification.\n- [`ed/refs`](https://github.com/w3c/webref/tree/curated/ed/refs): Normative and informative references to other specifications. One file per specification.\n\nIndividual files are named after the shortname of the specification, or after the shortname of the specification series for CSS definitions and raw IDL files. Individual files are only created when needed, meaning when the specification actually includes relevant terms.\n\nThe [`ed/index.json`](https://github.com/w3c/webref/tree/curated/ed/index.json) file contains the index of specifications that have been crawled, and relative links to individual files that have been created.\n\nThis repository uses [Reffy](https://github.com/w3c/reffy), a Web spec exploration tool, to crawl the specifications and generate the data. In particular, the data it contains is the result of running Reffy. The repository does not contain any more data.\n\nRaw WebIDL extracts are used in [web-platform-tests](https://github.com/web-platform-tests/wpt), please see their [interfaces/README.md](https://github.com/web-platform-tests/wpt/blob/master/interfaces/README.md) for details.\n\n\n## Curation guarantees\n\nData curation brings the following guarantees.\n\n### Web IDL extracts\n\n- All IDL files can be parsed by the version of [webidl2.js](https://github.com/w3c/webidl2.js/) referenced in `package.json`.\n- `WebIDL2.validate` passes with the exception of the \"no-nointerfaceobject\" rule about `[LegacyNoInterfaceObject]`, which is in wide use.\n- All types are defined by some specification.\n- All extended attributes are defined by some specification.\n- No duplicate top-level definitions or members.\n- No missing or mismatched types in inheritance chains.\n- No conflicts when applying mixins and partials.\n\n### CSS extracts\n\n- All values in CSS files can be parsed by the version of [CSSTree](https://github.com/csstree/csstree) used in `peerDependencies` in `package.json`.\n- No duplicate definitions of CSS properties provided that CSS extracts of [delta specs](https://github.com/w3c/browser-specs/#seriescomposition) are not taken into account (such extracts end with `-n.json`, where `n` is a level number).\n- CSS extracts contain a base definition of all CSS properties that get extended by other CSS property definitions (those for which `newValues` is set).\n- All entries in CSS files that do not extend a base definition link back to their actual definition in the spec. In other words, all entries under `properties[]`, `properties[].values[]`, `selectors[]`, `atrules[]` and `values[]` have an `href` key that contains an absolute URL with fragment, except properties that that have a `newValues` key, at-rules that neither have a `prose` nor a `value` key, and definitions of a [delta spec](https://github.com/w3c/browser-specs/#seriescomposition) that completely override a definition in a previous level.\n\n### Elements extracts\n\n- All Web IDL interfaces referenced by elements exist in Web IDL extracts.\n- All elements link back to their definition in the spec.\n\n### Events extracts\n\n- All events have a `type` attribute that match the name of the event\n- All events have a `interface` attribute to describe the interface used by the Event. The Web IDL interface exists in the latest version of the [`@webref/idl` package](https://www.npmjs.com/package/@webref/idl) at the time the `@webref/events` package is released, and represents an actual interface (i.e. not a mixin).\n- All events have a `targets` attribute with a non-empty list of target interfaces on which the event may fire. All Web IDL interfaces in the list exist in the latest version of the [`@webref/idl` package](https://www.npmjs.com/package/@webref/idl) at the time the `@webref/events` package is released, and represent an actual interface (i.e. not a mixin).\n- The `bubbles` attribute is always set to a boolean value for target interfaces that belong to a bubbling tree (DOM, IndexedDB, Serial API, Web Bluetooth).\n- The `bubbles` attribute is only set for target interfaces that belong to a bubbling tree.\n- The `bubblingPath` attribute is only set for target interfaces on which the event bubbles.\n- The `targets` attribute contains the top most interfaces in an inheritance chain, unless bubbling conditions differ. For instance, the list may contain `{ \"target\": \"Element\", \"bubbles\": true }` but not also `{ \"target\": \"HTMLElement\", \"bubbles\": true }` since `HTMLElement` inherits from `Element`.\n- For target interfaces that belong to a bubbling tree, the `targets` attribute only contains the deepest interface in the bubbling tree on which the event may fire and bubble. For instance, the list may contain `{ \"target\": \"HTMLElement\", \"bubbles\": true }`, but not also `{ \"target\": \"Document\" }` since event would de facto fire at `Document` through bubbling.\n\n## Known consumers\n\nThe following projects are known to use webref data:\n* MDN content management system, [yari](https://github.com/mdn/yari/)\n* [Web Platform Tests](https://github.com/web-platform-tests/wpt)\n* [Open Web Docs MDN Browser Compat Data collector](https://github.com/openwebdocs/mdn-bcd-collector)\n* [bikeshed](https://speced.github.io/bikeshed/), a specification authoring tool\n* [ReSpec](https://respec.org/docs/), a specification authoring tool\n* [\"DOM\" Bindings for TypeScript](https://github.com/microsoft/TypeScript-DOM-lib-generator)\n* [browser API bindings for Dart](https://github.com/dart-lang/)\n* the [Pulsar text editor](https://github.com/pulsar-edit/pulsar)\n* [PostCSS preset env plugin](https://github.com/csstools/postcss-plugins/tree/main/plugin-packs/postcss-preset-env)\n* [strudy](https://github.com/w3c/strudy)\n* [nodysseus](https://gitlab.com/ulysses.codes/nodysseus)\n* [WebIDLPedia](https://dontcallmedom.github.io/webidlpedia/)\n* [Webdex](https://dontcallmedom.github.io/webdex/)\n\nUsing webref data in a project that is not yet in the list? Let us know!\n\n## Potential spec anomalies\n\nWebref extracts are analyzed with [Strudy](https://github.com/w3c/strudy#strudy) to detect potential spec content anomalies such as broken links or invalid constructs, and report them as issues in the repository that hosts the spec.\n\nGlobal analyses used to be published in the [w3c/webref-analysis](https://github.com/w3c/webref-analysis) repository. That repository was archived in August 2024.\n\n## How to suggest changes or report an error\n\nFeel free to raise [issues in this repository](https://github.com/w3c/webref/issues) as needed. Note that most issues likely more directly apply to underlying tools:\n\n- Errors in the data are most likely caused by bugs or missing features in [Reffy](https://github.com/w3c/reffy), which is the tool that crawls and parses specifications under the hoods. If you spot an error, please report it in [Reffy's issue tracker](https://github.com/w3c/reffy/issues/new).\n- If you believe that a spec is missing from the list, please check [browser-specs](https://github.com/w3c/browser-specs/#how-to-addupdatedelete-a-spec) and report it [there](https://github.com/w3c/browser-specs/issues/new).\n\n\n## Development notes\n\nGitHub Actions workflows are used to automate most of the tasks in this repo.\n\n### Data update\n\n- [Update ED report](https://github.com/w3c/webref/actions/workflows/update-ed.yml) - crawls the [nightly](https://github.com/w3c/browser-specs/#nightly) version of specifications and updates the contents of the [`ed`](ed) folder. Workflow runs every 6 hours. Specifications that have not been modified since last crawl are skipped, unless the version of Reffy changed in the meantime. A typical crawl takes a **few minutes** to complete. A full crawl takes up to **12mn**.\n- [Update TR report](https://github.com/w3c/webref/actions/workflows/update-tr.yml) - crawls the [released](https://github.com/w3c/browser-specs/#release) version of specifications and updates the contents of the [`tr`](tr) folder. Workflow runs once per day. A typical crawl takes a **few minutes** to complete. A full crawl takes up to **8mn**.\n- [Curate data &amp; Prepare package PRs](https://github.com/w3c/webref/actions/workflows/curate.yml) - runs whenever crawled data gets updated and updates the `curated` branch accordingly (provided all tests pass). The job also creates pull requests to release new versions of NPM packages when needed. Each pull request details the diff that would be released, and bumps the package version in the relevant `packages/xxx/package.json` file.\n- [Clean up abandoned files](https://github.com/w3c/webref/actions/workflows/cleanup.yml) - checks the contents of repository to detect orphan crawl files that are no longer targeted by the latest crawl's result and creates a PR to delete these files from the repository. Runs once per week on Wednesday. The crawl workflows does not delete these files automatically because crawl sometimes fails on a spec due to transient network or spec errors.\n- [Test](https://github.com/w3c/webref/actions/workflows/test.yml) - runs tests on pull requests.\n- [Clean patches when issues/PR are closed](https://github.com/w3c/webref/actions/workflows/clean-patches.yml) - drops patches that no longer need to apply because underlying issues got fixed. Runs once per week.\n\n### Releases to NPM\n\n- [Publish `@webref/xx` package if needed](https://github.com/w3c/webref/actions/workflows/release-package.yml) - publishes a new version of the `@webref/css`, `@webref/elements`, `@webref/events` or `@webref/idl` package to NPM, tags the corresponding commits on the `main` and `curated` branches, and updates the relevant `@webref/xxx@latest` tag to point to the right commit on the `curated` branch. Runs whenever a pre-release PR is merged. Note that the released version is the version that appeared in `packages/css/package.json`, `packages/elements/package.json`, `packages/events/package.json` or `packages/idl/package.json` **before** the pre-release PR is merged.\n- [`@webref/xx` release: Request review of pre-release PR](https://github.com/w3c/webref/actions/workflows/request-pr-review.yml) - assigns reviewers to NPM package pull requests. Runs once per week.\n"
+        "text": "# Webref\n\n## Description\n\nThis repository contains **machine-readable references of CSS properties, definitions, IDL, and other useful terms that can be automatically extracted from web browser specifications** (see a [list of projects known to use the data](#known-consumers)). The contents of the repository are updated automatically **every 6 hours** (although note information about published _[/TR/](https://www.w3.org/TR/)_ versions of specifications are updated only once per day).\n\nSpecifications covered by this repository are technical Web specifications that appear in [browser-specs](https://github.com/w3c/browser-specs).\n\nThe `main` branch of this repository contains **automatically-generated raw extracts** from web browser specifications. These extracts come with no guarantee on validity or consistency. For instance, if a specification defines invalid IDL snippets or uses an unknown IDL type, the corresponding IDL extract in this repository will be invalid as well.\n\nThe `curated` branch contains **curated extracts**. Curated extracts are generated from raw extracts in the [`ed`](ed) folder by applying manually-maintained patches to fix invalid content and provide [validity and consistency guarantees](#curation-guarantees). The `curated` branch is updated automatically whenever the `main` branch is updated, unless patches need to be modified (which requires manual intervention). Curated extracts are published under https://w3c.github.io/webref/ed/.\n\nAdditionally, subsets of the curated content get manually reviewed and published as **NPM [packages](https://github.com/w3c/webref/tree/main/packages)** on a weekly basis:\n- [`@webref/idl`](https://www.npmjs.com/package/@webref/idl) contains a [curated](packages/idl#guarantees) version of the [`ed/idl`](ed/idl) folder.\n- [`@webref/css`](https://www.npmjs.com/package/@webref/css) contains a [curated](packages/css#guarantees) version of the [`ed/css`](ed/css) folder.\n- [`@webref/elements`](https://www.npmjs.com/package/@webref/elements) contains a [curated](packages/elements#guarantees) version of the [`ed/elements`](ed/elements) folder.\n- [`@webref/events`](https://www.npmjs.com/package/@webref/events) contains a [curated](packages/events#guarantees) version of the [`ed/events`](ed/events) folder.\n\n**Important:** The curated extracts only contain data for specifications that are in [good standing](https://github.com/w3c/browser-specs/#standing) (to keep the number of manually-maintained patches minimal and manageable). The NPM packages only contain curated extracts of specifications that are in good standing and that [target web browsers](https://github.com/w3c/browser-specs/#categories).\n\n**Important:** Unless you are ready to deal with invalid content, we strongly recommend that you process contents of the `curated` branch or NPM packages instead of raw content in the `main` branch.\n\n\n## Available extracts\n\nThis repository contains raw and curated information about [nightly](https://github.com/w3c/browser-specs/#nightly) versions of Web specifications in the [`ed`](https://github.com/w3c/webref/tree/curated/ed) folder, as well as raw information about the [released](https://github.com/w3c/browser-specs/#release) version (for _[/TR/](https://www.w3.org/TR/)_ specifications) in the [`tr`](tr) folder.\n\n**Note:** The [`tr`](tr) folder only contains information about [released](https://github.com/w3c/browser-specs/#release) specifications. Specifications that have not been published as _[/TR/](https://www.w3.org/TR/)_ documents (such as WHATWG specifications or Community Group reports) do not appear under the [`tr`](tr) folder in particular.\n\nMore often than not, released versions of specifications are much older than their nightly version. Data in the [`tr`](tr) folder is more invalid/inconsistent than data in the [`ed`](ed) folder as a result. Additionally, no attempt is being made at curating data in the [`tr`](tr) folder, *use the [`tr`](tr) folder at your own risk!*\n\nThe following subfolders in the `curated` branch contain individual machine-readable JSON or text files generated from specifications:\n\n- [`ed/cddl`](https://github.com/w3c/webref/tree/curated/ed/cddl): CDDL modules. If the specification defines a single CDDL module, one file gets created for the specification. If it defines multiple CDDL modules, one file gets created per CDDL module, plus one file named `[shortname]-all.cddl` with all CDDL definitions.\n- [`ed/css`](https://github.com/w3c/webref/tree/curated/ed/css): CSS terms (properties, descriptors, value spaces). One file per specification [series](https://github.com/w3c/browser-specs/#series).\n- [`ed/dfns`](https://github.com/w3c/webref/tree/curated/ed/dfns): `<dfn>` terms, along with metadata such as linking text, access level, namespace. One file per specification.\n- [`ed/elements`](https://github.com/w3c/webref/tree/curated/ed/elements): Markup elements defined, along with the interface that they implement. One file per specification.\n- [`ed/headings`](https://github.com/w3c/webref/tree/curated/ed/headings): Section headings. One file per specification.\n- [`ed/idl`](https://github.com/w3c/webref/tree/curated/ed/idl): Raw WebIDL index. One file per specification [series](https://github.com/w3c/browser-specs/#series).\n- [`ed/idlnames`](https://github.com/w3c/webref/tree/curated/ed/idlnames): WebIDL definitions per referenceable IDL name. One file per IDL name.\n- [`ed/idlnamesparsed`](https://github.com/w3c/webref/tree/curated/ed/idlnamesparsed): Parsed WebIDL structure of definitions in the `idlnames` folder. One file per IDL name.\n- [`ed/idlparsed`](https://github.com/w3c/webref/tree/curated/ed/idlparsed): Parsed WebIDL structure of definitions in the `idl` folder. One file per specification.\n- [`ed/ids`](https://github.com/w3c/webref/tree/curated/ed/ids): Fragments defined in the specification. One file per specification.\n- [`ed/links`](https://github.com/w3c/webref/tree/curated/ed/links): Links to other documents, along with targeted fragments. One file per specification.\n- [`ed/refs`](https://github.com/w3c/webref/tree/curated/ed/refs): Normative and informative references to other specifications. One file per specification.\n\nIndividual files are named after the shortname of the specification, or after the shortname of the specification series for CSS definitions and raw IDL files. Individual files are only created when needed, meaning when the specification actually includes relevant terms.\n\nThe [`ed/index.json`](https://github.com/w3c/webref/tree/curated/ed/index.json) file contains the index of specifications that have been crawled, and relative links to individual files that have been created.\n\nThis repository uses [Reffy](https://github.com/w3c/reffy), a Web spec exploration tool, to crawl the specifications and generate the data. In particular, the data it contains is the result of running Reffy. The repository does not contain any more data.\n\nRaw WebIDL extracts are used in [web-platform-tests](https://github.com/web-platform-tests/wpt), please see their [interfaces/README.md](https://github.com/web-platform-tests/wpt/blob/master/interfaces/README.md) for details.\n\n\n## Curation guarantees\n\nData curation brings the following guarantees.\n\n### Web IDL extracts\n\n- All IDL files can be parsed by the version of [webidl2.js](https://github.com/w3c/webidl2.js/) referenced in `package.json`.\n- `WebIDL2.validate` passes with the exception of the \"no-nointerfaceobject\" rule about `[LegacyNoInterfaceObject]`, which is in wide use.\n- All types are defined by some specification.\n- All extended attributes are defined by some specification.\n- No duplicate top-level definitions or members.\n- No missing or mismatched types in inheritance chains.\n- No conflicts when applying mixins and partials.\n\n### CSS extracts\n\n- All values in CSS files can be parsed by the version of [CSSTree](https://github.com/csstree/csstree) used in `peerDependencies` in `package.json`.\n- No duplicate definitions of CSS properties provided that CSS extracts of [delta specs](https://github.com/w3c/browser-specs/#seriescomposition) are not taken into account (such extracts end with `-n.json`, where `n` is a level number).\n- CSS extracts contain a base definition of all CSS properties that get extended by other CSS property definitions (those for which `newValues` is set).\n- All entries in CSS files that do not extend a base definition link back to their actual definition in the spec. In other words, all entries under `properties[]`, `properties[].values[]`, `selectors[]`, `atrules[]` and `values[]` have an `href` key that contains an absolute URL with fragment, except properties that that have a `newValues` key, at-rules that neither have a `prose` nor a `value` key, and definitions of a [delta spec](https://github.com/w3c/browser-specs/#seriescomposition) that completely override a definition in a previous level.\n\n### Elements extracts\n\n- All Web IDL interfaces referenced by elements exist in Web IDL extracts.\n- All elements link back to their definition in the spec.\n\n### Events extracts\n\n- All events have a `type` attribute that match the name of the event\n- All events have a `interface` attribute to describe the interface used by the Event. The Web IDL interface exists in the latest version of the [`@webref/idl` package](https://www.npmjs.com/package/@webref/idl) at the time the `@webref/events` package is released, and represents an actual interface (i.e. not a mixin).\n- All events have a `targets` attribute with a non-empty list of target interfaces on which the event may fire. All Web IDL interfaces in the list exist in the latest version of the [`@webref/idl` package](https://www.npmjs.com/package/@webref/idl) at the time the `@webref/events` package is released, and represent an actual interface (i.e. not a mixin).\n- The `bubbles` attribute is always set to a boolean value for target interfaces that belong to a bubbling tree (DOM, IndexedDB, Serial API, Web Bluetooth).\n- The `bubbles` attribute is only set for target interfaces that belong to a bubbling tree.\n- The `bubblingPath` attribute is only set for target interfaces on which the event bubbles.\n- The `targets` attribute contains the top most interfaces in an inheritance chain, unless bubbling conditions differ. For instance, the list may contain `{ \"target\": \"Element\", \"bubbles\": true }` but not also `{ \"target\": \"HTMLElement\", \"bubbles\": true }` since `HTMLElement` inherits from `Element`.\n- For target interfaces that belong to a bubbling tree, the `targets` attribute only contains the deepest interface in the bubbling tree on which the event may fire and bubble. For instance, the list may contain `{ \"target\": \"HTMLElement\", \"bubbles\": true }`, but not also `{ \"target\": \"Document\" }` since event would de facto fire at `Document` through bubbling.\n\n### CDDL extracts\n\nThe CDDL extracts currently come with no guarantee whatsoever and may be invalid. Tracked in [#1417](https://github.com/w3c/webref/issues/1417).\n\n## Known consumers\n\nThe following projects are known to use webref data:\n* MDN content management system, [yari](https://github.com/mdn/yari/)\n* [Web Platform Tests](https://github.com/web-platform-tests/wpt)\n* [Open Web Docs MDN Browser Compat Data collector](https://github.com/openwebdocs/mdn-bcd-collector)\n* [bikeshed](https://speced.github.io/bikeshed/), a specification authoring tool\n* [ReSpec](https://respec.org/docs/), a specification authoring tool\n* [\"DOM\" Bindings for TypeScript](https://github.com/microsoft/TypeScript-DOM-lib-generator)\n* [browser API bindings for Dart](https://github.com/dart-lang/)\n* the [Pulsar text editor](https://github.com/pulsar-edit/pulsar)\n* [PostCSS preset env plugin](https://github.com/csstools/postcss-plugins/tree/main/plugin-packs/postcss-preset-env)\n* [strudy](https://github.com/w3c/strudy)\n* [nodysseus](https://gitlab.com/ulysses.codes/nodysseus)\n* [WebIDLPedia](https://dontcallmedom.github.io/webidlpedia/)\n* [Webdex](https://dontcallmedom.github.io/webdex/)\n\nUsing webref data in a project that is not yet in the list? Let us know!\n\n## Potential spec anomalies\n\nWebref extracts are analyzed with [Strudy](https://github.com/w3c/strudy#strudy) to detect potential spec content anomalies such as broken links or invalid constructs, and report them as issues in the repository that hosts the spec.\n\nGlobal analyses used to be published in the [w3c/webref-analysis](https://github.com/w3c/webref-analysis) repository. That repository was archived in August 2024.\n\n## How to suggest changes or report an error\n\nFeel free to raise [issues in this repository](https://github.com/w3c/webref/issues) as needed. Note that most issues likely more directly apply to underlying tools:\n\n- Errors in the data are most likely caused by bugs or missing features in [Reffy](https://github.com/w3c/reffy), which is the tool that crawls and parses specifications under the hoods. If you spot an error, please report it in [Reffy's issue tracker](https://github.com/w3c/reffy/issues/new).\n- If you believe that a spec is missing from the list, please check [browser-specs](https://github.com/w3c/browser-specs/#how-to-addupdatedelete-a-spec) and report it [there](https://github.com/w3c/browser-specs/issues/new).\n\n\n## Development notes\n\nGitHub Actions workflows are used to automate most of the tasks in this repo.\n\n### Data update\n\n- [Update ED report](https://github.com/w3c/webref/actions/workflows/update-ed.yml) - crawls the [nightly](https://github.com/w3c/browser-specs/#nightly) version of specifications and updates the contents of the [`ed`](ed) folder. Workflow runs every 6 hours. Specifications that have not been modified since last crawl are skipped, unless the version of Reffy changed in the meantime. A typical crawl takes a **few minutes** to complete. A full crawl takes up to **12mn**.\n- [Update TR report](https://github.com/w3c/webref/actions/workflows/update-tr.yml) - crawls the [released](https://github.com/w3c/browser-specs/#release) version of specifications and updates the contents of the [`tr`](tr) folder. Workflow runs once per day. A typical crawl takes a **few minutes** to complete. A full crawl takes up to **8mn**.\n- [Curate data &amp; Prepare package PRs](https://github.com/w3c/webref/actions/workflows/curate.yml) - runs whenever crawled data gets updated and updates the `curated` branch accordingly (provided all tests pass). The job also creates pull requests to release new versions of NPM packages when needed. Each pull request details the diff that would be released, and bumps the package version in the relevant `packages/xxx/package.json` file.\n- [Clean up abandoned files](https://github.com/w3c/webref/actions/workflows/cleanup.yml) - checks the contents of repository to detect orphan crawl files that are no longer targeted by the latest crawl's result and creates a PR to delete these files from the repository. Runs once per week on Wednesday. The crawl workflows does not delete these files automatically because crawl sometimes fails on a spec due to transient network or spec errors.\n- [Test](https://github.com/w3c/webref/actions/workflows/test.yml) - runs tests on pull requests.\n- [Clean patches when issues/PR are closed](https://github.com/w3c/webref/actions/workflows/clean-patches.yml) - drops patches that no longer need to apply because underlying issues got fixed. Runs once per week.\n\n### Releases to NPM\n\n- [Publish `@webref/xx` package if needed](https://github.com/w3c/webref/actions/workflows/release-package.yml) - publishes a new version of the `@webref/css`, `@webref/elements`, `@webref/events` or `@webref/idl` package to NPM, tags the corresponding commits on the `main` and `curated` branches, and updates the relevant `@webref/xxx@latest` tag to point to the right commit on the `curated` branch. Runs whenever a pre-release PR is merged. Note that the released version is the version that appeared in `packages/css/package.json`, `packages/elements/package.json`, `packages/events/package.json` or `packages/idl/package.json` **before** the pre-release PR is merged.\n- [`@webref/xx` release: Request review of pre-release PR](https://github.com/w3c/webref/actions/workflows/request-pr-review.yml) - assigns reviewers to NPM package pull requests. Runs once per week.\n"
       },
       "w3c": {
         "group": 102,
@@ -180294,7 +180452,7 @@
         "body": "# Code of Conduct\n\nAll documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).\n"
       },
       "readme": {
-        "text": "# Device Bound Session Credentials explainer\n\nThis is the repository for Device Bound Session Credentials. You're welcome to\n[contribute](CONTRIBUTING.md)!\n\n## Authors:\n- [Kristian Monsen](kristianm@google.com), Google\n- [Arnar Birgisson](arnarb@google.com), Google\n\n## Participate (to come)\n- [Issue tracker](https://github.com/WICG/dbsc/issues)\n- [Discussion forum]\n\n## Table of Contents\n<!-- START doctoc generated TOC please keep comment here to allow auto update -->\n<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->\n\n- [Introduction](#introduction)\n  - [Goals](#goals)\n  - [Non-goals](#non-goals)\n  - [What makes Device Bound Session Credentials different](#what-makes-device-bound-session-credentials-different)\n    - [Application-level binding](#application-level-binding)\n    - [Browser-initiated refreshes](#browser-initiated-refreshes)\n  - [TPM considerations](#tpm-considerations)\n  - [Privacy considerations](#privacy-considerations)\n  - [Enterprise support](#enterprise-support)\n- [High level overview](#high-level-overview)\n  - [Start Session](#start-session)\n    - [Session Registration Header](#session-registration-header)\n    - [Session Registration JWT](#session-registration-jwt)\n    - [Session Registration instructions JSON](#session-registration-instructions-json)\n  - [Maintaining a session](#maintaining-a-session)\n    - [Refresh procedure](#refresh-procedure)\n    - [Ending a session](#ending-a-session)\n- [Interactions with other APIs](#interactions-with-other-apis)\n  - [Login Status API](#login-status-api)\n  - [Interaction with Inactive Documents (BFCache, Prerendering)](#interaction-with-inactive-documents-bfcache-prerendering)\n- [Alternative JavaScript API for StartSession](#alternative-javascript-api-for-startsession)\n\n<!-- END doctoc generated TOC please keep comment here to allow auto update -->\n\n## Introduction\nDevice Bound Session Credentials (DBSC) aims to reduce account hijacking caused by cookie theft. It does so by introducing a protocol and browser infrastructure to maintain and prove possession of a cryptographic key. The main challenge with cookies as an authentication mechanism is that they only lend themselves to bearer-token schemes. On desktop operating systems, application isolation is lacking and local malware can generally access anything that the browser itself can, and the browser must be able to access cookies. On the other hand, authentication with a private key allows for the use of system-level protection against key exfiltration.\n\nDBSC offers an API for websites to control the lifetime of such keys, behind the abstraction of a session, and a protocol for periodically and automatically proving possession of those keys to the website's servers.  There is a seperate key for each session, and it should not be possible to detect two different session keys are from one device. One of the key goals is to enable drop-in integration with common types of current auth infrastructure. By device-binding the private key and with appropriate intervals of the proofs, the browser can limit malware's ability to offload its abuse off of the user's device, significantly increasing the chance that either the browser or server can detect and mitigate cookie theft.\n\nDBSC is bound to a device with cryptographic keys that cannot be exported from the user’s device under normal circumstances, this is called device binding in the rest of this document. DBSC provides an API that servers can use to create a session bound to a device, and this session can periodically be refreshed with an optional cryptographic proof the session is still bound to the original device. At sign-in, the API informs the browser that a session starts, which triggers the key creation. It then instructs the browser that any time a request is made while that session is active, the browser should ensure the presence of certain cookies. If these cookies are not present, DBSC will hold network requests while querying the configured endpoint for updated cookies.\n\n### Goals\nReduce session theft by offering an alternative to long-lived cookie bearer tokens, that allows session authentication that is bound to the user's device. This makes the internet safer for users in that it is less likely their identity is abused, since malware is forced to act locally and thus becomes easier to detect and mitigate. At the same time the goal is to disrupt the cookie theft ecosystem and force it to adapt to new protections.\n\n### Non-goals\nDBSC will not prevent temporary access to the browser session while the attacker is resident on the user’s device. The private key should be stored as safe as modern desktop operating systems allow, preventing exfiltration of the session private key, but the signing capability will still be available for any program running as the user on the user’s device. \n\n### What makes Device Bound Session Credentials different\nDBSC is not the first proposal towards these goals, with a notable one being [Token Binding](https://en.wikipedia.org/wiki/Token_Binding). This proposal offers two important features that we believe makes it easier to deploy than previous proposals. DBSC provides application-level binding and browser initiated refreshes that can make sure devices are still bound to the original device.\n\n#### Application-level binding\nFor websites, device binding is most useful for securing authenticated sessions of users. DBSC allows websites to closely couple the setup of bound sessions with user sign-in mechanisms, makes session and key lifetimes explicit and controllable, and allows servers to design infrastructure that places verification of session credentials close to where user credentials (cookies) are processed in their infrastructure.\n\nAlternatives such as Token Binding gain much from e.g. integrating with TLS, but this can make integration harder in environments where e.g. TLS channel termination is far removed from the application logic behind user sign-in and session management.\n\n#### Browser-initiated refreshes\nOther proposals have explored lower-level APIs for websites to create and use protected private keys, e.g. via WebCrypto or APIs similar to WebAuthn. While this works in theory, it puts a very large burden on the website to integrate with. In particular, since the cost of using protected keys is high, websites must design some infrastructure for collecting signatures only as often as needed.\n\nThis means either high-touch integrations where the keys are only used to protect sensitive operations (like making a purchase), or a general ability to divert arbitrary requests to some endpoint that collects and verifies a signature and then retries the original request. The former doesn't protect the whole session and violates the principle of secure by default, while the latter can be prohibitively expensive for large websites built from multiple components by multiple teams, and may require non-trivial rewrites of web and RPC frameworks.\n\nDBSC instead allows a website to consolidate the session binding to a few points: At sign-in, it informs the browser that a session starts, which triggers the key creation. It then instructs the browser that any time a request is made while that session is active, the browser should ensure the presence of certain cookies. The browser does this by calling a dedicated refresh endpoint (specified by the website) whenever such cookies are needed, presenting that endpoint with a proof of possession of the private key. That endpoint in turn, using existing standard Set-Cookie headers, provides the browser with short-term cookies needed to make other requests.\n\nThis provides two important benefits:\n1. Session binding logic is consolidated in the sign-in mechanism, and the new dedicated refresh endpoint. All other parts of the website continue to see cookies as their only authentication credentials, the only difference is that those cookies are short-lived. This allows deployment on complex existing setups, often with no changes to non-auth related endpoints.\n1. If a browser is about to make a request where it has been instructed to include such a cookie, but doesn't have one, it defers making that request until the refresh is done. While this may add latency to such cases, it also means non-auth endpoints do not need to tolerate unauthenticated requests or respond with any kind of retry logic or redirects. This again allows deployment with minimal changes to existing endpoints.\n\nNote that the latency introduced by deferring of requests can be mitigated by the browser in other ways, which we discuss later.\n\n### TPM considerations\nDBSC depends on user devices having a way of signing challenges while protecting private keys from exfiltration by malware. This usually means the browser needs to have access to a Trusted Platform Module (TPM) on the device, which is not always available. TPMs also have a reputation for having high latency and not being dependable. Having a TPM is a requirement for installing Windows 11, and can be available on previous versions. All our studies are for public key cryptography using ECDSA_P256 algorithm.\n\n Chrome has done studies to understand TPM availability to understand the feasibility of secure sessions. Current data shows about 60%, and currently growing, of Windows users would be offered protections. Studies have also been done on the current populations of TPMs, both for latency and for predictability. Currently the latency is (P50: 200ms/ P95: 600ms) for signing operations. The error rate is very low, currently around 0.001%.\n\nBased on this research, TPMs are widely available, with a latency and consistency that is acceptable for the proposed usage.\n\n### Privacy considerations\nAn important high-level goal of this protocol is to introduce no additional surface for user tracking: implementing this API (for a browser) or enabling it (for a website) should not entail any significant user privacy tradeoffs.\n\nThere are a few obvious considerations to ensure we achieve that goal:\n- Lifetime of a session/key material: This should provide no additional client data storage (i.e., a pseudo-cookie). As such, we require that browsers MUST clear sessions and keys when clearing other site data (like cookies).\n- Cross-site/cross-origin data leakage: It should be impossible for a site to use this API to circumvent the same origin policy, 3P cookie policies, etc. (More on this below.)\n- Implementing this API should not meaningfully increase the entropy of heuristic device fingerprinting signals. (For example, it should not leak any stable TPM-based device identifier.)\n- This API—which allows background \"pings\" to the refresh endpoint when the user is not directly active—must not enable long-term tracking of a user when they have navigated away from the connected site.\n- Each session has a separate new key created, and it should not be possible to detect that different sessions are from the same device.\n\n### Enterprise support\n\nWhile DBSC addresses a general problem of session hijacking, and can be applicable to any _browser_ consumer, it is possible to expand this protocol to better support enterprise use cases. By adding specifics to key generation, we can provide a more secure environment for enterprise users. This is the goal of DBSC(E), which is an extension to DBSC. The high-level design of DBSC(E) is described in the [DBSC(E) Overview](./DBSCE/Overview.md).\n\nDBSC(E) removes the vulnerability DBSC has, where a malware, if already present in the device during the key generation, can potentially take over the session. DBSC(E) proposes to mitigate this vulnerability by introducing device key chaining: More details about the importance of DBSC are here: [Why DBSC(E)?](./DBSCE/Overview.md/#why-dbsce)\n\n## High level overview\n![High level diagram](reg_and_refresh.svg)\n[Link to editable diagram](https://sequencediagram.org/index.html#initialData=A4QwTgLglgxloDsIAIBEAVACgWVckAzshAFCiSzwhJoBCYA9gO4ECmYehyARmeNHEQpUAZXYA3dpyJMScktwC0APiYAuZASgBzBIqgJkAMwA2zEkxXcNAJgAMd5EwD0W3awAm+wzAZJWSAA0yGCsBMB+bMgGMCYArh5hyAAWrCCJYMQMmhD8mqwwcaH5BFp+AHTIyAA6CAASaRkaqKIFimKlUH6KAEqs2lAEEGAg0H4a5ZPIMMkgJiYB2qwAvJPlLbUAFDNzCwhLIawAjnFQoR7GDJnAYFDio6zIANasAJ7INwwMRsjfHwylMJlBAAShICAYEEeDEkmWsPEYLHY0QQUGgDyIbE6fh4Bg8Bm0tW4hE8v0MqXSyJuYQCMFYChUEA0oROYRQMFCD2eb1AZxIECszNYECKhmAcW4Jlg3Ne4Mh0NhPA0HLSUOQACkAOroJzOHbzRb0pTKJksuJszQ6Qxa9D8wWHEVga3ay26UZFI0qdTITAAeREOtcBQ9WOBrlykFDXUMtVqLQA3qg5tpUGo1sFUBBXsBU6gbahgmsAL7x9OoF6vXMAHnFktgAH0K8pUEWWsg5WqYcjvUMro9a1KYDLgmyQHWCMkSsCLPb7I4XL4GE8oI9qBcoziAJIAESJDA87xi8USmN8wGhP0Xy6SmyuOgMyAA1B9RskQbGEBSmmhWgKAMJfNeGggHEEDJPWV4rhsCDcPurzNKgiYbgg9ZQIkSBQEYK4cGmkytqgJDLMsIgMAAto80DkS+gIEGsREdgqyLwnEbCZLEsBPEQUoIE8lzXK+yCuGRBR+FCSAMso8IzAUvGYb8twDAgj6gGBhwnGcSSwXECAXJB9JzCgWk6dMgErsgEIoGaGkeBJ3oAOIAKKBgQwm+P44mWJJtgOLqbliaQrAmFERm6aZjxWecElSakMCyT8EWknpRCsAAHoMpAGWppznCZS5mdSbA0Gu5mQsgqXANZtkaI5zmuaJASkJ58Jzr59XiYFUQJaFeWPKRgxaPs8llSlFWRRZjFwkKrJDMgiRGOwOVMMkUALE4jxLOyYW0ZMVU+v6znBqEyHOKERhHZOtRfuwCFiDA7RAtGiibh4GgANrIcgO4ALotDOXkACx2AAjB+DSUmAN1tB0wKKH+swGvsrAaMhqHodAWHsKskzBPqexLFj6wEeNvyKlJnJqjavnw3jnommoZoWm4zq2gKXkOqKGoukz7qhLtfoBoJbCFEdD1+CdrBnWEF2fo010-rd93YnofThJESPIK9No-UT8ok92Gj3FKHhcp8fx-BENHRn91gtQuYX4MZH07nuB4orECRJAQZ4Xrl15ELeCkPs+Klvh+V0Q-Lwqw2FwGgeBenQbBB4IUhosoWhDWYdhqbFr9xNdpN+TC48H2juOqQeMER1xORtR3opcxZWyu01YLdXuY1s4+S4LlUX5DUkAENlD0AA))  \nThe general flow of a secure session is as follows:\n1. The website requests that the browser start a new session, providing an HTTP endpoint to negotiate registration parameters.\n1. The browser creates a device-bound key pair, and calls the registration HTTP endpoint to set up the session and register the public key.\n1. The server responds with a session identifier, and instructions on how to maintain the session. This is a (possibly empty) list of cookie names that the browser is expected to ensure exist, and their associated scope (origins+path).\n1. At a later time the session is closed by either the server requesting to close the session or the user clears the keys by clearing site data.\n\nAs long as that session is active, the browser performs the following refresh as needed:\n1. For any request within an applicable scope, the browser checks if the necessary cookies exist. If they exist, continue as normal.\n1. If not, the browser defers such requests while performing the following.\n1. The browser contacts the HTTP endpoint for the session, providing the session identifier and, if requested by the server, the necessary proof of possession of the associated private key. \n1. If the server is satisfied with the proof, it uses regular Set-Cookie headers to establish the necessary cookies with an appropriate Max-Age. The response can also include an updated set of instructions, e.g. if the server wishes to change which cookies are subject to this logic.\n1. If any requests were deferred in step 2, the browser now makes those requests including the updated set of cookies.\n1. The browser may choose to proactively refresh cookies that are about to expire, if it predicts the user may soon need them. This is purely a latency optimization, and not required.\n\nThere is an option for the server to opt out of the browser defering requests. If so it will instead:\n1. Sign any requests that would be defered, use the most recent challange. If there is not one, use the current timestamp. The browser may cache these signatures.\n1. The server can respond with 401 if it wants the request signed with a new challenge.\n1. The server can also serve challenges ahead of time on any response with the Sec-Session-Challenge header.\n1. Once the browser get an instruction to set the missing cookie it will stop signing requests.\nWe do not reccomend this option for most deployments, but it is possibly for those that want to potentially save a network roundtrip in some circumstances.\n\n\n### Start Session\n![Start session diagram](header_setup.svg)\n\n[Link to editable diagram](https://sequencediagram.org/index.html#initialData=MoUwTgbuC0B8CqBncACAggcxAOwC4C4VQBjaURRASwHttoAlEDSxXMAQ1xuwCgeMw1AK4AHFMlyjxICtxRgQARyEzcPJKkw5ccUJHD4ACgHlgAFRQB6ZMSELks2tdzswuB1Vo9s1XCBTUUGAoGsFaeAA0ekEAxADuABYgnPgA3gBEAEaU2AAmORjQ7AA2GPgAdJXpAL7qyGFYeAA8ZOBB+KA6AMLU1ADWlCCE7EK4CQD6xL0DIN6+-oGooeiNuFFt4PFJKRke3NCUudqUAGaDYBVVtTi5fD5+AUEh9SvaW8kE5J7YKCwoPnEUOxiFwoDwgA)\n\n#### Session Registration Header\nThe session start process is initiated by the server attaching a header with Sec-Session-Registration and appropriate parameters, this looks like:\n```http\nHTTP/1.1 200 OK\nSec-Session-Registration: (RS256 ES256);challenge=\"challenge_value\";path=\"StartSession\"\n```\nThis is a structured header with a list of token arguments representing the allowed algorithms (possibilities are ES256 and RS256). The list have multiple string attributes, \"path\" is required describing the endpoint to use, \"challenge\" is to provide a challenge value for the registration JWT. There is also an optional string attribute called authorization. There can be more than one registration on one response:\n```http\nHTTP/1.1 200 OK\nSec-Session-Registration: (ES256 RS256);path=\"path1\";challenge=\"challenge_value\";authorization=\"authcode\"\nSec-Session-Registration: (ES256);path=\"path2\";challenge=\"challenge_value\"\n```\n\nAn equivalent way of writing this is:\n```http\nHTTP/1.1 200 OK\nSec-Session-Registration: (ES256 RS256);path=\"path1\";challenge=\"challenge_value\";authorization=\"authcode\", (ES256);path=\"path2\";challenge=\"challenge_value\"\n```\n\nThe authorization value is optional for servers to send, but mandatory for clients to implement. If present, it will be sent to the registration endpoint in the `Authorization` header, and included in the registration JWT. This allows passing a bearer token that allows the server to link registration with some preceding sign in flow, as an alternative to the more traditional use of cookies. While this can also facilitate integration with some existing infrastructure, e.g. ones based on OAuth 2.0, this parameter is general and is not limited to the similarly named [Authorization Code](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1) in OAuth 2.0.\n\n#### Session Registration JWT\nThe browser responds to the session start by selecting a compatible signature algorithm and creating a device-bound private key for the new session. It then makes the following HTTP request (assuming the endpoint URL is https://auth.example.com/securesession):\n\n```http\nPOST /securesession/startsession HTTP/1.1\nHost: auth.example.com\nAccept: application/json\nCookie: whatever_cookies_apply_to_this_request=value;\nSec-Session-Response: JWT Proof\n\n```\nThe JWT proof is signed with the newly created private key, and needs to contain the following values (the public key is in the [JWK](https://datatracker.ietf.org/doc/html/rfc7517) format):\n```jsonc\n// Header\n{\n  \"alg\": \"Signature Algorithm\",\n  \"typ\": \"JWT\",\n}\n// Payload\n{\n  \"aud\": \"URL of this request\",\n  \"jti\": \"challenge_value\",\n  \"iat\": \"timestamp\",\n  \"key\": {\n    \"kty\": \"key type\",\n    \"<kty-specific parameters>\": \"<value>\",\n  },\n  \"authorization\": \"<authorization_value>\", // optional, only if set in registration header\n}\n```\n\n#### Session Registration instructions JSON\nIf the request is properly authorized, the server establishes whatever state represents the session server-side, and returns the following response.\n\n```http\nHTTP/1.1 200 OK\nContent-Type: application/json\nCache-Control: no-store\nSet-Cookie: auth_cookie=abcdef0123; Domain=example.com; Max-Age=600; Secure; HttpOnly;\n```\n\n```jsonc\n{\n  \"session_identifier\": \"session_id\",\n  \"refresh_url\": \"/RefreshEndpoint\",\n\n  \"scope\": {\n    // Origin-scoped by default (i.e. https://example.com)\n    // Specifies to include https://*.example.com except excluded subdomains.\n    // This can only be true if the origin's host is the root eTLD+1.\n    \"origin\": \"example.com\",\n    \"include_site\": true,\n    \"defer_requests\": true, // optional and true by default\n\n    \"scope_specification\" : [\n      { \"type\": \"include\", \"domain\": \"trusted.example.com\", \"path\": \"/only_trusted_path\" },\n      { \"type\": \"exclude\", \"domain\": \"untrusted.example.com\", \"path\": \"/\" },\n      { \"type\": \"exclude\", \"domain\": \"*.example.com\", \"path\": \"/static\" }\n    ]\n  },\n\n  \"credentials\": [{\n    \"type\": \"cookie\",\n    // This specifies the exact cookie that this config applies to. Attributes\n    // match the cookie attributes in RFC 6265bis and are parsed similarly to\n    // a normal Set-Cookie line, using the same default values.\n    // These SHOULD be equivalent to the Set-Cookie line accompanying this \n    // response.\n    \"name\": \"auth_cookie\",\n    \"attributes\": \"Domain=example.com; Path=/; Secure; SameSite=None\"\n    // Attributes Max-Age, Expires and HttpOnly are ignored\n  }]\n}\n```\n\nIf the request is not properly authorized, the server can request a new signed request by answering instead with a 401:\n\n```http\nHTTP/1.1 401\nSec-Session-Challenge: \"challenge_value\"\n```\n\nWhere Sec-Session-Challenge header is a structured header with a list of challenge values that may specify an optional \"id\" parameter: \"challenge_value\";id=\"session_id\".\nThe challenge applies to the current context if \"id\" is not present; otherwise it applies to the specific session. The browser ignores the challenge if \"id\" doesn't match any session locally.\n\nSubsequently, as long as the browser considers this session \"active\", it follows the steps above, namely by refreshing the auth_cookie whenever needed, as covered in the next section.\n\nNote if multiple cookies are required, the server returns multiple Set-Cookie headers, with corresponding entries in the \"credentials\" array in the response body.  \n\n### Maintaining a session\nAs long as the named cookie is not expired the browser will keep sending requests as normal. Once the cookie is expired the browser will hold all requests for the scope of the cookie, except where the server excluded the paths in the registration, while refreshing the cookie. This is where the browser driven protocol makes a difference, if not for this there would be potentially many requests without the required cookie.\n#### Refresh procedure\n![Refresh diagram](refresh_v2.svg)\n\n[Link to editable diagram](https://sequencediagram.org/index.html#initialData=A4QwTgLglgxloDsIAICqBnApmZBBA5pkgFCiSzwhLIASmANgCbIBKmAjgK6boTqnhocRCgDK2AG7ZixBAHsImZHKk4M2PISQAacWFUBiAO4ALTCAgAucenRQ5CZDDlyA1lCUhOEEwH1nbh7ImAAewFBgmIzE6jgERBAAtAB8dEysHNy86JbIAOIAogAqwSEgALbA9JgAdM7lAPTAYAqYMIqMvpFcPBDE+C2cwBkAZpHoJshYtvYIMVhxWknJeqqWAAoA8qIlDVgwnOM8dg4NkWM8JsSr2CmxmgmWNEVF68gALAAMAIyyrcqqNALB46G5gYxmCzWNqJGwnBCJADCJhA9GqCEIlhq2Jq8w08SQKTBG22u32hx4x1mZ0wFwmf0UAI09wJEF0kmwEPMVgA3gAicQwWFUhyJNjoYAOLHYvkAX2uHLAd2BrKeLzeACZPp8GUoVMyVUt2fpOaZudCkoiXO5MLkvD5-NaPABeCSo7jEIjReSM-VqQ0JY2GM1QtjVEBYZBmdLdLJ8ZBGKA+JxOnjIc7jMzRFlLImK3KFEqhCpVWr1JotRTtKJdTK9YhAA)\n\nThe browser refreshes the short-term session credential by calling the session endpoint:\n\n```http\nPOST /securesession/refresh HTTP/1.1\nHost: auth.example.com\nAccept: application/json\nCookie: whatever_cookies_apply_to_this_request=value;\nSec-Session-Id: session_id\n```\n\nIn response to this the server can optionally first request a proof of possession of the key by issuing a challenge to the browser by responding with a 401 response with a challenge:\n\n```http\nHTTP/1.1 401\nSec-Session-Challenge: \"challenge_value\";id=\"session_id\"\n```\n\nThe server can also serve challenges ahead of time attached to any response as an optimization, for example:\n```http\nHTTP/1.1 XXX\nSec-Session-Challenge: \"challenge_value\";id=\"session_id\"\n```\n\nIt is also possible to send challenges to multiple sessions:\n```http\nHTTP/1.1 XXX\nSec-Session-Challenge: \"challenge 1\";id=\"session 1\"\nSec-Session-Challenge: \"challenge 2\";id=\"session 2\"\n```\n\nThis can also be formatted as:\n```http\nHTTP/1.1 XXX\nSec-Session-Challenge: \"challenge 1\";id=\"session 1\", \"challenge 2\";id=\"session 2\"\n```\nas each challenge is a structured header item.\n\nThe browser replies to that response with a Sec-Session-Response header, containing a signed JWT:\n\n```http\nPOST /securesession/refresh HTTP/1.1\nSec-Session-Response: JWT proof\n```\n\nThe JWT proof contains:\n```json\n{\n  \"jti\": \"challenge_value\",\n  \"aud\": \"the URL to which the Sec-Session-Response will be sent\",\n  \"sub\": \"the session ID corresponding to the binding key\",\n}\n```\n\nIf the server is satisfied with the response, or if it did not request it, it answers by setting the short term cookie. Optionally the server can adjust the session in the body of the response (similar to how it was set up)[https://github.com/WICG/dbsc/blob/main/README.md#session-registration-instructions-json].\n\n```http\nHTTP/1.1 200 OK\nContent-Type: application/json\nCache-Control: no-store\nSet-Cookie: auth_cookie=abcdef0123; Domain=example.com; Max-Age=600; Secure; HttpOnly;\n```\nThe contents is a json with the same specifications as during the registration.\nOn receiving this response, the browser releases any requests that were deferred pending this refresh, including the new cookie.\nNote:\nThis response is identical to the response to session setup, and can be handled by the same logic in the client.\nThe new set of instructions replaces any previous instructions for the session. E.g. if the cookie name is different here than before, the browser should not trigger refreshes based on the absence of the old cookie name.\nThe server may issue a different Max-Age, or scope for the short-term cookie.\nThe server may set or update other cookies not subject to session refreshes in this response, as in any response.\n\nIf instead the server decides to end the session it can respond with:\n```json\n{\n  \"session_identifier\": \"session_id\",\n  \"continue\": false\n }\n```\nIn this case the browser should stop triggering any refreshes for this request, release any deferred requests without the short-term cookie, and clean up and delete the associated session state including the binding key.\n\n#### Ending a session\nThe session can end in several ways:\n- The server can end the session during a refresh by answering with {“continue”: false} during a refresh\n- The server can at any time send a header with Clear-Site-Data: \"storage\"\n- The user can clear site data, which will locally clear cookies and any registered session keys for the site\n\nIt is important that the user is always in control and can delete the session keys if wanted.\n\n## Interactions with other APIs\n### Login Status API\n### Interaction with Inactive Documents (BFCache, Prerendering)\nWhen a session is ended for any reason, any inactive documents which had access to that session's credentials should be destroyed. This ensures that pages in BFCache or that are pre-rendering that contain information guarded by those credentials are not presented after the session has ended.\n\n## Alternative JavaScript API for StartSession\n![Start session diagram](dbsc_js_v2.svg)\n\n[Link to editable diagram](https://sequencediagram.org/index.html#initialData=A4QwTgLglgxloDsIAIDqBTARsgCiA5ugFCiSzwhLICqAzumMgIKFInjRyIoDKDAbgyJF8YAPYBXYMh4QOyerVpQxCIhmx5CAWgB8dBs1YQAXMgQh+UfCAhiwAOnowJYdIuWqncyAAoHAQCURAhiEOjIYoKMBows6EgAxADuABbotiYAwm62EQDW6ACeyKBQYESxRgkQenxg0SY4API8ACrIAPTOru7ungjdPhAhYRFRhlXxSAA09dEp6ZkA3gBEmFAIACab+NogADb4JgEOqwC+RPMMelPGJgASbW04yABMAAwfo+GR0TT0OLGOYCBiLDKmPi1LJiMT5KDoMwgCQQVIAfRgsPh6AAvPxDhJiBpcAR0AAebR3GpmYDiAC2UHoDjctDEB0E-iCRASWx+43+xK06BBDTBaQhJj4ShUCGQjPMYmSyBAMGggiIQA)\n\nThe API consists of a new interface, SecureSession, an instance of which is obtained via the securesession property of the navigator object. The SecureSession interface supports the following method:\n\n- **startSession():**\n- Parameters:\n  - endpoint: The URL of the secure session endpoint, supporting /startsession and /refresh operations\n  - supported_binding_algs: Array of cryptographic algorithms supported by the server\n  - authorization: Optional authorization value to be passed to Start Session HTTP request\n- Returns:\n  - A promise with a string containing the session ID (which may be empty)\n\nWhen called, this method must:\n- Generate and store a new, secure cryptographic key pair\n- Call the \"endpoint\" + /startsession as specified below in Start Session (HTTP Request/Response)\n- Return a promise which\n  - If that call succeeds (i.e. returns an HTTP 200), returns a session ID obtained from that call (which can be the empty string)\n  - If that call fails, throws an exception (which may indicate the HTTP status of the failed call)\n\nRequirements:\n- The endpoint must have the same origin as the JavaScript.\n\nBelow is an example of the API being used:\n```javascript\nlet promise = navigator.secureSession.start({\n  // Session start options\n  \"endpoint\": \"<url prefix of standard session endpoint>\", // required\n  \"supportedBindingAlgorithms\": [\"ES256,RS256\"], // required\n  \"authorization\": \"<authorization value>\", // optional\n});\npromise.then((sessionInfo) => {\n  // Success means the browser has completed the session setup with the\n  // session endpoint and will perform the necessary maintenance tasks\n  // going forward.\n  console.log(\"Session with id {} was started.\", sessionInfo.id);\n});\npromise.catch((...) => {\n  // Session start failed for some reason, e.g. the HTTP endpoint was\n  // not reachable, or broke protocol.\n  <error handling>\n});\n```\n"
+        "text": "# Device Bound Session Credentials explainer\n\nThis is the repository for Device Bound Session Credentials. You're welcome to\n[contribute](CONTRIBUTING.md)!\n\n## Authors:\n- [Kristian Monsen](kristianm@google.com), Google\n- [Arnar Birgisson](arnarb@google.com), Google\n\n## Participate (to come)\n- [Issue tracker](https://github.com/WICG/dbsc/issues)\n- [Discussion forum]\n\n## Table of Contents\n<!-- START doctoc generated TOC please keep comment here to allow auto update -->\n<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->\n\n- [Introduction](#introduction)\n  - [Goals](#goals)\n  - [Non-goals](#non-goals)\n  - [What makes Device Bound Session Credentials different](#what-makes-device-bound-session-credentials-different)\n    - [Application-level binding](#application-level-binding)\n    - [Browser-initiated refreshes](#browser-initiated-refreshes)\n  - [TPM considerations](#tpm-considerations)\n  - [Privacy considerations](#privacy-considerations)\n  - [Enterprise support](#enterprise-support)\n- [High level overview](#high-level-overview)\n  - [Start Session](#start-session)\n    - [Session Registration Header](#session-registration-header)\n    - [Session Registration JWT](#session-registration-jwt)\n    - [Session Registration instructions JSON](#session-registration-instructions-json)\n  - [Maintaining a session](#maintaining-a-session)\n    - [Refresh procedure](#refresh-procedure)\n    - [Ending a session](#ending-a-session)\n- [Interactions with other APIs](#interactions-with-other-apis)\n  - [Login Status API](#login-status-api)\n  - [Interaction with Inactive Documents (BFCache, Prerendering)](#interaction-with-inactive-documents-bfcache-prerendering)\n- [Alternative JavaScript API for StartSession](#alternative-javascript-api-for-startsession)\n\n<!-- END doctoc generated TOC please keep comment here to allow auto update -->\n\n## Introduction\nDevice Bound Session Credentials (DBSC) aims to reduce account hijacking caused by cookie theft. It does so by introducing a protocol and browser infrastructure to maintain and prove possession of a cryptographic key. The main challenge with cookies as an authentication mechanism is that they only lend themselves to bearer-token schemes. On desktop operating systems, application isolation is lacking and local malware can generally access anything that the browser itself can, and the browser must be able to access cookies. On the other hand, authentication with a private key allows for the use of system-level protection against key exfiltration.\n\nDBSC offers an API for websites to control the lifetime of such keys, behind the abstraction of a session, and a protocol for periodically and automatically proving possession of those keys to the website's servers.  There is a seperate key for each session, and it should not be possible to detect two different session keys are from one device. One of the key goals is to enable drop-in integration with common types of current auth infrastructure. By device-binding the private key and with appropriate intervals of the proofs, the browser can limit malware's ability to offload its abuse off of the user's device, significantly increasing the chance that either the browser or server can detect and mitigate cookie theft.\n\nDBSC is bound to a device with cryptographic keys that cannot be exported from the user’s device under normal circumstances, this is called device binding in the rest of this document. DBSC provides an API that servers can use to create a session bound to a device, and this session can periodically be refreshed with an optional cryptographic proof the session is still bound to the original device. At sign-in, the API informs the browser that a session starts, which triggers the key creation. It then instructs the browser that any time a request is made while that session is active, the browser should ensure the presence of certain cookies. If these cookies are not present, DBSC will hold network requests while querying the configured endpoint for updated cookies.\n\n### Goals\nReduce session theft by offering an alternative to long-lived cookie bearer tokens, that allows session authentication that is bound to the user's device. This makes the internet safer for users in that it is less likely their identity is abused, since malware is forced to act locally and thus becomes easier to detect and mitigate. At the same time the goal is to disrupt the cookie theft ecosystem and force it to adapt to new protections.\n\nDBSC's primary threat model is that of an attacker who can read and tamper with the user agent, such as with a malware-compromised browser, in which the malware can read and modify browser memory and secrets stored on disk. In many operating systems, malware may be able to obtain privileged (root, kernel, etc.) access. DBSC aims to address this threat by establishing a cryptographic protocol in which secrets can be stored in dedicated systems (such as secure enclaves), though DBSC does not specify how implementors should store, backup, or sync keys as long as such storage is robust against the described threat. \n\nAs a secondary consideration, DBSC also mitigates against certain types of network and server compromise, such as network Attackers-in-the-Middle (where an attacker can read or modify network traffic) or HTTP server log leaks (where a server mistakenly logs full HTTP request/response headers to logs which can be read by unprivileged insiders).\n\nIn all of these scenarios, DBSC aims to enforce the specific constraint that *temporary read/write access to a user agent or network traffic does not enable long-lived access to any established DBSC sessions*. For example, if an attacker has malware running within a victim browser process, they should be unable to continue to authenticate as the victim browser once that malware is removed. (Note, however, that the definition of \"long-lived\" depends upon the configured refresh period; within that period, attackers *may* continue to have short-lived access to any established sessions.)\n\n### Non-goals\nDBSC will not prevent temporary access to any browser sessions while the attacker has ongoing access to a compromised user-agent. An attacker with ongoing access to a compromised user agent (or network AitM, etc) will be able to continuously access fresh DBSC-controlled bearer tokens, and an attacker with malware running on a compromised device will, on many modern operating systems, be able to treat even secure elements as a signing oracle, in order to provide proof-of-possession of the DBSC secret keys.\n\n### What makes Device Bound Session Credentials different\nDBSC is not the first proposal towards these goals, with a notable one being [Token Binding](https://en.wikipedia.org/wiki/Token_Binding). This proposal offers two important features that we believe makes it easier to deploy than previous proposals. DBSC provides application-level binding and browser initiated refreshes that can make sure devices are still bound to the original device.\n\n#### Application-level binding\nFor websites, device binding is most useful for securing authenticated sessions of users. DBSC allows websites to closely couple the setup of bound sessions with user sign-in mechanisms, makes session and key lifetimes explicit and controllable, and allows servers to design infrastructure that places verification of session credentials close to where user credentials (cookies) are processed in their infrastructure.\n\nAlternatives such as Token Binding gain much from e.g. integrating with TLS, but this can make integration harder in environments where e.g. TLS channel termination is far removed from the application logic behind user sign-in and session management.\n\n#### Browser-initiated refreshes\nOther proposals have explored lower-level APIs for websites to create and use protected private keys, e.g. via WebCrypto or APIs similar to WebAuthn. While this works in theory, it puts a very large burden on the website to integrate with. In particular, since the cost of using protected keys is high, websites must design some infrastructure for collecting signatures only as often as needed.\n\nThis means either high-touch integrations where the keys are only used to protect sensitive operations (like making a purchase), or a general ability to divert arbitrary requests to some endpoint that collects and verifies a signature and then retries the original request. The former doesn't protect the whole session and violates the principle of secure by default, while the latter can be prohibitively expensive for large websites built from multiple components by multiple teams, and may require non-trivial rewrites of web and RPC frameworks.\n\nDBSC instead allows a website to consolidate the session binding to a few points: At sign-in, it informs the browser that a session starts, which triggers the key creation. It then instructs the browser that any time a request is made while that session is active, the browser should ensure the presence of certain cookies. The browser does this by calling a dedicated refresh endpoint (specified by the website) whenever such cookies are needed, presenting that endpoint with a proof of possession of the private key. That endpoint in turn, using existing standard Set-Cookie headers, provides the browser with short-term cookies needed to make other requests.\n\nThis provides two important benefits:\n1. Session binding logic is consolidated in the sign-in mechanism, and the new dedicated refresh endpoint. All other parts of the website continue to see cookies as their only authentication credentials, the only difference is that those cookies are short-lived. This allows deployment on complex existing setups, often with no changes to non-auth related endpoints.\n1. If a browser is about to make a request where it has been instructed to include such a cookie, but doesn't have one, it defers making that request until the refresh is done. While this may add latency to such cases, it also means non-auth endpoints do not need to tolerate unauthenticated requests or respond with any kind of retry logic or redirects. This again allows deployment with minimal changes to existing endpoints.\n\nNote that the latency introduced by deferring of requests can be mitigated by the browser in other ways, which we discuss later.\n\n### TPM considerations\nDBSC depends on user devices having a way of signing challenges while protecting private keys from exfiltration by malware. This usually means the browser needs to have access to a Trusted Platform Module (TPM) on the device, which is not always available. TPMs also have a reputation for having high latency and not being dependable. Having a TPM is a requirement for installing Windows 11, and can be available on previous versions. All our studies are for public key cryptography using ECDSA_P256 algorithm.\n\n Chrome has done studies to understand TPM availability to understand the feasibility of secure sessions. Current data shows about 60%, and currently growing, of Windows users would be offered protections. Studies have also been done on the current populations of TPMs, both for latency and for predictability. Currently the latency is (P50: 200ms/ P95: 600ms) for signing operations. The error rate is very low, currently around 0.001%.\n\nBased on this research, TPMs are widely available, with a latency and consistency that is acceptable for the proposed usage.\n\n### Privacy considerations\nAn important high-level goal of this protocol is to introduce no additional surface for user tracking: implementing this API (for a browser) or enabling it (for a website) should not entail any significant user privacy tradeoffs.\n\nThere are a few obvious considerations to ensure we achieve that goal:\n- Lifetime of a session/key material: This should provide no additional client data storage (i.e., a pseudo-cookie). As such, we require that browsers MUST clear sessions and keys when clearing other site data (like cookies).\n- Cross-site/cross-origin data leakage: It should be impossible for a site to use this API to circumvent the same origin policy, 3P cookie policies, etc. (More on this below.)\n- Implementing this API should not meaningfully increase the entropy of heuristic device fingerprinting signals. (For example, it should not leak any stable TPM-based device identifier.)\n- This API—which allows background \"pings\" to the refresh endpoint when the user is not directly active—must not enable long-term tracking of a user when they have navigated away from the connected site.\n- Each session has a separate new key created, and it should not be possible to detect that different sessions are from the same device.\n\n### Enterprise support\n\nWhile DBSC addresses a general problem of session hijacking, and can be applicable to any _browser_ consumer, it is possible to expand this protocol to better support enterprise use cases. By adding specifics to key generation, we can provide a more secure environment for enterprise users. This is the goal of DBSC(E), which is an extension to DBSC. The high-level design of DBSC(E) is described in the [DBSC(E) Overview](./DBSCE/Overview.md).\n\nDBSC(E) removes the vulnerability DBSC has, where a malware, if already present in the device during the key generation, can potentially take over the session. DBSC(E) proposes to mitigate this vulnerability by introducing device key chaining: More details about the importance of DBSC are here: [Why DBSC(E)?](./DBSCE/Overview.md/#why-dbsce)\n\n## High level overview\n![High level diagram](reg_and_refresh.svg)\n[Link to editable diagram](https://sequencediagram.org/index.html#initialData=A4QwTgLglgxloDsIAIBEAVACgWVckAzshAFCiSzwhJoBCYA9gO4ECmYehyARmeNHEQpUAZXYA3dpyJMScktwC0APiYAuZASgBzBIqgJkAMwA2zEkxXcNAJgAMd5EwD0W3awAm+wzAZJWSAA0yGCsBMB+bMgGMCYArh5hyAAWrCCJYMQMmhD8mqwwcaH5BFp+AHTIyAA6CAASaRkaqKIFimKlUH6KAEqs2lAEEGAg0H4a5ZPIMMkgJiYB2qwAvJPlLbUAFDNzCwhLIawAjnFQoR7GDJnAYFDio6zIANasAJ7INwwMRsjfHwylMJlBAAShICAYEEeDEkmWsPEYLHY0QQUGgDyIbE6fh4Bg8Bm0tW4hE8v0MqXSyJuYQCMFYChUEA0oROYRQMFCD2eb1AZxIECszNYECKhmAcW4Jlg3Ne4Mh0NhPA0HLSUOQACkAOroJzOHbzRb0pTKJksuJszQ6Qxa9D8wWHEVga3ay26UZFI0qdTITAAeREOtcBQ9WOBrlykFDXUMtVqLQA3qg5tpUGo1sFUBBXsBU6gbahgmsAL7x9OoF6vXMAHnFktgAH0K8pUEWWsg5WqYcjvUMro9a1KYDLgmyQHWCMkSsCLPb7I4XL4GE8oI9qBcoziAJIAESJDA87xi8USmN8wGhP0Xy6SmyuOgMyAA1B9RskQbGEBSmmhWgKAMJfNeGggHEEDJPWV4rhsCDcPurzNKgiYbgg9ZQIkSBQEYK4cGmkytqgJDLMsIgMAAto80DkS+gIEGsREdgqyLwnEbCZLEsBPEQUoIE8lzXK+yCuGRBR+FCSAMso8IzAUvGYb8twDAgj6gGBhwnGcSSwXECAXJB9JzCgWk6dMgErsgEIoGaGkeBJ3oAOIAKKBgQwm+P44mWJJtgOLqbliaQrAmFERm6aZjxWecElSakMCyT8EWknpRCsAAHoMpAGWppznCZS5mdSbA0Gu5mQsgqXANZtkaI5zmuaJASkJ58Jzr59XiYFUQJaFeWPKRgxaPs8llSlFWRRZjFwkKrJDMgiRGOwOVMMkUALE4jxLOyYW0ZMVU+v6znBqEyHOKERhHZOtRfuwCFiDA7RAtGiibh4GgANrIcgO4ALotDOXkACx2AAjB+DSUmAN1tB0wKKH+swGvsrAaMhqHodAWHsKskzBPqexLFj6wEeNvyKlJnJqjavnw3jnommoZoWm4zq2gKXkOqKGoukz7qhLtfoBoJbCFEdD1+CdrBnWEF2fo010-rd93YnofThJESPIK9No-UT8ok92Gj3FKHhcp8fx-BENHRn91gtQuYX4MZH07nuB4orECRJAQZ4Xrl15ELeCkPs+Klvh+V0Q-Lwqw2FwGgeBenQbBB4IUhosoWhDWYdhqbFr9xNdpN+TC48H2juOqQeMER1xORtR3opcxZWyu01YLdXuY1s4+S4LlUX5DUkAENlD0AA))  \nThe general flow of a secure session is as follows:\n1. The website requests that the browser start a new session, providing an HTTP endpoint to negotiate registration parameters.\n1. The browser creates a device-bound key pair, and calls the registration HTTP endpoint to set up the session and register the public key.\n1. The server responds with a session identifier, and instructions on how to maintain the session. This is a (possibly empty) list of cookie names that the browser is expected to ensure exist, and their associated scope (origins+path).\n1. At a later time the session is closed by either the server requesting to close the session or the user clears the keys by clearing site data.\n\nAs long as that session is active, the browser performs the following refresh as needed:\n1. For any request within an applicable scope, the browser checks if the necessary cookies exist. If they exist, continue as normal.\n1. If not, the browser defers such requests while performing the following.\n1. The browser contacts the HTTP endpoint for the session, providing the session identifier and, if requested by the server, the necessary proof of possession of the associated private key. \n1. If the server is satisfied with the proof, it uses regular Set-Cookie headers to establish the necessary cookies with an appropriate Max-Age. The response can also include an updated set of instructions, e.g. if the server wishes to change which cookies are subject to this logic.\n1. If any requests were deferred in step 2, the browser now makes those requests including the updated set of cookies.\n1. The browser may choose to proactively refresh cookies that are about to expire, if it predicts the user may soon need them. This is purely a latency optimization, and not required.\n\nThere is an option for the server to opt out of the browser defering requests. If so it will instead:\n1. Sign any requests that would be defered, use the most recent challange. If there is not one, use the current timestamp. The browser may cache these signatures.\n1. The server can respond with 401 if it wants the request signed with a new challenge.\n1. The server can also serve challenges ahead of time on any response with the Sec-Session-Challenge header.\n1. Once the browser get an instruction to set the missing cookie it will stop signing requests.\nWe do not reccomend this option for most deployments, but it is possibly for those that want to potentially save a network roundtrip in some circumstances.\n\n\n### Start Session\n![Start session diagram](header_setup.svg)\n\n[Link to editable diagram](https://sequencediagram.org/index.html#initialData=MoUwTgbuC0B8CqBncACAggcxAOwC4C4VQBjaURRASwHttoAlEDSxXMAQ1xuwCgeMw1AK4AHFMlyjxICtxRgQARyEzcPJKkw5ccUJHD4ACgHlgAFRQB6ZMSELks2tdzswuB1Vo9s1XCBTUUGAoGsFaeAA0ekEAxADuABYgnPgA3gBEAEaU2AAmORjQ7AA2GPgAdJXpAL7qyGFYeAA8ZOBB+KA6AMLU1ADWlCCE7EK4CQD6xL0DIN6+-oGooeiNuFFt4PFJKRke3NCUudqUAGaDYBVVtTi5fD5+AUEh9SvaW8kE5J7YKCwoPnEUOxiFwoDwgA)\n\n#### Session Registration Header\nThe session start process is initiated by the server attaching a header with Sec-Session-Registration and appropriate parameters, this looks like:\n```http\nHTTP/1.1 200 OK\nSec-Session-Registration: (RS256 ES256);challenge=\"challenge_value\";path=\"StartSession\"\n```\nThis is a structured header with a list of token arguments representing the allowed algorithms (possibilities are ES256 and RS256). The list have multiple string attributes, \"path\" is required describing the endpoint to use, \"challenge\" is to provide a challenge value for the registration JWT. There is also an optional string attribute called authorization. There can be more than one registration on one response:\n```http\nHTTP/1.1 200 OK\nSec-Session-Registration: (ES256 RS256);path=\"path1\";challenge=\"challenge_value\";authorization=\"authcode\"\nSec-Session-Registration: (ES256);path=\"path2\";challenge=\"challenge_value\"\n```\n\nAn equivalent way of writing this is:\n```http\nHTTP/1.1 200 OK\nSec-Session-Registration: (ES256 RS256);path=\"path1\";challenge=\"challenge_value\";authorization=\"authcode\", (ES256);path=\"path2\";challenge=\"challenge_value\"\n```\n\nThe authorization value is optional for servers to send, but mandatory for clients to implement. If present, it will be sent to the registration endpoint in the `Authorization` header, and included in the registration JWT. This allows passing a bearer token that allows the server to link registration with some preceding sign in flow, as an alternative to the more traditional use of cookies. While this can also facilitate integration with some existing infrastructure, e.g. ones based on OAuth 2.0, this parameter is general and is not limited to the similarly named [Authorization Code](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1) in OAuth 2.0.\n\n#### Session Registration JWT\nThe browser responds to the session start by selecting a compatible signature algorithm and creating a device-bound private key for the new session. It then makes the following HTTP request (assuming the endpoint URL is https://auth.example.com/securesession):\n\n```http\nPOST /securesession/startsession HTTP/1.1\nHost: auth.example.com\nAccept: application/json\nCookie: whatever_cookies_apply_to_this_request=value;\nSec-Session-Response: JWT Proof\n\n```\nThe JWT proof is signed with the newly created private key, and needs to contain the following values (the public key is in the [JWK](https://datatracker.ietf.org/doc/html/rfc7517) format):\n```jsonc\n// Header\n{\n  \"alg\": \"Signature Algorithm\",\n  \"typ\": \"JWT\",\n}\n// Payload\n{\n  \"aud\": \"URL of this request\",\n  \"jti\": \"challenge_value\",\n  \"iat\": \"timestamp\",\n  \"key\": {\n    \"kty\": \"key type\",\n    \"<kty-specific parameters>\": \"<value>\",\n  },\n  \"authorization\": \"<authorization_value>\", // optional, only if set in registration header\n}\n```\n\n#### Session Registration instructions JSON\nIf the request is properly authorized, the server establishes whatever state represents the session server-side, and returns the following response.\n\n```http\nHTTP/1.1 200 OK\nContent-Type: application/json\nCache-Control: no-store\nSet-Cookie: auth_cookie=abcdef0123; Domain=example.com; Max-Age=600; Secure; HttpOnly;\n```\n\n```jsonc\n{\n  \"session_identifier\": \"session_id\",\n  \"refresh_url\": \"/RefreshEndpoint\",\n\n  \"scope\": {\n    // Origin-scoped by default (i.e. https://example.com)\n    // Specifies to include https://*.example.com except excluded subdomains.\n    // This can only be true if the origin's host is the root eTLD+1.\n    \"origin\": \"example.com\",\n    \"include_site\": true,\n    \"defer_requests\": true, // optional and true by default\n\n    \"scope_specification\" : [\n      { \"type\": \"include\", \"domain\": \"trusted.example.com\", \"path\": \"/only_trusted_path\" },\n      { \"type\": \"exclude\", \"domain\": \"untrusted.example.com\", \"path\": \"/\" },\n      { \"type\": \"exclude\", \"domain\": \"*.example.com\", \"path\": \"/static\" }\n    ]\n  },\n\n  \"credentials\": [{\n    \"type\": \"cookie\",\n    // This specifies the exact cookie that this config applies to. Attributes\n    // match the cookie attributes in RFC 6265bis and are parsed similarly to\n    // a normal Set-Cookie line, using the same default values.\n    // These SHOULD be equivalent to the Set-Cookie line accompanying this \n    // response.\n    \"name\": \"auth_cookie\",\n    \"attributes\": \"Domain=example.com; Path=/; Secure; SameSite=None\"\n    // Attributes Max-Age, Expires and HttpOnly are ignored\n  }]\n}\n```\n\nIf the request is not properly authorized, the server can request a new signed request by answering instead with a 401:\n\n```http\nHTTP/1.1 401\nSec-Session-Challenge: \"challenge_value\"\n```\n\nWhere Sec-Session-Challenge header is a structured header with a list of challenge values that may specify an optional \"id\" parameter: \"challenge_value\";id=\"session_id\".\nThe challenge applies to the current context if \"id\" is not present; otherwise it applies to the specific session. The browser ignores the challenge if \"id\" doesn't match any session locally.\n\nSubsequently, as long as the browser considers this session \"active\", it follows the steps above, namely by refreshing the auth_cookie whenever needed, as covered in the next section.\n\nNote if multiple cookies are required, the server returns multiple Set-Cookie headers, with corresponding entries in the \"credentials\" array in the response body.  \n\n### Maintaining a session\nAs long as the named cookie is not expired the browser will keep sending requests as normal. Once the cookie is expired the browser will hold all requests for the scope of the cookie, except where the server excluded the paths in the registration, while refreshing the cookie. This is where the browser driven protocol makes a difference, if not for this there would be potentially many requests without the required cookie.\n#### Refresh procedure\n![Refresh diagram](refresh_v2.svg)\n\n[Link to editable diagram](https://sequencediagram.org/index.html#initialData=A4QwTgLglgxloDsIAICqBnApmZBBA5pkgFCiSzwhLIASmANgCbIBKmAjgK6boTqnhocRCgDK2AG7ZixBAHsImZHKk4M2PISQAacWFUBiAO4ALTCAgAucenRQ5CZDDlyA1lCUhOEEwH1nbh7ImAAewFBgmIzE6jgERBAAtAB8dEysHNy86JbIAOIAogAqwSEgALbA9JgAdM7lAPTAYAqYMIqMvpFcPBDE+C2cwBkAZpHoJshYtvYIMVhxWknJeqqWAAoA8qIlDVgwnOM8dg4NkWM8JsSr2CmxmgmWNEVF68gALAAMAIyyrcqqNALB46G5gYxmCzWNqJGwnBCJADCJhA9GqCEIlhq2Jq8w08SQKTBG22u32hx4x1mZ0wFwmf0UAI09wJEF0kmwEPMVgA3gAicQwWFUhyJNjoYAOLHYvkAX2uHLAd2BrKeLzeACZPp8GUoVMyVUt2fpOaZudCkoiXO5MLkvD5-NaPABeCSo7jEIjReSM-VqQ0JY2GM1QtjVEBYZBmdLdLJ8ZBGKA+JxOnjIc7jMzRFlLImK3KFEqhCpVWr1JotRTtKJdTK9YhAA)\n\nThe browser refreshes the short-term session credential by calling the session endpoint:\n\n```http\nPOST /securesession/refresh HTTP/1.1\nHost: auth.example.com\nAccept: application/json\nCookie: whatever_cookies_apply_to_this_request=value;\nSec-Session-Id: session_id\n```\n\nIn response to this the server can optionally first request a proof of possession of the key by issuing a challenge to the browser by responding with a 401 response with a challenge:\n\n```http\nHTTP/1.1 401\nSec-Session-Challenge: \"challenge_value\";id=\"session_id\"\n```\n\nThe server can also serve challenges ahead of time attached to any response as an optimization, for example:\n```http\nHTTP/1.1 XXX\nSec-Session-Challenge: \"challenge_value\";id=\"session_id\"\n```\n\nIt is also possible to send challenges to multiple sessions:\n```http\nHTTP/1.1 XXX\nSec-Session-Challenge: \"challenge 1\";id=\"session 1\"\nSec-Session-Challenge: \"challenge 2\";id=\"session 2\"\n```\n\nThis can also be formatted as:\n```http\nHTTP/1.1 XXX\nSec-Session-Challenge: \"challenge 1\";id=\"session 1\", \"challenge 2\";id=\"session 2\"\n```\nas each challenge is a structured header item.\n\nThe browser replies to that response with a Sec-Session-Response header, containing a signed JWT:\n\n```http\nPOST /securesession/refresh HTTP/1.1\nSec-Session-Response: JWT proof\n```\n\nThe JWT proof contains:\n```json\n{\n  \"jti\": \"challenge_value\",\n  \"aud\": \"the URL to which the Sec-Session-Response will be sent\",\n  \"sub\": \"the session ID corresponding to the binding key\",\n}\n```\n\nIf the server is satisfied with the response, or if it did not request it, it answers by setting the short term cookie. Optionally the server can adjust the session in the body of the response (similar to how it was set up)[https://github.com/WICG/dbsc/blob/main/README.md#session-registration-instructions-json].\n\n```http\nHTTP/1.1 200 OK\nContent-Type: application/json\nCache-Control: no-store\nSet-Cookie: auth_cookie=abcdef0123; Domain=example.com; Max-Age=600; Secure; HttpOnly;\n```\nThe contents is a json with the same specifications as during the registration.\nOn receiving this response, the browser releases any requests that were deferred pending this refresh, including the new cookie.\nNote:\nThis response is identical to the response to session setup, and can be handled by the same logic in the client.\nThe new set of instructions replaces any previous instructions for the session. E.g. if the cookie name is different here than before, the browser should not trigger refreshes based on the absence of the old cookie name.\nThe server may issue a different Max-Age, or scope for the short-term cookie.\nThe server may set or update other cookies not subject to session refreshes in this response, as in any response.\n\nIf instead the server decides to end the session it can respond with:\n```json\n{\n  \"session_identifier\": \"session_id\",\n  \"continue\": false\n }\n```\nIn this case the browser should stop triggering any refreshes for this request, release any deferred requests without the short-term cookie, and clean up and delete the associated session state including the binding key.\n\n#### Ending a session\nThe session can end in several ways:\n- The server can end the session during a refresh by answering with {“continue”: false} during a refresh\n- The server can at any time send a header with Clear-Site-Data: \"storage\"\n- The user can clear site data, which will locally clear cookies and any registered session keys for the site\n\nIt is important that the user is always in control and can delete the session keys if wanted.\n\n## Interactions with other APIs\n### Login Status API\n### Interaction with Inactive Documents (BFCache, Prerendering)\nWhen a session is ended for any reason, any inactive documents which had access to that session's credentials should be destroyed. This ensures that pages in BFCache or that are pre-rendering that contain information guarded by those credentials are not presented after the session has ended.\n\n## Alternative JavaScript API for StartSession\n![Start session diagram](dbsc_js_v2.svg)\n\n[Link to editable diagram](https://sequencediagram.org/index.html#initialData=A4QwTgLglgxloDsIAIDqBTARsgCiA5ugFCiSzwhLICqAzumMgIKFInjRyIoDKDAbgyJF8YAPYBXYMh4QOyerVpQxCIhmx5CAWgB8dBs1YQAXMgQh+UfCAhiwAOnowJYdIuWqncyAAoHAQCURAhiEOjIYoKMBows6EgAxADuABbotiYAwm62EQDW6ACeyKBQYESxRgkQenxg0SY4API8ACrIAPTOru7ungjdPhAhYRFRhlXxSAA09dEp6ZkA3gBEmFAIACab+NogADb4JgEOqwC+RPMMelPGJgASbW04yABMAAwfo+GR0TT0OLGOYCBiLDKmPi1LJiMT5KDoMwgCQQVIAfRgsPh6AAvPxDhJiBpcAR0AAebR3GpmYDiAC2UHoDjctDEB0E-iCRASWx+43+xK06BBDTBaQhJj4ShUCGQjPMYmSyBAMGggiIQA)\n\nThe API consists of a new interface, SecureSession, an instance of which is obtained via the securesession property of the navigator object. The SecureSession interface supports the following method:\n\n- **startSession():**\n- Parameters:\n  - endpoint: The URL of the secure session endpoint, supporting /startsession and /refresh operations\n  - supported_binding_algs: Array of cryptographic algorithms supported by the server\n  - authorization: Optional authorization value to be passed to Start Session HTTP request\n- Returns:\n  - A promise with a string containing the session ID (which may be empty)\n\nWhen called, this method must:\n- Generate and store a new, secure cryptographic key pair\n- Call the \"endpoint\" + /startsession as specified below in Start Session (HTTP Request/Response)\n- Return a promise which\n  - If that call succeeds (i.e. returns an HTTP 200), returns a session ID obtained from that call (which can be the empty string)\n  - If that call fails, throws an exception (which may indicate the HTTP status of the failed call)\n\nRequirements:\n- The endpoint must have the same origin as the JavaScript.\n\nBelow is an example of the API being used:\n```javascript\nlet promise = navigator.secureSession.start({\n  // Session start options\n  \"endpoint\": \"<url prefix of standard session endpoint>\", // required\n  \"supportedBindingAlgorithms\": [\"ES256,RS256\"], // required\n  \"authorization\": \"<authorization value>\", // optional\n});\npromise.then((sessionInfo) => {\n  // Success means the browser has completed the session setup with the\n  // session endpoint and will perform the necessary maintenance tasks\n  // going forward.\n  console.log(\"Session with id {} was started.\", sessionInfo.id);\n});\npromise.catch((...) => {\n  // Session start failed for some reason, e.g. the HTTP endpoint was\n  // not reachable, or broke protocol.\n  <error handling>\n});\n```\n"
       },
       "prpreview": {
         "src_file": "index.html",
@@ -182047,151 +182205,6 @@
         "text": "# Element Capture\n\nThis repo has migrated [here](https://github.com/screen-share/element-capture).\n"
       }
     },
-    {
-      "id": "MDEwOlJlcG9zaXRvcnkxMzk4ODYwMTk=",
-      "name": "element-timing",
-      "owner": {
-        "login": "WICG"
-      },
-      "isArchived": false,
-      "homepageUrl": "https://wicg.github.io/element-timing/",
-      "description": "A proposal for an Element Timing specification.",
-      "isPrivate": false,
-      "createdAt": "2018-07-05T18:22:06Z",
-      "labels": [
-        {
-          "name": "a11y-needs-resolution",
-          "color": "ea7472"
-        },
-        {
-          "name": "a11y-tracker",
-          "color": "ea7472"
-        },
-        {
-          "name": "bug",
-          "color": "d73a4a"
-        },
-        {
-          "name": "discuss",
-          "color": "c2e0c6"
-        },
-        {
-          "name": "duplicate",
-          "color": "cfd3d7"
-        },
-        {
-          "name": "enhancement",
-          "color": "a2eeef"
-        },
-        {
-          "name": "good first issue",
-          "color": "7057ff"
-        },
-        {
-          "name": "help wanted",
-          "color": "008672"
-        },
-        {
-          "name": "i18n-needs-resolution",
-          "color": "F9C9FF"
-        },
-        {
-          "name": "i18n-tracker",
-          "color": "F9C9FF"
-        },
-        {
-          "name": "invalid",
-          "color": "e4e669"
-        },
-        {
-          "name": "privacy-needs-resolution",
-          "color": "d4af37"
-        },
-        {
-          "name": "privacy-tracker",
-          "color": "d4af37"
-        },
-        {
-          "name": "question",
-          "color": "d876e3"
-        },
-        {
-          "name": "security-needs-resolution",
-          "color": "ffff00"
-        },
-        {
-          "name": "security-tracker",
-          "color": "ffff00"
-        },
-        {
-          "name": "tag-needs-resolution",
-          "color": "7fff00"
-        },
-        {
-          "name": "tag-tracker",
-          "color": "7fff00"
-        },
-        {
-          "name": "wontfix",
-          "color": "ffffff"
-        }
-      ],
-      "defaultBranch": {
-        "name": "main"
-      },
-      "environments": {
-        "nodes": [
-          {
-            "name": "github-pages"
-          }
-        ]
-      },
-      "branchProtectionRules": {
-        "nodes": [
-          {
-            "pattern": "main",
-            "requiredApprovingReviewCount": null,
-            "requiredStatusCheckContexts": [],
-            "isAdminEnforced": false
-          }
-        ]
-      },
-      "w3cjson": {
-        "text": " {\n    \"group\":      [80485]\n,   \"contacts\":   [\"yoavweiss\"]\n,   \"repo-type\":  \"cg-report\"\n}\n"
-      },
-      "prpreviewjson": {
-        "text": "{\n    \"src_file\": \"index.bs\",\n    \"type\": \"bikeshed\"\n}\n"
-      },
-      "autoPublish": null,
-      "travis": null,
-      "contributing": {
-        "text": "# Web Platform Incubator Community Group\n\nThis repository is being used for work in the W3C Web Platform Incubator Community Group, governed by the [W3C Community License\nAgreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To make substantive contributions,\nyou must join the CG.\n\nIf you are not the sole contributor to a contribution (pull request), please identify all\ncontributors in the pull request comment.\n\nTo add a contributor (other than yourself, that's automatic), mark them one per line as follows:\n\n```\n+@github_username\n```\n\nIf you added a contributor by mistake, you can remove them in a comment with:\n\n```\n-@github_username\n```\n\nIf you are making a pull request on behalf of someone else but you had no part in designing the\nfeature, you can remove yourself with the above syntax.\n\n# Tests\n\nFor normative changes, a corresponding\n[web-platform-tests](https://github.com/web-platform-tests/wpt) PR is highly appreciated. Typically,\nboth PRs will be merged at the same time. Note that a test change that contradicts the spec should\nnot be merged before the corresponding spec change. If testing is not practical, please explain why\nand if appropriate [file a web-platform-tests issue](https://github.com/web-platform-tests/wpt/issues/new)\nto follow up later. Add the `type:untestable` or `type:missing-coverage` label as appropriate.\n"
-      },
-      "license": {
-        "text": "All Reports in this Repository are licensed by Contributors\nunder the\n[W3C Software and Document License](http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document).\n\nContributions to Specifications are made under the\n[W3C CLA](https://www.w3.org/community/about/agreements/cla/).\n\nContributions to Test Suites are made under the\n[W3C 3-clause BSD License](https://www.w3.org/Consortium/Legal/2008/03-bsd-license.html)\n\n"
-      },
-      "codeOfConduct": {
-        "body": "# Code of Conduct\n\nAll documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).\n"
-      },
-      "readme": {
-        "text": "# Element Timing: Explainer\n\nThe **Element Timing** API enables monitoring when developer-specified image elements or groups of text nodes are displayed on screen.\nThe way text nodes are grouped is described below.\n\n\n### Objectives\n\n1.  Inform developers when specific elements are first displayed on the screen.\nWe support the following types of images: \\<img\\>, \\<image\\> inside \\<svg\\>, and background-images.\nWe also support observing certain groups of text nodes. Web developers can better understand which are the critical images and text of their sites, so after annotating them the browser can provide timing information about those.\nThis image and text converage means that the majority of web content can be timed via this API.\n1.  Enable analytics providers to measure display time of key images or text, without explicit opt in from web developers.\nIn many cases it's not feasible for developers to modify their HTML just to get better performance insights, so it's important to provide basic information even for websites that cannot annotate their elements.\n\n\n### How do we register elements for observation?\n\nAn element can be registered for observation via the `elementtiming` HTML attribute.\nHaving this attribute set will signal the browser to expose render timing information for this element (its source image, background image, and/or text).\nIt should be noted that setting the `elementtiming` attribute does not work retroactively: once an element has loaded and is rendered, setting the attribute will have no effect.\nThus, it is strongly encouraged to set the attribute before the element is added to the document (in HTML, or if set on Javascript, before adding it to the document).\nHaving the attribute implies that:\n\n* If the element is an image, there will be an entry for the image.\n* If the element is affected by (possibly multiple) background images, there will be one entry for each of those background images.\n* If the element is associated to at least one text node, there will be one entry for the group of associated text nodes.\n\n### Image considerations\n\nWe define the <a name=\"image-time\">**image rendering timestamp**</a> as the next paint that occurs after the image has become fully loaded.\nThis is important to distinguish as progressively rendered images may have multiple initial renderings before the image has even been fully received by the user agent.\n\nAllowing third-party origins to measure the time an arbitrary image resource takes to render could expose sensitive information such as whether a user is logged into a website.\nTherefore, for privacy and security reasons, the [image rendering timestamp](#image-time) is only exposed in entries corresponding to resources that pass the [timing allow check](https://w3c.github.io/resource-timing/#dfn-timing-allow-check).\nHowever, to enable a more holistic picture, the rest of the information is exposed for arbitrary images.\n\n### Text considerations\n\nWe say that a text node <a name=\"belong\">**belongs to**</a> the closest block-level [Element](https://dom.spec.whatwg.org/#element) ancestor of the node.\nThis means that an element could have 0 or many associated text nodes with it.\n\nWe say that an element is *text-painted* if at least one text node [belongs to](#belong) and has been painted at least once.\nThus, the <a name=\"text-time\">**text rendering timestamp**</a> of an element is the time when it becomes *text-painted*.\n\nLet the *text rect* of a text node be the display rectangle of that node within the viewport.\nWe define the <a name=\"text-rect\">**text rect**</a> of an element as the smallest rectangle which contains the geometric union of the text rects of all text nodes which [belong to](#belong) the element.\n\n### What information is exposed?\n\nA `PerformanceElementTiming` entry has the following attributes:\n* `name`: for images, \"image-paint\". For text: \"text-paint\".\n* `entryType`: it will always be the string \"element\".\n* `startTime`: equal to `renderTime` if it is nonzero, otherwise equal to `loadTime`.\n* `duration`: always be set to 0.\n* `renderTime`: for images, the [image rendering timestamp](#image-time), or 0 when the resource does not pass the [timing allow check](https://w3c.github.io/resource-timing/#dfn-timing-allow-check). For text, the [text rendering timestamp](#text-time).\n* `loadTime`: for images, the latest between the time when the image resource is loaded and the time when the image resource is associated to the element. For text, 0.\n* `intersectionRect`: for images, the display rectangle of the image within the viewport. For text, the [text rect](#text-rect) of the associated text (only counting text nodes which have been painted at least once).\n* `identifier`: the value of the `elementtiming` attribute of the element.\n* `naturalWidth`: the [intrinsic](https://drafts.csswg.org/css2/conform.html#intrinsic) width of the image. It matches with the corresponding DOM [attribute](https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-naturalwidth) for img. 0 for text.\n* `naturalHeight`: the [intrinsic](https://drafts.csswg.org/css2/conform.html#intrinsic) height of the image. It matches with the corresponding DOM [attribute](https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-naturalheight) for img. 0 for text.\n* `id`: the element's ID.\n* `element`: points to the element. This will be \"null\" if the element is [disconnected](https://dom.spec.whatwg.org/#connected).\n* `url`: for images, the initial URL for the resource request. For text, this will be an empty string.\n\nNote: for background images, the element is the one being affected by the background image style.\n\nSample code:\n\n```javascript\n<img src=\"my_image.jpg\" elementtiming=\"foobar\">\n\nconst observer = new PerformanceObserver((list) => {\n  let perfEntries = list.getEntries().forEach(function(entry) {\n      // Send the information to analytics, or in this case just log it to console.\n      if (entry.identifier === 'foobar') {\n        if (entry.renderTime)\n          console.log(\"My image took \" + entry.renderTime + \" to render!\");\n        else\n          console.log(\"Rendering time not available. Image took \" + entry.loadTime + \" to load!\");\n      }\n   });\n});\nobserver.observe({entryTypes: ['element']});\n```\n\n### Questions\n\n#### What about Shadow DOM?\n\nUnfortunately Shadow DOM elements are not currently supported. \n\n#### What about invisible or occluded elements?\n\nThe entry creation might be affected by _visibility_: for instance, elements are not exposed if the style visibility is set to none, or the opacity is 0.\nHowever, occlusion will not affect entry creation: an entry is seen if the element is there, but hidden by a full-screen pop-up on the page.\n\n#### What are some differences between text and image observation?\n\n* Whereas for images it is OK to care only about those which are associated to a resource, for text that is definitely not the case.\nAn image not associated to a resource will need to be constructed manually and it is uncommon for such an image to be part of the key content of a website.\nNote that we consider inline images (those with data URIs) to have an associated resource, it is just inlined.\nOn the other hand, text is relevant regardless of whether it is associated to a webfont or not.\n\n* Image rendering steps are different from text rendering steps.\nFor images, initial paints may not include all of the image content and may be low quality.\nIt is only once we have fully loaded and decoded the image that we can be certain that the content being displayed is meaningful.\nIn contrast, any text painted is meaningful.\nIt should be noted that this is not perfect because there could be block level elements containing some text that renders quickly and some text that is blocked on webfonts.\nIn this case, for the purposes of Element Timing, the text blocked by webfonts will be completely ignored.\n\n* Text is actually simpler when it comes to security and privacy considerations.\nCross-origin images could reveal a lot of information about users, but text and webfonts embedded in a website do not.\nTherefore, whereas for images we had to consider resources that passed the timing allow check versus resources that did not, for text this distinction is not needed.\n\n"
-      },
-      "prpreview": {
-        "src_file": "index.bs",
-        "type": "bikeshed"
-      },
-      "w3c": {
-        "group": [
-          80485
-        ],
-        "contacts": [
-          "yoavweiss"
-        ],
-        "repo-type": [
-          "cg-report"
-        ]
-      }
-    },
     {
       "id": "MDEwOlJlcG9zaXRvcnkxMzAxMzQwMzQ=",
       "name": "encrypted-media",
@@ -201896,6 +201909,10 @@
       "type": "community group",
       "fullshortname": "cg/wicg",
       "repos": [
+        {
+          "name": "element-timing",
+          "fullName": "w3c/element-timing"
+        },
         {
           "name": "web-share-target",
           "fullName": "w3c/web-share-target",
@@ -202069,10 +202086,6 @@
           "name": "document-policy",
           "fullName": "WICG/document-policy"
         },
-        {
-          "name": "element-timing",
-          "fullName": "WICG/element-timing"
-        },
         {
           "name": "entries-api",
           "fullName": "WICG/entries-api"
@@ -206936,7 +206949,7 @@
           "href": "https://api.w3.org/groups/wg/rch/charters"
         },
         "active-charter": {
-          "href": "https://api.w3.org/groups/wg/rch/charters/465"
+          "href": "https://api.w3.org/groups/wg/rch/charters/526"
         },
         "join": {
           "href": "https://www.w3.org/groups/wg/rch/join"
@@ -206950,7 +206963,7 @@
       },
       "type": "working group",
       "start-date": "2022-07-21",
-      "end-date": "2025-01-20",
+      "end-date": "2026-12-18",
       "fullshortname": "wg/rch",
       "repos": [
         {