Align exposing scalabilityMode with the WebRTC "hardware capabilities" check

[pes10k]

This issue is being filed as part of the w3cping/privacy-request#117

There have been discussions in other issues around preventing WebRTC-related hardware capabilities from being used for browser fingerprinting. For example

• Expose powerEfficientEncoder/Decoder if MediaCapabilities allows it webrtc-stats#732 (comment)
• The HW exposure check does not solve Cloud Gaming use cases webrtc-stats#730

This issue is to verify that sites would be unable to learn scalabilityMode before the 6.1. Limiting of Hardware Capabilities checks have passed (or if not, that other comparable protections are in place). It might also be ideal to reference the above check in this spec

[henbos]

There are reasons to use scalabilityMode that does not involve a camera. The referenced limitation algorithm is a bad fit for scalabilityMode. This information is already exposed in MediaCapabilities, which is a promise-based API, so I would look there as the first step to have a discussion about this

[aboba]

The WebRTC-SVC specification relies on the Media Capabilities API for discovery of hardware capabilities. While it is possible to discover which scalabilityMode values are supported for each codec using setParameters() in a trial and error fashion, doing so does not indicate whether the underlying implementation is hardware accelerated. So this issue seems to have been filed in the wrong repo and needs to be moved (either to WebRTC-Stats or Media Capabilities).

[pes10k]

I dont think this is in the wrong location.

This proposal would expose additional fingerprinting surface. It needs to have some protection to prevent that fingerprinting surface from being misused. I'm suggesting the hardware check being discussed in other specs could be a place for this group to work to solve the privacy risk this proposal adds, but either way, the problem is the additional fingerprinting surface this proposal ads to the platform

[henbos]

MediaCapabilities is the API that webrtc-svc refers to for discoverability. There may be more work needed on this spec to ensure that we don't expose things unless MediaCapabilities has already exposed it, so I think it is fair to keep this issue open for now, but to get the ball rolling on privacy preserving mechanisms, we really do need to also file an issue on https://github.com/w3c/media-capabilities/issues. It would seem highly unlikely that this issue is resolved independently from MC when MC is the discoverability API that this API depends on

[pes10k]

It would seem highly unlikely that this issue is resolved independently from MC when MC is the discoverability API that this API depends on

Understood, 100%. I only mean that if proposals / specs are revealing fingerprint-relevant inputs through MC, and MC is in a state that it doesn't prevent user-harming code from accessing MC-controlled data, then those proposals / specs are in practice revealing fingerprint-bits. That its going through the MC machinery doesn't change this specs contribution to the privacy risk.

I see @samuelweiler opened w3c/media-capabilities#176 a couple years ago. Would this be a good place to continue from, or do you think it'd be better to create a new issue?

[henbos]

I understand your concern, but will you file an issue on https://github.com/w3c/media-capabilities/issues anyway? Edit: Ah w3c/media-capabilities#176 does the job

[aboba]

I have filed Media Capabilities Issue #209.

Related: w3c/media-capabilities#176

As discussed at yesterday's MEDIA WG meeting, time will be allocated for discussion of Media Capabilities issues at a future meeting.

[dontcallmedom-bot]

This issue was discussed in WebRTC November 2023 meeting – 21 November 2023 (Issue 92: Align exposing scalabilityMode with WebRTC “hardware capabilities” check 🎞︎)

[dontcallmedom]

@aboba I reset the "privacy-needs-resolution" label since that's up to the privacy IG to determine, not to us.