[mediacapture-main] risk model of stored permissions and constraint opportunities (#991)

rockinghelvetica has just created a new issue for https://github.com/w3c/mediacapture-main:

== risk model of stored permissions and constraint opportunities ==
The Note on [Privacy and Security Considerations](https://www.w3.org/TR/mediacapture-streams/#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](https://www.figma.com/community/plugin/1039957324840667051/vimeo-record?searchSessionId=ltcs76tp-estt6uzcmt8) 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](https://help.figma.com/hc/en-us/articles/360042532714-Use-plugins-in-files#Network_access) 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 token specified by the origin. The approach would need to consider fingerprinting surface and privacy UX within the browser.

The `deviceId` almost sounds like a good starting point, if I understand correctly that it is unique to the application scope (origin + iframe). Roughly:

- 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, unless it provides a valid `deviceId` as a constraint.

Questions raised:

- Does permission flow up to the origin (i.e. can [Figma.com](http://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 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.

Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/991 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 4 March 2024 20:49:33 UTC