oop's forgot to attache the screenshot, here we go.

Deleted: win10issue.png 234 KB

	win10issue.png 234 KB View Download

We need to resolve this ASAP as we're very close to Beta candidate cut.

to reproduce, you probably want to reset your firewall using "netsh firewall reset"

Note that the CL causing this has been reverted. Users still encounter the bug because the CL corrupted shortcuts, but the current tip of tree does NOT have this bug. We are working on an installer patch that will fix the broken shortcuts.

Hey fdoray@, this bug is on M50, the revert of the CL that caused this https://codereview.chromium.org/1666363002/ isn't in M50 branch 2661 yet, pls merge the revert into M50. Thanks!

Hmm... Branch 2661 was branched from revision 378081 and my CL is revision 378802. Also, I can't find any of the changes introduced by my CL in branch 2661. Because of that, I'm not able to revert my CL on branch 2661... Are you sure that my CL is in the M50 release branch / do you know what I might be doing wrong?

That's right, fdoray,rev 378802 shouldn't be in branch 2661. However, this bug is reported on 50.0.2661.11 - it could be a different issue or caused by a different CL? 

 pbommana@, this bug was reported for 50.0.2661.11. Can you please confirm that it repros on M50? 

re comment: 4 this is a different issue from the shortcut issue. In this case Chrome really is opening a listening port.

need to discover from someone - is this expected behavior that chrome will pop a firewall dialog, or is this a regression? I suppose I could do a bisect to find out.

+vitalybuka. Typically this dialog means that our mDNS listener is firing up. I'm so far unable to repro the dialog on my Win10 box, but I'll keep trying. This is unrelated to the canary bugaboo.

pbommana: could you copy-n-paste your Variations from chrome://version?

Please find the hashes below :
c175bf3c-3d47f4f4
16e0dd70-3f4a17df
b3888d8d-52a0c8a0
da89714-4ad60575
92fb4fc2-3f4a17df
e950616e-50896cf
7c1bc906-f55a7974
cf5ed6e1-73f2de3e
c1e6147b-4ad60575
f049a919-3f4a17df
775ebbd7-3f4a17df
31362330-3f4a17df
c70841c8-a2567007
f15c1c09-ca7d8d80
dd4da2fc-3f4a17df
93731dca-3f4a17df
9e5c75f1-d357b5f9
2c3080ba-ca7d8d80
64cbdfc2-ca7d8d80
f79cb77b-3f4a17df
89cd0b4b-ccd4c0fb
4ea303a6-18d729f
7aa46da5-669a04e0
9736de91-ca7d8d80
30e679f-ca7d8d80
ad6d27cc-3e870323
ca314179-3f4a17df
c8b9b12d-ca7d8d80
867c4c68-3d47f4f4
5e3f6590-ca7d8d80
6844d8aa-669a04e0
3ac60855-486e2a9c
ed1d377-e1cc0f14
75f0f0a0-a5822863
e7e71889-e1cc0f14
b39ea213-d1372334
6ab14220-3d47f4f4

I believe that this is ServiceDiscoveryClientMdns again. Something changed between M49 and M50. This used to not run if the firewall rules weren't in place. What has changed? Could someone bisect?

I tried and failed to bisect on a chromium build. Updating the status to try and purge the old dup issue...

Removed merged-into issue.

I think this is the relevant stack. local_discovery::ServiceDiscoveryClientMdns::StartNewClient is not hit at startup on M49, but is on M50.

00 0018d04c 6a9afe00 chrome_69490000!local_discovery::ServiceDiscoveryClientMdns::StartNewClient(void) [c:\b\build\slave\win\build\src\chrome\browser\local_discovery\service_discovery_client_mdns.cc @ 392]
01 0018d064 6a93c133 chrome_69490000!local_discovery::ServiceDiscoveryClientMdns::ServiceDiscoveryClientMdns(void)+0x7a [c:\b\build\slave\win\build\src\chrome\browser\local_discovery\service_discovery_client_mdns.cc @ 336]
02 0018d08c 6a794b3c chrome_69490000!local_discovery::ServiceDiscoverySharedClient::GetInstance(void)+0x78 [c:\b\build\slave\win\build\src\chrome\browser\local_discovery\service_discovery_shared_client.cc @ 95]
03 0018d0a4 6a76242f chrome_69490000!extensions::DnsSdRegistry::DnsSdRegistry(void)+0x36 [c:\b\build\slave\win\build\src\chrome\browser\extensions\api\mdns\dns_sd_registry.cc @ 111]
04 0018d0b8 6a7620d2 chrome_69490000!extensions::MDnsAPI::dns_sd_registry(void)+0x25 [c:\b\build\slave\win\build\src\chrome\browser\extensions\api\mdns\mdns_api.cc @ 81]
05 0018d1b8 6a761fd9 chrome_69490000!extensions::MDnsAPI::UpdateMDnsListeners(void)+0x6e [c:\b\build\slave\win\build\src\chrome\browser\extensions\api\mdns\mdns_api.cc @ 114]
06 0018d1c4 696f9e72 chrome_69490000!extensions::MDnsAPI::OnListenerRemoved(struct extensions::EventListenerInfo * details = 0x0018d1e8)+0x10 [c:\b\build\slave\win\build\src\chrome\browser\extensions\api\mdns\mdns_api.cc @ 90]
07 0018d29c 696f99a2 chrome_69490000!extensions::EventRouter::OnListenerAdded(class extensions::EventListener * listener = 0x05ffc168)+0x73 [c:\b\build\slave\win\build\src\extensions\browser\event_router.cc @ 256]
08 0018d2c8 6a694441 chrome_69490000!extensions::EventListenerMap::AddListener(class scoped_ptr<extensions::EventListener,std::default_delete<extensions::EventListener> > listener = class scoped_ptr<extensions::EventListener,std::default_delete<extensions::EventListener> >)+0xb0 [c:\b\build\slave\win\build\src\extensions\browser\event_listener_map.cc @ 111]
09 0018d2f0 696f1cc9 chrome_69490000!extensions::EventListenerMap::LoadFilteredLazyListeners(class std::basic_string<char,std::char_traits<char>,std::allocator<char> > * extension_id = 0x05fb9fbc, class base::DictionaryValue * filtered = <Value unavailable error>)+0x7e [c:\b\build\slave\win\build\src\extensions\browser\event_listener_map.cc @ 219]
0a 0018d310 696f103b chrome_69490000!extensions::EventRouter::OnExtensionLoaded(class content::BrowserContext * browser_context = 0x04e1ba60, class extensions::Extension * extension = 0x06616750)+0x5a [c:\b\build\slave\win\build\src\extensions\browser\event_router.cc @ 849]
0b 0018d338 696f05d6 chrome_69490000!extensions::ExtensionRegistry::TriggerOnLoaded(class extensions::Extension * extension = 0x06616750)+0x40 [c:\b\build\slave\win\build\src\extensions\browser\extension_registry.cc @ 56]
0c 0018d4d4 696ede68 chrome_69490000!ExtensionService::NotifyExtensionLoaded(class extensions::Extension * extension = 0x06616750)+0x265 [c:\b\build\slave\win\build\src\chrome\browser\extensions\extension_service.cc @ 1061]
0d 0018d518 69701a02 chrome_69490000!ExtensionService::AddExtension(class extensions::Extension * extension = 0x06616750)+0x2fb [c:\b\build\slave\win\build\src\chrome\browser\extensions\extension_service.cc @ 1521]
0e 0018d564 697014b3 chrome_69490000!extensions::InstalledLoader::Load(struct extensions::ExtensionInfo * info = 0x05f9daf8, bool write_to_prefs = false)+0x1d8 [c:\b\build\slave\win\build\src\chrome\browser\extensions\installed_loader.cc @ 236]
0f 0018da44 696ec194 chrome_69490000!extensions::InstalledLoader::LoadAllExtensions(void)+0x2c8 [c:\b\build\slave\win\build\src\chrome\browser\extensions\installed_loader.cc @ 296]
10 0018dab4 696c5d3b chrome_69490000!ExtensionService::Init(void)+0xbb [c:\b\build\slave\win\build\src\chrome\browser\extensions\extension_service.cc @ 428]
11 0018dec8 696c586b chrome_69490000!extensions::ExtensionSystemImpl::Shared::Init(bool extensions_enabled = true)+0x4b8 [c:\b\build\slave\win\build\src\chrome\browser\extensions\extension_system_impl.cc @ 217]
12 0018def8 696c56b8 chrome_69490000!extensions::ExtensionSystemImpl::InitForRegularProfile(bool extensions_enabled = true)+0x87 [c:\b\build\slave\win\build\src\chrome\browser\extensions\extension_system_impl.cc @ 325]
13 0018df70 696c5550 chrome_69490000!ProfileManager::DoFinalInitForServices(class Profile * profile = 0x04e1ba60, bool go_off_the_record = false)+0xc3 [c:\b\build\slave\win\build\src\chrome\browser\profiles\profile_manager.cc @ 1099]
14 0018dfd8 696c50ed chrome_69490000!ProfileManager::DoFinalInit(class Profile * profile = 0x04e1ba60, bool go_off_the_record = false)+0x93 [c:\b\build\slave\win\build\src\chrome\browser\profiles\profile_manager.cc @ 1059]
15 0018e054 696576a8 chrome_69490000!ProfileManager::AddProfile(class Profile * profile = 0x04e1ba60)+0xe4 [c:\b\build\slave\win\build\src\chrome\browser\profiles\profile_manager.cc @ 1251]
16 0018e0d0 6965752a chrome_69490000!ProfileManager::CreateAndInitializeProfile(class base::FilePath * profile_dir = 0x0018e1ec)+0xbb [c:\b\build\slave\win\build\src\chrome\browser\profiles\profile_manager.cc @ 1272]
17 0018e0f8 6965726a chrome_69490000!ProfileManager::GetProfile(class base::FilePath * profile_dir = 0x0018e1ec)+0x76 [c:\b\build\slave\win\build\src\chrome\browser\profiles\profile_manager.cc @ 400]
18 0018e208 6957eb62 chrome_69490000!`anonymous namespace'::CreatePrimaryProfile(struct content::MainFunctionParams * parameters = 0x00fe2224, class base::FilePath * user_data_dir = 0x00fe22dc, class base::CommandLine * parsed_command_line = 0x00fbd120)+0x198 [c:\b\build\slave\win\build\src\chrome\browser\chrome_browser_main.cc @ 395]
19 0018f65c 6957e419 chrome_69490000!ChromeBrowserMainParts::PreMainMessageLoopRunImpl(void)+0x709 [c:\b\build\slave\win\build\src\chrome\browser\chrome_browser_main.cc @ 1461]
1a 0018f6ac 6957e372 chrome_69490000!ChromeBrowserMainParts::PreMainMessageLoopRun(void)+0x8d [c:\b\build\slave\win\build\src\chrome\browser\chrome_browser_main.cc @ 1133]
1b 0018f700 694befb4 chrome_69490000!content::BrowserMainLoop::PreMainMessageLoopRun(void)+0xb7 

Why is this a user level install?

It's expected behavior for user level install for at least several year.

It doesn't matter weather it's User or system level I saw the issue, But in my case I was running Chrome user level installer test's hence the installation was User level.

Note : Just tried one more time reset your firewall using "netsh advfirewall reset" with system-level Chrome installation I still see the prompt.

Can you show me screenshot for system level one?

For user level we have no better solution then alert, as installer had not admin privileges.

Default install is system, and used by almost all users. System level install can edit rules and add exceptions for Chrome to avoid this alert.

Please find system level prompt as attachement and this was on Windows 10 32bit.

Deleted: Chromesystemlevel.png 1.4 MB

	Chromesystemlevel.png 1.4 MB View Download

Finally I got all the Finch hashes where I saw this issue, please find the finchhashes below :

c175bf3c-3d47f4f4
16e0dd70-3f4a17df
b3888d8d-ac4538a3
da89714-4ad60575
92fb4fc2-3f4a17df
e950616e-ee1ed1b4
7c1bc906-e919d5bc
cf5ed6e1-3f4a17df
c1e6147b-76cf6bae
f049a919-3f4a17df
775ebbd7-3f4a17df
31362330-3f4a17df
c70841c8-a2567007
f15c1c09-ca7d8d80
dd4da2fc-3f4a17df
93731dca-3f4a17df
9e5c75f1-f5d7252d
2c3080ba-ca7d8d80
64cbdfc2-ca7d8d80
f79cb77b-3f4a17df
89cd0b4b-51f0510c
4ea303a6-18d729f
7aa46da5-669a04e0
9736de91-ca7d8d80
30e679f-f23d1dea
ad6d27cc-7075cd8
ca314179-ca7d8d80
c8b9b12d-ca7d8d80
867c4c68-3d47f4f4
5e3f6590-5b0c9c46
6844d8aa-669a04e0
3ac60855-486e2a9c
ed1d377-e1cc0f14
75f0f0a0-6bdfffe7
e7e71889-e1cc0f14
b39ea213-d1372334
6ab14220-3d47f4f4


Note : I have been trying to reproduce the issue since this morning and wasn't able to reproduce, hence suspecting some finch trial has introduced this. I can force the windows alert prompt to show up if I run the command ""netsh advfirewall reset" and restart Chrome or Install Chrome.

According the stack alert is happening when extension os launched. So maybe inconsistency comes from there.

More reliable way to trigger mDns is to navigate to chrome://devices

I get the firewall popup on chrome://devices on every version of Chrome I can find (including Chrome stable) so I don't think it's that... seems like a more recent regression.

Oh, I got it.

If you run "netsh advfirewall reset" after chrome install, you just reset rules installer/updated set. So it's works as expected.

if no other way to reproduce the bug for system install, than everything works as expected. and issue can be closed

wfh@ system level install?

So acceptable reproducer must be in following order:

1. netsh advfirewall reset // never run again after that
2. system level chrome install
3. open chrome
4. navigate to chrome://devices
5. see alert

Firewall alerts are expected for user level install, local build or "netsh advfirewall reset".

Updated

1. netsh advfirewall reset // never run again after that
2. install chrome for system level
3. open chrome
4. navigate to chrome://devices
5. see alert

Firewall alerts are expected for user level install, local build or "netsh advfirewall reset" after install.

I followed the steps provided in Comment#37 and wasn't seeing the Windows Alert, tried both Chrome dev 64/32 bit versions system level on Windows 10 and 8.1. 

So I will wait for update from wfh@ and will close the bug if there is no correct reproducer.

BTW.
user level as admin should also avoid alert
alert itself creates new rule, so any installs after alert will see no alert.
So for fresh user level installs without admin (e.g. Canary or Stable from miniinstaler) alert is expected, but subsequent installations will have no alerts, as the first one already created a rule.
This behavior is known for a couple of years. 

It took quite a bit of digging, but I think the reason this is hard to repro is that it is due to the Media Router experiment: the Chrome Media Router extension is asking for mdns on canary and dev. With this extension, per-user Chrome will pop the firewall dialog out of the blue with no explanation for per-user installs. This is a pretty bad user experience.

Does this extension need to fire up mdns even if it isn't being used?

The Media Router extension does an initial round of discovery on startup. So grt@ I agree this might be what is causing the popup to appear. CC'ing mfoltz@ and skonig@.

Note that we haven't enable Media Router experiment on beta or stable yet.

Cloud Print also triggers mDNS discovery, so I'm unclear as to why this has suddenly become an issue.  Presumably even before Media Router, users who installed the Cast extension also would have seen this firewall dialog but we've never seen that happen, either.

In any event it would seem that Chrome's installer on Windows needs to set an appropriate firewall rule to allow mDNS traffic in order to avoid this message.  By chance was something done recently to remove that?

To respond to comment in #40: we do need to fire up mDNS because we need to detect if there are any Cast devices on your network, in order to show the Cast action to the user (or not).

skonig@ No, users didn't see alert before and they don't see it now (for default installations as system).

The only new thing here that "netsh advfirewall reset" was used after chrome install effectively resetting all rules added by installer.

I repro'd this on Win 10. It did not repro on Win 8.

Repro steps:
1. uninstall Chrome canary if you have it installed. (I also uninstalled other versions of Chrome I had installed)
2. ensure the firewall is enabled
3. reset firewall by entering $netsh advfirewall reset into an elevated command prompt
4. install Chrome canary

Actually confirmed repro on both Win 8 and 10. I spoke too soon in #45. A minute or two after the install on Win 8, the dialog appeared. 

dbbrooks@ Canary is not SYSTEM level install. We have alert for canary for about last two years, for print preview and chrome://devices. It's expected.

If you install Canary as admin, you should see no alert as well.

So IIUC, the alert only shows for user-level installs of Chrome, or any install of Chrome if you manually reset firewall rules?  And that this is consistent behavior going back a long time?

If so this doesn't seem like a regression at all but just a known issue.  Or is the issue that we're triggering the prompt under user-level installs of Chrome sooner b/c of Media Router? 

Assigning to skonig, changing component to Internals>Cast.

This is a recent thing that is different from what we've covered in the past. Per-user dev and all canary Chrome have started popping the firewall dialog at startup out of the blue. This is a result of the finch trial that enables the Media Router extension for dev and canary.

You can repro by deleting any chrome rules in "Windows Firewall with Advanced Security", deleting your User Data dir, then launching Chrome twice like this:

chrome.exe --force-fieldtrials=EnableMediaRouter/Enabled/

You will see the firewall prompt shortly after startup on the second launch. This should repro with any Google Chrome branded build (probably not Chromium builds).

Doing the same steps, but using --force-fieldtrials=EnableMediaRouter/Disabled/ allows you to launch Chrome until the cows come home with no complaints from Windows.

As Vitaly points out, we already install mDNS firewall rules for all per-machine installs. We cannot do this for per-user installs without requiring UAC somewhere.

I think it's a very bad user experience to pop a firewall dialog shortly after installing Chrome, or out of the blue when we enable Media Router for users. Bearing in mind that I have little awareness of what the Media Router extension is or does:

- Can we not do this Media Router thing by default on per-user installs (NN% of our population)?
- Can we ask users if they want the Media Router thing if they have a per-user install, and inform them that they will see a one-time firewall prompt from Windows that they can either accept or decline?
- Is the population of users interested in Media Router large enough that we want all Chrome users everywhere to carry the weight of the Media Router extension?

Please see these principles I wrote some time ago while pondering the possibilities: https://docs.google.com/a/chromium.org/document/d/13nUbcqPnnHrvtucGWkSkXooM4_CHYFPSwOBiKltdYT0/edit?usp=sharing.

+jschuh, someone else who is passionate about keeping Chrome awesome for our users.

Thanks.

To be clear this has nothing specific to do about Media Router, it's using existing mDNS functionality in Chrome that is already used by multiple features (Cloud Print among others).

The question is why MR is tickling it in a different way for user level installs that triggers the firewall prompt, or if there is a regression in the installer.

It seems like a user manually resetting firewall rules is a bit of a corner case, but I'm not familiar with data about how Chrome's user population manages their Windows firewall.

I agree we shouldn't be popping this dialog (i.e. should not be doing mDNS stuff) unless the user has triggered something to do this e.g. perhaps the first time they try and cast, or some other user initiated action.

Otherwise, the warning has no context, and it does not allow the user to make an informed decision about what action to take when the dialog presents itself.

+felt for security UX opinion on this...

mfoltz: As far as I can tell, the difference with Media Router is that it does its thing at startup. I am able to launch and use Chrome without seeing the firewall dialog when I force-disable MR, so somehow cloud print doesn't do mdns out of context.

So it sounds like the problem is not the dialog per se but the fact that it appears on startup with apparently no user action.

I guess I am wondering what would be a reasonable trigger from UX's point of view? Would the act of navigating to a site (e.g., YouTube) who would like to enable presentation be considered one?

I agree that showing this warning out of context is bad, however, the UX around the Presentation API is also bad without background discovery.

We could certainly wait to trigger it until the user clicked on"Cast..."
from the Hotdog menu or page context menu. It would introduce some
additional latency in populating the device list, but that's probably an
acceptable tradeoff.

The larger issue is that this approach would preclude sites like YouTube
from showing the Cast icon in the player, since the visibility of the icon
is determined by whether you have any devices you can cast to, and in order
to know that we have to discover.

If we also waited to try discovery until you navigated to a site like
YouTube, then the context for the firewall prompt would still be very
misleading.  It would look like YouTube itself is triggering it, even
though they have no direct control over this at all.  It's worse if you
think of sites like Netflix and people asking why Netflix is trying to scan
their local network.

Is it reasonable for users with per-user installs to see some sort of prompt like "allow websites to discover cast devices?" when they first visit a site that wants to probe for devices?

I'm removing RBS since the issue is with an experiment and not with a specific milestone.

OK I think I have a handle on this now after testing things locally.  My proposal is basically that for user installs of Chrome, we delay starting the mDNS listener until the user encounters MR in some way.  This should still allow sites like YT to work because DIAL will still work in discovering devices, even without mDNS.  Here's my proposed logic:

A) At launch time, before MR starts up the mDNS listener, check to see if Chrome is a user level install.  I believe that can be done here:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/chrome_browser_main_win.cc&q=CheckMachineLevelInstall&sq=package:chromium&type=cs&l=492

B) If not (i.e. Chrome is system install), start up the mDNS listener as per usual and we're done.

C) If we are a user-level install, check to see if the MR first run flow has been shown to the user.

D) If the FRF has been shown previously, start up the mDNS listener as per usual.

D) If the FRF has not been shown to the user previously, do not start up the mDNS listener but do start discovery via DIAL as per usual.

E) Once the user invokes the MR dialog for the first time (via Cast... menu or player icon) and the FRF is shown, start up mDNS listener.  This should trigger the firewall warning, -but- the warning is now contextual because the user has indicated intent to use another device.

I believe this will balance out the UX concerns around the firewall warning while keeping the basic functionality mostly intact, since we'll continue to discover via DIAL (which does not trigger any firewall warnings).  It's also broadly consistent with what happens today with the old Cast extension, which would trigger a firewall warning on user level installs the first time you installed it.

I agree with Stephen's general proposal (enable for system install always, and for user installs on first explicit Cast action by the user).

One question, though, are we certain that DIAL (SSDP) doesn't trigger the same prompt?  Is it possible that we're just seeing the mDNS listener trigger the prompt first?  I know Windows does have some special treatment of SSDP, so perhaps it does intentionally suppress the prompt that you'd otherwise expect for DIAL.

If I explicitly block mDNS but not SSDP, I don't get a firewall warning.  I
think that's because we initiate an SSDP request first, which makes it an
outbound versus inbound connection, and by default outbound connections are
allowed.  But admittedly, this probably requires some further testing.

You could check FirewallManager::CanUseLocalPorts (https://code.google.com/p/chromium/codesearch#chromium/src/chrome/installer/util/firewall_manager_win.h&q=file:firewall_manager_win%5C.h%20CanUseLocalPorts()&sq=package:chromium&type=cs&l=32), which is intended to mean "will the user not see a dialog if mDNS is used". This is likely better than "is this a per-user install of Chrome" since some users may have already passed through the firewall experience before getting the Media Router extension.

Sounds like a reasonable plan.  Two details:

- We probably need to handle the case where the FRF is not shown, but they would get the prompt again in step D) (because they denied permission, or reset their firewall rules).  How many times should we risk triggering the prompt?

- A tricky bit is that we need to decide whether to install the mDNS event handler in the first event loop of the event page, possibly before it can get a flag from the browser about the state of the firewall.  But we can likely figure out a way around that.

IIRC (Vitaly: please confirm), mDNS works properly regardless of how the user responds to the Windows firewall dialog. Definitely test it both ways to check for certain. It's been a long time, so I may be remembering wrong.

Re #61:
- FirewallManager is in chrome/installer/util - can Chrome.exe pull that code in itself?
- CanUseLocalPorts() just checks whether there are *any* rules for Chrome.exe, in the "advanced" impl. It doesn't seem to check e.g. what action the rules specify; is the idea that so long as there is an explicit rule, we know we won't trigger a prompt?  (In which case perhaps it should be WillUsingLocalPortsTriggerPrompts() ;)

Re #63:
- This sounds familiar; we discussed why we get prompts for mDNS but not for DIAL discovery, and one suggestion was that the use of bind() to a non-ephemeral port is interpreted by Windows Firewall as indicating that the port is to be used as a passive listener for incoming traffic, rather than to transmit outgoing traffic. That mDNS seems to work regardless of the firewall setting then makes sense - the prompt may only be preventing passive receipt of mDNS traffic, but when we actively transmit a discovery request the port is still (temporarily) pin-holed, allowing the response to be received.

>> FirewallManager is in chrome/installer/util - can Chrome.exe pull that code in itself?
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/local_discovery/service_discovery_shared_client.cc&q=CanUseLocalPorts&sq=package:chromium&type=cs&l=47

Re #63:
  That's correct, mDns can work in active mode even if user didn't respond to alert. If app needs to monitor devices on network, it will have to periodically send requests using chrome.mdns.forceDiscovery.

Re #61: yes, chrome.dll can safely use functions in chrome/installer/util.

Vitaly, could you comment on CanUseLocalPorts()?

Yes, CanUseLocalPorts was implemented to avoid alerts only. So rename into WillUsingLocalPortsTriggerPrompts sgtm.

Originally we used the function to check if we need to run from kind-of sandboxed network process. Windows can't show alert if it was triggered from "sandbox". We killed that code as sandbox with networking can be escaped easily. Now the function is used only for UMA counters.

Make sure to run the function from a file thread as it takes 0.5s on average.

You can use LocalDiscovery.IsFirewallReady from https://goo.gl/YEH1yL to get idea the scope of the problem. The bug is about users where LocalDiscovery.IsFirewallReady is reported as disabled.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/74d51922f5dc2516ce51cb49a36c0b4180ada30e

commit 74d51922f5dc2516ce51cb49a36c0b4180ada30e
Author: btolsch <btolsch@chromium.org>
Date: Tue Mar 29 08:35:50 2016

[Media Router] Conditionally enable mDNS on Windows.

This change enables mDNS on Windows only when the user is in a context related
to the Media Router. Previously, a firewall prompt could be triggered on browser
startup which is confusing.

BUG= 593167 
R=apacible@chromium.org,amp@chromium.org

Review URL: https://codereview.chromium.org/1821823002

Cr-Commit-Position: refs/heads/master@{#383689}

[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/android/router/media_router_android.cc
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/android/router/media_router_android.h
[add] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/media_route_provider_util_win.cc
[add] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/media_route_provider_util_win.h
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/media_router.gypi
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/media_router.h
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/media_router.mojom
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/media_router_metrics.h
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/media_router_mojo_impl.cc
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/media_router_mojo_impl.h
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/media_router_mojo_impl_unittest.cc
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/media_router_mojo_test.cc
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/media_router_mojo_test.h
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/mock_media_router.h
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/media/router/test_helper.h
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/chrome/browser/ui/webui/media_router/media_router_ui.cc
[modify] https://crrev.com/74d51922f5dc2516ce51cb49a36c0b4180ada30e/extensions/renderer/resources/media_router_bindings.js

Your change meets the bar and is auto-approved for M50 (branch: 2661)

Auto-assigning to take care of the merge.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a0651df3f75e0f21ab919d845a048029601ad230

commit a0651df3f75e0f21ab919d845a048029601ad230
Author: Wez <wez@chromium.org>
Date: Wed Mar 30 19:09:46 2016

[Media Router] Conditionally enable mDNS on Windows.

This change enables mDNS on Windows only when the user is in a context related
to the Media Router. Previously, a firewall prompt could be triggered on browser
startup which is confusing.

BUG= 593167 
R=apacible@chromium.org,amp@chromium.org

Review URL: https://codereview.chromium.org/1821823002

Cr-Commit-Position: refs/heads/master@{#383689}
(cherry picked from commit 74d51922f5dc2516ce51cb49a36c0b4180ada30e)

Review URL: https://codereview.chromium.org/1846673002 .

Cr-Commit-Position: refs/branch-heads/2661@{#433}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/android/router/media_router_android.cc
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/android/router/media_router_android.h
[add] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_route_provider_util_win.cc
[add] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_route_provider_util_win.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router.gypi
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router.mojom
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_metrics.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_mojo_impl.cc
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_mojo_impl.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_mojo_impl_unittest.cc
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_mojo_test.cc
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_mojo_test.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/mock_media_router.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/test_helper.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/ui/webui/media_router/media_router_ui.cc
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/extensions/renderer/resources/media_router_bindings.js

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a0651df3f75e0f21ab919d845a048029601ad230

commit a0651df3f75e0f21ab919d845a048029601ad230
Author: Wez <wez@chromium.org>
Date: Wed Mar 30 19:09:46 2016

[Media Router] Conditionally enable mDNS on Windows.

This change enables mDNS on Windows only when the user is in a context related
to the Media Router. Previously, a firewall prompt could be triggered on browser
startup which is confusing.

BUG= 593167 
R=apacible@chromium.org,amp@chromium.org

Review URL: https://codereview.chromium.org/1821823002

Cr-Commit-Position: refs/heads/master@{#383689}
(cherry picked from commit 74d51922f5dc2516ce51cb49a36c0b4180ada30e)

Review URL: https://codereview.chromium.org/1846673002 .

Cr-Commit-Position: refs/branch-heads/2661@{#433}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/android/router/media_router_android.cc
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/android/router/media_router_android.h
[add] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_route_provider_util_win.cc
[add] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_route_provider_util_win.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router.gypi
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router.mojom
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_metrics.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_mojo_impl.cc
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_mojo_impl.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_mojo_impl_unittest.cc
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_mojo_test.cc
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/media_router_mojo_test.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/mock_media_router.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/media/router/test_helper.h
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/chrome/browser/ui/webui/media_router/media_router_ui.cc
[modify] https://crrev.com/a0651df3f75e0f21ab919d845a048029601ad230/extensions/renderer/resources/media_router_bindings.js

I saw a security alert dialog this morning on 51.0.2689.0 canary. Not sure if same cause though.

The firewall dialog is still popping up for the "Chrome Media Router (Canary)" (pkedcjkdefgpdelpbcmbmeomcjbeemfm) extension when its DIAL listener is added (callstack below). Can this case be handled in a similar way to the mDNS case?

0:000:x86> k
 # ChildEBP RetAddr  
00 0033e83c 694273bb chrome_691a0000!extensions::DialAPI::OnListenerAdded [c:\b\build\slave\win\build\src\chrome\browser\extensions\api\dial\dial_api.cc @ 60]
01 0033e910 69426e8d chrome_691a0000!extensions::EventRouter::OnListenerAdded+0x74 [c:\b\build\slave\win\build\src\extensions\browser\event_router.cc @ 256]
02 0033e940 6941f297 chrome_691a0000!extensions::EventListenerMap::AddListener+0xbb [c:\b\build\slave\win\build\src\extensions\browser\event_listener_map.cc @ 111]
03 0033e954 6941f11d chrome_691a0000!extensions::EventListenerMap::LoadUnfilteredLazyListeners+0x37 [c:\b\build\slave\win\build\src\extensions\browser\event_listener_map.cc @ 205]
04 0033e974 6941e421 chrome_691a0000!extensions::EventRouter::OnExtensionLoaded+0x33 [c:\b\build\slave\win\build\src\extensions\browser\event_router.cc @ 847]
05 0033e99c 6941d9f6 chrome_691a0000!extensions::ExtensionRegistry::TriggerOnLoaded+0x40 [c:\b\build\slave\win\build\src\extensions\browser\extension_registry.cc @ 54]
06 0033eb40 6941b27b chrome_691a0000!ExtensionService::NotifyExtensionLoaded+0x271 [c:\b\build\slave\win\build\src\chrome\browser\extensions\extension_service.cc @ 1058]
07 0033eb84 6942f86a chrome_691a0000!ExtensionService::AddExtension+0x2fb [c:\b\build\slave\win\build\src\chrome\browser\extensions\extension_service.cc @ 1521]
08 0033ebd0 6942f2e5 chrome_691a0000!extensions::InstalledLoader::Load+0x1d5 [c:\b\build\slave\win\build\src\chrome\browser\extensions\installed_loader.cc @ 236]
09 0033ecb0 69419587 chrome_691a0000!extensions::InstalledLoader::LoadAllExtensions+0x292 [c:\b\build\slave\win\build\src\chrome\browser\extensions\installed_loader.cc @ 296]
0a 0033ed40 693fda76 chrome_691a0000!ExtensionService::Init+0xbd [c:\b\build\slave\win\build\src\chrome\browser\extensions\extension_service.cc @ 428]
0b 0033ef4c 693fd59b chrome_691a0000!extensions::ExtensionSystemImpl::Shared::Init+0x4c3 [c:\b\build\slave\win\build\src\chrome\browser\extensions\extension_system_impl.cc @ 233]
0c 0033ef7c 693fd3e8 chrome_691a0000!extensions::ExtensionSystemImpl::InitForRegularProfile+0x87 [c:\b\build\slave\win\build\src\chrome\browser\extensions\extension_system_impl.cc @ 346]
0d 0033eff4 693fd27c chrome_691a0000!ProfileManager::DoFinalInitForServices+0xc3 [c:\b\build\slave\win\build\src\chrome\browser\profiles\profile_manager.cc @ 1157]
0e 0033f05c 693fce18 chrome_691a0000!ProfileManager::DoFinalInit+0x93 [c:\b\build\slave\win\build\src\chrome\browser\profiles\profile_manager.cc @ 1115]
0f 0033f0d8 692be376 chrome_691a0000!ProfileManager::AddProfile+0xe4 [c:\b\build\slave\win\build\src\chrome\browser\profiles\profile_manager.cc @ 1309]
10 0033f154 692be0a7 chrome_691a0000!ProfileManager::CreateAndInitializeProfile+0xbb [c:\b\build\slave\win\build\src\chrome\browser\profiles\profile_manager.cc @ 1330]
11 0033f17c 692bddda chrome_691a0000!ProfileManager::GetProfile+0x76 [c:\b\build\slave\win\build\src\chrome\browser\profiles\profile_manager.cc @ 429]
12 0033f290 692a77e2 chrome_691a0000!`anonymous namespace'::CreatePrimaryProfile+0x192 [c:\b\build\slave\win\build\src\chrome\browser\chrome_browser_main.cc @ 401]
13 0033f7c4 692a708b chrome_691a0000!ChromeBrowserMainParts::PreMainMessageLoopRunImpl+0x717 [c:\b\build\slave\win\build\src\chrome\browser\chrome_browser_main.cc @ 1501]

Tried to verify the merge in the latest M-50(50.0.2661.66- 64 bit) on Windows-10 as per the following test steps:

1. Deleted chrome.exe from 'Control Panel\System and Security\Windows Firewall\Allowed apps' and the User Data dir.
2. Installed chrome version: 50.0.2661.66 and launched chrome from the terminal chrome.exe --force-fieldtrials=EnableMediaRouter/Enabled

Observed that the Windows security alert still pops up. Attached is the screenshot of the same.

btolsch@: Could you please confirm the fix and if anything above is being missed out in the repro steps.

Thanks in advance!

 

Deleted: 593167_50.0.2661.66.png 821 KB

	593167_50.0.2661.66.png 821 KB View Download

I just verified on 50.0.2661.66 with MR 5016.307.0.4 (staging version to be pushed to beta soon)

To verify:
1. run $netsh advfirewall reset
2. delete all files under Chrome's "User Data" dir
3. start Chrome with MR enabled 

The firewall prompt will not show up until the MR dialog is opened

I can't confirm that this is fixed. As grt@ mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=593167#c78 , discovery and thus firewall dialog is still triggered on startup due to extension adding mdns listener (see the stack in that comment).

This problem will of course not trigger if firewall manager has rule for allowing mdns in connection which is normally added by installer (I believe).

And that was with MR extension 5616.1017.0.0

Security>UX component is deprecated in favor of the Team-Security-UX label