1528078 - Add telemetry for getUserMedia/getDisplayMedia/enumerateDevices secure vs insecure vs legacy

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, enhancement, P2)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Our WEBRTC_GET_USER_MEDIA_SECURE_ORIGIN telemetry has expired. We should not renew it, since it used outdated https distinctions (e.g. https-iframe in http != secure).

Instead I propose we add new ones based on isSecureContext():

• WEBRTC_GET_USER_MEDIA_SECURE_CONTEXT
• WEBRTC_ENUMERATE_DEVICES_SECURE_CONTEXT

..maybe with different buckets for in-focus vs. background tab for bug 1397978.

Also some tracking to determine legacy usage would be prudent:

• WEBRTC_GET_USER_MEDIA_MEDIA_SOURCE
• WEBRTC_GET_DISPLAY_MEDIA_CONSTRAINTS

Comment 1

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Jan-Ivar, could you elaborate on what you are thinking for WEBRTC_GET_USER_MEDIA_MEDIA_SOURCE, and WEBRTC_GET_DISPLAY_MEDIA_CONSTRAINTS?

Comment 2

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: Bug 1528078 - Adding WebRTC device access and deprecated interface telemetry

Adding telemetry for gUM, enumerate devices, and mozRTCPeerConnection

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #0)

..maybe with different buckets for in-focus vs. background tab for bug 1397978.

See bug 1397978 comment 3 for context. We want to know whether the document HasFocus or not at the time of the request, for both getUserMedia() and enumerateDevices(), to count those impacted by that potential change to enumerateDevices(), as well as to count overall (ab)use of enumerateDevices() compared to valid uses in relation to getUserMedia().

In addition, I just realized it would be useful to know whether the request came from a cross-origin iframe or not as well, since we plan to turn on dom.security.featurePolicy.enabled in 68 it seems. I don't think we care about same-origin iframe, we can lump those in with non-iframe use. WDYT?

(In reply to Nico Grunbaum [:ng] from comment #1)

Jan-Ivar, could you elaborate on what you are thinking for WEBRTC_GET_USER_MEDIA_MEDIA_SOURCE, and WEBRTC_GET_DISPLAY_MEDIA_CONSTRAINTS?

The goal would be to detect usage of the legacy screen-share API we want to remove vs. adoption of its replacement.

The old (with choices):

navigator.mediaDevices.getUserMedia({video: {mediaSource: "screen"}});
navigator.mediaDevices.getUserMedia({video: {mediaSource: "window"}});
navigator.mediaDevices.getUserMedia({video: {mediaSource: "application"}});

We don't care about "browser" and "audio-capture" since these are behind pref. That said, from bug 1206900 it looks like WEBRTC_GET_USER_MEDIA_TYPE already covers this, so never mind!

The new:

navigator.mediaDevices.getDisplayMedia({video: constraintsOrTrue});
navigator.mediaDevices.getDisplayMedia({video: constraintsOrTrue, audio: constraintsOrTrue});

I think it would be useful to track pickup of the new replacement API to have something to compare against (combined numbers give total screen sharing requests).

Initially I thought we might as well split up the requests into buckets based on constraints used, but now I'm thinking that's not necessary and will only make counting harder, since there's no controlling for multiple constraints in the same request then.

It would however be useful to track requests for audio (which is entirely optional in getDisplayMedia) since Chrome has that.

Comment 4

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Jib, I am fine reordering the buckets as you suggested. I had to pick an order, and I went with 0 being the one we want to see go to 0. On second thought I think I would rather favor having bucket order be stable over time. Are some of those categories going to disappear, and thus should be MSB fields? For example, is there a point where this is all behind secure contexts and we don't want to even count those buckets?

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

For example, is there a point where this is all behind secure contexts and we don't want to even count those buckets?

Yes, the plan sometime post-bug 1335740 is to make everything secure context only. Were you thinking of making "insecure context" be 0x4?

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Should we just call them WEBRTC_GET_USER_MEDIA, WEBRTC_ENUMERATE_DEVICES, and WEBRTC_GET_DISPLAY_MEDIA?

Comment 7

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Jib, yeah I was thinking of making the security context the 3rd bit. Changing the names is good too.

Comment 8

[Chris H-C :chutten]

A quick reminder that new and changed Data Collections like these require Data Collection Review before landing. (You might already have been planning this. If so, well done!)

Comment 9

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: Bug-1528078-data-collection-review.md

Comment 10

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: Bug-1528078-data-collection-review.md

Comment 11

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Comment on attachment 9061937 [details]
Bug-1528078-data-collection-review.md

This was a duplicate post, obsoleting.

Comment 12

[Chris H-C :chutten]

Comment on attachment 9061936 [details]
Bug-1528078-data-collection-review.md

Sharing the load with Tim.

Comment 13

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

Comment on attachment 9061936 [details]
Bug-1528078-data-collection-review.md

data-review+; thank you!

--

1) Is there or will there be **documentation** that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes, in UseCounters.conf.

2) Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, the Firefox telemetry opt-out.

3) If the request is for permanent data collection, is there someone who will monitor the data over time?**

Yes, Jan-Ivar Bruaroey.

4) Using the **[category system of data types](https://wiki.mozilla.org/Firefox/Data_Collection)** on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1, technical data.

5) Is the data collection request for default-on or default-off?

Default-on.

6) Does the instrumentation include the addition of **any *new* identifiers** (whether anonymous or otherwise; e.g., username, random IDs, etc.  See the appendix for more details)?

No.

7) Is the data collection covered by the existing Firefox privacy notice?

Yes.

8) Does there need to be a check-in in the future to determine whether to renew the data? (Yes/No)

No, this is a permanent collection.

9) Does the data collection use a third-party collection tool?

No.

Comment 14

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Tim, a couple of the counters needed to be renamed from '*Background' to '*Unfocused'. Do I need to submit a revised data collection review doc, or can the data-review+ stand?

Comment 15

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

Nope; that's fine under the existing review.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/25bc2e11f12f
Adding WebRTC device access and deprecated interface telemetry r=jib,smaug

Comment 17

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/25bc2e11f12f