Chromium sends UDP broadcasts every two minutes even if the media router extension is disabled.
_Solution: open chrome.dll in a hex editor, replace the only instance of 239.255.255.250 with 0.0.0.0 and save._
Chromium always launches the crash reporter processes even if Breakpad is disabled.
_Solution: open chrome.exe in a hex editor, replace the only instance of crashpad-handler with xyxyxyxy-handler and save._
I'm too lazy to check if this also occurs in the official Chromium.
_Thanks to anon for finding these_
I'm guessing these are hacks for the latest Windows binary?
I'm not sure if the crashpad-handler process is a bug or not from our side, but the UDP broadcasting deserves a look.
That's correct, they are tested on 66.0.3359.139-1 for Windows.
As for the UDP broadcasts, they persist even after disabling "Load Media Router Component Extension" and "Media Remoting during Cast Tab Mirroring" in chrome:flags and setting EnableMediaRouter to false via group policy. A comment on issue 665572 at bugs.chromium.org suggests just disabling Media Router should be enough to stop them, but it's from two years ago and I haven't checked this on an unmodified Chromium build.
The UDP broadcast of the media router is not limited to Windows and can be effectively disabled by creating a _managed_ policy setting for EnableMediaRouter, at least in Linux.
The state of the media router is set in chrome/browser/media/router/media_router_feature.cc:
bool MediaRouterEnabled(content::BrowserContext* context) {
#if defined(OS_ANDROID) || BUILDFLAG(ENABLE_EXTENSIONS)
const PrefService::Preference* pref = GetMediaRouterPref(context);
// Only use the pref value if it set from a mandatory policy.
if (pref->IsManaged() && !pref->IsDefaultValue()) {
bool allowed = false;
CHECK(pref->GetValue()->GetAsBoolean(&allowed));
return allowed;
}
// The component extension cannot be loaded in guest sessions.
// TODO(crbug.com/756243): Figure out why.
return !Profile::FromBrowserContext(context)->IsGuestSession();
#else // !(defined(OS_ANDROID) || BUILDFLAG(ENABLE_EXTENSIONS))
return false;
#endif // defined(OS_ANDROID) || BUILDFLAG(ENABLE_EXTENSIONS)
}
Under Windows I tried both this...
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Chromium]
"EnableMediaRouter"=dword:00000000
...and setting EnableMediaRouter to 0 by enabling the "Enable policy management page" experiment and going to chrome:policy-tool.
In both cases the change is acknowledged by about:policy, but the broadcasts continue anyway.
@2x9Mon Did you restart Chromium after setting the policy? I cannot reproduce it with Windows 10 and Ungoogled Chromium 67.0.3396.87. Does the chrome:policy page show a Mandatory level for the policy? Otherwise it won't have an effect.
This is the policy I used, same as yours:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Chromium]
"EnableMediaRouter"=dword:00000000
@xsmile ,
I did restart, and chrome:policy indeed says it's mandatory. My OS is Windows 7 x64 in case that helps.
Speaking of which, I'm guessing you compiled 67.0.3396.87 from source to run it under Windows 10? I'm running 66.0.3359.139-1 as that's the latest one I can find precompiled binaries for. Maybe this is fixed in version 67, making my bug report on this matter moot :)
@2x9Mon I used the binaries compiled by Wyse- at https://github.com/Eloston/ungoogled-chromium/issues/414#issuecomment-402553207.
@xsmile
Thanks for the link! I upgraded to that version and the broadcasts are now gone under the same profile and setup, without having to patch anything.
I took a little time to find out which of the countermeasures I'd tried actually does the trick. It seems the UDP traffic is gone if and only if EnableMediaRouter is set to 0 via group policy. The "official" solution of disabling "Load Media Router Component Extension" and "Media Remoting during Cast Tab Mirroring" via chrome:flags does nothing, and neither does using their corresponding command-line switches instead.
I guess this issue is only about the crash reporter processes now :)
I took a little time to find out which of the countermeasures I'd tried actually does the trick. It seems the UDP traffic is gone if and only if EnableMediaRouter is set to 0 via group policy.
Hmm, do the UDP broadcasts occur in the Linux and macOS builds as well? If so, I wonder what it is necessary to disable them. We could use that info to make a patch that makes it easier to disable these UDP broadcasts, if someone is inclined to do so.
I located 2 chromium files that seem to be related to broadcasting 239.255.255.250.
dial_service.cc
permissions_data_unittest.cc
Not really sure what could be done with these but thought this information could be helpful.
We need to add a patch for that main stream to fix it for all platforms
Given that there is an existing policy setting to disable media router, I'd rather have a CLI flag for this toggle than patch out this specific code within media router.
To fix this create a text file to /etc/chromium/policies/managed/policies.json
and here is what it should contain :
{
"EnableMediaRouter": false
}
just as example here are some additional settings
{
"EnableMediaRouter": false,
"DefaultWebUsbGuardSetting": 2,
"DefaultWebBluetoothGuardSetting": 2,
"NativeMessagingUserLevelHosts": false,
"WPADQuickCheckEnabled": false,
"BackgroundModeEnabled": false,
"DisablePluginFinder": true
}
@intika Would you be able to submit a PR for this to the User Resources page on the Wiki? Thanks.
Most helpful comment
I'm guessing these are hacks for the latest Windows binary?
I'm not sure if the crashpad-handler process is a bug or not from our side, but the UDP broadcasting deserves a look.