The stats API allow hardware fingerprinting (encoder, powerEfficient)

[henbos]

From #550:

decoderImplementation, the codec data point, etc. reveal information about the underlying hardware beyond what's identified by getUserMedia

For the codec issue, I filed #674 as a separate issue due to the tie with webrtc-pc.
In the most recent TPAC (yesterday) we talked about fingerprinting in the context of adding powerEfficientEncoder.
@youennf added to #550 after the meeting:

@henbos proposed during the meeting the possibility to only expose this kind of fingerprinting past some user validation (for instance if getUserMedia/getDisplayMedia was called successfully on the document).

Maybe there is a way to phrase it in a generic way, something like:
As this field is a fingerprinting vector, it MUST only be exposed to contexts that the user interacted with in a deep manner, for instance if https://w3c.github.io/mediacapture-main/#context-capturing-state returns true.

I like this way of phrasing it and think we should add this to encoderImplementation and decoderImplementation, as well as the recently proposed powerEfficientEncoder and powerEfficientDecoder (#666).

[henbos]

Relying on context-capture-state is not perfect but good enough to take us forward, and I like the phrase leaving the door open for other "deep user interactions". It resolves the immediate fingerprinting issue, though it does prevent exposure in some previously available use cases.

But if we have a good privacy baseline we could iterate and add other exposure triggers in the future if that becomes necessary.

[henbos]

@pes10k thoughts?

[pes10k]

I think the general approach is appealing, but i dont think "in a deep manner" is specific enough guidance for implementors. It would be ideal to just comprehensively mention when the field should be available and when it shouldn't

[henbos]

This particular vagueness was phrased by @youennf. Youenn what if we add a hardware mitigation algorithm section that we refer to, and for now we make it explicitly that you MUST have "context capture state = true". While this does not have any vagueness, we would have a go-to place in the spec if we want to add other steps in the future where it should also be allowed to expose a metric.

It would be nice if we could be in a state where we're over-protective instead of under-protective allowing more discussion when the time comes that we want to expose the metrics to more use cases.

I feel like we get stuck on trying to have something be perfect and then we don't progress. Better to be over-protective and revisit, I say, so we can unblock the PR.

[youennf]

Youenn what if we add a hardware mitigation algorithm section that we refer to, and for now we make it explicitly that you MUST have "context capture state = true".

This sounds good to me.

[henbos]

Done: #670