Open pes10k opened 1 year ago
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
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).
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
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
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 https://github.com/w3c/media-capabilities/issues/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?
I understand your concern, but will you file an issue on https://github.com/w3c/media-capabilities/issues anyway? Edit: Ah https://github.com/w3c/media-capabilities/issues/176 does the job
I have filed Media Capabilities Issue #209.
Related: https://github.com/w3c/media-capabilities/issues/176
As discussed at yesterday's MEDIA WG meeting, time will be allocated for discussion of Media Capabilities issues at a future meeting.
@aboba I reset the "privacy-needs-resolution" label since that's up to the privacy IG to determine, not to us.
This issue is being filed as part of the https://github.com/w3cping/privacy-request/issues/117
There have been discussions in other issues around preventing WebRTC-related hardware capabilities from being used for browser fingerprinting. For example
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