The Note on Privacy and Security Considerations describes an onus on "developers of sites” that is muddied by the origin-level nature of stored permissions.

Developers of sites with stored permissions should be careful that these permissions not be abused.

Where the risk is that a webcam or microphone is accessed by an unexpected third party, care for this risk is diffused to millions of third parties on many popular web apps.

What I'm seeing in practice

There are many millions of developers working on Replit.com, Huggingface.co, and web apps like Figma (see the Vimeo plugin running under www.figma.com, for example) where a permission for a camera or microphone applies across the entire surface of user-generated content. Figma has a fairly responsible permissions workflow, but even their marketplace security schema doesn't account for where camera & microphone access might be inherited from prior authorization.

In my personal example, I am using Replit.com to develop a mediapipe app, but I am concerned that stored permissions extend to any other repl on the domain. To validate that fear, I navigated to an unfamiliar Huggingface Space and saw my camera turn on, because I had used the camera a month ago when playing with a Gradio demo in an unrelated Space.

How could these permissions be more security and privacy minded?

With the caveat that I’m just a web civilian offering comment & I’m relying on an ballpark sense of the principles being navigated by this group, these were my first thoughts on the problem:

This standard

The constraint mechanism feels like it might be extended to account for the relationship between origin and iframe, a path component, or some other policy/token specified by the origin.

Roughly: when an iframe calls navigator.mediaDevices.getUserMedia as with a Figma plugin or similar…

• A blocked permission at origin remains in force
• Unlike now, if the origin Allows access the iframe’s UX would be knocked back to Ask. The browser UX and stored permission would proceed in a familiar manner, but specific to the extra constraint.
• The constraint might need to function a little like deviceId, if I understand correctly that it is unique to the application scope (origin + iframe). The fingerprinting surface and privacy UX would have similar considerations, but the use of CDNs and identifiers that move around more than origin domains could complicate this.

Questions raised:

• Does permission flow up to the origin (i.e. can Figma.com access my microphone with stored permission because I first granted access to a plugin)?
• Is this granular permission the default (i.e. does Replit have to update their iframe code to adopt this)?
• Implications for browsers to message & manage split permissions for a given domain, allow all, abuse like unique apps asking over & over on a given page, etc.

Beyond draft changes, developer education about this risk can be improved and further promoted, based on the examples cited (Figma, Replit, et al).

Related standards

The Permissions Policy (https://www.w3.org/TR/permissions-policy-1/#policy-controlled-feature) draft feels relevant, but I need to get more familiar with it.

The ability for an app in an iframe to revoke its own privilege is a helpful mitigation, and it could be more clear on how this works. I would absolutely use it in my own code on Replit, and at the level of e.g. the Gradio framework it would greatly mitigate this risk for many web users. Relatedly: permissions with timed or session durations.

Browsers

Similar to nuances of third-party cookie management, there can be a role for UX like permission audits and better communication about who has access to the camera.