- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Apr 2019 12:37:15 +0000
- To: public-webrtc@w3.org
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:
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