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

Re: [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 22:47:17 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-432017909-1540248436-sysbot+gh@w3.org>
> First, one needs the right message to convey all the implication to the user.
> When sharing camera and/or microphone, the user is somehow understanding that some privacy is getting lost. The message you suggested might not enable the user to understand the implications of their choice.

Fully agree, phrasing this as understandable as possible is crucial. The *implementation suggestion* is coming from a non-native English speaking person which doesn't have a great background in UX design - me. So, I'm absolutely sure it can and should be improved greatly. But the necessity remains.

> Second, the more you prompt, the more the prompts become meaningless as users will start clicking without caring about the choice.

Granted, it's true that a user might do that (it's not going to be me, and I guess it's not going to be a privacy-affine person but there will be those people). However, we cannot play the bouncer and eventually dismiss new permission requests because the club is full of them. At least not without a viable alternative.

> For audio/video cases, if one of the user is giving access to camera/mic/screen, the other user does not need to provide host candidates. If a user is a native app (remote device access, drones...), it could be its own STUN server and the native app will probably provide its host candidates.

I believe the use case here is that both sides want to communicate directly (think of same network IoT stuff, for example a baby monitor or a door bell and a browser on the other side). Even if the native app would provide its own STUN server (which, as a requirement I find... weird), it will still not be reachable if browser and native app cannot communicate via the page origin's route. I'm sure @steelyglint can elaborate on the use case (and correct me if I'm wrong).

GitHub Notification of comment by lgrahl
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2012#issuecomment-432017909 using your GitHub account
Received on Monday, 22 October 2018 22:47:19 UTC

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