1364975 - Allow WebExtensions to disable WebRTC

Status: RESOLVED FIXED

(WebExtensions :: General, enhancement, P2)

Description

[Bob Silverberg [:bsilverberg]]

As there are already settings in the privacy API which deal with WebRTC, I think it makes sense to add this to the privacy.network namespace.

According to the notes in [1], this would make use of the `media.peerconnection.enabled`, which seems to be accurate looking at m-c code. That is a boolean, so this can be browser.privacy.network.webRTCEnabled.

[1] https://docs.google.com/document/d/1HZiI-dqFATzLpmTtN1Bg6tD8y4N0Ne3D74LEWWgttOk/edit#

Comment 1

[Bob Silverberg [:bsilverberg]]

Attachment: Bug 1364975 - Allow WebExtensions to disable WebRTC,

Implement privacy.network.webRTCEnabled to allow WebExtensions to enable and disable WebRTC.

Review commit: https://reviewboard.mozilla.org/r/142414/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/142414/

Comment 2

[Bob Silverberg [:bsilverberg]]

Comment on attachment 8870853 [details]
Bug 1364975 - Allow WebExtensions to disable WebRTC,

Byron, could you please take a look at this and confirm that if a WebExtension wants to be able to disable and enable WebRTC `media.peerconnection.enabled` is the correct preference to flip?

Comment 3

[Byron Campen [:bwc]]

Comment on attachment 8870853 [details]
Bug 1364975 - Allow WebExtensions to disable WebRTC,

Yeah, that's the pref you want.

Comment 4

[Andrew Swan [:aswan]]

Does this pref affect getUserMedia()?  Or is that considered not part of webrtc?

Comment 5

[Bob Silverberg [:bsilverberg]]

(In reply to Andrew Swan [:aswan] from comment #4)
> Does this pref affect getUserMedia()?  Or is that considered not part of
> webrtc?

My manual testing indicates that this does not affect getUserMedia(). I assume that getUserMedia has uses outside of WebRTC.

Comment 6

[Andrew Swan [:aswan]]

(In reply to Bob Silverberg [:bsilverberg] from comment #5)
> (In reply to Andrew Swan [:aswan] from comment #4)
> > Does this pref affect getUserMedia()?  Or is that considered not part of
> > webrtc?
> 
> My manual testing indicates that this does not affect getUserMedia(). I
> assume that getUserMedia has uses outside of WebRTC.

Does it?  I'm only familiar with it in the context of webrtc.  How about naming this something more specific to remove any possible confusion?  eg, PeerConnectionEnabled?

Comment 7

[Bob Silverberg [:bsilverberg]]

(In reply to Andrew Swan [:aswan] from comment #6)
> (In reply to Bob Silverberg [:bsilverberg] from comment #5)
> > (In reply to Andrew Swan [:aswan] from comment #4)
> > > Does this pref affect getUserMedia()?  Or is that considered not part of
> > > webrtc?
> > 
> > My manual testing indicates that this does not affect getUserMedia(). I
> > assume that getUserMedia has uses outside of WebRTC.
> 
> Does it?  I'm only familiar with it in the context of webrtc.  How about
> naming this something more specific to remove any possible confusion?  eg,
> PeerConnectionEnabled?

I think getUserMedia belongs to the Media Capture and Streams API, which is used by WebRTC, as documented on MDN [1]:

"WebRTC serves multiple purposes, and overlaps substantially with the Media Capture and Streams API. Together, they provide powerful multimedia capabilities to the Web..."

Because WebRTC is a term that is already used in the privacy API, and in fact is the term used by the requestor of this bug, I assumed it would be the best name for this setting, and less confusing that introducing a new term like "PeerConnection", but if you feel strongly about it I will change it to PeerConnectionEnabled.

[1] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API#WebRTC_concepts_and_usage

Comment 8

[Andrew Swan [:aswan]]

I was personally confused by this and the naming of the underlying preference together with the statement on MDN that the two "overlap substantially" all argue for using PeerConnection in the api visible to extensions.  But I think somebody with a deeper background in this area should weigh in.  I suggest :jib, who is familiar with both webrtc and webextensions.

Comment 9

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

It's confusing. Historically, I believe WebRTC started out as the term for getUserMedia, and ballooned into an umbrella term for both getUserMedia + RTCPeerConnection, as well as the name of the latter spec. It seems to be growing still, to include everything in mediacapture and webrtc, including extension specs like screensharing, MediaRecorder, ImageCapture and webrtc-stats [1]. As a result, it's hard to know what people mean when they use the term without context. The term is generally avoided in APIs for that reason.

In Gecko,
 - set both media.navigator.enabled=false and media.peerconnection.enabled=false to disable getUserMedia [2].
 - set just media.peerconnection.enabled=false to disable RTCPeerConnection alone.

It's not possible to disable gUM if RTCPeerConnection is enabled. gUM was the only possible source when that was written, though I'm actually not sure if that makes sense anymore, now that we have element and canvas captureStream and Web Audio.

It's not possible to disable MediaStream, MediaStreamTrack, MediaRecorder or the captureStream APIs.

[1] https://webrtc.github.io/samples/
[2] https://dxr.mozilla.org/mozilla-central/rev/39d5cc0fda5e16c49a59d29d4ca186a5534cc88b/dom/base/Navigator.cpp#1716-1717

Comment 10

[Andrew Swan [:aswan]]

I've lost of track of the original source of the request, but my vote is that we use PeerConnection in the name of the setting exposed to extensions, so that we avoid propagating confusion about exactly what the term "webrtc" encompasses.

Comment 11

[Bob Silverberg [:bsilverberg]]

(In reply to Andrew Swan [:aswan] from comment #10)
> I've lost of track of the original source of the request, but my vote is
> that we use PeerConnection in the name of the setting exposed to extensions,
> so that we avoid propagating confusion about exactly what the term "webrtc"
> encompasses.

Sounds good, and thanks for the info, jib.

Comment 12

[Bob Silverberg [:bsilverberg]]

Comment on attachment 8870853 [details]
Bug 1364975 - Allow WebExtensions to disable WebRTC,

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/142414/diff/1-2/

Comment 13

[Bob Silverberg [:bsilverberg]]

The patch has been updated with the name change.

Comment 14

[Andrew Swan [:aswan]]

Comment on attachment 8870853 [details]
Bug 1364975 - Allow WebExtensions to disable WebRTC,

https://reviewboard.mozilla.org/r/142414/#review148434

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e62d60b214d1
Allow WebExtensions to disable WebRTC, r=aswan

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e62d60b214d1

Comment 17

[Will Bamberg [:wbamberg]]

I've updated https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy/network

Please let me know if this covers it.

Comment 18

[Bob Silverberg [:bsilverberg]]

(In reply to Will Bamberg [:wbamberg] from comment #17)
> I've updated
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy/network
> 
> Please let me know if this covers it.

Looks good, thanks Will.

Comment 19

[Logan]

Sorry if I'm missing something, but I don't see the option for browser.privacy.network.peerConnectionEnabled in FF57.0a1 in about:config. Should I still be using media.peerconnection.enabled?

Comment 20

[Andy McKay]

browser.privacy.network.peerConnectionEnabled is an API, not preference in about:config, see https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy/network

Comment 21

[Logan]

(In reply to Andy McKay [:andym] from comment #20)
> browser.privacy.network.peerConnectionEnabled is an API, not preference in
> about:config, see
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy/network

Dumb question. Then I should be able to write the below?
var setting = browser.privacy.network.peerConnectionEnabled.set({
  value: "false"
});

Comment 22

[ChrisAntaki]

I tried running that code from a background script, and it led to this => "TypeError: browser.privacy is undefined"

Does the extension need more permissions than ["browserSettings"] ?

Comment 23

[Logan]

(In reply to ChrisAntaki from comment #22)
> I tried running that code from a background script, and it led to this =>
> "TypeError: browser.privacy is undefined"
> 
> Does the extension need more permissions than ["browserSettings"] ?

I got the same thing on Firefox nightly 57.0a1...

Comment 24

[Andy McKay]

The permission needed is "privacy". I can't see this on the MDN page, so flipping the dev-doc-needed flag:

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy
https://dxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/schemas/privacy.json#22

Comment 25

[ChrisAntaki]

Cool, adding the "privacy" permission works!

Would it make sense to expand on this sentence? "Note that WebExtensions does not give you access to the browser's own preferences (that is, the preferences exposed in the SDK by preferences/service)." (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Comparison_with_the_Add-on_SDK#Settings). After reading that, I had initially assumed that modifying the "peerConnectionEnabled" would no longer be possible.

Comment 26

[Will Bamberg [:wbamberg]]

I've updated https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy to include the permission.

> Would it make sense to expand on this sentence?

Yes! I've updated that to mention the "privacy" and "browserSettings" APIs.

Marking this as dev-doc-complete, again, but let me know if we need anything else.