Bug #2696

Enable media.peerconnection.enabled

arder - about 1 year ago - . Updated 3 months ago.

% Done:



Is still necesary have 'media.peerconnection.enabled' disable?

I think mostly in this time of Covid19 the people needs to comunicate each to others and tool libre/free tools like are useful to do that and it require 'media.peerconnection.enabled=true' even the FSF used jitsi on the LibrePlanet 2020 and suggest use it

Related issues

Related to Packages - Bug #2767: [iceweasel] Jitsi Meet doesn't work in 1:75.0-1.parabola3fixed




Updated by oaken-source about 1 year ago

  • Status changed from unconfirmed to confirmed

We have actually been investigating why jitsi does not work on iceweasel. Are you certain that this setting is what causes the problem? As far as I know, jitsi will fall back to a classic client/server infrastructure when p2p is not available.

Have you verified that jitsi works once that setting is enabled?



Updated by arder about 1 year ago

Yes, I enabled that in 'about:config' and now the video calls works fine to me, with the option enable the video/audio can't be enable and didn't work, with the option enable you can see in the browser console that RTC.getCurrentlyAvailableMediaDevices() is not available and for that reason jitsi crash


Updated by oaken-source about 1 year ago

  • Assignee set to oaken-source
  • Status changed from confirmed to in progress

okay, thanks! I have enabled that setting in vendor.js and started a build.


Updated by grizzlyuser about 1 year ago

oaken-source -
AFAIK this preference is enabled by default, so it'd be better to just remove it from vendor.js if "true" value is desired for it.

Also please note there's another one related to peerconnection in vendor.js

I found the following description of these preferences, although it's not clear how actual it is:

As I understand, some users may rely on "media.peerconnection.enabled" set to "false" when they use VPN in order to not leak a local IP address.
I don't know if the preference actually helps with that, but it looks like if you're going to flip it, then it'd be a good idea to notify users about that, for example via News on the main Parabola webpage.

Also, uBlock Origin extension has a setting called "Prevent WebRTC from leaking local IP addresses", and the preferences it does change in about:config actually differ from the "media.peerconnection.enabled". So it's not clear which way is correct.


Updated by arder about 1 year ago

I think is fine leave "" as "true", according to adds a security level but keep the compatibility with WebRTC and allow use it, also have a beter explaot of that option


Updated by bill-auger about 1 year ago

up until a few versions ago, the webrtc code was compiled out with --disable-webrtc - i removed that switch when i noticed that i could not make webrtc calls with iceweasel - that itself was not sufficient, but it was the first step toward making it work - now i think this we have gotten it fully working - megver verified it yesterday that 'media.peerconnection.enabled' was the missing puzzle piece

the peerconnection protocol has privacy implications - it does leak your IP, for example; but so does every p2p communications software - p2p software can not function otherwise - if this were such a problem, we would need to blacklist jami, tox, retroshare, all bittorrent clients, tons of other stuff

webrtc is free software and the FSDG does not require disabling it, because it is not the classic "anti-feature" - it is a very desirable feature to some people for practical reasons, and undesirable to others for privacy reasons - but that is exactly why we have the privacy-enhanced repo - people with [nonprism] enabled should get a privacy-enhanced version of iceweasel, with webrtc disabled by default; and those with [nonprism] disabled should get the full-featured version

TLDR: anything related to extra privacy, that disables functionality which is FSDG-fit, and which could be configured in a nonprism package, should be - i have been assuming all along that the webrtc feature is in that class; and that once it was actually working, we could ensure that the 'hardened-preferences' package disabled it explicitly, if it does not already

if merely having the webrtc code compiled in, is an inherent privacy concern, then we would need to build a separate iceweasel for nonprism - IIRC, thats what we already do for icedove


Updated by Megver83 about 1 year ago

  • Related to Bug #2767: [iceweasel] Jitsi Meet doesn't work in 1:75.0-1.parabola3 added

Updated by bill-auger 3 months ago

  • Assignee changed from oaken-source to bill-auger

it is enabled - this ticket could have been closed long ago


Updated by bill-auger 3 months ago

  • Status changed from in progress to fixed

Also available in: Atom PDF