- From: heyheyjc via GitHub <sysbot+gh@w3.org>
- Date: Sat, 09 Feb 2019 08:36:36 +0000
- To: public-webrtc-logs@w3.org
> @heyheyjc, can you describe your data-channel dependent site and what is precisely needed to make it work?
Sure. It's a collaborative screenwriting SPA with about 25,000 weekly users. When editing a script in eg Google Drive, users form WebRTC p2p edit-groups (websocket signalling, Operational Transform based editing, and a RAFT-based leader system for conflict control). It works great, just not for same-building Safari users (or Edge users, of course, but I'll worry about that once Edge gets above 0% on caniuse.com).
As for explaining to a bunch of paranoid and non-computer-savvy writers with overly active imaginations that that little red camera icon _doesn't_ mean I'm recording them in their underpants? Yeah, wish me luck.
The real problem with the getUserMedia hack is that the permission request doesn't remotely match the permissions required, and nor does it explain the actual risks. Example: someone doing an 'adult' stream might want to share their camera but would _never_ want to give away their location. Since Safari doesn't inform them of that risk, what good is the restriction and permission request really? The current situation seems the worst of both worlds, not providing any genuine security or privacy benefit, while holding back legitimate uses.
So I like the idea, and only for HOST if that's possible, of a per-domain "Permission to establish direct ('peer-to-peer') connections?" plus a 'What are the risks": "This may allow the other browser to see your IP address, which potentially could be used to learn your location".
Hope this is some help.
--
GitHub Notification of comment by heyheyjc
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2012#issuecomment-462025785 using your GitHub account
Received on Saturday, 9 February 2019 08:36:37 UTC