Re: [webrtc-stats] Expose powerEfficientEncoder/Decoder if MediaCapabilities allows it (#732)

> Is the above correct? If so, I have two questions:
> 1. I was surprised by the "any" bits in the above, but i don't see anything in the [exposing hardware check]( that ties the properties of the device being described with the device playing). Is this intentional?
> 2. I'm not able to find any algorithm or description of when `MediaCapabilitiesInfo.powerEfficient` is made available. Am I missing it? If so, can you kindly point me to it?  If it doesn't exist, then the change in this PR is worrying, since it would change a useful, well defined privacy protection, into a privacy protection that was loosely or (un-)defined

@pes10k, thank you for the feedback.

As far as I understood, your understanding is correct.  And as the following sentences as @henbos mentioned at the begining of this issue. We thought this couldn't worsen the security concern beyond the level of MediaCapabilities exposure.

_This exposes powerEfficientEncoder and powerEfficientDecoder (but not encoderImplementation or decoderImplementation) in contexts .... This should not significantly increase fingerprinting surface beyond what MediaCapabilities is already doing and if MC becomes more restrictive than so would getStats._

However, if you are still concerning on this level of exposure. Could you please share your opinion about exposing the decoderFallback as an alternative as I proposed on

My opinion is decoderFallback metric obscures the hardware exposure because it is only getting enabled when there is a hardware decoder fallback gets intiated. And then it will be gone when it is recovered.

GitHub Notification of comment by xingri
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Saturday, 11 February 2023 00:31:38 UTC