Meeting minutes
Recording: https://
Slideset: https://
PEPC for camera & microphone
Overview of PEPC for Camera and Microphone
[Jan-Ivar Bruaroey provided an overview of PEPC (Page Embedded Permission Control), which proposes a new user experience (UX) for camera and microphone access. The working group had previously resolved to use Media Capture Streams or its extension to anchor discussions on PEPC integration, requiring decisions on the API shape and content. This overview aimed to present a vision for using camera and microphone through PEPC, starting with an analysis of the geolocation API.]
[The existing PEPC implementation for WebRTC and camera/microphone access requires multiple button pushes (up to three) to activate the camera, which Jan-Ivar Bruaroey suggested makes the process less user-friendly than the current standard two-click process. The PEPC button is often shown as a website prompt rather than being properly embedded in the page layout, causing an extra layer of user interaction. A mock-up was presented showing how a PEPC button could be embedded directly into the page layout, potentially replacing an existing button.]
Analysis of the Geolocation Element API Shape
[The geolocation element, shipped in Chrome 144, provides a basic "Use location" button that initiates resource acquisition, functioning as a page-embedded powerful feature control button. The user initiates the resource acquisition by clicking the button, which fires an event that returns information such as latitude, longitude, and accuracy upon success. Mike West confirmed that clicking the button gives the user a choice to grant location access temporarily or persistently, with an option to request continuous access using a 'watch' attribute.]
[Interaction between Legacy and PEPC Geolocation APIs: The legacy Geolocation API's `getCurrentPosition` method and the new PEPC geolocation element were compared, demonstrating that once permission is granted via PEPC, the page gains access through the legacy API for the duration of the session. However, if a user chooses "allow this time only," future visits result in "prompt fatigue," which PEPC aims to improve. The "allow always" option allows the website to decide when to turn on the feature in the future, which is considered a privacy trade-off.]
[Proposal for "Allow on Button Push" Persistence: A new persistence level, "Allow on button push," was proposed as a middle ground that simplifies feature usage by the user without permanent privacy compromise. With this option, the user receives a granted permission only until the tab is closed, but on future visits, they will not be prompted as long as they use the PEPC button first. This persistence level is not currently exposed via the Permissions API, meaning the web page cannot tell ahead of time what will happen when the button is pushed.]
[Discussion on UX and Persistence of PEPC Buttons: There was a discussion about the wording of permission choices, with Jan-Ivar Bruaroey noting that the exact phrasing ("Allow on button push," "Allow while visiting the site") is a UX question for individual browsers, and they represent concepts rather than required terminology. Tim Panton raised a concern that if a user chooses "allow on button push," they need to be able to recognize the PEPC button on future visits, even with website style changes. Mike West responded that core elements of the button, like the icon and text, are largely browser-controlled to ensure legibility and comprehensibility regardless of the surrounding presentation.]
Usermedia elements
[Proposed Microphone Element API Shape: Jan-Ivar Bruaroey proposed a simple HTML microphone element following the geolocation model, intended to be a toggle button that stays on the page. When clicked, it would call `getUserMedia` with set constraints and fire a `stream` event upon user allowance. The proposal suggested that the browser would fire a source-level mute/unmute event on the single audio track when the button is toggled off and on, though Youenn Fablet argued for source-level muting to prevent conflicts with cloned tracks.]
[Proposed Camera Element and Muting Strategy: A similar proposal was made for a camera element with a "Turn on camera" toggle button and the ability to set video constraints. The discussion reiterated that if the button only mutes a single track, as proposed, it allows advanced applications to clone the track for self-view (e.g., a "comb check") while simple applications benefit from default behavior. It was acknowledged that web developers may choose to remove the built-in button if it is too restrictive, necessitating a design that encourages developers to keep the button visible.]
[UserMedia Element and Constraints Discussion: A third element, `usermedia`, was proposed for cases where a website might want to ask for both microphone and camera permissions simultaneously. Youenn Fablet questioned the need for this element in a minimum viable product (MVP), citing concerns about the complexity and the difficulty in designing an appropriate icon that conveys both capabilities. Jan-Ivar Bruaroey agreed that `usermedia` was the "least interesting button" but noted that the Chrome team had expressed interest in it because it allows for single-prompt acquisition of both capabilities, reducing friction.]
[User Media Element and Constraints Discussion: A third element, `user-media`, was proposed for cases where a website might want to ask for both microphone and camera permissions simultaneously. Youenn Fablet questioned the need for this element in a minimum viable product (MVP), citing concerns about the complexity and the difficulty in designing an appropriate icon that conveys both capabilities. Jan-Ivar Bruaroey agreed that `user-media` was the "least interesting button" but noted that the Chrome team had expressed interest in it because it allows for single-prompt acquisition of both capabilities, reducing friction.]
Future Collaboration and Roadmap
[The speaker announced plans for an editor's meeting during the current week to meet with the PEPC team to get a status update and agree on a minimum feature set for a Version 1 and a future roadmap. They also plan to discuss developer feedback from the origin trial, which was used by several major video conferencing applications, and decide on plans for periodic follow-up meetings. Jan-Ivar Bruaroey stressed the importance of these meetings being public and having minutes.]
[Review of PEPC Button Details and API Shape: A meeting scheduled for Thursday will be used to sort out details regarding the PEPC (permissions, elements, presentation, storage, and identity) discussion points. The main questions revolve around the mute/unmute functionality, the API shape for the user media element (and whether it is an MVP), styling, and constraints. Mike West confirmed that the listed topics cover the main points and that they are open to collaboration, though consensus on all points is not guaranteed.]
[Discussion on PEPC Button Longevity and Geolocation: youenn fablet raised a question about the expected lifespan of the PEPC button for geolocation, noting that the design being pushed for microphone and camera permissions suggests a long duration. Mike West indicated that different capability controls can reasonably have different expected developer paths and that they are open to feedback on the decisions made for the geolocation version shipping in 144. The current design intent is for the geolocation button to remain on the page to provide control, for example, over location attachment to a search.]
[Constraining APIs to Promote Better Developer Patterns: Mike West noted that making durable changes to the access level associated with a button would be difficult as long as the API exists. They suggested a collaborative effort to find good patterns for developers and then collaborate on ways to constrain the APIs to help developers find those agreed-upon patterns. The PEPC discussions for the day concluded, and Mike West excused themself from the remainder of the meeting.]
Need further discussion on MVP scope and long term goal
RESOLUTION: Continue camera/microphone button design discussions between WebRTC WG and PEPC, open to all WG members, slot will be webrtc editor’s meeting.
RTC prefix
RESOLUTION: Move on with a PR for adding RTC prefix.
dropped frame counter for MSTP
RESOLUTION: Consensus on ready for PR. Might need further technical discussion/design on whether to allow the stat to identify when frames were dropped (how many frames are dropped between two video frames exposed).