Ungoogled-chromium: Two minor complaints

Created on 11 Jul 2018  路  15Comments  路  Source: Eloston/ungoogled-chromium

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_

enhancement

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.

All 15 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ribatamu picture ribatamu  路  3Comments

dm17 picture dm17  路  3Comments

hrj picture hrj  路  3Comments

Chilcout picture Chilcout  路  3Comments

Eloston picture Eloston  路  4Comments