Closed Bug 1364975 Opened 7 years ago Closed 7 years ago

Allow WebExtensions to disable WebRTC

Categories

(WebExtensions :: General, enhancement, P2)

enhancement

Tracking

(firefox55 fixed)

RESOLVED FIXED
mozilla55
Tracking Status
firefox55 --- fixed

People

(Reporter: bsilverberg, Assigned: bsilverberg)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, Whiteboard: triaged[privacy])

Attachments

(1 file)

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 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?
Attachment #8870853 - Flags: review?(docfaraday)
Comment on attachment 8870853 [details] Bug 1364975 - Allow WebExtensions to disable WebRTC, Yeah, that's the pref you want.
Attachment #8870853 - Flags: review?(docfaraday) → review+
Does this pref affect getUserMedia()? Or is that considered not part of webrtc?
(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.
(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?
(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
Flags: needinfo?(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.
Flags: needinfo?(aswan) → needinfo?(jib)
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
Flags: needinfo?(jib)
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.
(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.
The patch has been updated with the name change.
Attachment #8870853 - Flags: review?(aswan) → review+
Keywords: dev-doc-needed
Pushed by bsilverberg@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e62d60b214d1 Allow WebExtensions to disable WebRTC, r=aswan
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Flags: needinfo?(bob.silverberg)
(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.
Flags: needinfo?(bob.silverberg)
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?
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
(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" });
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"] ?
(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...
Flags: needinfo?(bob.silverberg)
Flags: needinfo?(bob.silverberg)
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.
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.
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: