Since bug 1588817 enabled mDNS obfuscation, a visit of https://www.gog.com will trigger the Windows User Account Control prompt to access the private network (OS: Windows 8.1).

1. Install Firefox into a disk location where it hadn't been previously installed.
2. Create a new Firefox profile.
3. Launch the profile.
4. Open https://www.gog.com
5. Wait for the prompt to be shown (<5 seconds).

Dan, is this expected?

Could paste the screen-short?

ni aryx for comment 1

This is expected in that our implementation mDNS relies upon opening a port on the local network to send and receive mDNS packets. This might not be an issue for Chrome if they rely on the OS DNS resolver, but we wanted to be sure things would work on older versions of Windows which lack support for mDNS.

Currently, we start the mDNS resolver as soon as we gather a local IP address. Since this site doesn't appear to use WebRTC it is likely that they are gathering local IP addresses as part of tracking visitors. Getting this prompt on a site which doesn't appear to use WebRTC seems like something which would be unexpected for users.

One possibility would be start the mDNS resolver when we receive a remote IP address through JavaScript. In that case it is much more likely that we're about to set up a WebRTC connection. That change in timing might create connectivity problems for legitimate uses of WebRTC, so it would require some investigation.

Technically, this prompt is not a UAC dialog.

Do we have any data (e.g. from nightly or beta) about how often this dialog is shown? (Trying to figure out whether this should be a concern wrt shipping mdns address obfuscation in 72 in 2 weeks)

(In reply to Julien Cristau [:jcristau] (afk Dec 25-29) from comment #6)

Do we have any data (e.g. from nightly or beta) about how often this dialog is shown? (Trying to figure out whether this should be a concern wrt shipping mdns address obfuscation in 72 in 2 weeks)

We don't have any data. If Windows Firewall is enabled, it will show up the first time you visit a site that gathers local IP addresses through WebRTC. The change I suggested above would hopefully mean the dialog will not be shown until the user visits a site which uses data channels for legitimate purposes, which I expect would mean most users would never see it.

With the holiday season, I don't think I can get a fix for this landed in time for Firefox 72. I'll put together a patch to hold mDNS to Nightly in case we decide this is severe enough to not ship mDNS for 72.

Thanks Dan. Do you know if this is affecting Windows 10 users as well?
Without much data to support a decision, my initial reaction is to hold this feature from shipping in 72. We will need to make a decision on this next week.
Adding Maire to the bug as well for tracking.

(In reply to Adam Stevenson [:adamopenweb] from comment #8)

Thanks Dan. Do you know if this is affecting Windows 10 users as well?
Without much data to support a decision, my initial reaction is to hold this feature from shipping in 72. We will need to make a decision on this next week.
Adding Maire to the bug as well for tracking.

Yes, I can reproduce this on Windows 10 as well. I think it makes sense to hold off shipping this in Firefox 72. It would be a lot better if users only see the Firewall dialog if they are on a site where they expect to share a file.

We're going to disable obfuscation for 72 so tracking bug 1605861 instead of this one.

It looks like we can also detect if the Windows Firewall is running [1] and perhaps not start the mdns service in that case.

[1] https://docs.microsoft.com/en-us/windows/win32/api/wscapi/nf-wscapi-wscgetsecurityproviderhealth

Currently we register mDNS hostnames when we gather the local interfaces. By
waiting until StartIceChecks is called, it is less likely that we will end up
starting the mdns_service for a site which is not using WebRTC for
communication. This is more efficient, and avoids surprises like triggering
the Windows Firewall dialog for sites which are using WebRTC to gather local
IP addresses.

Depends on D59765

https://hg.mozilla.org/mozilla-central/rev/42d880c6ec1c
https://hg.mozilla.org/mozilla-central/rev/bebd7befedef

I tested this on my Windows 10 machine and it seems to be working fine, but it would be great if someone from QA could verify this just to be sure. STR are in comment 0. Thank you!

(In reply to Dan Minor [:dminor] from comment #16)

I tested this on my Windows 10 machine and it seems to be working fine, but it would be great if someone from QA could verify this just to be sure. STR are in comment 0. Thank you!

Yes, this issue was already on our radar, I've just finished the verification. I’ve reproduced this issue with the steps provided in bug descriptions with Fx 74 (2020-01-14) on Windows 10 x64. On the same platform, using today’s Nightly (2020-01-15), I no longer can triggered the Windows Firewall prompt using default or custom installation location. Verified fixed also on Windows 7 x32, macOS 10.15 and Ubuntu 18.04 x64.

Hi Adam, now that this is fixed, what would you like to do next?

We could request uplift to Beta and see if we can get this shipped with Firefox 73 or we could leave this on Firefox 74. We could add some new telemetry on this to evaluate the impact that this has in the wild. To add the telemetry and collect useful data would probably mean having to leave this on Firefox 74.

Like I mentioned in Comment 11, we could probably disable mDNS if we detect the windows firewall is running, so users would never see a dialog. That could have a negative impact on connectivity for legitimate uses of DataChannels, so we might want additional telemetry if we chose that route.

Thanks!

I think we should let it ride in 74 and evaluate the impact. With our shorter release cadence and all hands coming up, let's play it safe.

Interestingly, I was testing something using Chrome two weeks ago, and got a Windows Firewall Dialog asking me to allow Chrome access to a private network.