W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > July 2019

Re: [webrtc-pc] Permission API for receive-only media and data use cases (#2175)

From: youennf via GitHub <sysbot+gh@w3.org>
Date: Wed, 10 Jul 2019 02:48:42 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-509886023-1562726921-sysbot+gh@w3.org>
> > That would further entice developers in calling getUserMedia when they do not have host candidates (for good or bad reasons) since this will be a one-time call.
> It's already a one-time-call in Chrome today, so I think they're sufficiently enticed. 😉

For the prompt yes. To get host candidates, I believe they would need to call getUserMedia each time, which can be visible and very intriguing/creapy to users.

> By exposing it, users can at least see what is happening, and even revoke it with the **X**

Right, this is an option I like somehow.
With the particular UI illustration, it would seem weird though to expose the information and then allow the user to no longer expose it.

> > Ideally, we would be able to identify legit uses of RTCPeerConnection.
> Not possible I think. We'll just end up boosting our successful connection numbers.

Not to say this would improve much the connection rate, but a connection that is providing content for a large video element visible in a page seems like a legit case. If the connection is using a TURN candidate, there could be room for optimization.

> > Or we would identify cases where leaking the host candidate is not a privacy issue.
> That's `getUserMedia`. Once gUM is granted, its fingerprint surface dwarfs 192.168.1.x.

IPv6 temporary addresses are cheaper and have less fingerprint risks.
If a device could dynamically be assigned to several temporary IPv6 addresses, the risk would further decrease.

GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2175#issuecomment-509886023 using your GitHub account
Received on Wednesday, 10 July 2019 02:48:45 UTC

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