Disable WebRTC in Chromium

[craftyguy]

WebRTC is enabled in Chromium distributed by CopperheadOS, is it possible to disable it outright, or at least expose the flag to do so?

[thestinger]

It won't be outright disabled and chrome://flags won't be changed because it's not really meant for use by end users. It could be exposed as a site option. Why single out WebRTC among all of the features that are available though? Do you really want a way to turn off the portion of the feature leaking local IP addresses? That part could be disabled by default, but not the whole feature. We aren't going to remove useful features rather than making them opt-in if they aren't important or opt-out if they are, and WebRTC as a whole is definitely important.

[thestinger]

It won't be outright disabled and chrome://flags won't be changed because it's not really meant for use by end users. It could be exposed as a site option. Why single out WebRTC among all of the features that are available though? Do you really want a way to turn off the portion of the feature leaking local IP addresses? That part could be disabled by default, but not the whole feature. We aren't going to remove useful features rather than making them opt-in if they aren't important or opt-out if they are, and WebRTC as a whole is definitely important.

[craftyguy]

Rather than argue the importance (or not) of webrtc, I think having the leaking of local IP addresses disabled is a start.

[craftyguy]

Rather than argue the importance (or not) of webrtc, I think having the leaking of local IP addresses disabled is a start.

[CopperheadUser]

+1, definitly security-breach "feature".

[CopperheadUser]

+1, definitly security-breach "feature".

[kewde]

Chromium has a flag you can set, namely chrome.privacy.network.webRTCIPHandlingPolicy.
It is supposed to be default_public_interface_only to prevent WebRTC from contacting local addresses. I think this should be the default setting.

But it can also be set to another value
disable_non_proxied_udp - disables non-proxied UDP and forces proxy. This policy forces the use of a proxy, and only allows WebRTC traffic over UDP proxies. This will effectively disable WebRTC communication for most users (depending on UDP proxy usage).

I suppose the UI needs a toggle to switch between the two if it does not yet provide this option?

[kewde]

Chromium has a flag you can set, namely chrome.privacy.network.webRTCIPHandlingPolicy.
It is supposed to be default_public_interface_only to prevent WebRTC from contacting local addresses. I think this should be the default setting.

But it can also be set to another value
disable_non_proxied_udp - disables non-proxied UDP and forces proxy. This policy forces the use of a proxy, and only allows WebRTC traffic over UDP proxies. This will effectively disable WebRTC communication for most users (depending on UDP proxy usage).

I suppose the UI needs a toggle to switch between the two if it does not yet provide this option?

[thestinger]

Need a way to control this in the Privacy menu and then the default can be changed for Chromium. WebView will be more of a hassle to deal with if it is.

[thestinger]

Need a way to control this in the Privacy menu and then the default can be changed for Chromium. WebView will be more of a hassle to deal with if it is.

[kewde]

@thestinger has chrome become the default webview for Android in 7.0?

[kewde]

@thestinger has chrome become the default webview for Android in 7.0?

[thestinger]

CopperheadOS has a build of SystemWebView.apk and ChromeModernPublic.apk from the Chromium source tree. The WebView is always a separate app, even when using Monochrome. Not sure how Monochrome is relevant to this though.

[thestinger]

CopperheadOS has a build of SystemWebView.apk and ChromeModernPublic.apk from the Chromium source tree. The WebView is always a separate app, even when using Monochrome. Not sure how Monochrome is relevant to this though.

[kewde]

@thestinger I read that the chrome apk can act as WebView?
http://gadgets.ndtv.com/apps/news/google-chrome-to-replace-webview-in-android-70-nougat-863667

I'm not sure where to look, does Chromium power the WebView? Or is it seperate?

[kewde]

@thestinger I read that the chrome apk can act as WebView?
http://gadgets.ndtv.com/apps/news/google-chrome-to-replace-webview-in-android-70-nougat-863667

I'm not sure where to look, does Chromium power the WebView? Or is it seperate?

[thestinger]

This is all you need to know:

CopperheadOS has a build of SystemWebView.apk and ChromeModernPublic.apk from the Chromium source tree.

CopperheadOS doesn't have Chrome, which is Monochrome.apk not ChromeModern.apk with a separate SystemWebVIew.apk anymore. Either way, they always run as separate apps and they are built from the same source tree. Those two things are always true, and those are the only things relevant to this issue. It doesn't matter which packaging format is used (split vs. monolithic).

[thestinger]

This is all you need to know:

CopperheadOS has a build of SystemWebView.apk and ChromeModernPublic.apk from the Chromium source tree.

CopperheadOS doesn't have Chrome, which is Monochrome.apk not ChromeModern.apk with a separate SystemWebVIew.apk anymore. Either way, they always run as separate apps and they are built from the same source tree. Those two things are always true, and those are the only things relevant to this issue. It doesn't matter which packaging format is used (split vs. monolithic).

[thestinger]

Replacing this with #529 since it's not going to be disabled. It would probably only take 15 lines of code to implement this. Maybe someone is interested in contributing, otherwise it won't be added.

[thestinger]

Replacing this with #529 since it's not going to be disabled. It would probably only take 15 lines of code to implement this. Maybe someone is interested in contributing, otherwise it won't be added.

[craftyguy]

Any guidance on how to build and test without doing a custom COS build, signing, etc? My understanding is that i can't test a debug chromium build i modified on my COS device because of the mismatch in signing. Pardon my ignorance, I would like to help.

…

On December 14, 2016 9:46:34 PM PST, Daniel Micay ***@***.***> wrote: Replacing this with #529 since it's not going to be disabled. It would probably only take 15 lines of code to implement this. Maybe someone is interested in contributing, otherwise it won't be added. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #521 (comment)

[craftyguy]

Any guidance on how to build and test without doing a custom COS build, signing, etc? My understanding is that i can't test a debug chromium build i modified on my COS device because of the mismatch in signing. Pardon my ignorance, I would like to help.

…

On December 14, 2016 9:46:34 PM PST, Daniel Micay ***@***.***> wrote: Replacing this with #529 since it's not going to be disabled. It would probably only take 15 lines of code to implement this. Maybe someone is interested in contributing, otherwise it won't be added. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #521 (comment)

[thestinger]

In chrome/android/BUILD.gn, change the package id:

manifest_package = "org.chromium.chrome"

[thestinger]

In chrome/android/BUILD.gn, change the package id:

manifest_package = "org.chromium.chrome"

[thestinger]

The key to doing it is just copying one of the other preferences (preference bridge stuff, UI code, etc. - mostly just boilerplate). Starting with 2 just the two states exposed by uBlock Origin would be fine. Can expose the full functionality later, or not at all if no one really wants it.

[thestinger]

The key to doing it is just copying one of the other preferences (preference bridge stuff, UI code, etc. - mostly just boilerplate). Starting with 2 just the two states exposed by uBlock Origin would be fine. Can expose the full functionality later, or not at all if no one really wants it.

[thestinger]

I'd also be fine with doing attack surface reduction via Site settings by adding options for WebGL, WebRTC, etc. but #512 is a hard prerequisite and it's not going to be easy to implement or maintain it so it really needs to happen upstream.

[thestinger]

I'd also be fine with doing attack surface reduction via Site settings by adding options for WebGL, WebRTC, etc. but #512 is a hard prerequisite and it's not going to be easy to implement or maintain it so it really needs to happen upstream.

[craftyguy]

Thank you for the pointers.

Another silly question: you'd want a contribution in the form of a patch against (which source tree?) chromium in the form of a pull request to this repo?

[craftyguy]

Thank you for the pointers.

Another silly question: you'd want a contribution in the form of a patch against (which source tree?) chromium in the form of a pull request to this repo?

[csagan5]

I have added a patch to disable WebRTC for Bromite here: bromite/bromite@83e140c

It patches against Chromium v63.x (63.0.3239.15 at the moment)

[csagan5]

I have added a patch to disable WebRTC for Bromite here: bromite/bromite@83e140c

It patches against Chromium v63.x (63.0.3239.15 at the moment)