Fingerprinting section could be improved

[youennf]

The specification has a privacy section which mentions issues like fingerprinting based on capabilities and identifying underlying codecs. The specification does not provide much guidelines for mitigations except to piggy-back on a 'privacy budget' which is not really specified. It seems additional efforts and thoughts could be put on fingerprinting removal/mitigation strategies.

Also the spec says that: 'Much of this profile is already exposed by existing APIs'. This is not really true. For instance we are trying to remove leaks from WebRTC specs (see https://github.com/w3c/webrtc-stats/issues/550 for instance) and some implementations do not expose values for that very reason. WebCodec is also currently exposing hardware/software which is not exposed in Media Capabilities (powerEfficient != hardware acceleration).

There are other potential fingerprinting issues that should probably be described and discussed:

• Timing information might further allow identify user behavior (side channel information, especially with SW codecs)
• A web page in the background might be able from time to time to try encoding/decoding video and see whether it can get access to hardware codecs. If it is not able to get hardware capabilities, it might mean the user is in a call.
• If encoders/decoders use buffer pools with a max size, retaining video samples might allow getting that information which might be hardware/OS specific

It would be desirable for the spec to exhaustively list fingerprinting issues and potential mitigations. It would be desirable to set some goals on what to achieve in terms of fingerprinting. Neutral would be great. It would for instance be desirable to be able to implement this API with the necessary mitigations so that this API does not help differentiating devices like Mac mini vs. MacPro vs. MacBookPro.

[youennf]

Some specs do use markup to identify potential fingerprinting, for instance https://www.w3.org/TR/webrtc-stats/#dom-rtcinboundrtpstreamstats-decoderimplementation

[chcunningham]

Some of these are covered in separate issues filed after our recent discussion w/ PING

• privacy budget, we resolved to add in simpler mitigations like returning a ~common baseline of capabilities. tracked in https://github.com/w3c/webcodecs/issues/233
• timing attacks, tracked in https://github.com/w3c/webcodecs/issues/234

@youennf, for the issues that are not covered, can you open separate sub issues? This helps to have more focused discussions.

Also the spec says that: 'Much of this profile is already exposed by existing APIs'. This is not really true. For instance we are trying to remove leaks from WebRTC specs (see w3c/webrtc-stats#550 for instance) and some implementations do not expose values for that very reason. WebCodec is also currently exposing hardware/software which is not exposed in Media Capabilities (powerEfficient != hardware acceleration).

I is not my intent to convey that WebCodecs introduces nothing new, but I think its important to highlight new vs overlap. If other APIs change to not overlap we can update the text (seems early at this point). For MC, in practice powerEfficient will often = hardware accelerated and it is easy enough for an attacker to understand where that will be true on a per implementation basis.

It would be desirable for the spec to exhaustively list fingerprinting issues and potential mitigations.

Happy to do so. My intent with the existing text was to cover everything I had identified so far.

It would for instance be desirable to be able to implement this API with the necessary mitigations so that this API does not help differentiating devices like Mac mini vs. MacPro vs. MacBookPro.

The mitigation mentioned at the top should go along way here. That is: expose a common baseline set of capabilities. For separate concerns (e.g. timing attacks), lets discuss in their separate issues.

[chcunningham]

Triage note: marking 'editorial', as this requests additions to privacy considerations. Note: As mentioned above, I still think this should probably be split into sub issues.