Warn users when uBlock Origin's WebRTC option is enabled

[0xf00f]

I have entered a room at hubs.mozzila.com, and invited a friend to join via the link and the friend has joined the room. We don't see each other's avatar, nor hear any sounds that we make.

It seems that we don't even see the same shared space. For example - I spawned several ducks and scattered them around the room, but they are not shown on the friend screen.

[cvan]

I experience this intermittently but relatively frequently. I notice that if I refresh the Hub room browser page and tell my friend(s) to do the same, we can then correctly see one another.

[brianpeiris]

Thanks for the report @0xf00f. Can you share what devices you were using and whether you were on a wifi or cellular network?

[0xf00f]

I made several tests.

Test 1: Two laptops. Both on the same wifi.

• client 1 is Firefox beta (manually downloaded) on Debian 9, used daily (several addons)
• client 2 is Firefox Portable (from portableapps.com) on Windows 10.
  Didn't work.
  I tried to reload client 1, few minutes after client 2 connected. Again didn't work.

Test 2: One laptop

• client 1 is Firefox beta (manually downloaded) on Debian 9, used daily (several addons)
• client 2 Google Chrome (clean profile used only for experiments)
  It didn't work
  Then, I kept the Google Chrome open and restarted Firefox with a clean profile, and this time it worked.

Test 3: One laptop

• client 1 is Firefox beta (manually downloaded) on Debian 9, used daily (several addons)
• client 2 is Firefox beta (manually downloaded) on Debian 9, clean profile - no addons
  Again it didn't work
  Then I refreshed the page on both of them as suggested by cvan. Again it didn't work.

Test 4: One laptop

• client 1 is Firefox beta (manually downloaded) on Debian 9, clean profile - no addons
• client 2 is Firefox Developer Edition beta (manually downloaded) on Debian 9, clean profile - no addons
  This time it worked on first try.

Test 5: One laptop

• i kept client 1 open
• i switched client 2 to Firefox beta (manually downloaded) on Debian 9, used daily (several addons)
  it didn't work.
  Then I refreshed the page on both of them as suggested by cvan. Again it didn't work.

Test 6: One laptop

• i kept client 1 open
• i switched client 2 back to Firefox Developer Edition beta (manually downloaded) on Debian 9, clean profile - no addons
  It worked.

Conclusion: It seems that the problem is in the Firefox profile I am using daily. Either some settings or some of the plugins.
I am seeing this error message in the console log:
ICE failed, add a TURN server and see about:webrtc for more details

I opened about:webrtc in the problematic firefox profile and I am seeing this:

`
insert 'ice' (registry) succeeded: ice
insert 'ice.pref' (registry) succeeded: ice.pref
insert 'ice.pref.type' (registry) succeeded: ice.pref.type
insert 'ice.pref.type.srv_rflx' (UCHAR) succeeded: 0x64
insert 'ice.pref.type.peer_rflx' (UCHAR) succeeded: 0x6e
insert 'ice.pref.type.host' (UCHAR) succeeded: 0x7e
insert 'ice.pref.type.relayed' (UCHAR) succeeded: 0x05
insert 'ice.pref.type.srv_rflx_tcp' (UCHAR) succeeded: 0x63
insert 'ice.pref.type.peer_rflx_tcp' (UCHAR) succeeded: 0x6d
insert 'ice.pref.type.host_tcp' (UCHAR) succeeded: 0x7d
insert 'ice.pref.type.relayed_tcp' (UCHAR) succeeded: 0x00
insert 'stun' (registry) succeeded: stun
insert 'stun.client' (registry) succeeded: stun.client
insert 'stun.client.maximum_transmits' (UINT4) succeeded: 7
insert 'ice.trickle_grace_period' (UINT4) succeeded: 5000
insert 'ice.tcp' (registry) succeeded: ice.tcp
insert 'ice.tcp.so_sock_count' (INT4) succeeded: 0
insert 'ice.tcp.listen_backlog' (INT4) succeeded: 10
insert 'ice.tcp.disable' (char) succeeded: \000
ICE(PC:1528242169085149 (id=32212254725 url=https://hubs.mozilla.com/02y4pizadmb/mammoth-appropriate-social)): Error parsing attribute: candidate:2 1 tcp 1015022079 52.53.219.72 0 typ host tcptype active
ICE(PC:1528242169085149 (id=32212254725 url=https://hubs.mozilla.com/02y4pizadmb/mammoth-appropriate-social)): peer (PC:1528242169085149 (id=32212254725 url=https://hubs.mozilla.com/02y4pizadmb/mammoth-appropriate-social):default) specified bogus candidate

SDP
Local SDP (Offer)

v=0
o=mozilla...THIS_IS_SDPARTA-61.0 6887349563479416396 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 5F:FB:0D:AE:18:10:6C:4C:1A:49:AB:5D:45:85:23:06:C3:DA:E3:6E:ED:6D:58:EF:3D:69:B9:65:40:CB:1A:20
a=group:BUNDLE sdparta_0
a=ice-options:trickle
a=msid-semantic:WMS *
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=sendrecv
a=end-of-candidates
a=ice-pwd:e3be292acf12ae0fd27c2c8cb7000931
a=ice-ufrag:df17ebc5
a=mid:sdparta_0
a=sctpmap:5000 webrtc-datachannel 256
a=setup:actpass
a=max-message-size:1073741823

Remote SDP (Answer)

v=0
o=mozilla...THIS_IS_SDPARTA-61.0 1528242170509954 1 IN IP4 52.53.219.72
s=-
t=0 0
a=sendrecv
a=group:BUNDLE sdparta_0
a=ice-lite
a=msid-semantic:WMS janus
m=application 9 DTLS/SCTP 5000
c=IN IP4 52.53.219.72
a=candidate:1 1 udp 2013266431 52.53.219.72 46652 typ host
a=candidate:2 1 tcp 1015022079 52.53.219.72 0 typ host tcptype active
a=candidate:3 1 tcp 1010827775 52.53.219.72 22652 typ host tcptype passive
a=sendrecv
a=end-of-candidates
a=fingerprint:sha-256 40:F7:B1:3D:F9:1E:04:B8:FF:5F:FF:5F:25:75:EB:C0:ED:F3:25:06:49:1F:AE:B4:E7:7A:BE:69:2F:DA:CA:B2
a=ice-options:trickle
a=ice-pwd:m2JFqKrAq1ePLCZWWLBlPx
a=ice-ufrag:h/PG
a=mid:sdparta_0
a=sctpmap:5000 webrtc-datachannel 16
a=setup:active
`

[brianpeiris]

Interesting. Thanks so much for doing all those tests. If you go to about:config and search for "tcp", do you have any non-default settings there?

I'm not sure why your particular Firefox profile would error out on the SDP's TCP line. Maybe @mquander has some ideas.

[0xf00f]

There are no non-default tcp settings in the browser profiles. The profiles are the same.

[mqp]

This is surprising, I'll try to understand why your Firefox doesn't like that ICE candidate.

I turned on ICE-TCP the other day in Janus because it seemed like a "free win" to support people who are behind firewalls that block UDP; if it turns out there are browser incompatibility problems I didn't know about, worst case is that I have to turn it back off.

[0xf00f]

After more testing I found out that the problem I am having is due to the uBlock Origin addon although - uBlock Origin says that it has blocked 0 requests. I have checked the logs and it seems that all requests are passed through. I have disabled the blocking on the site and the problem remained.

When I completely removed the uBlock Origin addon, the problem was solved.

[brianpeiris]

I haven't been able to reproduce this. Here's what I tried:

One laptop:

• client 1 is Firefox stable on Windows, clean profile with uBlock Origin installed
• client 2 is Firefox Developer Edition on Windows, clean profile, no addons.

I was able to see avatars as expected.

If possible, could you try with a fresh profile and uBlock Origin installed? I wonder if there's something about the way you've configured uBlock.

[0xf00f]

Reset to default settings of the uBlock Origin addon solved the issue.
Then enabling "Prevent WebRTC from leaking local IP addresses" setting introduced the problem once again.

Test done with a single laptop, running Debian testing and same Firefox 61.0 installed manually from beta channel

• client 1 is profile used daily - prevent webrtc activated/deactived here
• client 2 - completely clean profile

[mqp]

Oh, wow, I should have thought of that. I know a lot of people use settings like that. It should probably be one of our first troubleshooting steps in the future.

I will think about whether we can detect this and provide some error feedback that will give people the right idea.

[brianpeiris]

Yup, confirmed that the uBlock option breaks Hubs on windows as well. Thanks for testing @0xf00f.
According to uBlock's wiki, this option effectively disables WebRTC entirely in Firefox. I agree we should display an appropriate error if WebRTC breaks, but I'm not sure if we need to detect/inform users about uBlock specifically.

https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-leaking-local-IP-address#firefox

[misslivirose]

I did a test today on this quickly and I wasn't able to repro so I'm going to close this until we get additional confirmation of a more recent use case, just given the age of this issue and the number of updates that have happened in the meantime.

[0xf00f]

I did a test again right now - uBlock Origin was enabled and the option Prevent WebRTC leaking ip address was enabled, and I did not encounter the original issue.