Is still necesary have 'media.peerconnection.enabled' disable? https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/vendor.js.in#n210
I think mostly in this time of Covid19 the people needs to comunicate each to others and tool libre/free tools like https://meet.jit.si 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 https://www.fsf.org/blogs/community/better-than-zoom-try-these-free-software-tools-for-staying-in-touch
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 grizzlyuser about 1 year ago
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 "media.peerconnection.ice.default_address_only" as "true", according to https://github.com/schomery/privacy-settings/issues/55#issuecomment-242300047 adds a security level but keep the compatibility with WebRTC and allow use it, also https://www.reddit.com/r/firefox/comments/8hjh3h/google_voice_psa_if_you_have_been_recently_having/dylurz4/ 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