autofocus processing model to better match browser behavior, fit better within the specification ecosystem, and avoid bad results for users.",
"id": "autofocus-overhaul",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1574435",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": null,
"mozPositionIssue": 195,
"org": "WHATWG",
@@ -639,7 +639,7 @@
"description": "<video>.requestVideoFrameCallback() allows web authors to be notified when a frame has been presented for composition.",
"id": "requestVideoFrameCallback",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This is intended to allow web authors to do efficient per-video-frame processing of video, such as video processing and painting to a canvas, video analysis, or synchronization with external audio sources.",
"mozPositionIssue": 250,
"org": "Proposal",
@@ -651,7 +651,7 @@
"description": "This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes.",
"id": "http-stale-controls",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "The stale-while-revalidate cache control extension appears to provide improved user experience with no obvious drawbacks. We take no position on the other mechanisms in RFC 5861 at this time.",
"mozPositionIssue": 144,
"org": "Proposal",
@@ -664,7 +664,7 @@
"id": "http-client-hints",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Client_hints",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=935216",
- "mozPosition": "non-harmful",
+ "mozPosition": "neutral",
"mozPositionDetail": "Architecturally, Mozilla prefers client-side solutions for retrieving alternate versions of content, such as the HTML <picture> tag. Despite these architectural preferences, we find that Client-Hints do not present a concrete harm to the web or to its users. ",
"mozPositionIssue": 79,
"org": "IETF",
@@ -676,7 +676,7 @@
"description": "This document defines a web platform API for observing system-wide user presence signals.",
"id": "idle-detection-api",
"mozBugUrl": "",
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "We are concerned about the user-surveillance, user-manipulation, and abuse of user resources potential of this API, despite the required 60 second mitigation. Additionally it seems to be an unnecessarily powerful approach for the motivating use-cases, which themselves are not even clear they are worth solving, as pointed out in https://lists.webkit.org/pipermail/webkit-dev/2020-October/031562.html",
"mozPositionIssue": 453,
"org": "Proposal",
@@ -688,7 +688,7 @@
"description": "The imperative slotting API allows the developer to explicitly set the assigned nodes for a slot element.",
"id": "imperative-shadow-dom",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "The proposal is a relatively small addition to the existing Shadow DOM API and can make it easier to use Shadow DOM.",
"mozPositionIssue": 409,
"org": "WHATWG",
@@ -700,7 +700,7 @@
"description": "The Import Assertions and JSON modules proposal adds an inline syntax for module import statements to pass on more information alongside the module specifier, and an initial application for such attributes in supporting JSON modules in a common way across JavaScript environments.",
"id": "import-attributes",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1648614",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This proposal enables the importing of JSON content into a JS module. This mechanism is a prerequisite for HTML/CSS/JSON modules.",
"mozPositionIssue": 373,
"org": "Ecma",
@@ -712,7 +712,7 @@
"description": "Import maps allow web pages to control the behavior of JavaScript imports.",
"id": "import-maps",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1688879",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "We support the overall intent of the proposal and consider it worth prototyping. There are a few technical details that may require some care, in particular the relationship between speculative parsing and dynamic import maps.",
"mozPositionIssue": 146,
"org": "Proposal",
@@ -724,7 +724,7 @@
"description": "This document proposes a few changes to cookies inspired by the properties of the HTTP State Tokens mechanism. First, cookies should be treated as \"SameSite=Lax\" by default. Second, cookies that explicitly assert \"SameSite=None\" in order to enable cross-site delivery should also be marked as \"Secure\". Third, same-site should take the scheme of the sites into account. Fourth, cookies should respect schemes. Fifth, cookies associated with non-secure schemes should be removed at the end of a user's session. Sixth, the definition of a session should be tightened.",
"id": "cookie-incrementalism",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Any approach that reduces the scope of cookie use is a security and privacy win. Because some such changes can break websites that rely on the broader scope, we would like to proceed with caution, but believe that the feature is worth experimenting with and collecting data about.",
"mozPositionIssue": 260,
"org": "Proposal",
@@ -736,7 +736,7 @@
"description": "This specification defines an API that allows websites to convert from a given code value to a valid key value that can be shown to the user to identify the given key. The conversion from code to key is based on the user\u2019s currently selected keyboard layout. It is intended to be used by web applications that want to treat the keyboard as a set of buttons and need to describe those buttons to the user.",
"id": "keyboard-map",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1469017",
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "We're concerned that this exposes keyboard layouts, which seem likely to be a significant source of fingerprinting data, in a way that does not require any user interaction.",
"mozPositionIssue": 300,
"org": "Proposal",
@@ -748,7 +748,7 @@
"description": "This specification defines an API that allows web page authors to monitor the largest paint an element triggered on screen.",
"id": "largest-contentful-paint",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1722322",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "We are aware the concerns about this API such as the heuristic isn't perfect, however, we believe this is the area we should explore and there are positive signs from this API such that it has the best correlation with SpeedIndex.",
"mozPositionIssue": 191,
"org": "Proposal",
@@ -760,7 +760,7 @@
"description": "This specification defines an API that provides web page authors with insights into the stability of their pages based on movements of the elements on the page.",
"id": "layout-instability",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1651528",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "We're somewhat uneasy about the potential burden that this feature imposes on sites that don't use it, due to the requirements of the \"buffered\" flag. However, setting that reservation aside, we think this sort of feature is worth exploring. We've filed spec issues on that reservation and on some other points that need clarity.",
"mozPositionIssue": 374,
"org": "Proposal",
@@ -773,7 +773,7 @@
"id": "loading-lazy-attr",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-loading",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1542784",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "As currently scoped in the HTML pull request this is a reasonable addition to how images are fetched. (Note that the scope on Can I use is slightly bigger. Frames are likely a reasonable addition, but have their own set of design challenges.)",
"mozPositionIssue": 151,
"org": "WHATWG",
@@ -785,7 +785,7 @@
"description": "This document updates RFC 6761 with the goal of ensuring that \"localhost\" can be safely relied upon as a name for the local host's loopback interface. To that end, stub resolvers are required to resolve localhost names to loopback addresses. Recursive DNS servers are required to return \"NXDOMAIN\" when queried for localhost names, making non-conformant stub resolvers more likely to fail and produce problem reports that result in updates. Together, these requirements would allow applications and specifications to join regular users in drawing the common-sense conclusions that \"localhost\" means \"localhost\", and doesn't resolve to somewhere else on the network.",
"id": "let-localhost-be-localhost",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1220810",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "The proposal, to the extent it applies to browsers, is to hardcode localhost to always resolve to a loopback address instead of invoking the resolver library to perform such translation. Since browsers (including Firefox) treat files hosted on localhost to be more privileged than remote content, this proposal seems to be a good belt-and-suspenders approach to prevent certain exploits.",
"mozPositionIssue": 121,
"org": "IETF",
@@ -798,7 +798,7 @@
"id": "low-level-sockets",
"mdnUrl": null,
"mozBugUrl": null,
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "This API creates a way to circumvent protections, in particular the same-origin policy, that have been developed to protect these services. The safeguards outlined in the explainer are inadequate and incomplete. Relying on user consent is not a sufficient safeguard if this capability were to be exposed to the web.",
"mozPositionIssue": 431,
"org": "Proposal",
@@ -811,7 +811,7 @@
"id": "media-feeds",
"mdnUrl": null,
"mozBugUrl": null,
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "Media feeds uses harmful technologies to amplify a harmful feature. Many of the capabilities this enables are available to sites in other ways. For those capabilities that are not, extensions to the Media Session API would be preferable.",
"mozPositionIssue": 370,
"org": "Proposal",
@@ -824,7 +824,7 @@
"id": "media-session",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/Media_Session_API",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1112032",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This API allows sites to offer users common media controls, which improves usability of media playback sites.",
"mozPositionIssue": 28,
"org": "W3C",
@@ -837,7 +837,7 @@
"id": "mst-content-hint",
"mdnUrl": null,
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Content Hints is a welcome higher-level abstraction that does not require broad knowledge and tuning of video encoder, audio-processing, and congestion controls directly. Early concerns over lack of specificity around how hints interact with the lower-level controls they complement have been addressed.",
"mozPositionIssue": 101,
"org": "W3C",
@@ -850,7 +850,7 @@
"id": "mixed-content",
"mdnUrl": null,
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1779757",
- "mozPosition": "important",
+ "mozPosition": "positive",
"mozPositionDetail": "Managing mixed content has been an important cornerstone of the migration to more HTTPS. The level 2 spec is an important step towards more HTTPS adoption and has the potential to also improve the user experience on sites with accidentally mixed content.",
"mozPositionIssue": 668,
"org": "W3C",
@@ -863,7 +863,7 @@
"id": "netinfo",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/Network_Information_API",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1057169",
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "This API provides information about a client's network connection, which allows sites to obtain additional information about clients and their environment. It is better that sites use methods that dynamically adapt to available bandwidth, as that is more accurate and likely to be applicable in the moment.",
"mozPositionIssue": 117,
"org": "Proposal",
@@ -875,7 +875,7 @@
"description": "This specification defines a delivery mechanism for a number of policies which are to be applied to an entire origin. It compliments header-based delivery mechanisms for existing policies (Content Security Policy, Referrer Policy, etc).",
"id": "origin-policy",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1508290",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Giving developers the ability to set policies for an entire origin is a powerful new primitive that will benefit security of applications as well as performance due to the ability to bypass CORS preflights. The renewed effort to make this happen takes a strong anti-tracking stance that is in line with our efforts around privacy in Fetch, such as isolating the HTTP cache. Given this, it seems worth figuring out if this can be made viable.",
"mozPositionIssue": 160,
"org": "Proposal",
@@ -887,7 +887,7 @@
"description": "This feature allows for an agent cluster to be keyed by origin rather than site.",
"id": "domenic-origin-isolation",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1665474",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Letting developers opt out of document.domain and reduce the potential size of their agent cluster allows user agents to balance security, performance, and resource management.",
"mozPositionIssue": 244,
"org": "WHATWG",
@@ -899,7 +899,7 @@
"description": "This specification defines capabilities that enable Web applications to handle requests for payment.",
"id": "payment-handler",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1465682",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "The Payment Handler API has the potential to enable an open and secure payments ecosystem for the Web. At the same time, we remain concerned about some of the user interface requirements, and by the privacy and security assumptions made in the specification. We've raised our concerns at the W3C, and are working with the Payments working group to address those concerns. We hope that by prototyping the API we will actively address the privacy, security, and UI concerns; and fix those in the specification too. Additionally, having a working prototype will allow us to closely collaborate with the developer community and financial industry. By doing so, we will gain a better understanding of how we can solve the challenges we'll face, were we to eventually ship this API.",
"mozPositionIssue": 23,
"org": "W3C",
@@ -923,7 +923,7 @@
"description": "This specification describes a method that enables web applications to synchronize data in the background.",
"id": "periodic-background-sync",
"mozBugUrl": null,
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "We're concerned that this feature would allow users to be tracked across networks (leaking private information about location and IP address and how they change over time), and that it would allow script execution and resource consumption when it isn't clear to the user that they're interacting with the site. We might reconsider this position given evidence that these concerns can be safely addressed, however, addressing them for periodic background sync appears substantially harder than doing so for one-off background sync.",
"mozPositionIssue": 214,
"org": "Proposal",
@@ -936,7 +936,7 @@
"id": "permissions",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API",
"mozBugUrl": null,
- "mozPosition": "important",
+ "mozPosition": "positive",
"mozPositionDetail": "Mozilla believes that the ability to work with user permissions is critical for user agency. There are certain aspects of the API that are not suitable for the permissions model used in Firefox and so we would like to work on improving several aspects of the API. In particular, we think that the way that status of permissions needs to more accurately reflect the different states that exist or could exist. We also think that the interactions with Feature Policy need to be better clarified. We're committed to fixing this, because permissions has become critical in making the web a more capable platform and it is important to ensure that we preserve user control over their online experience.",
"mozPositionIssue": 19,
"org": "W3C",
@@ -948,7 +948,7 @@
"description": "This specification defines a mechanism that allows developers to selectively enable and disable use of various browser features and APIs.",
"id": "feature-policy",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1390801",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Mozilla's primary interest in this specification is in the delegation of permissions to third-party contexts that are not granted there by default. To that end we have shipped the allow attribute. The recently revised Permissions-Policy header seems worth prototyping and would allow for sites to impose restrictions on themselves. We hope that the JavaScript API can be folded into the Permissions API and have not evaluated the reporting functionality as of yet.",
"mozPositionIssue": 24,
"org": "W3C",
@@ -984,7 +984,7 @@
"description": "This specification defines APIs for scheduling and controlling prioritized tasks.",
"id": "scheduling-api",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1734997",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This feature is useful for web developers to provide a more responsive experience to users.",
"mozPositionIssue": 546,
"org": "Proposal",
@@ -997,7 +997,7 @@
"id": "priority-hints",
"mdnUrl": null,
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Priority hints allow sites to provide information about how subresources on a page might be prioritized for fetching. This can allow the browser to override parts of the internal prioritization heuristics that are used for resource fetching, which could improve page load performance.",
"mozPositionIssue": 606,
"org": "Proposal",
@@ -1022,7 +1022,7 @@
"id": "cors-and-rfc1918",
"mdnUrl": null,
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1481298",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "While imperfect and arguably at odds with Internet architecture, localhost and local networks of end users are vulnerable to attacks that this protocol will help mitigate.",
"mozPositionIssue": 143,
"org": "Proposal",
@@ -1034,7 +1034,7 @@
"description": "Powerful web applications would like to exchange data with native applications via the OS clipboard (copy-paste). The existing Web Platform has a high-level API that supports the most popular standardized data types (text, image, rich text) across all platforms. However, this API does not scale to the long tail of specialized formats. In particular, non-web-standard formats like TIFF (a large image format), and proprietary formats like .docx (a document format), are not supported by the current Web Platform. Raw Clipboard Access aims to provide a low-level API solution to this problem, by implementing copying and pasting of data with any arbitrary Clipboard type, without encoding and decoding.",
"id": "raw-clipboard-access",
"mozBugUrl": null,
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "The current proposal has significant risks of attacks on native applications. Some of these attacks may be mitigated by pickling or other similar solutions. If such a solution is incorporated, we would be willing to reevaluate this proposal.",
"mozPositionIssue": 206,
"org": "Proposal",
@@ -1047,7 +1047,7 @@
"id": "relative-indexing-method",
"mdnUrl": null,
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1658308",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Relative indexing is useful for typed arrays and arrays and will be a quality of life improvement for developers.",
"mozPositionIssue": 458,
"org": "Ecma",
@@ -1059,7 +1059,7 @@
"description": "This document defines a generic reporting framework which allows web developers to associate a set of named reporting endpoints with an origin. Various platform features can use these endpoints to deliver feature-specific reports in a consistent manner.",
"id": "reporting",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1620573",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This is a reasonable generalization of the CSP reporting mechanism that allows more features to adopt it.",
"mozPositionIssue": 104,
"org": "W3C",
@@ -1071,7 +1071,7 @@
"description": "A way to force an embedded document and descendants (regardless of origin) into each having their own agent/event loop.",
"id": "documentaccess",
"mozBugUrl": null,
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "Changing control flow of cross-origin documents without their consent is not something we should expand upon (i.e., beyond what sandboxing allows) as it could enable attack vectors. Furthermore, forcing same-origin documents in the same browsing context group to be in different agents is a major architectural change and this does not offer enough advantages to make such a change.",
"mozPositionIssue": 197,
"org": "Proposal",
@@ -1083,7 +1083,7 @@
"description": "The Sanitizer API allows turning supplied HTML into a safe HTML DOM tree",
"id": "sanitizer-api",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1650370",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This could be useful, since libraries exists and the browser could do it better.",
"mozPositionIssue": 106,
"org": "Proposal",
@@ -1095,7 +1095,7 @@
"description": "Reducing the scope of cookies by including the URL scheme in their keying material as well as reducing the lifetime of non-secure cookies.",
"id": "scheming-cookies",
"mozBugUrl": null,
- "mozPosition": "important",
+ "mozPosition": "positive",
"mozPositionDetail": "Reducing the scope of cookies along this axis is a major win.",
"mozPositionIssue": 298,
"org": "Proposal",
@@ -1107,7 +1107,7 @@
"description": "This document specifies an API that allows web applications to request a screen wake lock. Under the right conditions, and if allowed, the screen wake lock prevents the system from turning off a device's screen.",
"id": "screen-wake-lock",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1589554",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "As the scope of the specification has been reduced to screen wake locks, it's worth prototyping this API in a manner that restricts it to foreground first-party content. Additionally, the API appears flexible enough that a permission grant can be performed asynchronously, allowing us to evaluate the most appropriate permission model should we choose to ship this API in the future. As the API allows the capability to be revoked at any time, we can also prototype eagerly granting, notifying the user what's going on, and allowing users to disable the capability entirely - either per origin, or globally through a browser setting. There is a risk that sites could abuse the API for the sake of engagement, which could unnecessarily drain a device's battery. It could also be a nuisance or be used for social engineering attacks: such as disabling the system's ability to password-lock a device when the screen doesn't switch off if the user leaves their device unattended. Prototyping this capability would allow us to further evaluate how to best mitigate the aforementioned concerns.",
"mozPositionIssue": 210,
"org": "W3C",
@@ -1119,7 +1119,7 @@
"description": "A use of TLS Exported Authenticators is described which enables HTTP/2 clients and servers to offer additional certificate-based credentials after the connection is established. The means by which these credentials are used with requests is defined.",
"id": "http2-secondary-certs",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This specification enables client authentication in HTTP/2, which is of some benefit. However, it is the server authentication that is most interesting from a privacy perspective. There are some challenges that would need to be worked through before this could be deployed in anything other than an experiment.",
"mozPositionIssue": 175,
"org": "IETF",
@@ -1131,7 +1131,7 @@
"description": "The Serial API provides a way for websites to read and write from a serial device through script. Such an API would bridge the web and the physical world, by allowing documents to communicate with devices such as microcontrollers, 3D printers, and other serial devices. There is also a companion explainer document.",
"id": "webserial",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=webserial",
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "Devices that offer serial interfaces often expose powerful, low-level functions over the interface with little or no authentication. Exposing that sort of capability to the web without adequate safeguards presents a significant threat to those devices.",
"mozPositionIssue": 336,
"org": "Proposal",
@@ -1143,7 +1143,7 @@
"description": "This document specifies the \"SVCB\" and \"HTTPSSVC\" DNS resource record types to facilitate the lookup of information needed to make connections for origin resources, such as for HTTPS URLs. SVCB records allow an origin to be served from multiple network locations, each with associated parameters (such as transport protocol configuration and keying material for encrypting TLS SNI). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPSSVC DNS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.",
"id": "dnsop-svcb-httpssvc",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "While there are some details of the proposal that may require refining, we beleive that this is a promising approach to support Encrypted SNI, and may help improve user experience with HTTP/3.",
"mozPositionIssue": 208,
"org": "IETF",
@@ -1155,7 +1155,7 @@
"description": "A way to give a node in the DOM a hidden subtree in which the children of the node can be inserted.",
"id": "shadow-trees",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "A welcome successor to XBL!",
"mozPositionIssue": 60,
"org": "WHATWG",
@@ -1167,7 +1167,7 @@
"description": "This document specifies how a server can send an HTTP request/ response pair, known as an exchange, with signatures that vouch for that exchange's authenticity. These signatures can be verified against an origin's certificate to establish that the exchange is authoritative for an origin even if it was transferred over a connection that isn't. The signatures can also be used in other ways described in the appendices. These signatures contain countermeasures against downgrade and protocol-confusion attacks.",
"id": "http-origin-signed-responses",
"mozBugUrl": null,
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "Mozilla has concerns about the shift in the web security model required for handling web-packaged information. Specifically, the ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome, as is the removal of a guarantee of confidentiality from the web security model (the host serving the web package has access to plain text). We recognise that the use cases satisfied by web packaging are useful, and would be likely to support an approach that enabled such use cases so long as the foregoing concerns could be addressed.",
"mozPositionIssue": 29,
"org": "Proposal",
@@ -1179,7 +1179,7 @@
"description": "The Storage Access API provides a means for authenticated cross-site embeds to check their blocking status and request access to storage if they are blocked.",
"id": "storage-access-api",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1469714",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "In our current efforts to limit the impact of cross-site tracking there are cases where we may unintentionally break parts of web pages that users depend on. The storage access API provides a programmatic way for affected embedded content to fix these types of broken experiences for the user. Also, in our upcoming efforts to limit the potential capabilities for unknown third-parties to track the user, we would like to continue to restrict the storage capabilities of the third-party context. The storage access API similarly provides a programmatic path for the embedded widgets which cannot work correctly without access to their data. It isn't an ideal solution, for example our implementation falls back to prompting the user if it cannot automatically determine whether access should be granted or not, but it is a step in the right direction in the game of reversing the current defaults of the web, that is granting permissive storage access rights to all third-party contexts unconditionally.",
"mozPositionIssue": 280,
"org": "Proposal",
@@ -1192,7 +1192,7 @@
"id": "streams",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/Streams_API",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1128959",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Streams are an important building block for many APIs, in particular around networking and media.",
"mozPositionIssue": 70,
"org": "WHATWG",
@@ -1204,7 +1204,7 @@
"description": "This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header fields. It is intended for use by specifications of new HTTP header fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.",
"id": "structured-headers",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1631722",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Use of structured headers promises to improve consistency and interoperability of new HTTP header fields. Depending on further security analysis, we may upgrade this feature to 'important' in the future.",
"mozPositionIssue": 256,
"org": "IETF",
@@ -1216,7 +1216,7 @@
"description": "Serializing and deserializing JavaScript Error objects.",
"id": "errors-structured-cloning",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1556604",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Good extension to the object serialization algorithm (StructuredSerializeInternal) as currently there is no way to serialize errors.",
"mozPositionIssue": 165,
"org": "WHATWG",
@@ -1229,7 +1229,7 @@
"id": "tc39-stage-3",
"mdnUrl": null,
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1435811",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Due to the structure of TC39, stage 3 signifies that a proposal is ready to implement. Stage 3 proposals have been reviewed by the SpiderMonkey team and more broadly within Gecko. Stage 2 proposals which require security/privacy review or host integration require their own Mozilla Standards Position.",
"mozPositionIssue": 527,
"org": "Ecma",
@@ -1241,7 +1241,7 @@
"description": "A proposal for extending URL fragment syntax with a list of text bits to highlight and scroll to.",
"id": "scroll-to-text-fragment",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1753933",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This is an important use case to address and the proposal does a good job at mitigating the compatibility and security issues. As a result the syntax is a tad inelegant, but workable. (See also the position on Fragmention, which aims to address similar use cases.)",
"mozPositionIssue": 194,
"org": "Proposal",
@@ -1265,7 +1265,7 @@
"description": "The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with a model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional.",
"id": "webtransport",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "We are generally in support of a mechanism that addresses the use cases implied by this solution document. While major questions remain open at this time -- notably, multiplexing, the API surface, and available statistics -- we think that prototyping the proposed solution as details become more firm would be worthwhile. We would like see the new WebSocketStream and WebTransport stream APIs to be developed in concert with each other, so as to share as much design as possible.",
"mozPositionIssue": 167,
"org": "Proposal",
@@ -1277,7 +1277,7 @@
"description": "Top-level await enables modules to act as big async functions: With top-level await, ECMAScript Modules (ESM) can await resources, causing other modules who import them to wait before they start evaluating their body.",
"id": "top-level-await",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1519100",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "An ergonomic way of handling modules that contain top level asynchronous work.",
"mozPositionIssue": 444,
"org": "Ecma",
@@ -1289,7 +1289,7 @@
"description": "In Transport Layer Security (TLS) handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.",
"id": "tls-certificate-compression",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Compression of certificates should provide some performance advantages.",
"mozPositionIssue": 96,
"org": "IETF",
@@ -1313,7 +1313,7 @@
"description": "An API that allows applications to lock down powerful APIs to only accept non-spoofable, typed values in place of strings to prevent vulnerabilities caused by using these APIs with attacker-controlled inputs.",
"id": "trusted-types",
"mozBugUrl": null,
- "mozPosition": "non-harmful",
+ "mozPosition": "neutral",
"mozPositionDetail": "The API could be used to harden sites against certain cross-site scripting issues, but it is sufficiently complex that we are concerned that it will not be suitable for many sites.",
"mozPositionIssue": 20,
"org": "W3C",
@@ -1325,7 +1325,7 @@
"description": "The QID Emoji Tag Sequences (or QID emoji, for short) have been proposed to provide a well-defined mechanism for implementations to support additional valid emoji that are not representable by Unicode characters or emoji zwj sequences. This mechanism allows for the interchange of emoji whose meaning is discoverable, and which should be correctly parsed by all conformant implementations (although only displayed by implementations that support it). The meaning of each of these valid emoji is established by reference to a Wikidata QID.",
"id": "unicode-emoji-qid",
"mozBugUrl": null,
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "Mozilla has a number of concerns about this proposal, including: (a) the lack of reference glyphs is likely to increase miscommunication between users; (b) having a formal, versioned approval process provides synchronization between implementors for adding new glyphs, and this proposal removes that; (c) QID glyphs that are later adopted into Unicode would result in duplicate encodings, perhaps in perpetuity; (d) gathering telemetry about the popularity of specific emoji for the purposes of more formal codepoint assignments may cause privacy issues and provides incumbent implementors a competitive advantage; and (e) there are no barriers to abuse of the QID system to create non-emoji characters as a general end-run around the Unicode process.",
"mozPositionIssue": 233,
"org": "Unicode",
@@ -1337,7 +1337,7 @@
"description": "This document defines a set of Client Hints that aim to provide developers with the ability to perform agent-based content negotiation when necessary, while avoiding the historical baggage and passive fingerprinting surface exposed by the venerable \"User-Agent\" header.",
"id": "ua-client-hints",
"mozBugUrl": null,
- "mozPosition": "non-harmful",
+ "mozPosition": "neutral",
"mozPositionDetail": "UA Client Hints proposes that information derived from the User-Agent header field be sent as new structured fields to HTTPS servers that opt into receiving that information. The goal is to reduce the number of parties that can passively fingerprint users using UA fields. However, three of the new headers are sent unconditionally in every HTTPS request without explicit opt-in. We would prefer to progressively freeze the value of User-Agent HTTP header without replacement. We acknowledge the performance trade-offs this might introduce, but note that the performance characteristics of the proposed design are unclear and optimized almost exclusively for the very first connection to a site. The overheads involved add further uncertainty about performance as three new header fields are sent in every HTTPS request, plus fields for any information a site requests using the Accept-CH mechanism. Adding fields makes it more likely that server-side limits on fields are exceeded, which - even if it is not be a problem now - future specifications might be affected. Any benefit to edge caches from the use of the Vary mechanism on the new headers is not realized unless all clients send these new headers. For caching, we would prefer to explore other options that do not rely on all clients sending the new fields. The proposed NavigatorUAData interface JS API is preferable to use of header fields as it would better allow for auditing of the use of the information.",
"mozPositionIssue": 202,
"org": "Proposal",
@@ -1350,7 +1350,7 @@
"id": "webauthn",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1294514",
- "mozPosition": "important",
+ "mozPosition": "positive",
"mozPositionDetail": "Public key cryptographic authentication is a major improvement in the fight against phishing, and we encourage all security-conscious web applications to implement authentication flows utilizing Web Authentication in the future.",
"mozPositionIssue": 163,
"org": "W3C",
@@ -1363,7 +1363,7 @@
"id": "background-sync",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/SyncManager",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1547906",
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "We're concerned that this feature would allow users to be tracked across networks (leaking private information about location and IP address and how they change over time), and that it would allow script execution and resource consumption when it isn't clear to the user that they're interacting with the site. We might reconsider this position given evidence that these concerns can be safely addressed.",
"mozPositionIssue": 173,
"org": "Proposal",
@@ -1376,7 +1376,7 @@
"id": "web-bluetooth",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=674737",
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.",
"mozPositionIssue": 95,
"org": "Proposal",
@@ -1388,7 +1388,7 @@
"description": "This specification describes an API that can be used to retrieve the amount of budget an origin has available for resource consuming background operations, as well as the cost associated with doing such an operation.",
"id": "budget-api",
"mozBugUrl": null,
- "mozPosition": "non-harmful",
+ "mozPosition": "neutral",
"mozPositionDetail": "This specification is being abandoned.",
"mozPositionIssue": 73,
"org": "Proposal",
@@ -1400,7 +1400,7 @@
"description": "An API that allows web applications to encode and decode audio and video",
"id": "web-codecs",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This proposes a coherent set of APIs to address encoding and decoding of video and audio, which is designed to be extensible, composable, and address real use cases with good performance.",
"mozPositionIssue": 209,
"org": "Proposal",
@@ -1412,7 +1412,7 @@
"description": "This specification describes support for accessing modern 3D graphics and GPU computation capabilities on the Web.",
"id": "webgpu",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1602129",
- "mozPosition": "important",
+ "mozPosition": "positive",
"mozPositionDetail": "We believe that WebGPU is key to enable more interactive and content-rich applications on the Web than currently possible with WebGL. WebGPU can scale better to the capabilities of GPUs with less overhead for users because it's modelled after the intersection of the modern native GPU APIs, so allows developers to express the GPU workloads more explicitly.",
"mozPositionIssue": 239,
"org": "Proposal",
@@ -1425,7 +1425,7 @@
"id": "web-locks",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API",
"mozBugUrl": "",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "The specification provides important web platform primitives for same-global and cross-global coordination and avoids requiring other APIs to grow their own transaction abstractions (ex: the Service Worker spec's Cache API).",
"mozPositionIssue": 64,
"org": "Proposal",
@@ -1450,7 +1450,7 @@
"description": "Near Field Communication (NFC) enables wireless communication between two devices at close proximity, usually less than a few centimeters. This document defines an API to enable selected use cases based on NFC technology. The current scope of this specification is NDEF. Low-level I/O operations (e.g. ISO-DEP, NFC-A/B, NFC-F) and Host-based Card Emulation (HCE) are not supported within the current scope.",
"id": "web-nfc",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1308614",
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.",
"mozPositionIssue": 238,
"org": "Proposal",
@@ -1463,7 +1463,7 @@
"id": "web-share",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1312422",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This specification defines an API that invokes sharing features of the operating system, for passing information to other applications. One risk of this is that having this as in-page user interface rather than in-browser user interface may reduce the relevance to the user of the information shown in the URL/location bar. However, given the demand for this capability it seems like it is likely worth exposing to the Web, and we support prototyping this feature.",
"mozPositionIssue": 27,
"org": "W3C",
@@ -1475,7 +1475,7 @@
"description": "This specification defines an API that allows websites to declare themselves as web share targets, which can receive shared content from either the Web Share API, or system events (e.g., shares from native apps). This is a similar mechanism to navigator.registerProtocolHandler, in that it works by registering the website with the user agent, to later be invoked from another site or native application via the user agent (possibly at the discretion of the user). The difference is that registerProtocolHandler registers the handler via a programmatic API, whereas a Web Share Target is declared in the Web App Manifest, to be registered at a time of the user agent or user's choosing.",
"id": "web-share-target",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1476515",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This specification affords web applications the ability to handle user-initiated 'share' actions (e.g., sharing a link, image, text, or other media) in contexts that have traditionally been the exclusive domain of native and/or system applications. We believe this API is worth prototyping because it enhances the utility of web applications to end-users, and allows us to explore ways that web applications can more effectively integrate with the underlying operating system.",
"mozPositionIssue": 27,
"org": "Proposal",
@@ -1487,7 +1487,7 @@
"description": "This document describes a common data model and API for the Web of Things. The Web Thing Description provides a vocabulary for describing physical devices connected to the World Wide Web in a machine readable format with a default JSON encoding. The Web Thing REST API and Web Thing WebSocket API allow a web client to access the properties of devices, request the execution of actions and subscribe to events representing a change in state. Some basic Web Thing Types are provided and additional types can be defined using semantic extensions with JSON-LD. In addition to this specification there is a note on Web Thing API Protocol Bindings which proposes non-normative bindings of the Web Thing API to various existing IoT protocols. There is also a document describing Web of Things Integration Patterns which provides advice on different design patterns for integrating connected devices with the Web of Things, and where each pattern is most appropriate.",
"id": "web-thing-api",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": null,
"mozPositionIssue": 44,
"org": "W3C",
@@ -1500,7 +1500,7 @@
"id": "wasm-exceptions",
"mdnUrl": null,
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1695715",
- "mozPosition": "important",
+ "mozPosition": "positive",
"mozPositionDetail": "Exception handling is important to C++ programs targeting the web, and to other languages in the future.",
"mozPositionIssue": 573,
"org": "Proposal",
@@ -1513,7 +1513,7 @@
"id": "wasm-simd",
"mdnUrl": null,
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1625130",
- "mozPosition": "important",
+ "mozPosition": "positive",
"mozPositionDetail": "Supports common SIMD data type and operations important to C/C++/Rust programs targeting the web within domains such as graphics, video/audio encoding/decoding, and machine learning.",
"mozPositionIssue": 491,
"org": "W3C",
@@ -1526,7 +1526,7 @@
"id": "webdriver-bidi",
"mdnUrl": null,
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1690255",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "Automation is an important capability for the web platform - for example, reliable automated testing makes it easier for websites to offer a functional user experience. The current standard protocol for building these tools has fallen behind demonstrated needs, which has in part led to new tools being built on Chrome DevTools Protocol. This makes it harder to automate across multiple browsers and versions of browsers - it\u2019d be better for the standard protocol to support these needs.",
"mozPositionIssue": 632,
"org": "W3C",
@@ -1539,7 +1539,7 @@
"id": "webhid",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/HID",
"mozBugUrl": null,
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "This API, like WebUSB, provides access to generic devices. Though this API is limited to human interface devices (HID), the same concerns apply as WebUSB, namely that devices are generally not designed with access from arbitrary websites in their threat model.",
"mozPositionIssue": 459,
"org": "Proposal",
@@ -1552,7 +1552,7 @@
"id": "webrtc-insertable-streams",
"mdnUrl": null,
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This approach provides sites a way to offer a form of end-to-end protection for media, especially in those very common cases where media for group sessions is managed by a central service. The proposed API, together with the SFrame proposal, provides sites the ability to limit the information that is exposed to the central service. Mozilla would prefer to include better key management than this approach proposes, perhaps using MLS, which might guarantee certain security and privacy gains for users. However, we recognize that this is not yet feasible and this API can provide security and privacy gains if carefully applied by sites.",
"mozPositionIssue": 330,
"org": "W3C",
@@ -1564,7 +1564,7 @@
"description": "Use cases about providing guarantees to users about the privacy of their WebRTC videoconferencing when the servers are not trusted but the JavaScript is.",
"id": "webrtc-nv-use-cases-trusted-js",
"mozBugUrl": null,
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "We believe the \"Untrusted JS\" alternative would allow browsers to provide useful guarantees to users about the security of their videoconferencing, but the \"Trusted JS\" variant would not, and seems likely to add unnecessary complexity.",
"mozPositionIssue": 205,
"org": "Proposal",
@@ -1577,7 +1577,7 @@
"id": "webusb",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/USB",
"mozBugUrl": null,
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.",
"mozPositionIssue": 100,
"org": "Proposal",
@@ -1590,7 +1590,7 @@
"id": "webxr",
"mdnUrl": "https://developer.mozilla.org/en-US/docs/Web/API/WebXR_Device_API",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1419190",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "The WebXR Device API is the basis for VR, MR, and AR on the web. This is a significant and large suite of features. There is the potential for XR to provide significant benefits, but also a number of risks to individual privacy and security due to the way that XR relies on sensors and environmental data. Developing new interaction models also presents challenges and considerable work is required before new norms are established. Mozilla is actively working on WebXR and supportive of its overall goals. Our participation in and implementation of this API is critical to understanding the feature and learning how to empower users in managing the associated risks.",
"mozPositionIssue": 218,
"org": "Proposal",
@@ -1614,7 +1614,7 @@
"description": "This specification defines an API for running scripts in stages of the rendering pipeline independent of the main javascript execution environment.",
"id": "worklets",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1315239",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This specification is essential for allowing features like the CSS Paint API and CSS Layout API to be implemented in a safe way.",
"mozPositionIssue": 93,
"org": "W3C",
@@ -1638,7 +1638,7 @@
"description": "The dialog element represents a part of an application that a user interacts with to perform a task, for example a dialog box, inspector, or window.",
"id": "dialog-element",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=840640",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "A high-level HTML feature for authors to achieve these use cases while getting a11y right seems useful, and we have an implementation.",
"mozPositionIssue": 388,
"org": "WHATWG",
@@ -1650,7 +1650,7 @@
"description": "The enterkeyhint attribute specifies what action label (or icon) to present for the enter key on virtual keyboards.",
"id": "enterkeyhint-attr",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1490661",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": null,
"mozPositionIssue": 68,
"org": "WHATWG",
@@ -1662,7 +1662,7 @@
"description": "Allow arbitrary DOM subtrees to become inert",
"id": "inert-attr",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=921504",
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "A high-level tool for authors to achieve some of these use cases while getting a11y right seems useful",
"mozPositionIssue": 174,
"org": "WHATWG",
@@ -1674,7 +1674,7 @@
"description": "Proposal to add various output attributes on HTML's <input> elements that would allow developers to declare some conversions the browser could do to, for example, images and videos.",
"id": "input-file-output-attributes",
"mozBugUrl": null,
- "mozPosition": "non-harmful",
+ "mozPosition": "neutral",
"mozPositionDetail": "While this seems like it could be a useful capability to expose, we'd rather see it exposed in a way that can be composed with other existing APIs, and we're concerned that there's a risk of runaway complexity through adding more and more features to it.",
"mozPositionIssue": 237,
"org": "Proposal",
@@ -1686,7 +1686,7 @@
"description": "A descriptor for CSS @page rules that changes the orientation of the page in generated PDF output (or similar) without otherwise affecting layout.",
"id": "page-orientation-descriptor",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "This is a simple addition (to a relatively complex existing feature, named pages) that can improve the experience of producing printed PDF output from web-based word processors or similar systems that largely do their own page layout.",
"mozPositionIssue": 346,
"org": "W3C",
@@ -1698,7 +1698,7 @@
"description": "An attribute that specifies the rules for generating acceptable passwords.",
"id": "passwordrules-attribute",
"mozBugUrl": null,
- "mozPosition": "harmful",
+ "mozPosition": "negative",
"mozPositionDetail": "We believe this proposal, as drafted, encourages bad practices around passwords without encouraging good practices (such as minimum password length), and further has ambiguous and conflicting overlap with existing input validity attributes. We believe the existing input validity attributes and API are sufficient for expressing password requirements.",
"mozPositionIssue": 61,
"org": "WHATWG",
@@ -1710,7 +1710,7 @@
"description": "The new scroll events introduced in this document provide web developers a way to listen to the state of the scrolling and when their content is being overscrolled or when the scrolling has finished. This information will be useful for the effects such as pull to refresh or history swipe navigations in the web apps.",
"id": "scrollend-and-overscroll-events",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "We believe these are likely to provide frequently-requested functionality that is useful for many web applications.",
"mozPositionIssue": 240,
"org": "Proposal",
@@ -1722,7 +1722,7 @@
"description": "The template element is used to declare fragments of HTML that can be cloned and inserted in the document by script.",
"id": "template-element",
"mozBugUrl": null,
- "mozPosition": "worth prototyping",
+ "mozPosition": "positive",
"mozPositionDetail": "A reasonable addition to HTML (and XML), if not somewhat taxing on the parser.",
"mozPositionIssue": 60,
"org": "WHATWG",
diff --git a/activities.py b/activities.py
index 69a4c46d..b45c323d 100755
--- a/activities.py
+++ b/activities.py
@@ -77,12 +77,11 @@ class ActivitiesJson(object):
"mozPosition",
True,
[
- "under consideration",
- "important",
- "worth prototyping",
- "non-harmful",
+ "positive",
+ "neutral",
+ "negative",
"defer",
- "harmful",
+ "under consideration",
],
),
("mozPositionDetail", False, StringType),
diff --git a/index.html b/index.html
index 4b5093e3..20cccf6d 100644
--- a/index.html
+++ b/index.html
@@ -104,12 +104,11 @@ The possible positions are: