Update report.json

Author: w3c-validate-repos-bot

report.json

@@ -4958,7 +4958,7 @@
       }
     ]
   },
-  "timestamp": "2019-11-19T15:33:53.291Z",
+  "timestamp": "2019-11-20T00:10:37.877Z",
   "repos": [
     {
       "id": "MDEwOlJlcG9zaXRvcnkxNDY0NzUwNjY=",
@@ -10186,6 +10186,10 @@
         {
           "name": "i18n-tracking",
           "color": "F9C9FF"
+        },
+        {
+          "name": "No consensus",
+          "color": "b0d659"
         }
       ],
       "defaultBranch": {
@@ -17789,7 +17793,7 @@
       },
       "isArchived": false,
       "homepageUrl": "https://w3c.github.io/dmpl",
-      "description": "Conversational Interfaces CG Report - Dialogue Manager Programming Language",
+      "description": "Dialogue Manager Programming Language - intermediate representation for autonomous interactive systems",
       "isPrivate": false,
       "createdAt": "2019-03-06T10:15:22Z",
       "labels": {
@@ -17886,7 +17890,7 @@
       },
       "isArchived": false,
       "homepageUrl": "https://w3c.github.io/dms/",
-      "description": "DM Script",
+      "description": "Dialogue Manager Script - programming language for autonomous interactive systems",
       "isPrivate": false,
       "createdAt": "2019-11-08T01:16:44Z",
       "labels": {
@@ -88586,74 +88590,52 @@
       "description": "Compiler infrastructure and toolchain library for WebAssembly",
       "isPrivate": false,
       "createdAt": "2015-10-29T20:26:28Z",
-      "labels": {
-        "edges": [
-          {
-            "node": {
-              "name": "bug",
-              "color": "fc2929"
-            }
-          },
-          {
-            "node": {
-              "name": "duplicate",
-              "color": "cccccc"
-            }
-          },
-          {
-            "node": {
-              "name": "enhancement",
-              "color": "84b6eb"
-            }
-          },
-          {
-            "node": {
-              "name": "help wanted",
-              "color": "159818"
-            }
-          },
-          {
-            "node": {
-              "name": "invalid",
-              "color": "e6e6e6"
-            }
-          },
-          {
-            "node": {
-              "name": "question",
-              "color": "cc317c"
-            }
-          },
-          {
-            "node": {
-              "name": "wontfix",
-              "color": "ffffff"
-            }
-          },
-          {
-            "node": {
-              "name": "LLVM wasm backend",
-              "color": "c2e0c6"
-            }
-          },
-          {
-            "node": {
-              "name": "wasm2js",
-              "color": "f9d0c4"
-            }
-          },
-          {
-            "node": {
-              "name": "plugins",
-              "color": "df12e2"
-            }
-          }
-        ],
-        "pageInfo": {
-          "endCursor": "Y3Vyc29yOnYyOpHOYSozZQ==",
-          "hasNextPage": false
+      "labels": [
+        {
+          "name": "bug",
+          "color": "fc2929"
+        },
+        {
+          "name": "duplicate",
+          "color": "cccccc"
+        },
+        {
+          "name": "enhancement",
+          "color": "84b6eb"
+        },
+        {
+          "name": "help wanted",
+          "color": "159818"
+        },
+        {
+          "name": "invalid",
+          "color": "e6e6e6"
+        },
+        {
+          "name": "question",
+          "color": "cc317c"
+        },
+        {
+          "name": "wontfix",
+          "color": "ffffff"
+        },
+        {
+          "name": "LLVM wasm backend",
+          "color": "c2e0c6"
+        },
+        {
+          "name": "wasm2js",
+          "color": "f9d0c4"
+        },
+        {
+          "name": "plugins",
+          "color": "df12e2"
+        },
+        {
+          "name": "good first bug",
+          "color": "8855e0"
         }
-      },
+      ],
       "defaultBranch": {
         "name": "master"
       },
@@ -96566,7 +96548,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": "# encrypted-media-encryption-scheme\nIncubation for encryption scheme query feature in EME\n\nhttps://wicg.github.io/encrypted-media-encryption-scheme/\n"
+        "text": "# encrypted-media-encryption-scheme\nIncubation for encryption scheme query feature in EME\n\nhttps://wicg.github.io/encrypted-media-encryption-scheme/\n\n## Polyfill\n\nA simple polyfill is available here:\n - https://github.com/google/eme-encryption-scheme-polyfill\n - https://www.npmjs.com/package/eme-encryption-scheme-polyfill\n\nThe compiled bundle for this polyfill is 3.1kB, or 1.2kB gzipped.\n\n## Implementation status\n\n - Older version implemented in Chrome behind a command-line flag\n - Older version implemented in Safari TP\n - EME spec PR in review:\n   - https://github.com/w3c/encrypted-media/pulls/\n"
       },
       "prpreview": {
         "src_file": "index.bs",
@@ -100593,7 +100575,7 @@
       },
       "isArchived": false,
       "homepageUrl": "https://wicg.github.io/origin-policy/",
-      "description": null,
+      "description": "A mechanism for origins to set their origin-wide configuration in a central location",
       "isPrivate": false,
       "createdAt": "2016-07-22T07:36:52Z",
       "labels": {
@@ -100639,10 +100621,28 @@
               "name": "wontfix",
               "color": "ffffff"
             }
+          },
+          {
+            "node": {
+              "name": "future policy item",
+              "color": "5319e7"
+            }
+          },
+          {
+            "node": {
+              "name": "open design question",
+              "color": "c2e0c6"
+            }
+          },
+          {
+            "node": {
+              "name": "addition/proposal",
+              "color": "4f2293"
+            }
           }
         ],
         "pageInfo": {
-          "endCursor": "Y3Vyc29yOnYyOpHOGJRSOA==",
+          "endCursor": "Y3Vyc29yOnYyOpHOZIcYyg==",
           "hasNextPage": false
         }
       },
@@ -100671,7 +100671,7 @@
       },
       "codeOfConduct": null,
       "readme": {
-        "text": "# Origin Policy\n\n***Under construction***. This proposal is being picked back up again after some years of slow progress. At this point the repository is in an inconsistent state, with the below explainer and the spec out of sync with the latest discussions on the issue tracker, and with prototype implementations in browsers.\n\nFor some of the latest thinking, see the issue tracker, as well as the mostly-updated [policy format](./policy-format.md) and [version negotiation](./version-negotiation.md) sub-explainers. Read other materials with an understanding that many of the proposed mechanisms are changing. We'll work to get the explainer and spec updated as soon as possible.\n\n---\n\n**tl;dr** Origin Manifest is a web platform mechanism\nthat aims to shift configuring the origin from web applications to the origin\nitself.\nThat is instead of burdening web applications to set configuration options as\nHTTP response headers, Origin Manifest allows declaring those options\nout-of-band representing the entire origin, not particular web applications.\nFor this the origin provides a manifest file in a predefined well-known\nlocation which browsers can load and apply.\n\n\n## The Problems and Goals\n\n### Configurations with origin-wide effects\n**Problem:** Some configuration delivery mechanisms, e.g. like HTTP headers, affect an entire\n  origin even though they might have been set through only a sub-resource load.\n  Misconfiguration of font resource header can have dramatic effects for the\n  origin, e.g. a wrong HPKP value.\n\n**Goals:** Configurations for web applications with effects on entire origin in\n  a more structured way to minimize the chances for origin misconfiguration\n  through individual web applications sharing the same origin.\n\n### HTTP header redundancy\n**Problem 1:** Some HTTP headers have to be sent again and again without actually changing the\n  values. Sometimes these headers add significant number of\n  bytes, e.g. CSP.\n\n**Problem 2:** Some HTTP headers are sent with every response even though their\n  effect has a lifetime, e.g. HSTS. Within the valid time frame these headers\n  do not need to be repeated.\n\n**Goal:** Mechanism to download configurations like HTTP header values only\n  once. These values are only overridden when needed.\n\n### Missing configurations\n**Problem:** For complex web applications it is easy to forget configuring\n  certain resources or pages, e.g. the error page.\n\n**Goal 1:** Fallback settings that are applied when HTTP headers are not set.\n\n**Goal 2:** Baseline settings that guaranteed to be applied, e.g. baseline CSP\n  which guarantees a certain least level of security for the entire origin.\n\n### CORS-preflight overhead\n**Problem:** For certain resources the CORS-preflight decisions can be\n  pre-determined. That is, the server decision to (dis-)allow access is\n  independent of the actual request itself but static for certain requests, e.g.\n  \"allow all requests from a.com\".\n\n**Goal:** Mechanism to inform a browser about CORS access decisions beforehand\n  to avoid CORS-preflight request overhead.\n\n\n## The Proposal\nWe propose Origin Manifest as a web platform mechanism that aims to shift\nconfiguring the origin from web applications to the origin itself.\n\n### Server side\nOrigin Manifest files are to be published in a well-known location on the\nserver. This enforces that the origin and not the individual web apps defines\nthem.\n\n### Client side\nWeb clients fetch and cache manifests for an origin. There can always be at most\none manifest for an origin. The client enforces the configurations from a\nmanifest similar to how HTTP headers are used. In fact, currently most\nconfigurations directly relate to HTTP headers, e.g. CSP.\n\n### Origin Manifest File\n\n#### File Format\nOrigin Manifests must be written in valid JSON format. The currently discussed\nschema will look like or similar to the one propsed by Mike West in\nhttps://github.com/WICG/origin-policy/issues/19#issuecomment-321229817.\n\n#### Versioning\nUpdates to the Origin Manifest file are natural. To this end every manifest has\na by the server defined version identifier. This allows firstly to easily\nidentify if a client needs to fetch a newer version. Secondly, it allows a web\napplication to decide that a manifest cached in the client is \"good enough\" to\navoid fetching a newer version for performance reasons.\n\n\n### Fetching Protocol\nClients always set the `Sec-Origin-Manifest` header to indicate the support for\nthe mechanism. Servers can then opt-in to use the mechanism by sending back a\n`Sec-Origin-Manifest` header with the current manifest version. If servers\nshould decide to not send the header, clients try to retreive a manifest from\ntheir cache and not use Origin Manifest otherwise.\n\n#### Opt-in\nIn case no manifest is cached the client indicates support for the feature by\nsetting the value 1.\n![Opt-in](/images/opt_in.png)\n\n#### Updating and Confirming\nIn case a manifest is cached the client informs the server about the currently\ncached version. If the version is accepted by the server the response simply\nconfirms the header. No fetch is needed. Otherwise the new version is fetched.\n![Updating and Confirm](/images/update.png)\n\n#### Opt-out\nServers can decide not no longer use Origin Manifest. If so they can set the\n`Sec-Origin-Manifest` header to 0 in the response. Clients then behave like no\nmanifest was ever set and remove the currently cached manifest from cache (if\nany).\n\n## Related Work\nMark Nottingham came up with basically the same idea around the same time\nhttps://mnot.github.io/I-D/site-wide-headers/.\nThe goal is of course to pick the best parts from both approaches and to merge\nthem into a useful mechanism.\n\n\n## Discussion\n**Why is the current version sent?**\n\nThe currently cached version is set in the request header to allow HTTP2 Push.\nIn particular, the server can decide to push the manifest since it knows whether\nit will be eventually fetched or not.\n\n\n**Why does it defer the response?**\n\nCertain configuration options, e.g. CSP, require to be loaded before the actual\ncontent is processed, e.g. a HTML document is rendered. This makes it also\nfundamentally different from Application Manifest\n(https://w3c.github.io/manifest/).\n\n\n**Why not just using HTTP caching and ETag?**\n\nWe need to process Origin Manifests differently from other data fetched over\nHTTP. In particular, it allows us to manage the different versions and to ensure\nthat there exists at most only exactly one manifest per origin.\nAlso, directly related to the above question \"Why is the current version sent?\",\nwe need to store and notify the current version or servers using HTTP/2 would\nstart pushing the manifest to the client which clients would need to cancel.\nThis imposes performance costs we want to avoid.\n"
+        "text": "# Origin Policy\n\nOrigin policy is a web platform mechanism that allows origins to set their origin-wide configuration in a central location, instead of using per-response HTTP headers.\n\n## The problems and goals\n\n### Configurations with origin-wide effects\n\n**Problem 1:** Using HTTP headers as a delivery mechanism for origin-wide configuration allows individual resources or web applications on an origin to misconfigure the entire origin. For example, if one page on an origin sets the [`Strict-Transport-Security`](https://tools.ietf.org/html/rfc6797) response header before all other pages are available over HTTPS, the other pages become inaccessible.\n\n**Problem 2:** Allowing different resources to give different values for origin-wide configuration, via different HTTP response headers, complicates the web- and browser-developer facing models for the features in question. Such cases require defining a conflict resolution procedure (e.g., HSTS's decision to choose the most-strict policy seen so far).\n\n**Goal:** Centralize configuration for entire origin, so that when used exclusively, origin policy ensures coordination between individual resources and applications sharing the same origin.\n\n### HTTP header redundancy\n\n**Problem 1:** Some HTTP headers have to be sent again and again without actually changing their values. Sometimes these headers add significant number of bytes, e.g. [CSP](https://w3c.github.io/webappsec-csp/).\n\n**Problem 2:** Some HTTP headers are sent with every response, even though their effect has a lifetime, e.g. [HSTS](https://tools.ietf.org/html/rfc6797). Within the valid time frame these headers do not need to be repeated.\n\n**Goal:** Provide a mechanism to download origin-wide configurations only once per origin, instead of per request, and only update them when needed.\n\n### Missing configurations\n\n**Problem:** For complex web applications it is easy to forget configuring certain resources or pages, e.g. the error page.\n\n**Goal 1:** Allow applying origin-wide fallback settings that are applied when correpsonding HTTP headers are not set.\n\n**Goal 2:** Allow providing baseline settings that are guaranteed to be applied, e.g. baseline CSP which guarantees a certain minimum level of security for the entire origin.\n\n### CORS-preflight overhead\n\n**Problem:** For certain resources the CORS-preflight decisions can be predetermined. That is, the server decision to (dis-)allow access is independent of the actual request itself, but is instead static for certain requests, e.g. \"allow all requests from a.com\" or \"use the [basic safe CORS protocol setup](https://fetch.spec.whatwg.org/#basic-safe-cors-protocol-setup)\".\n\n**Goal:** Provide a mechanism to inform the browser about CORS access decisions beforehand, to avoid the CORS-preflight request overhead.\n\n\n## The proposal\n\n### The origin policy manifest\n\nServer operators can provide a per-origin **origin policy manifest**, at `/.well-known/origin-policy`, which is a JSON file that allows configuring various origin-wide settings. An example would be\n\n```json\n{\n  \"id\": \"my-policy\",\n  \"content_security\": {\n    \"policy\": [\"frame-ancestors 'none'\", \"object-src 'none'\"],\n    \"policy_report_only\": [\"script-src 'self' https://cdn.example.com/js/\"]\n  },\n  \"features\": {\n    \"policy\": \"geolocation 'self' https://example.com\",\n    \"policy_report_only\": \"document-domain 'none'\"\n  },\n  \"cors_preflights\": {\n    \"no_credentials\": {\n      \"origins\": \"*\"\n    },\n    \"unsafe_include_credentials\": {\n      \"origins\": [\"https://trusted.example.com/\"]\n    },\n  },\n  \"origin_isolated\": \"best-effort\"\n}\n```\n\nFor more on the policy format, see [the dedicated document](./policy-format.md).\n\n### Fetching and applying the origin policy\n\nBrowsers then fetch and cache origin policies for a given origin. They can optionally do so proactively (e.g. for frequently-visited origins), but generally will be driven by the web application sending a HTTP response header requesting that a given origin policy be fetched and applied:\n\n```\nOrigin-Policy: allowed=(none my-policy my-old-policy), preferred=my-policy\n```\n\nHere the header specifies allowed and preferred policies, which correspond to the JSON document's `\"id\"` value. This allows servers to take on a variety of behaviors, including:\n\n* Require that a given origin policy be available (either from the cache or via fetching) and applied, before proceeding with page initialization\n* Allow a previous revision of the policy, or no policy at all, to apply, but in the background do an asynchronous update of the policy so that future resource fetches will apply the preferred one.\n\nFor more on the model for fetching and updating origin policies, see [the dedicated document](./version-negotiation.md).\n\nAnother important note is that the policy items in question automatically stop applying (in a policy item-specific way) when the origin policy stops applying. So, for example, removing the `\"content_security\"` member of the origin policy manifest above would cause any future loads that use that origin policy to not include the CSP in question. Combined with the usual HTTP cache expiry mechanisms for the `/.well-known/origin-policy` resource, this allows a general \"max age\" mechanism for origin-wide configuration, similar to the `max-age` parameter of [HSTS](https://tools.ietf.org/html/rfc6797), but for all policy items.\n\n### Configurable policy items\n\nWe anticipate specifying the following configurable policy items inside the origin policy:\n\n* [Origin Isolation](https://github.com/domenic/origin-isolation)\n* [Content Security Policy](https://w3c.github.io/webappsec-csp/)\n* [Feature Policy](https://w3c.github.io/webappsec-feature-policy/)\n* [Document Policy](https://github.com/w3c/webappsec-feature-policy/blob/master/document-policy-explainer.md)\n* [Referrer Policy](https://w3c.github.io/webappsec-referrer-policy/)\n* [Cross-Origin Resource Sharing](https://fetch.spec.whatwg.org/#http-cors-protocol)\n* TLS Configuration, including [Strict Transport Security](https://tools.ietf.org/html/rfc6797) and [Expect-CT](https://httpwg.org/http-extensions/expect-ct.html)\n* [Client Hints](https://httpwg.org/http-extensions/client-hints.html)\n\nSome of these will be specified sooner than others, and plans may change as we do that specification and implementation work, but we hope to include at least origin isolation, content security policy, and feature policy in initial spec drafts.\n\nNote that generally, if a policy item can be configured both with origin policy and on a per-resource level, the per-resource headers will have precedence. The exact meaning of \"precedence\" depends on the policy item in question.\n\nSee the [policy format](./policy-format.md) sub-explainer for information on the syntax and semantics envisioned for each of these.\n"
       },
       "w3c": {
         "group": [