Closed
Bug 1364975
Opened 7 years ago
Closed 7 years ago
Allow WebExtensions to disable WebRTC
Categories
(WebExtensions :: General, enhancement, P2)
WebExtensions
General
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 hidden (mozreview-request) |
Assignee | ||
Comment 2•7 years ago
|
||
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 3•7 years ago
|
||
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+
Comment 4•7 years ago
|
||
Does this pref affect getUserMedia()? Or is that considered not part of webrtc?
Assignee | ||
Comment 5•7 years ago
|
||
(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•7 years ago
|
||
(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?
Assignee | ||
Comment 7•7 years ago
|
||
(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)
Comment 8•7 years ago
|
||
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)
Comment 9•7 years ago
|
||
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)
Comment 10•7 years ago
|
||
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.
Assignee | ||
Comment 11•7 years ago
|
||
(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 hidden (mozreview-request) |
Assignee | ||
Comment 13•7 years ago
|
||
The patch has been updated with the name change.
Comment 14•7 years ago
|
||
mozreview-review |
Comment on attachment 8870853 [details]
Bug 1364975 - Allow WebExtensions to disable WebRTC,
https://reviewboard.mozilla.org/r/142414/#review148434
Attachment #8870853 -
Flags: review?(aswan) → review+
Assignee | ||
Updated•7 years ago
|
Keywords: dev-doc-needed
Comment 15•7 years ago
|
||
Pushed by bsilverberg@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e62d60b214d1
Allow WebExtensions to disable WebRTC, r=aswan
Comment 16•7 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox55:
--- → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Comment 17•7 years ago
|
||
I've updated https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy/network
Please let me know if this covers it.
Flags: needinfo?(bob.silverberg)
Assignee | ||
Comment 18•7 years ago
|
||
(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)
Updated•7 years ago
|
Keywords: dev-doc-needed → dev-doc-complete
Comment 19•7 years ago
|
||
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•7 years ago
|
||
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•7 years ago
|
||
(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•7 years ago
|
||
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•7 years ago
|
||
(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)
Comment 24•7 years ago
|
||
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
Flags: needinfo?(bob.silverberg)
Keywords: dev-doc-complete → dev-doc-needed
Comment 25•7 years ago
|
||
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•7 years ago
|
||
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.
Keywords: dev-doc-needed → dev-doc-complete
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•