{"id":489,"date":"2025-06-11T19:00:01","date_gmt":"2025-06-11T19:00:01","guid":{"rendered":"https:\/\/blog.mozilla.org\/webrtc\/?p=489"},"modified":"2025-06-24T23:20:22","modified_gmt":"2025-06-24T23:20:22","slug":"one-time-permissions-are-here-to-stay","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/webrtc\/one-time-permissions-are-here-to-stay\/","title":{"rendered":"One-time permissions are here to stay!"},"content":{"rendered":"

\"\"<\/p>\n

One-time camera and microphone permissions are now in Chrome (since M116<\/a>), joining Firefox and Safari. This means that per-session permissions are now available to use cross-browser. Chrome calls the option “Allow this time”<\/strong><\/em>, where “this time”<\/em> (as in “one-time”<\/em>) refers to the scope of the grant, which the browser forgets once the user closes the page. This is the default in Firefox and Safari.<\/p>\n

This gives users more control over their privacy, and forces sites to work without persistent permission. We’ll explore where old patterns break and how to build device selection that works for everyone.<\/p>\n

Why do browsers offer one-time permissions?<\/h2>\n

Users might not be comfortable making long-term decisions about a website’s permissions.
\n
\nFor camera and microphone, the risk of untimely recording is of particular concern: For backwards compatibility, navigator.mediaDevices.getUserMedia()<\/code><\/a> doesn’t require transient activation<\/a>. This means open tabs might turn on the camera or microphone at any time. Invasive<\/a> or malicious<\/a> applications can abuse this.<\/p>\n

\"\"<\/p>\n

Users might not even trust legitimate websites with this decision, for fear of confusion over when people can and can’t see them. They might feel better knowing recording cannot commence without the push of a button.<\/p>\n

More browsers now support one-time permission than support persistent permission. So it seems time for applications to design for them.<\/p>\n

Why do websites need to care? (The web model)<\/h2>\n

Many users assume configuration and selection of their cameras and microphones is handled by browsers. They don\u2019t realize how much of this experience websites control. Web developers are faced with navigating several browser differences:<\/p>\n\n\n\n\n\n\n\n
Browser<\/em><\/th>\nPermission models<\/em><\/th>\nDevices granted<\/em><\/th>\nDevices enumerable<\/em><\/th>\n<\/tr>\n<\/thead>\n
Firefox<\/strong><\/td>\none-time & persisted<\/td>\nper-device & all of a kind<\/td>\nafter use<\/td>\n<\/tr>\n
Chrome<\/strong><\/td>\none-time & persisted<\/td>\nall of a kind<\/td>\nafter permission (not to spec)<\/em><\/td>\n<\/tr>\n
Safari<\/strong><\/td>\none-time only<\/td>\nall of a kind<\/td>\nafter use<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

<\/p>\n

In hindsight, this may have been a mistake. As Uncle Ben would say, “with great power comes great responsibility<\/a>“<\/em>. So it might be good to review how websites are faring in this area.<\/p>\n

Goodbye persistent permission mindset<\/em><\/h3>\n

This anti-pattern of the past worked in only one browser, where not<\/em> having persistent permission was a tell that someone was a first-time user. In a nutshell, the mindset was: divert users without persisted permission to a separate priming page, and the main application needn\u2019t bother with permission at all. A major simplification.<\/p>\n

This was never interoperable, yet influenced early web design. Web developers were given the navigator.permissions.query()<\/code> API to navigate implementation-defined<\/a> behavior to help escalate permission.<\/p>\n

Users who didn’t (or couldn’t) persist permission were stuck in a “slow lane”, treated as first-time users every meeting. They were lucky if the website remembered their devices or let them choose at all. Some websites didn’t even work<\/a>.<\/p>\n

This mindset no longer fits any browser, so hopefully we’ve seen the last of it.<\/p>\n

Designing for all users<\/h3>\n

With Chrome M116, users can easily reset permissions from the URL bar in all modern browsers. This renders priming anti-patterns of the past obsolete.<\/p>\n

Less is more. Don’t grill users for permission, and don’t expect it to stay from a previous visit. Simply let the browser ask for it at point-of-use, and you’ll be fine and interoperable!<\/p>\n

The hardest remaining part is device selection<\/em>, which is the focus of the remainder of this post.<\/p>\n

Selecting camera \/ mic \u2014 with privacy<\/h2>\n

Websites\u2014not browsers\u2014build the picker UI (don’t ask<\/a>). They call navigator.mediaDevices.enumerateDevices()<\/code><\/a> to fill the UI, but exposing every device up-front would hand trackers a stable fingerprint.<\/p>\n

\"Cart<\/p>\n

So the rule today is: use first, list later. A page must call getUserMedia()<\/code><\/a> before it can list devices.<\/p>\n

In contrast, early spec drafts let sites enumerate devices on return visits if the user had once granted access. But this form of persistence was hostile to privacy\u2014trackers still try it on 8% of page loads<\/a>.<\/p>\n

So in 2020 the W3C Privacy Interest Group<\/a> closed the loophole, and browsers agreed to block enumeration until after use<\/em><\/a> of camera or microphone.<\/p>\n

One engine still ignores this (crbug 40138537<\/a>), tempting sites to ship workflows that rely on persistence between visits. Backwards compatibility with websites that were never interoperable in the first place, is somehow holding up progress. That seems backwards.<\/p>\n

So if you happen to work on one of these websites, we’re here to help! Here are some ideas for making device selection work with one-time permissions (with interoperability as a bonus)!<\/p>\n

Simple selection: Make it secondary<\/h3>\n

Most users have just one microphone and one front-facing camera. So the most obvious solution is to put selection under \u2699\ufe0f settings:<\/p>\n

    \n
  1. Remember what camera and microphone they used last time<\/li>\n
  2. Open the user’s camera and microphone first<\/li>\n
  3. Direct the user to a \u2699\ufe0f Settings page to change camera or microphone<\/li>\n<\/ol>\n

    A benefit of this model is the user sees the result instantly.<\/p>\n

    Advanced selection: without permission<\/h3>\n

    More websites are letting users into meetings without requiring permission upfront. We support this trend, as it is great for user privacy!<\/p>\n

    But some of them also offer device selection directly in the room. How can they do both? We’ll cover some strategies:<\/p>\n

      \n
    1. remember choices<\/strong> \u2014 recall the user’s device choices from last time from localStorage<\/code><\/li>\n
    2. cache the device list<\/strong> \u2014 copy the device list to localStorage (it doesn’t change that often)<\/li>\n
    3. call gUM<\/strong> \u2014 don’t be afraid to call getUserMedia<\/code> to refresh a selector the user interacts with<\/li>\n<\/ol>\n

      Here’s a demo<\/a> of 1 and 2:
      \n