Closed Bug 1528078 Opened 9 months ago Closed 6 months ago

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

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox67 --- wontfix
firefox68 --- fixed

People

(Reporter: jib, Assigned: ng)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 1 obsolete file)

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

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

Flags: needinfo?(jib)
Assignee: nobody → na-g

Adding telemetry for gUM, enumerate devices, and mozRTCPeerConnection

(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.

Flags: needinfo?(jib)

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?

Flags: needinfo?(jib)

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?

Flags: needinfo?(jib)

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

Depends on: 1335740
No longer depends on: 1335740
See Also: → 1335740

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

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!)

Attachment #9061936 - Flags: data-review?(chutten)
Attached file Bug-1528078-data-collection-review.md (obsolete) —
Attachment #9061937 - Flags: data-review?(chutten)
Attachment #9061937 - Flags: data-review?(chutten)
Comment on attachment 9061937 [details]
Bug-1528078-data-collection-review.md

This was a duplicate post, obsoleting.
Attachment #9061937 - Attachment is obsolete: true
Comment on attachment 9061936 [details]
Bug-1528078-data-collection-review.md

Sharing the load with Tim.
Attachment #9061936 - Flags: data-review?(chutten) → data-review?(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.
Attachment #9061936 - Flags: data-review?(tdsmith) → data-review+

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?

Flags: needinfo?(tdsmith)

Nope; that's fine under the existing review.

Flags: needinfo?(tdsmith)
Pushed by na-g@nostrum.com:
https://hg.mozilla.org/integration/autoland/rev/25bc2e11f12f
Adding WebRTC device access and deprecated interface telemetry r=jib,smaug
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Regressions: 1553213
Blocks: 1561007
You need to log in before you can comment on or make changes to this bug.