Control API permissions

[muodov]

Control API permissions

Submitter(s)

Maxim Tsoy (DuckDuckGo)

Motivation

In apps that can load arbitrary web apps, such as WebView-powered browsers, it is desirable to give users control over website permissions via custom native UI. For example, a browser can prompt a user to allow a web app to access the camera, and then show an indicator while it's being used. To allow browsers to manage permissions, we need WebView APIs to:

• list what permissions have been set for a given site (allow/deny/query)
• programmatically change and reset them
• receive events when a permission is requested or used

Some examples of permissions include:

• camera / microphone
• geolocation
• screen capture
• other permissions managed with Permissions API

Stakeholders

WebView vendors (Google, Microsoft, Apple)
Browser vendors (e.g. DuckDuckGo)

Analysis

There's currently no cross-platform approach and support. Most WebViews provide events / APIs for specific permissions, but the feature parity could be better.
Some specific examples of limitations:

• Webkit has ways to control microphone and camera, but doesn't support Geolocation
• Microsoft's WebView2 support is limited:
  • Feature request: Permissions API MicrosoftEdge/WebView2Feedback#2427
  • Feature request: Device or permission "in use" event MicrosoftEdge/WebView2Feedback#2428
  • Feature request: API for screen sharing MicrosoftEdge/WebView2Feedback#2442
• Android WebView could use some WebRTC-related events: WebRTC IP leak duckduckgo/Android#429

Related W3C deliverables and/or work items

Permissions API

How is the issue solved in the Browser, and what’s more is needed?

Non-webview Browsers have implement this using internal APIs.

[QingAn]

@muodov Please also take a look at #28

[aluhrs13]

Adding some additional thoughts - For the basic permissions cases WebView2 has a PermissionRequested event that allows the host app to directly handle permissions or show custom UI for a permission request. Since WV2 apps already have direct access to native APIs for something that would require permission for a normal web app, "bypassing" the web security makes sense. @muodov Did a great job enumerating some of the direct gaps we still have around managing permissions after the initial use-case.

One problem we've seen with WebView2 that would apply more generically here is implicitly captured in MicrosoftEdge/WebView2Feedback#2442. As the web platform evolves, these permissions are getting more and more complex. Camera, Geolocation, Notifications, etc. are all fairly simple allow or deny cases. The getDisplayMedia capability of the Screen Capture API is much more complex, with multiple tabs and options that if being given to the host app programmatically need to be customized. Making sure the approach to this problem can scale to future use-cases might need to do something like coordinate with the Permissions Registry as new permissions are added to have recomendations for how WebViews should handle them.