-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getCapabilities
seems to leak hardware capabilities w/o a permission
#54
Comments
The spec already has the following text about
|
While this allows browsers to solve the issue, I do not think this resolves this issue to a satisfactory extent, because...
|
Also note that this relates to createOffer() and createAnswer() as well, which will list all the codec capabilities in the SDP as well even if you don't use this API. |
Making a promise-based requestCapabilities() that would allow accepting or rejecting based on permissions / a user prompt might take us one step in the right direction, but unless we figure out what kinds of permissions could make sense to a user in a wider context, this would only add confusion. |
and if we expose it all through createOffer(), putting a guard on getCapabilities() is exactly zero improvement in privacy. |
createOffer already says: "In privacy-sensitive contexts, browsers can consider mitigations such as generating SDP matching only a common subset of the capabilities." getCapabilities in the spec should perhaps at least refer to that. |
@jan-ivar I have interpreted this advice as referring to the potential for limiting leaks relating to support for codecs in hardware. For example, if there is a flag to enable hardware acceleration, then if the flag is not set, higher profiles may not be provided by This is different from the browser hiding supported codec configurations from |
If we want to progress on any of these issues we need to take a stance:
Once we know what is and is not acceptable, we can start talking about solutions. Today there seem to be a disconnect between privacy requests in spec discussions and current implementations. |
Here is a paper that describes hardware fingerprinting techniques: Note that the fingerprinting value of supported audio formats is greater than video formats, and that hardware characteristics such as CPU, media devices, WebGL and WebGPU is most valuable for fingerprinting. My take is that we should focus on primary fingerprinting information rather than on secondary information which provides little incremental values (e.g. the supported video codecs and profiles). |
To provide more detail with respect to what @alvestrand said: "and if we expose it all through createOffer(), putting a guard on getCapabilities() is exactly zero improvement in privacy." Here is a document which describes what is returned in AFAICT, the only thing that is in |
Still don't know what to do with this one, as noted in earlier discussions this is tied to other APIs like createOffer/createAnswer so solving it in isolation does not improve the situation very much. Will we get input from privacy review or revisit these later? |
Proposed resolution is to include a note relating to implementation issues with hardware capabilities. As noted in https:/w3c/webrtc-pc/issues/2539, implementations may not return hardware capabilities (at least prior to calling |
Any solution to this specific problem in WebRTC-PC would be an API change which is not for final CR at this point. Moving to webrtc-extensions. Related issues: |
Direction is to address this concern via Issue #95 |
Moved from the WebRTC-SVC repo: w3c/webrtc-svc#22
Opened by snyderp
Apologies if I'm misreading the spec, but if I'm reading it correctly it looks like a site can learn about the visitors underlying hardware capabilities w/o a permission prompt or some other positive, affirmative action by the visitor.
Is my reading of the spec correct then, there is a FP vector exposed by the current text that would need to be mitigated (e.g. sites couldn't access it by default).
Otherwise, if this is addressed elsewhere, could you kindly point me to where, so I dont make the same mistake twice? :) Thanks!
The text was updated successfully, but these errors were encountered: