W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > October 2018

[webrtc-pc] Obtain user consent for one-way media and data use cases

From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
Date: Mon, 22 Oct 2018 18:52:29 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-372522146-1540215012-sysbot+gh@w3.org>
lgrahl has just created a new issue for https://github.com/w3c/webrtc-pc:

== Obtain user consent for one-way media and data use cases ==
This is a backport from https://github.com/w3c/webrtc-nv-use-cases/pull/14 I would like to get added to WebRTC 1.0:

> The application must be able to request user consent for one-way media and data only use cases in a non-discriminating way.

### Rationale

There are use cases that would love to request user consent but cannot use `getUserMedia`, namely unidirectional audio/video or data only use cases. For example, security cameras, baby monitors, drones, MOOCs, remote device access, easy file transfer, etc. could 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 an indirect connection can be much more restraining than for real-time audio/video data because of the potential impact on throughput.

I suspect that the [mDNS extension to hide host candidates](https://tools.ietf.org/html/draft-mdns-ice-candidates-00) is going to be accepted by the IETF WG and shipped in 1.0 stacks (in fact, Safari already does it). That extension is going to affect use cases that do not have user consent and thus automatically handicap all use cases mentioned above.

### Implementation Suggestion

Now, this is something where I expect a lot of discussions. Implementations could add a new permission request. An example:

> Will you allow **filetransfer.example.org** to establish a direct connection?
> [Learn more]


I would happily provide a PR for adding this.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2012 using your GitHub account
Received on Monday, 22 October 2018 18:52:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:07 UTC