Standards Positions

Link	Specification	Position	Concerns	Topics	Venues	More info
🔗	[WebRTC] Align browsers on RTP stats lifetimes	positive		API		#1202
🔗	Remove auto-detection of ISO-2022-JP charset in HTML	positive				#1199
🔗	Happy Eyeballs Version 3	positive				#1192
🔗	[Push API] Declarative Web Push	positive		API		#1176
Details Description Declarative Web Push introduces a JSON format that the user agent can recognize and parse without a Service Worker. Rationale We believe this proposal can reduce the required code size to subscribe push notifications, and it introduces a way for browsers to suppress potentially unwanted push notifications from tracking users.
🔗	H26x Codec support updates for MediaRecorder	neutral	interoperability			#1174
🔗	On-device Web Speech API	positive		API		#1157
Details Description This is a set of improvements to the Web Speech API specification that aims at adding features for users to perform speech-to-text and text-to-speech using the device's capabilities, without relying on web services. This also allows using Web Speech API with MediaStreamTrack. Rationale We believe this is a strong and welcome improvement to the API, on multiple aspects: added capabilities to the platform, in terms for feature and performance (e.g. being able to do high-quality low-latency recognition), but also accessibility and privacy.
🔗	Navigation API: sourceElement	positive		API		#1154
🔗	Add finalResponseHeadersStart to resource timing	positive		API		#1108
🔗	CSS text-box, text-box-trim, text-box-edge	positive		CSS		#1105 📊
🔗	Dialog BeforeToggle/Toggle events	positive		HTML		#1101
🔗	template element	positive				#1098
Details Description The template element is used to declare fragments of HTML that can be cloned and inserted in the document by script. Rationale A reasonable addition to HTML (and XML), if not somewhat taxing on the parser.
🔗	Worklets	positive				#1097
Details Description This specification defines an API for running scripts in stages of the rendering pipeline independent of the main javascript execution environment. Rationale This specification is essential for allowing features like the CSS Paint API and CSS Layout API to be implemented in a safe way.
🔗	Shadow trees (formerly known as Shadow DOM)	positive				#1094 📊
Details Description A way to give a node in the DOM a hidden subtree in which the children of the node can be inserted. Rationale Standardized successor of XBL.
🔗	HTML Imports	negative				#1093 📊
Details Description HTML Imports are a way to include and reuse HTML documents in other HTML documents. Rationale Mozilla anticipated that JavaScript modules would change the landscape here and would rather invest in evolving that, e.g., through HTML Modules. Having a single mechanism to deal with dependencies rather than several, potentially conflicting systems, seems preferable.
🔗	Custom elements	positive				#1092 📊
Details Description A way to create new HTML elements implemented through JavaScript. Rationale Standardized successor of XBL.
🔗	CSS Typed OM	positive				#1091
Details Description Converting CSSOM value strings into meaningfully typed JavaScript representations and back can incur a significant performance overhead. This specification exposes CSS values as typed JavaScript objects to facilitate their performant manipulation. Rationale This specification provides an easier way to manipulate the CSS object model.
🔗	CSS Properties and Values API	positive				#1090
Details Description This CSS module defines an API for registering new CSS properties. Properties registered using this API are provided with a parse syntax that defines a type, inheritance behaviour, and an initial value. Rationale This specification makes it significantly easier to use CSS custom properties in ways that are more like regular CSS properties.
🔗	CSS Painting API	positive				#1089 📊
Details Description An API for allowing web developers to define a custom CSS <image> with javascript, which will respond to style and size changes. Rationale This specification allows developing prototypes of new graphical CSS features and provides an escape hatch for developers when the existing features aren't good enough for a particular piece of a web page.
🔗	CSS Layout API	positive				#1088
Details Description An API for allowing web developers to define their own layout modes with javascript. Rationale This specification allows developing prototypes of new CSS layout systems and provides an escape hatch for developers when the existing systems aren't good enough for a particular piece of a web page.
🔗	Relax <select> parser	positive	compatibility	HTML		#1086
🔗	CSS Scoping :has-slotted pseudo	positive		CSS		#1079
🔗	MediaStreamTrackProcessor and VideoTrackGenerator	positive		API		#1078
🔗	Transferable RTCDataChannel	positive		API		#1077 📊
🔗	RTCRtpEncodingParameters.scaleResolutionDownTo	positive		API		#1071
🔗	PerformanceEventTiming.interactionId	positive		API		#1069
🔗	Writing Assistance APIs	defer		API		#1067
🔗	FYI Private State Token API Permissions Policy Default Allowlist Wildcard	negative	venue, privacy, use cases			#1066
🔗	FedCM as a trust signal for the Storage Access API	positive		API		#1065
🔗	Customizable select element	positive	compatibility	CSS, HTML		#1060
🔗	Selection API: getComposedRanges	positive		API		#1055
🔗	[css-sizing-4] stretch keyword for sizing properties	positive		CSS		#1054 📊
🔗	DOM State-preserving move (Node.prototype.moveBefore)	positive		API		#1053
🔗	Backdrop filter mirror edgeMode	positive		CSS		#1051
🔗	ariaNotify API	defer	complexity, API design	API		#1049
🔗	CSS Nesting: The Nested Declarations Rule	positive		CSS		#1048
Details Description Implicit rules created by nesting create a new kind of rule, not an style rule Rationale Straight improvement to the status quo of CSS nesting
🔗	Transferable MediaStreamTrack (Media Capture and Streams Extension)	positive		API		#1044
🔗	Partitioned :visited links history	positive				#1040
🔗	Prioritized Task Scheduling: scheduler.yield()	positive				#1039
🔗	New trusted-types-eval keyword for CSP script-src	positive				#1032
🔗	Local Peer-to-Peer API	defer				#1029
🔗	improved styling of <details> and <summary> elements	positive				#1027
🔗	Partitioned Popins	defer				#1023
🔗	CSS interpolate-size property and calc-size() function	positive				#1022
🔗	The ChapterInformation interface	positive				#1019
🔗	Allow converting VideoFrame to RGB pixel formats by calling VideoFrame.copyTo()	positive				#1017
🔗	AudioContext.onerror	positive				#1016
🔗	Reduce Accept-Language	defer		HTTP		#1014
Details Description Describes a technique to limit the languages sent in the Accept-Language header to a single language to reduce the passive fingerprint sent by a user. Rationale Mozilla is exploring anti-fingerprinting engineering proposals. While this is interesting to consider, until we know how much it would actually help our users and how much it would affect the web, we will defer an opinion.
🔗	CSS Nesting: @nest	positive		CSS		#1013 📊
🔗	document.caretPositionFromPoint API in shadow DOM scenario	positive				#1012
🔗	Importmap integrity	neutral	security			#1010
🔗	Constructors for RTC Encoded Frames with metadata	positive				#1009
🔗	getHTML() and the serializable concept	positive				#1006
🔗	Digital Credentials	negative				#1003
Details Description The digital credentials API is an extension to the credential management API that enables access to identity documentation that might be held in the user agent or a wallet on the same device. Rationale This interface carries a significant risk of causing privacy problems and could lead to unjustified exclusion of web users. Any solution in this area needs to do more to manage these risks before it could be considered safe to deploy.
🔗	autocomplete=device-eid and =device-imei	negative				#1002
🔗	MediaRecorder: Support mp4 container with avc1 and mp4a.40.2 codecs for MediaRecorder	positive				#996
🔗	[css-color-adjust-1] Root non-overlay scrollbars used color scheme	positive				#995
🔗	CSS margin-trim property	positive				#994 📊
🔗	CSS text-wrap-style: pretty	positive	compatibility, complexity	CSS		#993 📊
🔗	View Transition Classes	positive		CSS		#988
🔗	Standardized CSS zoom	positive				#977
🔗	WebRTC: RTCIceCandidate relayProtocol and url properties	positive		API		#976
🔗	The textInput event	neutral				#975
🔗	Make computation of directionality account for Shadow DOM	positive				#974
🔗	CSS Fragmentation Level 3 - §3.3 Breaks Between Lines: orphans, widows	positive				#972 📊
Details Description These CSS properties provide control over typographic widows and orphans during fragmentation/pagination.
🔗	The pageconceal event (part of cross-document view-transitions)	positive				#969
🔗	Fetch keepalive	positive				#967 📊
🔗	WebSockets: Allow http(s) scheme and relative URLs	positive				#966
🔗	popover=hint	positive	accessibility			#965
🔗	WebAuthn: Allow for credential creation in a cross-origin iframe	positive				#964
🔗	Private Access Tokens	negative				#954
Details Description Private Access Tokens is the name given to the integration of Privacy Pass mechanism into Apple's networking stack. Rationale This application of Privacy Pass fairly closely follows the IETF specification, but the integration with the Web means that the effect is of a proprietary deployment. A number of considerations relevant to use on the Web have not been adequately addressed in the deployment.
🔗	WebAssembly JS Promise Integration	positive				#944
Details Rationale Addresses a major paint point for developers porting existing applications that assume synchronous I/O to the web.
🔗	FileSystemObserver	positive				#942
🔗	New 'onmove' event handler for the Window object	defer				#938
🔗	MediaTrackSupportedConstraints.eyeGazeCorrection	positive				#934
🔗	Lazy load scroll margin	positive				#933
🔗	WebGPU default entry points to shader modules	positive				#931
🔗	Long Animation Frame	positive				#929
Details Description This specification defines APIs for reporting information for frames that take a long time to render. Rationale This feature allows web developers to measure frame congestion and jank, and has a correlation with how user perceive this type of congestion. Web developers can use this API to improve the perceived performance of their pages.
🔗	navigation.activation	positive				#928
🔗	Page Embedded Permission Control	negative	complexity, integration, use cases			#908
🔗	View Transitions: list of types	positive				#905
🔗	Invokers (command & commandfor)	positive				#902
Details Description Invokers allow authors to assign behaviour to buttons in a more accessible and declarative way. Rationale This proposal reduces the need for JavaScript for pages to build interactive elements. Using invokers is more likely to result in good accessibility and device-independence than existing methods.
🔗	Fire toggle events using microtasks	positive				#901
🔗	Extending Storage Access API (SAA) to non-cookie storage	positive				#898
🔗	MediaStreamTrack Statistics (Video)	positive				#895
🔗	Feature detection for supported clipboard formats	positive				#889
🔗	CaptureStartFocusBehavior enum value "focus-capturing-application"	positive				#888
🔗	Allow <hr> tags inside <select> tags	positive				#887
🔗	HTMLSelectElement showPicker()	positive				#886
🔗	CSS Values 5: attr() fallback	positive				#885
🔗	Remove same-origin blanket enforcement from CSP Embedded Enforcement	positive				#878
🔗	HTML: Document Render-Blocking	positive				#875
🔗	X25519Kyber768 key encapsulation for TLS	positive				#874
🔗	Global Privacy Control (GPC)	positive				#867 📊
Details Description This spec defines a signal that conveys a person's request to websites and services to not sell or share their personal information with third parties. Rationale This signal defined in this specification provides users with a way to opt-out of the disclosure of their information to third parties once per profile in a way that is legally enforced in some jurisdictions, and is being considered in future regulations.
🔗	Policy container	positive				#863
🔗	Multiple Readers and Writers in File System Access API	positive				#861
🔗	Opaque Response Blocking	positive				#860
Details Description Safelist certain opaque responses based on MIME type and block everything else. Rationale Our preferred approach to handle opaque responses when defending against Spectre attacks.
🔗	Element Capture	negative				#857
🔗	Web Environment Integrity API	negative				#852
🔗	css-ui field-sizing property	positive				#849
🔗	ManagedMediaSource API	positive				#845
Details Description This proposal extends Media Source Extension objects with a number of features that allow web applications to be more efficient in terms of power usage and memory. Rationale This opt-in feature of Media Source Extension allows implementations to reclaim memory when needed, and to allows scheduling download of media data when it's best to do so in terms of power usage. This is especialy important on mobile. This has the potential to improve the experience of media playback on low-power devices, but also generally allows web applications to use resources more efficiently.
🔗	Locale Extensions	negative				#844
Details Description Exposes to the Web user preferences for hour cycle, first day of week, temperature unit, numbering system, and calendar system overriding values implied by language-region pair Rationale Use cases have legitimacy, but they don't seem strong enough to justify the additional fingerprinting surface. Addressing fingerprinting, if even possible, would likely to involve disproportionate design, engineering, and UI surface relative to the utility.
🔗	CSS Color 5: Relative Color Syntax	positive				#841 📊
Details Description Relative color syntax (RCS) allows developers to create a range of dynamic colors, starting from a base color, that will change as the base color changes. Great for creating color palettes and schemes. Rationale Enables more freedom for developers to make use of the new forms and spaces introduced in CSS Color Module Level 4.
🔗	Lazy loading for iframes	positive				#840 📊
🔗	contenteditable="plaintext-only"	positive				#839
🔗	UserActivation API	positive				#838
Details Description The UserActivation API provides the ability to query whether the window currently has or has previously had real user interaction. Rationale This API exposes the sticky activation and transient activation concepts which browsers use internally for, e.g., allowing popups. These concepts are useful for web apps as well.
🔗	Bounce Tracking Mitigations	positive				#835
Details Description This specification defines navigational tracking and when and how browsers are required to prevent it from happening. Rationale With 3rd-party cookies being restricted by default in all major browsers, navigational tracking plays an increasingly important role on the web. This spec describes an effective cross-browser mechanism to combat bounce tracking, which does not rely on tracker lists. It provides predictable detection heuristics for web developers and preserves legitimate uses of short-lived redirects where possible. While browsers already ship similar protections, e.g. Firefox's tracker purging, aligning on common behavior improves web compatibility and encourages site developers to use specialized APIs, rather than relying on top level redirects for functionality.
🔗	dialogmodaltarget attribute	negative				#834
🔗	@starting-style CSS Rule	positive				#833
🔗	Exclusive accordions with <details name="">	positive				#831
🔗	Web Charts	negative				#829
🔗	ServiceWorker static routing API	positive				#828
Details Description The initial proposal allows ServiceWorkers to define routes using URLPattern to bypass the ServiceWorker, avoiding spurious ServiceWorker wake-ups and avoiding the additional latency of sending requests to the ServiceWorker that it will not handle. Longer term, the mechanism could also support consulting the Cache API without needing to wake up a ServiceWorker. Rationale A longstanding performance concern for ServiceWorkers and the sites using them is that there is no way to skip going to a ServiceWorker for a controlled page when there is a "fetch" handler present. The Static Routing API has been recognized as an ideal solution to address the problem versus other proposals like adding new attributes to HTML tags or arguments to the fetch API. The static routing API had been discussed extensively in ServiceWorker WG meetings as a reasonable option but very complex to implement and specify, which is why it was not part of the original spec. With the introduction of the URLPattern API, the Static Routing API is thankfully even easier to implement and specify. The evolutionary approach where the Static Routing API will only start with a network source that bypasses the ServiceWorker is appropriately pragmatic.
🔗	contain-intrinsic-size: auto none syntax support	positive				#827
🔗	Snapshotting inherited base URL	positive				#813
🔗	Deprecate TLS SHA-1 server signatures	positive				#812
🔗	Tabbed web apps	defer				#811
🔗	CSS Values 5: random()	positive		CSS		#809
🔗	Deprecation / Removal of Mutation Events	positive				#807 📊
🔗	Ignore target names which contain both \n and < characters	positive				#804
🔗	CSS Motion Path	positive				#802
🔗	Add value argument to URLSearchParams's has() and delete()	positive				#801
🔗	HTTPS Upgrades	positive				#800
🔗	Isolated Web Apps	negative	venue, security, API design			#799
🔗	WebAuthn PRF extension	positive				#798
🔗	Intervention Reporting (Reporting API)	neutral				#797
🔗	COEP violation (Reporting API)	positive				#796
🔗	COOP violation (Reporting API)	positive				#795
🔗	CSS Anchor Positioning	positive				#794 📊
Details Description Anchor Positioning allows positioned elements to size and position themselves relative to one or more 'anchor elements' elsewhere on the page. Rationale This is an important evolution of absolute positioning that addresses a common and much requested authoring use case that otherwise requires the use of JavaScript.
🔗	WebRTC Codec selection API	positive				#789
🔗	customElements.getName	positive				#785
🔗	Submitting element directionality via the dirname attribute	positive				#782
🔗	Fenced frames	negative	complexity, privacy, security, use cases	HTML		#781
🔗	WhatWG owning type streams	positive				#778
🔗	Zstandard compression format for Content-Encoding	positive				#775
Details Description Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet Mail Extensions (MIME). Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only. Rationale Zstandard/Zstd has been shown to be an effective compression scheme especially for dynamic content, by reducing load on servers to deliver the same level of compression. It also enables improvements from future work on Compression Dictionaries. Chrome shipped support for Zstd in early 2024, and Firefox followed soon after. It has been judged to be worth the ongoing cost in maintenance and complexity to support for decompression, and is also useful for supporting TLS certificate decompression.
🔗	AbortSignal.any()	positive				#774
🔗	Focusability of elements with display:contents	positive				#772 📊
🔗	Compression dictionary transport	positive				#771
🔗	Protected Audience API	negative	complexity, annoyance, venue, integration, performance, privacy, dependencies, API design, use cases	API, HTML		#770
🔗	Unsanitized HTML read/write in Async Clipboard API	neutral				#769
🔗	overflow:overlay aliases overflow:auto	positive				#768
🔗	Report Critical-CH caused restart in NavigationTiming	neutral				#767
🔗	Back/forward cache NotRestoredReasons API	positive				#766
🔗	Scripting media feature	positive		CSS		#765 📊
🔗	import conditions - supports()	positive				#761
🔗	URL (part of Interop 2023)	positive				#759
🔗	RTCRtpReceiver.jitterBufferTarget	positive				#756
🔗	CSS text-wrap: balance	positive				#755
🔗	Interoperable Private Attribution	defer				#753
🔗	Document Subtitle	neutral		HTML		#749
🔗	Use v flag instead of u for HTML pattern attribute RegExps	positive				#745
🔗	MathML colspan attribute for the <mtd> element	negative				#743
🔗	Implement subset of File System Access API	defer				#738 📊
🔗	Never Unpartition Storage APIs via the Storage Access API	positive				#737
🔗	requestStorageAccessFor	defer				#736
🔗	The Language Pseudo-class: :lang() (Selectors Level 4)	positive				#735
🔗	New dialog initial focus algorithm	positive				#734
🔗	FileSystemFileHandle.move() for local files	negative				#732
🔗	Programatically disabling hardware encoding/decoding in WebRTC	positive	power			#728
🔗	baseline-source CSS property	positive				#727
🔗	CSS root font units	positive				#725
🔗	Aligning on behavior of prefetch	positive				#723 📊
🔗	Interim response timings in resource timing	positive				#722
🔗	Remove support for data: URL in SVGUseElement	positive				#718
🔗	No-Vary-Search	positive	interoperability	HTTP		#717
🔗	Extending the PointerEvent with Unique DeviceId Attribute	positive		API		#715
🔗	WebRTC RTP header extension control	positive				#713
🔗	TLS ClientHello extension permutation	positive				#709
🔗	Canvas Floating Point Color Types	positive				#708
🔗	Content-type in Resource Timing	positive				#705
🔗	fetchLater() API	positive				#703
🔗	FedCM Permissions Policy	positive				#701
🔗	CSS lh and rlh units	positive				#699
🔗	The Popover API	positive				#698
Details Description Adds the global popover attribute to declaratively make an element be rendered on top of all other content and allow closing by the user (light dismiss). Rationale A common paradigm on the web which would be good for accessibility and developer ergonomics to support as a feature in HTML.
🔗	Conditional Focus	positive				#697
🔗	CSS Nesting Module Level 1	positive				#695 📊
Details Description This module introduces the ability to nest one style rule inside another, with the selector of the child rule relative to the selector of the parent rule. This increases the modularity and maintainability of CSS stylesheets. Rationale Nesting is a valuable tool for simplifying CSS authoring. Many authoring formats include the capability in some form, but native support will make the capability consistent and more widely available.
🔗	WebAuthentication Conditional UI	positive				#692
🔗	CustomStateSet for custom elements	positive				#688
🔗	Style Container Queries (for custom properties)	positive				#686
🔗	AudioContext.setSinkId()	positive				#683
🔗	Wildcards in Permissions Policy Origins	positive				#679
🔗	CHIPS (Cookies Having Independent Partitioned State)	positive				#678
Details Description Defines the Partitioned cookie attribute. This attribute will indicate to user agents that these cross-site cookies should only be available in the same top-level context that the cookie was created in. Rationale This spec provides an opt-in mechanism to enable partitioned cookies. This allows more browsers to support partitioned cookies, and once adopted by sites can facilitate the default blocking of third-party cookies.
🔗	View Transitions API	positive				#677 📊
Details Description The View Transitions API allows developers to create animated visual transitions representing changes in the document state. Rationale View Transitions allows developers to create animated transitions between states within one document as well as transitions when navigating across documents. The latter is a new capability for the web. We think the API design should be consistent between these cases where possible. As of mid-2023, the specification and implementation experience for this feature for same-document transitions is further along than for cross-document transitions.
🔗	Autoplay Policy Detection API	positive				#675
Details Description This specification provides web developers the ability to detect if automatically starting the playback of a media file is allowed in different situations. Rationale This API provides a convenient and synchronous answer to whether a particular kind of media can autoplay, which is something web developers are currently detecting either with various hacks or through UA detection. This doesn't expose new information for fingerprinting (see w3c/autoplay#24) as media elements already expose through events which media will autoplay by trying to autoplay.
🔗	The model element	defer				#674
🔗	Encoding streams API (TextDecoderStream and TextEncoderStream)	positive				#673 📊
🔗	Mixed Content Level 2	positive				#668
Details Description This specification describes how a user agent should handle fetching of content over unencrypted or unauthenticated connections in the context of an encrypted and authenticated document. Rationale 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.
🔗	Subset of CSP 3: script-src-elem, script-src-attr, style-src-elem and style-src-attr	positive				#666 📊
🔗	HTTP response status code in Resource Timing	positive				#665
🔗	ContentVisibilityAutoStateChanged event	positive				#664
🔗	fetch streaming upload	positive				#663
🔗	Render blocking status in Resource Timing	positive				#662
🔗	CSS Overflow for replaced elements	positive				#659
🔗	MediaTrackSupportedConstraints.backgroundBlur	positive				#658
🔗	DisplayMediaStreamConstraints.surfaceSwitching	neutral				#653
🔗	WebAssembly Relaxed SIMD	positive		WebAssembly		#651
🔗	Auto-sizes for lazy-loaded images in HTML	positive				#650
Details Description Allow authors to omit the 'sizes' attribute, use the keyword 'auto', for responsive lazy images in HTML to let the browser use the layout size from CSS or width/height attributes. Rationale This proposal makes it easier for web developers to use responsive images. There is some risk that the behavior of cached images can cause flicker in some cases.
🔗	css-easing: linear() easing	positive				#649
🔗	import.meta.resolve()	positive				#647
🔗	Shared Storage	negative				#646
Details Description Shared storage is storage for an origin that is intentionally not partitioned by top-frame site. Storage may only be read in a restricted environment that has carefully constructed output gates. Rationale Mozilla has significant concerns about the viability of the isolation components of this design. The use cases presented do not, at this time, justify the complexity and privacy risks associated with this proposal.
🔗	CSS Overscroll Fixed Elements	positive				#643
🔗	MediaTrackConstraintSet.displaySurface	positive				#642
🔗	MediaTrackSupportedConstraints.suppressLocalAudioPlayback	positive				#641
🔗	Response.json()	positive				#640
🔗	DisplayMediaStreamConstraints.selfBrowserSurface	positive				#639
🔗	DisplayMediaStreamConstraints.systemAudio	positive				#638
🔗	Streams for the Web Cryptography API	neutral				#637
🔗	Element.checkVisibility method	positive				#634
🔗	form rel attribute	positive				#633
🔗	WebDriver-BiDi	positive				#632
Details Description The BiDirectional WebDriver Protocol, a mechanism for remote control of user agents. Rationale 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’d be better for the standard protocol to support these needs.
🔗	Focusgroup	defer		HTML		#631
🔗	Topics API	negative				#622
Details Description The goal of the Topics API is to provide callers with coarse-grained advertising topics that the page visitor might currently be interested in. Rationale Mozilla is unable to see a way to make the Topics API work from a privacy standpoint. Though the information the API provides is small, our belief is that this is more likely to reduce the usefulness of the information for advertisers than it provides meaningful protection for privacy. Unfortunately, it is hard to identify concrete ways in which this might be improved.
🔗	Speculation Rules - Navigational prefetching and prerendering	neutral	complexity			#620
🔗	FedCM (was WebID)	neutral				#618
Details Description A Web Platform API that allows users to login to websites with their federated accounts in a privacy preserving manner. Rationale Federated login is a widely-used feature on the web with significant user benefits in usability and security. Unfortunately, federated identity on the web relies on the same techniques that are used to track web users. Federated Credential Management API provides an opportunity to put the browser in control of managing cross-site logins. However, FedCM currently gives too much power to the identity providers it works for and fails to facilitate other identity providers’ flows. The current FedCM API is designed with a lot of consideration for click-through rate optimization, which is a chief concern of social-login providers. One key design choice that has constrained subsequent decisions is that the initial UI rendered in the browser must be able to show the accounts available from the identity provider, facilitating single click account-linking. Mozilla would not render account information across information contexts before the user makes the choice to link those contexts. However, Google currently does, providing a browser-controlled UI that looks very similar to Google Identity Services’ OneTap widget where third-party cookies are already shared. This is evidence of a bug in the specification, not a feature of “engine freedom” to develop innovative UI. We believe the reduced scope of the Lightweight FedCM proposal is much closer to appropriately balancing the interests of developers and users and is much more likely to reach a solution all browsers would implement.
🔗	font-palette and @font-palette-values	positive				#617 📊
🔗	hidden=until-found HTML attribute and beforematch event	positive				#612
🔗	<search> element	positive				#610
🔗	blocking="render" attribute on <link>, <script> and <style>	positive				#608
🔗	mix-blend-mode: plus-lighter	positive				#607
🔗	Priority Hints	positive				#606
Details Description Specification of the Priority Hints feature. Rationale 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.
🔗	Close watchers	positive				#604
🔗	Concise Binary Object Representation (CBOR)	defer				#603 📊
🔗	Changing the Origin-Agent-Cluster default, aka deprecating document.domain	positive				#601
🔗	minPinLength in WebAuthn	positive				#595
🔗	Cookie Expires/Max-Age attribute upper limit	positive				#592
🔗	HDR CSS Media Queries	positive				#584
🔗	Disable custom protocols in sandboxed iframe.	positive				#581
🔗	CSP for WebAssembly	positive				#580
🔗	Auto-expanding details elements	positive				#578
🔗	Enforce COEP in SharedWorker	positive				#577 📊
🔗	HTMLScriptElement.supports(type) method	positive				#576
🔗	WebAssembly Exception Handling	positive				#573
Details Description exception propagation and handling for webassembly Rationale Exception handling is important to C++ programs targeting the web, and to other languages in the future.
🔗	URLPattern	positive				#566 📊
Details Description The URLPattern API provides a web platform primitive for matching URLs based on a convenient pattern syntax. Rationale URLPattern is an important primitive for the evolution of ServiceWorkers through the introduction of the Static Routing API. Similar to Web Locks which evolved out of the ServiceWorkers Cache API, it is appropriate that URLPattern be distinct from the Service Workers spec and WG as it is useful in other contexts as well.
🔗	Capability Delegation	positive	venue	API		#565
🔗	Support for font-family: math	positive				#564
🔗	supports(<font-technology>)extended syntax for @font-face	positive				#563
🔗	AccessHandles for the Origin Private File System	positive				#562
Details Description File System defines infrastructure for file systems as well as their API. Rationale A storage endpoint with a POSIX-like file system API is a valuable addition to the web platform.
🔗	PWAs as URL Handlers	defer				#550
🔗	Scheduling APIs: scheduler.postTask	positive				#546
Details Description This specification defines APIs for scheduling and controlling prioritized tasks. Rationale This feature is useful for web developers to provide a more responsive experience to users.
🔗	Scalable Video Coding (SVC) Extension for WebRTC	positive				#544
🔗	Navigation API	positive				#543
Details Description The navigation API provides a web application-focused way of managing same-origin same-frame history entries and navigations. Rationale This API is a good improvement for implementing SPAs over the status quo. There are various details that we're not sure about in the spec and we'd like to continue reviewing and submit feedback about issues we find.
🔗	CSS Module Scripts	positive				#541
🔗	COEP: credentialless	positive				#539
🔗	Window Controls Overlay	defer				#529
🔗	:has() pseudo class	positive				#528 📊
Details Description :has selector lets authors select elements that anchor at least one element that matches its inner relative selector. Rationale We recognize that :has is something that a lot of people want. That power does come with performance costs, like the potential for very poor performance when there is DOM tree mutation. Overall, the utility of the selector justifies this risk, but we might need to do more to help developers avoid the worst problems.
🔗	Standards position for TC39 Stage 3 Proposals	positive				#527
Details Description Stage 3 proposals add new features to the JavaScript language. Stage 3 indicates that a proposal has been accepted by implementations and other delegates as ready to implement, as per the TC39 staging process. Rationale 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.
🔗	JPEG XL	neutral				#522 📊
Details Description The JPEG XL Image Coding System (ISO/IEC 18181) has a rich feature set and is particularly optimised for responsive web environments, so that content renders well on a wide range of devices. Moreover, it includes several features that help transition from the legacy JPEG format. Rationale JPEG-XL includes features and performance that might differentiate it from other formats, but the benefits it provides are not significant enough on their own to justify the cost of adding another C++ image decoder to browsers. A memory-safe decoder would reduce these costs considerably, and we are open to shipping one that meets our requirements.
🔗	Adding FTP related protocols to the registerProtocolHandler safelist.	positive				#513
🔗	contain-intrinsic-size auto & longhands	positive				#512
🔗	Aligning high-resolution timer granularity to cross-origin isolated capability	positive				#502
🔗	COLRv1 Color Gradient Vector Fonts	positive				#497
Details Description Extends the COLR table in OpenType fonts with a new format supporting richer graphical capabilities for emoji (and similar) glyph design. Rationale Provides comparable design capabilities to OpenType-SVG, but in a more compact and lightweight form that integrates better into font rendering pipelines. Has the potential to supersede OpenType-SVG fonts in web use.
🔗	WebAssembly SIMD	positive				#491
Details Description 128-bit vector data type and operations for webassembly Rationale 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.
🔗	Clipboard DataTransfer read-only files	positive				#484
🔗	Custom Highlight API	positive				#482
🔗	Storage Buckets API	positive				#475
Details Description The Storage Buckets API provides a way for sites to organize locally stored data into groupings called "storage buckets". This allows the user agent or sites to manage and delete buckets independently rather than applying the same treatment to all the data from a single origin. Rationale Data clearing on storage pressure is fundamentally limited by the current single "default" storage bucket per origin and an all-or-nothing persistent flag for that bucket. As use of ServiceWorkers continues to increase and sites store or cache more data, a primitive that makes it easier for sites to store their data more granularly and for browsers to clear it more granularly is essential, especially for devices with limited storage and/or heavy storage uses outside of the browser's own needs.
🔗	CSS @scope	positive				#472 📊
Details Description @scope rule allows targeting CSS rules to subtree or fragment of a document. Rationale Scoped styles allow authors to precisely control upper- and lower-bounds of where CSS rules, without having to add many attributes on DOM elements. However, there is a risk of performance degradation that will have to be answered with implementation experience.
🔗	CSS Cascade Layers	positive				#471
Details Description CSS Cascade Layers provides a structured way to organize related style rules within a single origin. Rules within a single cascade layer cascade together, without interleaving with style rules outside the layer. Rationale This feature provides a way to abstract CSS rules in style sheets, supported in popular CSS frameworks/pre-processors, and a frequent web developer request. Though the specification is in early stages, the goal is worth pursuing.
🔗	WebHID (Human Interface Device) API	negative				#459 📊
Details Description This document describes an API for providing access to devices that support the Human Interface Device (HID) protocol. Rationale 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.
🔗	Relative indexing method on JS indexables (.at)	positive				#458
Details Description A TC39 proposal to add an .at() method to all the basic indexable classes (Array, String, TypedArray) which allows relative indexing of collection. Rationale Relative indexing is useful for typed arrays and arrays and will be a quality of life improvement for developers.
🔗	Readable Byte Streams	positive				#457 📊
Details Description Byte streams are a specialization of Streams that are designed to deal with raw bytes. Rationale Byte streams are a useful specialization of streams that is well suited to performant I/O and they are well integrated with Typed Arrays.
🔗	Web Authentication ResidentKeyRequirement and credProps	positive				#456
🔗	Idle Detection API	negative				#453
Details Description This document defines a web platform API for observing system-wide user presence signals. Rationale 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 this message.
🔗	Top-level await in JS	positive				#444 📊
Details 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. Rationale An ergonomic way of handling modules that contain top level asynchronous work.
🔗	Atomics.waitAsync	positive				#433
Details Description A proposal for an 'asynchronous atomic wait' for ECMAScript, primarily for use in agents that are not allowed to block. Rationale Represents a meaningful way for the main thread to interact with blocking concurrent patterns in workers and other off-thread work.
🔗	Raw Sockets API	negative	venue, security, use cases			#431
Details Description This describes APIs for TCP and UDP communication with arbitrary hosts Rationale 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.
🔗	Transferable Streams	positive				#430
🔗	CSS Overflow 3: overflow:clip	positive				#418 📊
Details Description overflow:clip is a feature of CSS Overflow Module Level 3 that is similar to overflow:hidden except without a formatting context or programmatic scrollability. Rationale This feature is both a useful declarative presentational feature for web developers and standardizes a non-standard -moz prefixed value.
🔗	Imperative Shadow DOM Distribution API	positive				#409
Details Description The imperative slotting API allows the developer to explicitly set the assigned nodes for a slot element. Rationale The proposal is a relatively small addition to the existing Shadow DOM API and can make it easier to use Shadow DOM.
🔗	HTML: dialog element	positive				#388 📊
Details 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. Rationale A high-level HTML feature for authors to achieve these use cases while getting a11y right seems useful, and we have an implementation.
🔗	Layout Instability API	positive				#374
Details 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. Rationale 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.
🔗	Import Attributes	positive				#373
Details 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. Rationale This proposal enables the importing of JSON content into a JS module. This mechanism is a prerequisite for HTML/CSS/JSON modules.
🔗	A Well-Known URL for Changing Passwords	positive				#372
Details Description This specification defines a well-known URL that sites can use to make their change password forms discoverable by tools. This simple affordance provides a way for software to help the user find the way to change their password.
🔗	Media Feeds	negative				#370
Details Description This specification enables web developers to show personalized media recommendations on the browser UI. Rationale 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.
🔗	First-Party Sets	negative				#350
Details Description This document proposes a new web platform mechanism to declare a collection of related domains as being in a First-Party Set. Rationale We believe the definition of first party should be clear and understandable to users, web developers, and publishers, and thus ideally it should be based only on the top-level URL. While we can't quite do that today because it isn't compatible with all sites, we'd like to move towards doing that, rather than standardizing a mechanism that moves away from that. See more details.
🔗	Scroll-driven Animations	positive				#347
Details Description Defines CSS properties and an API for creating animations that are tied to the scroll offset of a scroll container. Rationale Animations linked to scrolling is desired for some web applications or web sites. A declarative solution allows for better user control and should be easier to use for web developers.
🔗	Named pages with page-orientation	positive				#346 📊
Details Description A descriptor for CSS @page rules that changes the orientation of the page in generated PDF output (or similar) without otherwise affecting layout. Rationale 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.
🔗	URL Protocol Handler Registration for web apps	defer				#340
🔗	Serial API	neutral				#336 📊
Details 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. Rationale 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. A user deliberately installing a site-specific add-on may be adequate, given sufficiently understandable consent copy.
🔗	Declarative Shadow DOM	positive				#335
Details Description Declarative creation of Shadow DOM is a new capability that allows a webpage to be more fully constructed server side, without requiring JavaScript to run. Rationale This is a reasonable proposal which takes into account the various constraints and security considerations that come with changing the HTML parser.
🔗	CSS Properties & Values API: @property	positive				#331 📊
Details Description The @property rule represents a custom property registration directly in a stylesheet without having to run any JS. Rationale Having a declarative registration mechanism for custom properties is a good addition to CSS Properties and Values API.
🔗	webrtc insertable streams	positive				#330
Details Description This API defines an API surface for manipulating the encoded bits of MediaStreamTracks being sent via an RTCPeerConnection. Rationale 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.
🔗	Document Policy	neutral				#327 📊
Details Description Document policy allows content to define a policy that constrains embedded content. Rationale The mechanism described provides sites greater control over embedded content. Constraints are accepted by content or the browser does not load the content. This ensures that policies are effective without risk of content breaking in inexplicable ways due to those policies. The specification needs a lot more work, but no significant problems are apparent or anticipated.
🔗	CSP Embedded Enforcement	neutral				#326
Details Description This document defines a mechanism by which a web page can embed a nested browsing context if and only if it agrees to enforce a particular set of restrictions upon itself. Rationale This specification allows sites to specify minimum CSP policies for embedded content. The risk of problems arising from misalignment between different policies is managed well. The resulting complexity is not trivial, but it is balanced against the security improvements.
🔗	Keyboard Map API	negative				#300 📊
Details 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’s 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. Rationale 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.
🔗	Scheme-bound cookies	positive				#298
Details 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. Rationale Reducing the scope of cookies along this axis is a major win.
🔗	Crash Reporting	positive				#288
Details Description This document defines a mechanism for reporting browser crashes to site owners through the use of the Reporting API. Rationale This seems like it could be a useful addition to the reporting API. We're not yet confident what level of user consent is needed, but we can experiment with that without changes to the specification.
🔗	Event Timing	positive				#283
Details Description This specification defines APIs for observing latency of certain events triggered by user interaction. Rationale This feature grants web authors insights about the latency of certain events triggered by user interaction. This API reports the timestamp of when the event was created, when the browser started to process the event, when the browser finished to process the event and the next frame rendering time (which represented when the content of the event was presented on screen). We believe this is useful for web authors to learn more about user engagement.
🔗	Storage Access API	positive				#280
Details 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. Rationale 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.
🔗	X25519 in Web Cryptography	positive				#271
Details Description Add support for Curve25519 algorithms in the Web Cryptography API, namely the signature algorithm Ed25519 and the key agreement algorithm X25519. Rationale We are in favor of this work, but would like to see it have a path to standardization. When doing that, it may be worth reconsidering some of the "no seatbelts" aspects of WebCrypto more generally, and perhaps adding other algorithms as well.
🔗	Web Bundles (Web Packaging)	neutral				#264
Details Description Bundled exchanges provide a way to bundle up groups of HTTP request+response pairs to transmit or store them together. They can include multiple top-level resources with one identified as the default by a manifest, provide random access to their component exchanges, and efficiently store 8-bit resources. Rationale The mechanism as currently sketched out seems to provide potentially useful functionality for a number of use cases. This is a complex mechanism, and substantial detail still needs to be filled in. We believe the general intent of the feature is well-enough defined to designate as "non-harmful" at this time (rather than "defer"), although we anticipate potentially revisiting this decision as the mechanism is refined.
🔗	Private State Token API	negative				#262
Details Description The Private State Token API is a web platform API that allows propagating a limited amount of signals across sites, using the Privacy Pass protocol as an underlying primitive. Rationale Private State Tokens provides sites with the means to exchange information about visitors, using Privacy Pass to ensure that there are very tight bounds on the rate of information transfer. We conclude that the usage constraints in the design are insufficient to effectively safeguard privacy.
🔗	Schemeful Same-Site	positive				#260
Details 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. Rationale 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.
🔗	WebXR Hit Test	defer				#259
Details Description Describes a method for performing hit tests against real world geometry to be used with the WebXR Device API. Rationale We believe that (as of February 2020) more iteration on the specification draft is needed before we can establish a position.
🔗	Structured Headers	positive				#256
Details 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. Rationale 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.
🔗	ARIA Annotations	positive				#253
Details Rationale This contains changes needed to support screen reader accessibility of comments, suggestions, and other annotations in published documents and online word processing applications.
🔗	video.requestVideoFrameCallback()	positive				#250 📊
Details Description <video>.requestVideoFrameCallback() allows web authors to be notified when a frame has been presented for composition. Rationale 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.
🔗	Origin isolation	positive				#244
Details Description This feature allows for an agent cluster to be keyed by origin rather than site. Rationale 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.
🔗	timezonechange event	defer				#241
Details Description An event that fires when the user's timezone changes. Rationale The timing of the delivery of this event to sites might expose users to cross-site tracking. How that risk is mitigated has not yet been decided, and that decision is likely to influence our position.
🔗	scrollend and overscroll events	positive				#240
Details 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. Rationale We believe these are likely to provide frequently-requested functionality that is useful for many web applications.
🔗	WebGPU	positive				#239 📊
Details Description This specification describes support for accessing modern 3D graphics and GPU computation capabilities on the Web. Rationale 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.
🔗	Web NFC	negative				#238 📊
Details 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. Rationale 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.
🔗	output attributes on HTML's <input type=file> element	neutral				#237
Details 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. Rationale 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.
🔗	Fragmentions	positive				#234
Details Description A proposal for using URL fragments with spaces in them to select a bit of text to highlight and scroll to Rationale We feel that some of the use cases this proposal addresses are very important to address, but worry about the lack of a clear processing model and about possible compat constraints that may need implementation experience to fully understand. More details are in the position issue. See also the position on Scroll to Text Fragment, which aims to address similar use cases.
🔗	QID Emoji	negative				#233
Details 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. Rationale 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.
🔗	WebXR Device API	positive				#218 📊
Details Description This specification describes support for accessing virtual reality (VR) and augmented reality (AR) devices, including sensors and head-mounted displays, on the Web. Rationale 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.
🔗	Periodic Background Sync	negative				#214 📊
Details Description This specification describes a method that enables web applications to synchronize data in the background. Rationale 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.
🔗	Get Installed Related Apps	negative				#213 📊
Details Description The Get Installed Related Apps API allows web apps to detect if related apps are installed on the current device. Rationale This feature increases the fingerprinting surface of browsers without sufficient safeguards.
🔗	ARIA IDL interface/reflection (non-IDREF)	positive				#211
🔗	Screen Wake Lock API	positive				#210 📊
Details 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. Rationale 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.
🔗	Web Codecs	positive				#209
Details Description An API that allows web applications to encode and decode audio and video Rationale 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.
🔗	HTTPSSVC DNS Record	positive				#208
Details 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. Rationale 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.
🔗	Compression Streams	positive				#207
Details Description This document defines a set of JavaScript APIs to compress and decompress streams of binary data. Rationale This provides a small API wrapper around compression formats implementations already have to support and hopefully leads to more things being compressed due to ease-of-use.
🔗	Raw Clipboard Access API	negative				#206
Details 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. Rationale 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.
🔗	"Trusted JS" use-case for secure web conferencing	negative				#205
Details 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. Rationale 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.
🔗	Audio Focus API	positive				#203
Details Description This API will help by improving the audio-mixing of websites with native apps, so they can play on top of each other, or play exclusively. Rationale This proposes a straightforward API for improving mixing of audio produced by website.
🔗	User Agent Client Hints	neutral				#202
Details 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. Rationale 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.
🔗	Default Accessibility Semantics for Custom Elements	positive				#201
Details Description This will allow custom elements to have "default" accessibility semantics, analogous to how built-in elements have "implicit" or "native" semantics. Rationale This is an important addition to custom elements as otherwise they'd have to publicly expose their internals in order to get accessibility correct.
🔗	Reflecting IDREF/IDREF list ARIA attributes to element references	positive				#200
Details Description This will allow ARIA relationship attributes to be set more easily via JavaScript, and in particular will allow setting ARIA relationship attributes which work across Shadow DOM boundaries (with limitations). Rationale This is an important piece in making web components accessible. While this unfortunately does not address all of the use cases for ARIA references across shadow roots and it cannot be used declaratively, there is no other single alternative which solves these problems in a reasonable, ergonomic way.
🔗	EditContext	positive	compatibility			#199
🔗	Limiting Same Origin Document Access	negative				#197
Details Description A way to force an embedded document and descendants (regardless of origin) into each having their own agent/event loop. Rationale 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.
🔗	HTML: autofocus="" overhaul	positive				#195
Details Description Overhaul the autofocus processing model to better match browser behavior, fit better within the specification ecosystem, and avoid bad results for users.
🔗	Scroll To Text Fragment	positive				#194 📊
Details Description A proposal for extending URL fragment syntax with a list of text bits to highlight and scroll to. Rationale 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.)
🔗	Element Timing API	positive		API		#192
🔗	Largest Contentful Paint	positive				#191
Details Description This specification defines an API that allows web page authors to monitor the largest paint an element triggered on screen. Rationale 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.
🔗	Web Share Target	positive				#176
Details 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. Rationale 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.
🔗	Secondary Certificates and TLS Exported Authenticators	positive				#175
Details 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. Rationale 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.
🔗	HTML: inert attribute	positive				#174 📊
Details Description Allow arbitrary DOM subtrees to become inert Rationale A high-level tool for authors to achieve some of these use cases while getting a11y right seems useful
🔗	Web Background Synchronization (BackgroundSync)	negative				#173 📊
Details Description This specification describes a method that enables web applications to synchronize data in the background. Rationale 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.
🔗	Credential Management Level 1	defer				#172 📊
Details Description This specification describes an imperative API enabling a website to request a user’s credentials from a user agent, and to help the user agent correctly store user credentials for future use. Rationale Development of the specification seems to have stalled and it's also not a priority for Mozilla.
🔗	HTML toast element 🍞	negative				#169
🔗	WebTransport	positive				#167 📊
Details 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. Rationale 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.
🔗	Structured cloning of errors	positive				#165
Details Description Serializing and deserializing JavaScript Error objects. Rationale Good extension to the object serialization algorithm (StructuredSerializeInternal) as currently there is no way to serialize errors.
🔗	WebAuthn	positive				#163 📊
Details Description This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. Conceptually, one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application. The user agent mediates access to authenticators and their public key credentials in order to preserve user privacy. Authenticators are responsible for ensuring that no operation is performed without user consent. Authenticators provide cryptographic proof of their properties to Relying Parties via attestation. This specification also describes the functional model for WebAuthn conformant authenticators, including their signature and attestation functionality. Rationale 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.
🔗	Private Click Measurement	defer				#161
Details Description This specification defines a privacy preserving way to attribute a conversion, such as a purchase or a sign-up, to a previous ad click. Rationale We're interested in this specification in order to support a way for a click source to measure conversions as a result of the user clicking on an ad without sharing user-identifying information with the click source in the third-party context. However, we are waiting to take a position until the fraud preventions that it depends on are specified and we can understand their properties.
🔗	Origin Policy	positive				#160
Details 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). Rationale 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.
🔗	File Handling	defer				#158
Details Description This proposal gives web applications a way to register their ability to handle (read, stream, edit) files with given MIME types and/or file extensions. Rationale Not far enough along to properly evaluate.
🔗	HTML portal element (Portals)	defer				#157 📊
Details Description This specification defines a mechanism that allows for rendering of, and seamless navigation to, embedded content. Rationale While we are deferring evaluation of this proposal, because per Domenic's comment it is in the early stages of development and it is too early to evaluate fully, there are concerns (serious enough to mark it as harmful) that we would like to see addressed as it develops. Most significantly, it needs to explain its interaction with the Web's storage mechanisms in a way that doesn't contribute to third-party tracking or reduce the effectiveness of proposals designed to mitigate such tracking (such as those that partition storage based on toplevel origins). It also needs to justify the (still undetermined) amount of complexity that it adds to the web platform with sufficiently valuable use cases to justify that complexity.
🔗	File System Access API	negative				#154 📊
Details Description This document defines a web platform API that lets websites gain write access to the local file system. It builds on File API, but adds lots of new functionality on top. Rationale There's a subset of this API we're quite enthusiastic about (in particular providing a read/write API for files and directories as alternative storage endpoint), but it is wrapped together with aspects for which we do not think meaningful end user consent is possible to obtain (in particular cross-site access to the end user's local file system). Overall we consider this harmful therefore, but Mozilla could be supportive of parts, provided this were segmented better.
🔗	Contact Picker API	defer				#153
Details Description This proposal adds an API for prompting and querying the user’s contacts for one or more items with a handful of contact properties. Rationale This API innovates in some ways beyond several previous Contacts APIs, though uses different properties than HTML autofill field names.
🔗	Lazy loading for images	positive				#151 📊
Details Description Enabling images and iframes to be fetched at a later time, when the user is likely to look at them. Rationale As currently specified in HTML this is a reasonable addition to how images and iframes are fetched.
🔗	Form Participation API	positive				#150
Details Description An API to enable objects other than built-in form control elements to participate in form submission, form validation, and so on. Rationale These propose what seems likely to be a useful addition to allow custom controls to participate in form validation and submission.
🔗	Import maps	positive				#146 📊
Details Description Import maps allow web pages to control the behavior of JavaScript imports. Rationale 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.
🔗	Fetch/HTTP: Stale While Revalidate	positive				#144
Details 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. Rationale 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.
🔗	CORS and RFC1918	positive				#143
Details Description This document specifies modifications to Fetch which are intended to mitigate the risks associated with unintentional exposure of devices and servers on a client’s internal network to the web at large. Rationale 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.
🔗	Encrypted SNI	positive				#139
Details Description This document defines a simple mechanism for encrypting the Server Name Indication for TLS 1.3. Rationale This feature enables encryption of the server name in connection attempts. It provides much-needed protection against attempts by network observers to see what people are doing. This work is complementary with efforts to encrypt DNS requests that we are also driving.
🔗	HTML Modules	positive				#137
Details Description An extension of the ES6 Script Modules system to include HTML Modules. These will allow web developers to package and access declarative content from script in a way that allows for good componentization and reusability, and integrates well into the existing ES6 Modules infrastructure.
🔗	content-visibility API	positive				#135
🔗	HTTP 103 Status	positive				#134
Details Description This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response. Rationale We believe that experimentation with the 103 response code is worthwhile. We do have some concerns about the lack of clear interaction with Fetch, which we hope will be specified before the mechanism is put into widespread use.
🔗	PFP: Cache Digest	neutral				#131
Details Description This specification defines a HTTP/2 frame type to allow clients to inform the server of their cache's contents. Servers can then use this to inform their choices of what to push to clients. Rationale This is experimental technology that might improve the use of server push by giving servers information about what is cached. It is still unclear how much this might improve performance; more experimentation is likely necessary to prove this out.
🔗	imagesrcset and imagesizes attributes on <link>	positive				#130
Details Description Adds imagesrcset and imagesizes attributes to <link> which correspond to the srcset and sizes attributes of <img> respectively, for the purposes of preloading. Rationale A relevant aspect of <link rel=preload> support.
🔗	CSS Grid Level 2: subgrid	positive				#125 📊
Details Description This draft defines additions to CSS Grid, primarily for the subgrid feature. Rationale Subgrid adds a critical enhancement to CSS Grid, in particular for many CSS Grid use-cases that require alignment across nested semantic elements.
🔗	Hardcode localhost name resolution to always resolve to a loopback address	positive				#121
Details 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. Rationale 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.
🔗	Container Queries	positive				#118 📊
Details Description CSS container queries allow conditional CSS based on aspects of elements within the document (such as box dimensions or computed styles). Rationale This feature addresses a long-standing request from web developers. It allows web content to be declaratively styled to make it context-aware and responsive, to a much greater degree than would be possible otherwise. We think this is a challenge that's worth solving, and we think this feature is a good way to address it.
🔗	Network Information API	negative				#117 📊
Details Description The Network Information API enables web applications to access information about the network connection in use by the device. Rationale 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.
🔗	IntersectionObserver V2: Detecting occlusion and visual effects	positive				#109
Details Description IntersectionObserver extension for occlusion detection / clickjacking prevention. Rationale Security positive, interop concerns are being addressed.
🔗	Badging API	positive				#108
Details Description This specification defines an API allowing web applications to set an application-wide badge, shown in an operating-system-specific place associated with the application (such as the shelf or home screen), for the purpose of notifying the user when the state of the application has changed (e.g., when new messages have arrived), without showing a more heavyweight notification.
🔗	Sanitizer specification	positive				#106 📊
Details Description The Sanitizer API allows turning supplied HTML into a safe HTML DOM tree Rationale This could be useful, since libraries exists and the browser could do it better.
🔗	Reporting API	positive				#104
Details 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. Rationale This is a reasonable generalization of the CSP reporting mechanism that allows more features to adopt it.
🔗	Constructable Stylesheets	positive				#103
Details Description This draft defines additions to CSSOM to make CSSStyleSheet objects directly constructable, along with a way to use them in DocumentOrShadowRoots.
🔗	MediaStreamTrack Content Hints	positive				#101 📊
Details Description This specification extends MediaStreamTrack to let web applications provide an optional media-content hint attribute. This helps sinks like RTCPeerConnection or MediaRecorder select encoder parameters and processing algorithms appropriately based on a hint about the nature of the content being consumed without having to examine the actual content. Rationale 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.
🔗	WebUSB API	negative				#100 📊
Details Description This document describes an API for securely providing access to Universal Serial Bus devices from web pages. Rationale 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.
🔗	Network Error Logging (NEL)	negative	privacy			#99
Details Description The Network Error Logging spec enables website to declare a reporting policy that can be used to report encountered network errors that prevented it from successfully loading its requested resources. Rationale The API enables the collection of user-specific information that sites might not otherwise be able to observe, which includes information that might be private under some circumstances. Furthermore, the specification does not seem to track changes to the Reporting API it builds upon and seems effectively unmaintained.
🔗	TLS certificate compression	positive				#96
Details 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. Rationale Compression of certificates should provide some performance advantages.
🔗	Web Bluetooth	negative				#95 📊
Details Description This document describes an API to discover and communicate with devices over the Bluetooth 4 wireless standard using the Generic Attribute Profile (GATT). Rationale 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.
🔗	Cookie-Store API	positive				#94 📊
Details Description An asynchronous Javascript cookies API for documents and workers Rationale This API provides better access to cookies. We are positive for a subset of this API which only exposes the same information available through document.cookie. See WICG/cookie-store issue #241.
🔗	Clear Site Data	positive				#90
Details Description This document defines an imperative mechanism which allows web developers to instruct a user agent to clear a site's locally stored data related to a host. Rationale This feature is useful for sites to be able to recover from mistakes in deployment of certain web technologies like Service Workers, and thus makes them more confident about deploying such technology.
🔗	Clipboard API	positive				#89
Details Description This document describes APIs for accessing data on the system clipboard. It provides operations for overriding the default clipboard actions (cut, copy and paste), and for directly accessing the clipboard contents. Rationale Async Clipboard API is an improvement over execCommand for accessing the clipboard. Security concerns are addressed by gating on user activation and a non-modal dialog.
🔗	Fetch Metadata Request Headers	positive				#88
Details Description This document defines a set of Fetch metadata request headers that aim to provide servers with enough information to make a priori decisions about whether or not to service a request based on the way it was made, and the context in which it will be used. Rationale This gives servers useful context about requests that can be used to mitigate various security issues. The existing setup for embed/object elements gave some tough design challenges for this feature that were satisfactorily resolved. (There's also a reasonable expectation to be able to simplify these elements going forward.)
🔗	Fetch: CORB	neutral				#81
Details Description Blocklist certain opaque responses based on MIME type and return an 'emptied' response instead. Rationale While this is an important aspect of a robust Spectre-defense, we would like to see a safelist-based approach pursued, e.g., Opaque Response Blocking.
🔗	Client Hints	neutral				#79 📊
Details Description An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines an extensible and configurable set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header field allows user agents to indicate what formats they prefer, Client Hints allow user agents to indicate device and agent specific preferences. Rationale 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.
🔗	Web Budget API	neutral				#73
Details 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. Rationale This specification is being abandoned.
🔗	Picture-in-Picture	defer				#72 📊
Details Description This specification intends to provide APIs to allow websites to create a floating video window always on top of other windows so that users may continue consuming media while they interact with other content sites, or applications on their device. Rationale We ship Picture-in-Picture (PiP) as a feature in Firefox, but without exposing a JavaScript API. We are evaluating if our PiP UI affordances are sufficient for users and web applications. In the future, we may reconsider exposing the API, which is why we have chosen to 'defer'.
🔗	TransformStreams (part of the Streams Standard)	positive				#70 📊
Details Description This specification provides APIs for creating, composing, and consuming streams of data that map efficiently to low-level I/O primitives. Rationale Streams are an important building block for many APIs, in particular around networking and media.
🔗	HTML: enterkeyhint attribute	positive				#68 📊
Details Description The enterkeyhint attribute specifies what action label (or icon) to present for the enter key on virtual keyboards.
🔗	BigInt	neutral				#65 📊
Details Description This proposal adds arbitrary-precision integers to ECMAScript. Rationale Shipping in Firefox.
🔗	Web Locks	positive				#64
Details Description This document defines a web platform API that allows script to asynchronously acquire a lock over a resource, hold it while work is performed, then release it. While held, no other script in the origin can acquire a lock over the same resource. This allows contexts (windows, workers) within a web application to coordinate the usage of resources. Rationale 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).
🔗	HTML: passwordrules attribute	negative		HTML		#61
Details Description An attribute that specifies the rules for generating acceptable passwords. Rationale 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.
🔗	CSS Shadow Parts	positive				#59
Details Description This specification defines the ::part() and ::theme() pseudo-elements on shadow hosts, allowing shadow hosts to selectively expose chosen elements from their shadow tree to the outside page for styling purposes.
🔗	WebMIDI	positive				#58 📊
Details Description This specification defines an API supporting the MIDI (Musical Instrument Digital Interface) protocol, enabling web applications to enumerate and select MIDI input and output devices on the client system and send and receive MIDI messages. It is intended to enable non-music MIDI applications as well as music ones, by providing low-level access to the MIDI devices available on the users' systems. Rationale This specification is a reasonable technical design for exposing MIDI devices to JavaScript, which has some demonstrated use-cases in the market. MIDI devices are not universally hardened against adversarial input (especially when sysex is involved) so we don't believe this API is safe to expose in the casual and low-trust context of ordinary websites. We therefore only expose it in Firefox if the user has deliberately installed a site-specific add-on to enable the capability.
🔗	Web Thing API	positive				#44
Details 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.
🔗	Geolocation using Generic Sensor API	negative				#36
Details Description This specification defines the GeolocationSensor interface for obtaining the geolocation of the hosting device. Rationale Given that the web already has a geolocation API, any additional API for the same purpose would have to meet a high bar as both will need to be maintained forever. While the document claims to improve security and privacy, there is no evidence that is the case. And as it can be largely polyfilled on top of the existing API, it seems better to invest in web platform geolocation additions there, if any.
🔗	Generic Sensors	negative				#35
Details Description This specification defines a framework for exposing sensor data to the Open Web Platform in a consistent way. It does so by defining a blueprint for writing specifications of concrete sensors along with an abstract Sensor interface that can be extended to accommodate different sensor types. Rationale The purpose of most sensors and their associated risks are incredibly hard to convey to users, which means we cannot get informed consent. We are interested in addressing the use cases websites need sensors for in ways that do not give websites access to the sensors directly as that is rife with security and privacy issues.
🔗	Web Packaging Format	negative				#29 📊
Details 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. Rationale 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.
🔗	Media Session API	positive				#28
Details Description This specification enables web developers to show customized media metadata on platform UI, customize available platform media controls, and access platform media keys such as hardware keys found on keyboards, headsets, remote controls, and software keys found in notification areas and on lock screens of mobile devices. Rationale This API allows sites to offer users common media controls, which improves usability of media playback sites.
🔗	Web Share API	positive				#27 📊
Details Description This specification defines an API for sharing text, links and other content to an arbitrary destination of the user's choice.The available share targets are not specified here; they are provided by the user agent. They could, for example, be apps, websites or contacts. Rationale 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.
🔗	Feature Policy	positive				#24 📊
Details Description This specification defines a mechanism that allows developers to selectively enable and disable use of various browser features and APIs. Rationale 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.
🔗	Payment Handler API	positive				#23
Details Description This specification defines capabilities that enable Web applications to handle requests for payment. Rationale 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.
🔗	Payment Method Manifest	defer				#22
Details Description This specification defines the machine-readable manifest file, known as a payment method manifest, describing how a payment method participates in the Web Payments ecosystem, and how such files are to be used. Rationale We'd like to defer this for the same reasons as Payment Handler, given that it is closely related.
🔗	Accelerated Shape Detection in Images	defer				#21
Details Description This document describes an API providing access to accelerated shape detectors (e.g. human faces) for still images and/or live image feeds. Rationale We're concerned about possible complexity, variations in support between operating systems, and possible fingerprinting surface, but we'd like to wait and see how this proposal evolves.
🔗	Trusted Types	positive				#20 📊
Details 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. Rationale Mozilla believes that preventing DOM-based XSS is an important security goal. The track record of preventing DOM-based XSS is convincing. Dealing with inscrutable third-party dependencies or external JavaScript has been a major concern of security and enforcing reasonable boundaries is a promising approach. We have some reservations about some features in the Chromium implementation, which need to be validated and standardized or removed.
🔗	Permissions API	positive				#19 📊
Details Description The Permissions Standard defines common infrastructure for other specifications that need to interact with browser permissions. It also defines an API to allow web applications to query and request changes to the status of a given permission. Rationale 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.

Legend

The possible positions are:

positive

Mozilla regards this work as a potential improvement to the web.

neutral

Mozilla is not convinced of the merits of this work, but does not see any significant negative potential.

negative

Mozilla believes that pursuing this work in its current form would not be good for the web.

defer

Mozilla takes no position on this work.

under consideration

Mozilla has not taken a position on this work and is gathering more information.