Intent to Ship: Capability Elements <usermedia> MVP

[Chromestatus]

Contact emails

lemi...@google.com, tun...@google.com

Explainer

https://github.com/WICG/PEPC/blob/main/usermedia_element.md

Specification

https://wicg.github.io/PEPC/permission-elements.html

Summary

Usermedia Capability Element, is a declarative, user-activated control for accessing the starting and interacting with media streams. This addresses the long-standing problem of permission prompts being triggered directly from JavaScript without a strong signal of user intent. By embedding a browser-controlled element in the page, the user's click provides a clear, intentional signal. This enables a much better prompt UX and, crucially, provides a simple recovery path for users who have previously denied the permission. Note: This feature was previously developed and tested in an Origin Trial as the more generic <permission> element. Based on feedback from developers and other browser vendors, it has evolved into capability-specific elements to provide a more tailored and powerful developer experience.

Blink component

Public Trackers > Chromium Public Trackers > Chromium > Internals > Permissions > PermissionElement

Web Feature ID

permissions

Motivation

The current web permission model for interacting with user media relies on JavaScript-triggered prompts, giving the user agent no strong signal of user intent. This results in out-of-context prompts, user frustration, and difficult-to-recover-from denial states. We propose the <usermedia> element, or a suite of elements. This will be semantic HTML control with browser-controlled content and strict styling constraints. These constraints are fundamental to the security model, ensuring a very high level of confidence in the user's intent when making a permission decision at both the site and OS level. Crucially, the <usermedia> element evolves beyond simply managing permissions; it streamlines the entire journey by also facilitating starting and interacting with media streams. This often eliminates the need for separate JavaScript API calls, simplifying implementation and creating a more seamless user flow. By providing a clear, consistent, in-page control, this element solves significant user problems related to context blindness and "permission regret," offering a simple recovery path from a previously denied state. The combination of a user-initiated element and a subsequent browser-controlled confirmation UI enhances intent capture, improves accessibility, and prevents manipulative patterns, providing a significantly better experience for both users and developers.

Initial public proposal

https://github.com/WICG/PEPC/issues/62

TAG review

https://github.com/w3ctag/design-reviews/issues/1079

TAG review status

Issues addressed

Origin Trial Name

UserMediaElement

Goals for experimentation

This Origin Trial serves two primary purposes: ensuring continuity for existing partners who have successfully integrated this pattern, and providing a platform to validate and iterate on the new, capability-specific <usermedia> element. While our previous Origin Trial for <permission> provided strong evidence for the core user-initiated model, feedback from developers and browser vendors prompted us to evolve the design. This new trial is essential for gathering insights on a refined, data-centric API shape to help us reach cross-browser consensus. To ensure a seamless transition and prevent disruption for our valued OT partners, this trial will initially launch with an API shape that is functionally equivalent to the previous <permission> trial, simply using the new <usermedia> element name. This provides a stable foundation from which we will iterate based on further discussion. Our goal is to evolve this element towards our proposed data-centric design (https://github.com/WICG/PEPC/blob/main/usermedia_element.md). However, we recognize that this more advanced API has raised compatibility and complexity concerns with developers (https://github.com/WICG/PEPC/issues/62). Therefore, a primary objective of this trial is to work closely with the community to address these concerns and refine the final API. TPAC WebRTC minutes https://www.w3.org/2025/11/11-webrtc-minutes.html#551

Chromium Trial Name

UserMediaElement

Origin Trial documentation link

https://github.com/WICG/PEPC/blob/main/usermedia_element.md

WebFeature UseCounter name

kHTMLPermissionElement

Risks

Interoperability and Compatibility

There is a risk that this feature fails to be adopted by other browsers. This can be mitigated by backwards designing a reasonable fallback mechanism so that the element can degrade gracefully if the it's in an unsupported environment.

Gecko: Under consideration (https://github.com/mozilla/standards-positions/issues/1245)

WebKit: No signal

Web developers: Positive https://github.com/WICG/PEPC/issues/2#issuecomment-2393820279 https://github.com/WICG/PEPC/issues/2#issuecomment-2393861768 https://github.com/WICG/PEPC/issues/2#issuecomment-2393911331 https://github.com/WICG/PEPC/issues/2#issuecomment-2619657041 https://github.com/WICG/PEPC/issues/62#issuecomment-3482975001 https://github.com/WICG/PEPC/issues/62#issuecomment-3482981942 https://github.com/WICG/PEPC/issues/62#issuecomment-3498355775 https://github.com/WICG/PEPC/issues/62#issuecomment-3513734884

Other signals:

Ergonomics

No foreseen ergonomics risks.

Activation

A polyfill can help developers use this feature without risking broken functionality on non-supporting browsers.

Security

https://github.com/WICG/PEPC/blob/main/explainer.md#Security

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Feature is not shipping on WebView due to it requiring permission manager embedder support.

Debuggability

The element raises issues to the devtools issues panel which help developers debug issues with their usage of the element.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
The element is not supported on Android WebView as it requires permission manager support to function and the WebView permission manager defers most permission decisions to the embedder by design.

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/html/semantics/permission-element/usermedia

DevTrial instructions

https://github.com/WICG/PEPC/blob/main/HOWTO.md#enabling-usermedia

Flag name on about://flags

No information provided

Finch feature name

UserMediaElement

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

True

Tracking bug

https://crbug.com/443013457

Availability expectation

Feature is available only in Chromium browsers. We are not aware of other browsers adoption.

Adoption expectation

Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome. Partners who are tested the feature in OT are expected to continue usage.

Adoption plan

We are planning to publish on developer.chrome.com and do further partner outreach

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No

Estimated milestones

Shipping on desktop	149
Origin trial desktop first	144
Origin trial desktop last	148
DevTrial on desktop	144
Shipping on Android	149
Origin trial Android first	144
Origin trial Android last	148
DevTrial on Android	144

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

This is an MVP launch. The MVP feature is fully functional and used by developers right now. We are working closely with the WebRTC on post-MVP features, the open topics will based on the foundation of the MVP, that we agreed upon with the WebRTC. Some of the open topics are for example: In the future, we might want to add a parameter to the getUserMedia algorithm so that the algorithm can determine whether the getUserMedia is called from the <usermedia> element or getUserMedia API. Potential to add additional attributes for <usermedia> interface. We're putting finishing touches on the spec now, work-in-progress PR is here, but once that lands we want to ship for M149 so wanted to start the discussion now.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4926233538330624?gate=6467532078841856

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/692719de.050a0220.17ec37.00c3.GAE%40google.com
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6942ed09.050a0220.1050d6.0961.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Rick Byers]

I'm excited to see this ship! I see this as another important use of the PEPC technology to better enable the browser to be an effective intermediary between the site and the user. Just a few nits and questions:

On Wed, Apr 15, 2026, 10:32 a.m. Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

lemi...@google.com, tun...@google.com

Explainer

https://github.com/WICG/PEPC/blob/main/usermedia_element.md

Specification

https://wicg.github.io/PEPC/permission-elements.html

Summary

Usermedia Capability Element, is a declarative, user-activated control for accessing the starting and interacting with media streams. This addresses the long-standing problem of permission prompts being triggered directly from JavaScript without a strong signal of user intent. By embedding a browser-controlled element in the page, the user's click provides a clear, intentional signal. This enables a much better prompt UX and, crucially, provides a simple recovery path for users who have previously denied the permission. Note: This feature was previously developed and tested in an Origin Trial as the more generic <permission> element. Based on feedback from developers and other browser vendors, it has evolved into capability-specific elements to provide a more tailored and powerful developer experience.

Blink component

Public Trackers > Chromium Public Trackers > Chromium > Internals > Permissions > PermissionElement

Note that web-exposed features typically live under the 'Blink' component, and they get some extra love (like an extra expert triage rotation) to help ensure web devs are getting fast and helpful responses and that important externally-reported regressions don't get missed. Bugs under 'Internals' are normally assumed to not contain important externally-reported issues. As long as your team is on top of your bug triage (eg. would notice within 1-2 days if someone filed a bug there saying a change broke their website) then it's not a big deal, may not be worth the hassle of moving. Regardless, does not need to block this intent IMHO. 

Web Feature ID

permissions

Since this is a distinct feature we'd want to track usage of independently, it should have a distinct feature ID. Please file an issue here and just tag it as missing for now.

Motivation

The current web permission model for interacting with user media relies on JavaScript-triggered prompts, giving the user agent no strong signal of user intent. This results in out-of-context prompts, user frustration, and difficult-to-recover-from denial states. We propose the <usermedia> element, or a suite of elements. This will be semantic HTML control with browser-controlled content and strict styling constraints. These constraints are fundamental to the security model, ensuring a very high level of confidence in the user's intent when making a permission decision at both the site and OS level. Crucially, the <usermedia> element evolves beyond simply managing permissions; it streamlines the entire journey by also facilitating starting and interacting with media streams. This often eliminates the need for separate JavaScript API calls, simplifying implementation and creating a more seamless user flow. By providing a clear, consistent, in-page control, this element solves significant user problems related to context blindness and "permission regret," offering a simple recovery path from a previously denied state. The combination of a user-initiated element and a subsequent browser-controlled confirmation UI enhances intent capture, improves accessibility, and prevents manipulative patterns, providing a significantly better experience for both users and developers.

Initial public proposal

https://github.com/WICG/PEPC/issues/62

TAG review

https://github.com/w3ctag/design-reviews/issues/1079

There's also a more specific review request a couple weeks ago. Probably its the one you should list in chromestatus for this feature (and it links to the related prior ones anyway). No need to block this I2S, but of course we expect that you'll engage with any feedback that comes there in parallel.

It looks like you have just a 50% pass rate (8/16) on the dashboard right now. Has someone done a triage pass over these failures? Perhaps some of these tests are passing in Chrome infra but failing on wpt.fyi?

Getting all the tests passing doesn't need to block I2S, but we want to make sure we understand the current and likely future state of the tests since it's a proxy for maturity and spec conformance, and is really valuable for any other implementations to follow. 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69dfa184.050a0220.c8e20.03e8.GAE%40google.com.

[Thomas Nguyen]

Thank you for reviewing this.

Note that web-exposed features typically live under the 'Blink' component, and they get some extra love (like an extra expert triage rotation) to help ensure web devs are getting fast and helpful responses and that important externally-reported regressions don't get missed. Bugs under 'Internals' are normally assumed to not contain important externally-reported issues. As long as your team is on top of your bug triage (eg. would notice within 1-2 days if someone filed a bug there saying a change broke their website) then it's not a big deal, may not be worth the hassle of moving. Regardless, does not need to block this intent IMHO. 

Thanks for the input. Component UI>Browser>Permissions>, or UI>Browser>Permissions>Prompts makes more sense, aligning the experience with the existing behavior of the <geolocation> element

Since this is a distinct feature we'd want to track usage of independently, it should have a distinct feature ID. Please file an issue here and just tag it as missing for now.

 Filed an issue, with feature definition tag (I could not find missing tag)

There's also a more specific review request a couple weeks ago. Probably its the one you should list in chromestatus for this feature (and it links to the related prior ones anyway). No need to block this I2S, but of course we expect that you'll engage with any feedback that comes there in parallel.

Regarding the TAG review, thanks for catching that, I accidentally provided the old link.

It looks like you have just a 50% pass rate (8/16) on the dashboard right now. Has someone done a triage pass over these failures? Perhaps some of these tests are passing in Chrome infra but failing on wpt.fyi?
Getting all the tests passing doesn't need to block I2S, but we want to make sure we understand the current and likely future state of the tests since it's a proxy for maturity and spec conformance, and is really valuable for any other implementations to follow. 

As for the WPT results, you are exactly right. Those tests pass in Chrome infra but are failing on wpt.fyi (error: secure context required). I have a CL in progress to rename the tests to .https.html, it will likely take 1–2 days for the changes to sync and for the dashboard to reflect the updated results.

--

Thomas Nguyen

Software Engineer

tun...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. 

     

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Rick Byers]

Perfect, thanks for the answers and cleanups! LGTM1 to ship.

[Mike Taylor]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8VX9jdKZZ_tj%2BaMzZkHeVmE7N%2BFhfcywx4qa9235m6Yw%40mail.gmail.com.

[Mike Taylor]

Sorry, LGTM2 % requesting the missing Testing bit in your chromestatus entry.

[Dan Clark]

     >  Gecko: Under consideration (https://github.com/mozilla/standards-positions/issues/1245)

This signals thread is for an earlier version of PEPC, and there was a request in the thread to split out <usermedia> into a separate position thread once it's ready. Can you do that? It's not clear from the old thread that the current shape of the feature has been reviewed by Gecko.

     > WebKit: No signal

Can you request a WebKit position?

Thanks,

Dan

[Thomas Nguyen]

Sorry, LGTM2 % requesting the missing Testing bit in your chromestatus entry

Thanks. I have flipped the Testing bit in ChromeStatus and added more WPT coverage.

[Minh Le]

Hi Dan,

thank you for the reminder, here are the standard positions requests

• https://github.com/WebKit/standards-positions/issues/651
  
• https://github.com/mozilla/standards-positions/issues/1392

Best,

Minh

[Philipp Hancke]

Looking forward to this shipping! Can you please also add a sample to

  https://github.com/webrtc/samples

which remains a go-to location for all things getUserMedia and WebRTC (maybe we can get it to 15k stars finally ;-))

--