[webrtc-pc] Pull Request: Permission API for receive-only media and data use cases

lgrahl has just submitted a new pull request for https://github.com/w3c/webrtc-pc:

== Permission API for receive-only media and data use cases ==
## Background

There are use cases that do not use `getUserMedia`, namely unidirectional audio/video or data only use cases. For example, security cameras, baby monitors, town-hall sessions, drones, MOOCs, remote device access, easy file transfer, multiplayer games, etc. all of which can greatly benefit from mode 1. In some cases, these may be connected via a separate interface that is not the default interface. Furthermore, for data only use cases, a relayed connection can be much more restraining than for real-time audio/video because of the potential impact on throughput.

## Direct Permission API

This PR proposes to add *Direct Connection API* to the spec. If accepted, user agents could safely ship more strict default modes without patronising the before mentioned use cases.

With help from @jan-ivar, this API has been tailored in a way to encourage permission being granted without having to rely on a prompt. However, it does also enable implementations to use a permission prompt if desired.

### Intended Usage

The intent is that an application should always provide context when using the permission request as outlined in the [examples that have been added](https://lgrahl.github.io/webrtc-pc/#directconnectionpermission-example*).

### Implementation Suggestions

#### Switch in the site's information panel

To not bother the user with a permission prompt, the browsers could integrate the permission request in form of a switch in the site's information panel, next to the URL - analogue to the *autoplay* feature in Firefox:

![direct-connection-permission-switch](https://user-images.githubusercontent.com/1793755/55011827-c7858700-4fe6-11e9-8fe2-8a744dd8ab5c.png)

Depending on the user's preferences, selectable options could for example be *Yes* and *Hide VPN addresses*.

#### Prompt

Browsers could also integrate the changes proposed in this PR with the following permission request being triggered once `registerDirectConnectionInterest` is being called:

    Will you allow example.org to establish a direct connection?
    [Learn more]
    
    [Yes                             |v]
    :Yes                               :
    :Yes, but hide VPN addresses       :

    [x] Remember the decision for this page

    [Don't allow] [Allow]
    
If one clicks on *Learn more*, it could open a separate page that explains the impact on privacy regarding the exposal of all interface's addresses.

However, the user should probably not be able to demote the mode in the permission request below the one that is already active.

### Why not as an extension spec?

This PR clarifies when IP handling modes are being applied, when they are effective and how a mode change is being signalled to the application. Furthermore, media receive only use cases and data channels are part of WebRTC 1.0. As such, they should have an equal opportunity to leverage the full potential of WebRTC, just like send/receive audio/video use cases. This allows to solve the privilege escalation of `getUserMedia`.

### Permission API Update

Spec: https://lgrahl.github.io/permissions/#direct-connection
Diff: https://github.com/w3c/permissions/compare/master...lgrahl:direct-connection

### Notes

The use of the [Permissions API](https://www.w3.org/TR/permissions) allows to re-use the `"direct-connection"` permission in other specs (and potentially in other ways).

As a nice side-effect, browsers that implicitly grant the `"direct-connection"` permission when granting `"camera"` or `"microphone"` permissions, would now also trigger the `connectionupgradable` event in case the mode has been upgraded.

### To do

- [ ] Go through the spec and update parts that currently refer to which candidates may be exposed under which circumstances.
- [ ] Line breaks.

Resolves #2012

See https://github.com/w3c/webrtc-pc/pull/2175

Received on Wednesday, 17 April 2019 12:37:16 UTC