[Webkit-unassigned] [Bug 174500] New: WebRTC data channel only applications require capture permissions for direct connections

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=174500

            Bug ID: 174500
           Summary: WebRTC data channel only applications require capture
                    permissions for direct connections
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media Elements
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: lennart.grahl at gmail.com

Currently, ICE candidates of type 'host' will not be gathered/handed out to the application in case no capture permission has been granted. While this may be a perfect solution for audio/video, it leaves data channel only applications with either srflx/relay only or with the need for an unfitting permission request.

The biggest issue with this approach is: How do you explain to the user that you need capture permissions for a direct peer-to-peer connection? That smells fishy and I understand everyone who will decline such a request for this exact reason.

So, if the user rejects this permission request, secondary issues are that you
a) now always need to provide a STUN server, and
b) always need to provide a TURN server (which itself is rather expensive in terms of operating costs and may not be feasible for small open source applications for this reason) because there are plenty of routers who are not capable of doing NAT loopback (yep, even models from 2017). Thus, one cannot rely on server reflexive candidates.

My proposal would be that the application can request a permission to "establish a direct connection" (maybe also displaying some hints on what this means towards privacy, etc.) which enables the use of host candidates.

(P.S.: You should probably add a WebRTC component to your Bugzilla.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170714/3d60b32b/attachment.html>