`getCapabilities` seems to leak hardware capabilities w/o a permission

[aboba]

Moved from the WebRTC-SVC repo: https://github.com/w3c/webrtc-svc/issues/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!

[dontcallmedom]

The spec already has the following text about getCapabilities:

These capabilities provide generally persistent cross-origin information on the device and thus increases the fingerprinting surface of the application. In privacy-sensitive contexts, browsers can consider mitigations such as reporting only a common subset of the capabilities.

[henbos]

browsers can consider mitigations such as reporting only a common subset of the capabilities

While this allows browsers to solve the issue, I do not think this resolves this issue to a satisfactory extent, because...

• It makes caring about the privacy concern completely optional. Today's browsers seem to ignore this optional comment.
• If a browser does care about the privacy concern, it robs that browser of the full feature set. I.e. it does not provide a way to obtain the relevant permissions such that getCapabilities() is usable to the same extent that it is in a browser that doesn't care.

[henbos]

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.

[henbos]

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.

[alvestrand]

and if we expose it all through createOffer(), putting a guard on getCapabilities() is exactly zero improvement in privacy.

[jan-ivar]

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.

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.

[aboba]

@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 getCapabilities or createOffer, effectively hiding information on acceleration hardware from the application.

This is different from the browser hiding supported codec configurations from getCapabilities or createOffer without a flag, because in practice there is no easy way for an application to re-enable them. The application could attempt to discover which codec configurations were really supported by calling setCodecPreferences with additional entries added to the list returned by getCapabilities, hoping that it would not return an error. But this wouldn't really address privacy concerns, it just makes application development more complicated.

[henbos]

If we want to progress on any of these issues we need to take a stance:

• What information is acceptable to expose without explicit permission?
• What information is not acceptable to expose without explicit permission?

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.

[aboba]

Here is a paper that describes hardware fingerprinting techniques: http://yinzhicao.org/TrackingFree/crossbrowsertracking_NDSS17.pdf And a site that illustrates them: https://amiunique.org/fp

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).

[aboba]

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 getCapabilities() versus what is in the SDP returned by createOffer, createAnswer, etc.

AFAICT, the only thing that is in getCapabilities but not in the SDP is information on the supported scalability modes. Since hardware rarely provides additional support for encoding of scalability modes the additional information doesn't help with fingerprinting.

[henbos]

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?

[aboba]

Proposed resolution is to include a note relating to implementation issues with hardware capabilities. As noted in https://github.com/w3c/webrtc-pc/issues/2539, implementations may not return hardware capabilities (at least prior to calling createOffer()).

[aboba]

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: https://github.com/w3c/webrtc-extensions/issues/49 https://github.com/w3c/webrtc-svc/issues/22

[aboba]

Direction is to address this concern via Issue https://github.com/w3c/webrtc-extensions/issues/95