Google's unloved plan to fix web permissions gathers support

Google has been testing a new way for websites to ask permission to access sensitive browser controls, such as the microphone and camera, despite longstanding opposition from Mozilla and Apple. Following recent refinements to the proposal, Mozilla now appears to be warming to the changes.

The debate is around the implementation of a proposed web specification called Page Embedded Permission Control (PEPC), which would allow browsers to render HTML buttons that make permission requests for access to the device camera, microphone, and geolocation data.

The proposal touches on a crucial question: whose interests does the browser serve? The user, the website owner, or the browser maker?

The browser has long been referred to as a User-Agent (it identifies itself to servers thus), and browser users have a substantial amount of control over how their browser renders websites. They can install extensions to block ads and enhance privacy, for example.

But browsers also cater to the interests of website owners and browser makers like Google. They support commercially relevant functions and provide access to valuable data, for example.

Browser makers like Apple, Brave, Google, Microsoft, Mozilla, and Vivaldi balance those sometimes competing interests in different ways. And internet users may choose their browsers based on those differences - if they have a choice in the matter.

Google's concern, as spelled out in the PEPC proposal, is that the current permission system is confusing.

"The current implementation of permissions on the web causes significant problems for users," explains Google Chrome product manager Minh Le in the latest iteration of the proposal. "While permissions are crucial to the web, enabling powerful capabilities (like camera or microphone access) while safeguarding user privacy and security by delegating sensitive decisions to users, this model frequently falters in practice, leading to frustration and perceived issues for users."

Le argues that the multi-layered permission model - with enforcement at the web origin, within the user agent (browser), and at the system (OS) level - gives rise to false positives and false negatives. For example, users often join a video call only to discover their microphone is blocked because of a previous permission denial, not a software glitch.

"If a permission is granted without the user intending it (false positive, e.g., as a result of a 'dark pattern' on the page), or if a permission is denied without intent (false negative, e.g., camera not working in video conference), the browser has failed its user," Le says.

Various developers representing different browser makers have been discussing the matter at least since 2022. While there's general agreement that the permission process can be improved, the devil is in the details.

Last year, Google announced plans to test a dedicated HTML element in an origin trial, starting with Chrome 126, released June 11, 2024. Then last month, the search juggernaut published some enhancements to the element, as part of an origin trial that runs until mid-August.

The HTML element - markup a developer would include in a webpage - remains behind a flag in Chrome 137, the current stable release.

The new element is declarative rather than imperative - invoking it declares what the developer wants (to ask permission) instead of specifying how exactly that will be accomplished. And it aims to prevent design patterns that spam web users with permission requests and that abuse modal interactions that may not represent consent (tricking a visitor into granting permission). It also aspires to make it easier to undo permission settings, for example, when it's not obvious how to undo blocked microphone access.

The proposal's goals, as articulated by Le, are to: better capture user intent, reduce false negatives and false positives, mitigate regret from operating system-based and site-based permissions, and tie permissions more closely to context so they're better understood.

Developers with Mozilla and Apple gave the proposal a cold reaction.

In April 2024, Apple standards engineer Marcos Cáceres cited various objections to the proposal, such as increased UI/design complexity, security complexity, and element styling options that could be abused.

Last November, Mozilla developer Simon Friedberger published a similar critique, observing that the main goal seems to be preventing "permission regret," something that matters more to websites shut out by users than to users who are shutting out websites.

"The metrics chased seem to favor websites, at the cost of users," he wrote. "A low conversion rate is a sign of permissions doing their job. A high conversion rate is a sign they're not. PEPC seems to chase the latter."

Friedberger also observed that the interaction pattern lets users undo a permission denial but doesn't provide a way to revoke a decision to allow access.

Last week, however, Mozilla's opposition softened somewhat. Citing the revisions Google floated in May, Mozilla's Jan-Ivar Bruaroey wrote, "Recent positive developments in PEPC warrant reconsideration."

Once those are implemented, Bruaroey wrote in a separate blog post, the addition of native HTML and mute-toggles in browsers will put device selection back under the control of the browser, rather than the operating system or server.

A Mozilla spokesperson told The Register, "Mozilla is committed to ensuring that people remain in control of their online experience. Better permissions UX can help with that, so we're excited about the potential of new design approaches in this area.

"PEPC is trying to solve a real problem with permission requests today - they are often annoying and can lead to unintended grants or denials. But the current version in the Chrome Origin Trial has some major issues and we think it would be a mistake to ship it to the web platform as-is."

In particular, the Firefox-maker says, each permission should get its own control, rather than having them all lumped together under a single HTML element.

"For example, while asking permission ahead of time is fine for notifications, it's an anti-pattern for camera and microphone, where device permission should be granted at point of use," the spox explained. ®