Privacy & Security self review

[dontcallmedom]

It would be good to review the document through the privacy & security questionnaire - this would in particular help for the wide review of the document pre-CR.

[hadleybeeman]

Hello! I'm sure this will come up in your self-review, but I'd be interested in hearing your thoughts on if/how you think this feature might expand the fingerprinting surface area for identifying a browser/user.

(Whenever you're ready to address this. No rush here!)

[alvestrand]

There's a few words in https://w3c.github.io/webrtc-stats/#security-considerations (calling out IP addresses as a consideration). There are other attributes that will expand fingerprinting surface (such as codec implementation strings). I don't see how much mitigation we can do here, either - these stats are all needed for operation of services.

[hadleybeeman]

Thanks for the quick response, @alvestrand! We will look forward to seeing more detail in your response to the privacy and security questionnaire. We are interested in things like whether the latency exposed by roundTripTime in RTCOutboundRTPStreamStats or RTCIceCandidatePairStats might expose something about the user's distance from the server (and therefore, where in the world they are).

We do understand that mitigations can be tricky. It might be helpful to have different levels of statistics based on the privacy invasiveness... for example, the media-layers stats might be different to the transport-layer stats? Where mitigation isn't possible, exposing all the unmitigated threats in the spec will help implementers make informed decisions about how to present them to users.

[hadleybeeman]

Hi all — we are meeting again and checking on the progress of things. How is this going? Can we help at all?

[hadleybeeman]

@dontcallmedom Hello! We're just looking at this in our TAG review. It seems that no one is assigned to it... should there be someone? We're not sure who to work with. Thanks for any help. :)

[dontcallmedom]

the chairs, editors and I plan on getting a first stab at the self review in the upcoming few weeks

[hadleybeeman]

That's great, @dontcallmedom. Thanks for the quick reply! We'll check in with you after that then.

[dontcallmedom]

Here is a first stab at reviewing the spec through the questionnaire for discussion tomorrow with @vr000m and @aboba.

I think the relevant questions in the questionnaire for this spec are:

• personally identifiable information
• persistent state
• cross-origin perstatent state
• access to new data
• new exposure on local device configuration?
• temporary identifiers? (aplenty)
• 1st vs 3rd party? (exploitability by ads?)
• incognito mode?

(from my review the others are orthogonal to WebRTC stats).

In analyzing which data might expose new state, and in particular potential new cross-origin state, we should distinguish:

• data that is already exposed in WebRTC 1.0 (for which we should indicate similar fingerprinting concerns and invite similar mitigations)
• data that is uniquely exposed by WebRTC stats

One way also to think of the overall question is to look at 2 questions:

• whether and how can WebRTC stats be used to fingerprint the user in absence of an actual WebRTC session?
• what can an adversary learn on the user's device once a connection is established? is there a difference between a audio-video session vs a simple data channel session from that perspective?

Some more random notes on possible specific concerns:

• how closely have we looked at the impact of isolated media streams on WebRTC Stats? WebRTC 1.0 has some high level guidance on the topic, but it's unclear to me whether it has been applied in practice to this spec. Also, it feels like a lot of data on the media content may leak through stats
• we're exposing both local and remote ntp clocks - I vaguely remember some concerns about that in other specs

[dontcallmedom]

here is my stab at filling the questionnaire and completing the security section based on it: #251

[alvestrand]

Closed by #251