- From: pes10k via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Mar 2023 23:55:35 +0000
- To: public-webrtc-logs@w3.org
@henbos > In your opinion, is exposing powerEfficientDecoder adding FP surface in a context that already has MC's powerEfficient No, i don't think so, at least as far as I understand the two properties. But we have a lot of legacy privacy harm in the platform, and so im extremely uncomfortable with new specs reducing the privacy protections they have because they exist in legacy / older features. In other words, i think the right outcome to this mismatch is to bring the protections around MC's `powerEfficient` up to par with `getStats()`, and to leave the terrific and well defined algoritm around `getStats()` as a model for other specs to align on, instead of removing or weakening a well defined protection to align it with a undefined one. > There are 200+ metrics so the app could poll this API for any reason, so asking for HW permission as a result of someone wanting to know the bitrate of their data channel does not make sense. Totally understood and agreed. There is a lot behind `getStats()` that has little or not affect on user privacy, and bugging users w/ a prompt for those details would be all harm and no benefit. You could imagine a `getStats(sensitive=false)` call that returns the non-sensitive values, and a `getStats(sensitive=true)` one that prompts (again just a straw suggestion). -- GitHub Notification of comment by pes10k Please view or discuss this issue at https://github.com/w3c/webrtc-stats/pull/732#issuecomment-1451045840 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 March 2023 23:55:37 UTC