✨ Feature Suggestion | WebRTC info box / wiki / something near the VoIP section about profiles/users #1815

New Issue

2020-04-03T06:15:44Z

Mikaela commented

2020-04-03 06:15:44 +00:00

(Migrated from github.com)

Description

We are telling people to disable WebRTC, but not why and with the COVID-19 pandemic a lot of WebRTC based tools are popular.

I think we should have a infobox telling why to disable WebRTC or at least how to temporarily enable WebRTC.

To answer the latter question, I would mention:

firefox --ProfileManager and about:profiles and how creating a separate profile just for WebRTC (or to simplify it, JitsiMeet*
Chromium's users menu and adding a separate user for WebRTC.

When the user is using a different profile or user account, they are missing all the tweaks and extensions from their normal browser and thus WebRTC is more likely to work with less pain than unloading extensions and tweaking about:config.

I don't know how well known those features are, but they are how I handle WebRTC and also some people I presume technical have found them useful.

Heavily related: #1814 (at least in my mind)

## Description We are telling people to disable WebRTC, but not why and with the COVID-19 pandemic a lot of WebRTC based tools are popular. I think we should have a infobox telling *why to disable WebRTC* or at least *how to temporarily enable WebRTC*. To answer the latter question, I would mention: * `firefox --ProfileManager` and `about:profiles` and how creating a separate profile just for WebRTC (or to simplify it, JitsiMeet* * Chromium's users menu and adding a separate user for WebRTC. When the user is using a different profile or user account, they are missing all the tweaks and extensions from their normal browser and thus WebRTC is more likely to work with less pain than unloading extensions and tweaking `about:config`. I don't know how well known those features are, but they are how I handle WebRTC and also some people I presume technical have found them useful. Heavily related: #1814 (at least in my mind)

dngray commented

2020-04-03 06:53:06 +00:00

(Migrated from github.com)

I think this might be a good idea actually

lgrahl commented

2020-04-03 09:33:48 +00:00

(Migrated from github.com)

FYI, Chromium does not expose private IP addresses any more unless A/V permissions have been granted (which I think is a questionable move but that is another matter). They use mDNS to conceal private IP addresses.

For Firefox, this is still an open issue.

So, you can think of partially dropping this recommendation (if the exposed IP addresses were the only reason).

FYI, Chromium does [not expose private IP addresses any more](https://groups.google.com/forum/#!topic/discuss-webrtc/6stQXi72BEU) unless A/V permissions have been granted (which I think is a questionable move but that is another matter). They use mDNS to conceal private IP addresses. For Firefox, this is still an [open issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1544770). So, you can think of partially dropping this recommendation (if the exposed IP addresses were the only reason).

Mikaela commented

2020-04-03 09:55:39 +00:00

(Migrated from github.com)

We seem to already have a "related information" below VoIP, so maybe the WebRTC infobox could go there.

I think dropping the recommendation would be a separate issue and this infobox would still be necessary as there are extensions blocking WebRTC and I don't know what they are in my usual setup, but I think it may be something popular like PrivacyBadger or µMatrix.

They use mDNS to conceal private IP addresses.

Does this mean that they use hostname.local addresses and leak that identifiable bit of information?

We seem to already have a "related information" below VoIP, so maybe the WebRTC infobox could go there. I think dropping the recommendation would be a separate issue and this infobox would still be necessary as there are extensions blocking WebRTC and I don't know what they are in my usual setup, but I think it may be something popular like PrivacyBadger or µMatrix. > They use mDNS to conceal private IP addresses. Does this mean that they use `hostname.local` addresses and leak that identifiable bit of information?

lgrahl commented

2020-04-03 10:14:33 +00:00

(Migrated from github.com)

Does this mean that they use hostname.local addresses and leak that identifiable bit of information?

No, it is supposed to be a random UUID, so <UUID.local>. See https://github.com/rtcweb-wg/mdns-ice-candidates for details.

That being said, last time I fiddled around with it, there were some issues with it that can leak information about the whole private network. The related Chromium issue is currently not publicly visible, so I don't think they have fixed it, yet.

> Does this mean that they use hostname.local addresses and leak that identifiable bit of information? No, it is supposed to be a random UUID, so `<UUID.local>`. See https://github.com/rtcweb-wg/mdns-ice-candidates for details. That being said, last time I fiddled around with it, there were some issues with it that [can leak information about the whole private network](https://github.com/rtcweb-wg/mdns-ice-candidates/issues/121#issuecomment-582891964). The related Chromium issue is currently not publicly visible, so I don't think they have fixed it, yet.

👍 1

dngray commented

2020-04-04 05:52:57 +00:00

(Migrated from github.com)

I'm not sure we should be recommending people use Firefox with Jitsi because of https://github.com/privacytoolsIO/privacytools.io/issues/1814 hmm.

dngray commented

2020-04-27 03:36:31 +00:00

(Migrated from github.com)

I believe we can close this as we have a warning for Jitsi:

<span class="badge badge-warning"
      data-toggle="tooltip"
      title=""
      data-original-title="Our Firefox tweaks recommend disabling WebRTC as it can be used to leak your IP address even behind a VPN, which is why Tor Browser disables it.">
      Requires WebRTC
</span>

I believe we can close this as we have a warning for Jitsi: ```html <span class="badge badge-warning" data-toggle="tooltip" title="" data-original-title="Our Firefox tweaks recommend disabling WebRTC as it can be used to leak your IP address even behind a VPN, which is why Tor Browser disables it."> Requires WebRTC </span> ```

lgrahl commented

2020-04-28 08:39:52 +00:00

(Migrated from github.com)

Chromium does not expose private IP addresses any more unless A/V permissions have been granted (which I think is a questionable move but that is another matter). They use mDNS to conceal private IP addresses.

Thought you might be interested: This is now active in Firefox (75 but probably also in older versions), too. Try it yourself:

Open https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
Click "Gather Candidates"
You will only see your public IP and a couple of .local mDNS names with random UUIDs.

Personally, I believe there are further reasons why TOR disables WebRTC. The whole peer-to-peer concept is detrimental to their main use case. Even being able to see the public IP is undesirable in their case, so I don't think the description fits.

Anyway, if IP leaking was your only concern, you can consider dropping it.

> Chromium does [not expose private IP addresses any more](https://groups.google.com/forum/#!topic/discuss-webrtc/6stQXi72BEU) unless A/V permissions have been granted (which I think is a questionable move but that is another matter). They use mDNS to conceal private IP addresses. Thought you might be interested: This is now active in Firefox (75 but probably also in older versions), too. Try it yourself: 1. Open https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ 2. Click "Gather Candidates" 3. You will only see your public IP and a couple of `.local` mDNS names with random UUIDs. Personally, I believe there are further reasons why TOR disables WebRTC. The whole peer-to-peer concept is detrimental to their main use case. Even being able to see the public IP is undesirable in their case, so I don't think the description fits. Anyway, if IP leaking was your only concern, you can consider dropping it.

dngray commented

2020-04-29 08:40:55 +00:00

(Migrated from github.com)

Anyway, if IP leaking was your only concern, you can consider dropping it.

I think that was the main reason.

I checked this in 68.7ESR, and it does leak the IP, whereas you're right Firefox 75 does not. Debian has the ESR version in their repositories.

So maybe need to modify the warning. I tried it a few times and the UUID changed each time with Firefox 75.

I wonder if @Thorin-Oakenpants has anything to add about this? Should we even bother with the media.peerconnection.enabled setting or any of those, for 75+ (or whenever they added that

> Anyway, if IP leaking was your only concern, you can consider dropping it. I think that was the main reason. I checked this in 68.7ESR, and it does leak the IP, whereas you're right Firefox 75 does not. Debian has the ESR version in their repositories. So maybe need to modify the warning. I tried it a few times and the UUID changed each time with Firefox 75. I wonder if @Thorin-Oakenpants has anything to add about this? Should we even bother with the `media.peerconnection.enabled` setting or any of those, for 75+ (or whenever they added that

Thorin-Oakenpants commented

2020-04-30 10:16:09 +00:00

(Migrated from github.com)

Not my area of expertise - and there are other reasons, but I'd have to check, as to why WebRTC is disabled.

If you look in the diffs at ghacks user.js: there have been some WebRTC prefs and changes in core FF: I say recently, but that's subjective: but certainly since 68/ESR. One of which we Earthlng tried to bring to @gorhill 's attention in this comment, at the end

here's a couple

flipped in FF74
pref("media.peerconnection.ice.obfuscate_host_addresses", true); // prev: false

added in Ff70
pref("media.peerconnection.ice.proxy_only_if_behind_proxy", false)

Not my area of expertise - and there are other reasons, but I'd have to check, as to why WebRTC is disabled. If you look in the diffs at ghacks user.js: there have been some WebRTC prefs and changes in core FF: I say recently, but that's subjective: but certainly since 68/ESR. One of which ~~we~~ Earthlng tried to bring to @gorhill 's attention in [this comment, at the end](https://github.com/ghacksuserjs/ghacks-user.js/issues/805#issuecomment-557538162) --- here's a couple flipped in FF74 pref("media.peerconnection.ice.obfuscate_host_addresses", true); // prev: false added in Ff70 pref("media.peerconnection.ice.proxy_only_if_behind_proxy", false)

This repo is archived. You cannot comment on issues.