Stats & isolated streams

[dontcallmedom]

While doing a first pass at a security review for WebRTC stats, I noticed the text on isolated media streams in WebRTC 1.0 leaves open the access to stats for them:

In particular, the statistics that RTCPeerConnection records are not reduced in capability. New statistics that might compromise isolation MUST be avoided, or explicitly suppressed for isolated streams.

It sounds like stats might leak a lot about isolated streams to the JavaScript layer, so @aboba suggested I raise an issue so that we look more closely into this.

[aboba]

@vr00m What do you think?

[vr000m]

Do we need a minimum set of stats that does not compromise the isolated stream and still helps with debugging issues? or we leave that to the implementors to pick?

[dontcallmedom]

I don't see why we should not leave it to implementors - this needs to be interoperable as far as I can tell.

[alvestrand]

@dontcallmedom one too many "not" in that sentence?

[dontcallmedom]

yes, I meant "I don't see why we should leave it to implementors" :)

[alvestrand]

So far, I know that volume leaks information. The fact that there is a call (and associated info such as IP addresses) doesn't seem to warrant different treatment for isolated vs non-isolated streams.
So what else in track stats should be treated differently, if anything?

[dontcallmedom]

This needs to address also CSRC and SSRC and isolated streams

[alvestrand]

Dan will take a look at his notes to try to reproduce consensus. @vr000m do you remember?

[stefhak]

From TPAC: https://www.w3.org/2017/11/06-webrtc-minutes.html#item18

[burnburn]

I confirmed in my notes that Harald was going to do a PR because there is not a blanket answer here across all types of stats.

[vr000m]

AFAICR, to do a PR to suggest not reporting stats that leak. IIRC: it was CSRC and volume.

[alvestrand]

Created w3c/webrtc-stats#352 to forbid reporting CSRC and audioHandler.audioLevel.