- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Sat, 24 Feb 2024 16:03:20 +0000
- To: public-webrtc-logs@w3.org
Does Safari have data on how well this works in practice on video conferencing webpages? It seems to me the main gain here is the roughly 5.35% ([5.65](https://chromestatus.com/metrics/feature/timeline/popularity/3452) - [0.3](https://chromestatus.com/metrics/feature/timeline/popularity/3451)) of webpages that only use WebRTC for fingerprinting. E.g. only blocking BFCache after sRD could have a large impact without disrupting video conferencing. > Personally, I would be very irritated if hitting back or reopening a tab turned my camera/microphone on and dumped me back into a meeting. I think many other users would feel the same way. Websites can already do that, so I think that is orthogonal (thanks to persisted permissions or even permission grace periods). We messed up gUM which doesn't require transient activation, but it's probably too late to change that. UAs might be able to mitigate this with muting — idea in https://github.com/w3c/mediacapture-extensions/issues/39#issuecomment-955131893). -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/200#issuecomment-1962409792 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 24 February 2024 16:03:21 UTC