Enable WebRTC

[RomanZhilich]

As README sates it's disabled.

Is it possible to enable WebRTC without re-building? If not is there an ETA to add this option or it is hard and I shouldn't hope for it anytime soon?

[Eloston]

There's no way of enabling WebRTC right now without rebuilding.

I am planning on adding an option for it and other features. I will probably make them global options until we figure out a good and flexible configuration system to implement. EDIT: See status update below.

Related to #38.

[Eloston]

I tried looking through the source code, but it isn't clear to me how I should attempt to add an option for this; WebRTC code is all over the place. I believe some Chromium forks have an option like this, but I don't remember their names or if they have source code. Any help will be appreciated.

Also, does anyone know what the WebRTC log uploader does in chrome/browser/media/webrtc/webrtc_log_uploader.cc?

[Atavic]

I retrieved this:
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/common_types.cc

by looking at mozilla wiki that linked to a similar common_types.cc

[Eloston]

@Atavic I've gathered from your links that there's logging to aid in debugging applications that use WebRTC. But, I'm still not understanding how this relates to the WebRTC log uploader I mentioned earlier. Would you be able to clarify?

BTW, I've determined that it uploads to chrome::kUploadURL (which is https://clients2.google.com/cr/report) in WebRtcLogUploader::UploadCompressedLog

[Atavic]

https://clients2.google.com/cr/report is also used for Crash Reports.

Here there are some comments. Here is a parser. Hope it's somewhat useful.

[Eloston]

@Atavic I can see what data they are capturing now, but I'm still not understanding why they are capturing uploading the data. Perhaps it is for diagnostic purposes just like crash reports?

EDIT: capturing -> uploading

[Atavic]

Paragraph 6.4.2 [Page 41] of http://www.ietf.org/rfc/rfc3550 is listed here.
It's for optimization of audio and video streams, based on bandwidth and eventual lags.

Monitoring happens in real time for 10 seconds here.
What I have gathered today is that proto is the log stored locally.

[Eloston]

@Atavic Sorry, I made a typo in my original message. I mean to ask why they are uploading the logs to Google. I don't think this is something we can gather by just looking through code. I've tried looking online, but I haven't been able to find anything either.

BTW, Protobuf is described here. It's used in all Google projects involving some networking protocol as far as I've seen.

[Atavic]

Wireshark could come handy.

[Eloston]

@Atavic Thanks for the tip, but packet capturing will not be necessary. I will add a patch to disable log uploading altogether once a switch is implemented to turn on and off WebRTC support. (I should note that log uploading won't work anyway with domain substitution.)

[Eloston]

This article has been recently brought to my attention: https://nakedsecurity.sophos.com/2017/05/31/chrome-bug-that-lets-sites-secretly-record-you-not-a-flaw-insists-google/

I haven't investigated the situation yet. If someone knows about the UI code behind this, that would be helpful to know.

I don't know much about WebRTC in Chromium, but perhaps we can add another feature to re-ask for permission to use WebRTC after it had stopped being used?

[Atavic]

Bug report.

[Eloston]

I have decided to change my stance on this issue. Chromium has a feature to enable WebRTC per-site, so there's really no need to have another switch for it. The log uploader will be patched out in the next stable version.

Also, I don't feel that the indicator light problem is enough to keep WebRTC disabled. If Google isn't doing anything about it, and Inox has WebRTC, then I see no reason why ungoogled-chromium should keep it disabled.

[macandchief]

May I ask: Do I understand it correctly that WebRTC will be enabled on default in this browser?

[Eloston]

@macandchief Yes, WebRTC will be enabled starting with version 62. All WebRTC runtime options will be the same as normal Chromium for now.

[macandchief]

I see, thank you for the quick response. Somehow I had the understanding that being WebRTC removed is an advantage from a security point of view. As a comment under the "Chrome bug that lets sites secretly record you 'not a flaw'" says: "Disable WebRTC which honestly from a security and privacy standpoint you should have disabled anyway as it leaks information such as your real IP address and location even when using a VPN."

I liked it not being part of Eloston/ungoogled-chromium, but I guess it simply means that I will have to care about to disable it in the future.

[Eloston]

@macandchief I've seen more people complain about WebRTC being disabled than leaving it enabled. Regarding your concern, uBlock Origin has a feature to mitigate it: https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-leaking-local-IP-address

[macandchief]

Yes, I understand. Although those complains seem to be a bit strange to me as basically every other browser from FF over Chromium till Brave have WebRTC, if anyone needs it. While I considered it to be the unique feature of ungoogled chromium having basic functionality without all the junk (which makes it absolutely fantastic - and secure -, especially with the right add-ons being fast and easy on resources). Obviously it's ok too to add it and using something like uBlock Origin in the future. Anyhow thank you for the clarification.

[Eloston]

@macandchief While it's true that features are removed or disabled, I don't believe it significantly improves performance (although I don't have much concrete to back this up). ungoogled-chromium pretty much does what its name implies.

And I'd like to emphasize that implication, because I think the major draw to this project is really just that. ungoogled-chromium hasn't really differed much from the status quo that Chromium and Firefox are setting (and that Brave is challenging) for the Internet. Significantly differing from this takes a lot more effort that I and some sporadic contributions can do. For now, I'll just ride along in a mostly similar path.

[lulcat]

+1 on the macandchief.. there is ample oppurtunity to have a side browser with full functionalkuty and little privacy, even chromium/chrome normal.. changing your stance due to 'compaints' is the wrong way to go. The entire pointof privacy breaches is the reliance on the lazy masses.. you are now adding to that.

I just found this project as I have along time intended it myself but have so many other patching projects.. and the first thing I will have to do is fork this again to uncommit this? Wow, easier to just drawpatches again then and this becomes pointless.

[Eloston]

@lulcat Can you show us how WebRTC leaks data after denying hardware access permissions and using uBlock Origin's WebRTC local IP address leak prevention feature? If you show us, I will use that to reconsider my decision.

So far, the only two arguments I've seen against WebRTC in this thread are the following:

• WebRTC leaks one's local IP address - Solved by extensions such as uBlock Origin
• WebRTC is another attack surface (security concern); WebRTC could leak data (privacy concern) - I don't have any concrete information on this. I'm not going to disable something due to an abstract concern if there are strong and concrete reasons to keep it.

Do note that if someone comes along with a patch that adds an option to toggle WebRTC (e.g. a command-line flag in chrome://flags), then I would more than likely go with this.

[lulcat]

Eloston.. having now built the (inox) , after patching it to my distro... I see where you are coming from. Although I stand by the unecessary unique machine id hash sharing and what not with this.. ("in the old days, one would manually grant stuff").. there is just so much metadata.. so ye.. the lan ip being blockable is a good thing.. that people who work on patching chromium to be non-google for safety, is great work.. and if it makes sense to keep webrtc enabled, and rather patch in the surrounding framework, then ok... but it is just generally how things are going which is so bad. I think maybe a solution to this, is integrating the chrome extension into the code.. It seemed Serge (from Canonical) linked the source code at some point and it seems to have been removed again.. not sure why, but as I will build (or try to build) this from an old version of yours, I can try to put that in.

[lulcat]

Mind you, I have entirely different projects I am working on, so this might be a on and off thing to look into from my side.

[Atavic]

WebRTC is another attack surface (security concern);

Firefox and Chrome have implemented WebRTC that allow requests to STUN servers be made that will return the local and public IP addresses for the user. These request results are available to javascript, so you can now obtain a users local and public IP addresses in javascript.

Additionally, these STUN requests are made outside of the normal XMLHttpRequest procedure, so they are not visible in the developer console or able to be blocked by plugins such as AdBlockPlus or Ghostery. This makes these types of requests available for online tracking if an advertiser sets up a STUN server with a wildcard domain.

WebRTC leaks one's local IP address; WebRTC could leak data (privacy concern)

uBo is preventing the not-internet facing machines info to be sent (or leaked), while the machine connecting to the WebRTC service is still announced (that's needed for WebRCT to work).

[Eloston]

@Atavic Insightful, thanks. But if a user is not behind a NAT, JavaScript can simply connect to a peer that can discover the IP address, right? Would the safer option be to disable all WebRTC JavaScript APIs?

Normally it would be better to disable WebRTC via GN, but it's not a tested configuration, and it breaks PepperFlash.

[Atavic]

The CLI switch
--force-webrtc-ip-handling-policyhas some options that limit the interfaces opened to WebRTC communication.

[xsmile]

@Atavic, @Eloston I'm not sure if I see any real issue here. The public IP is needed to initiate connections to other servers and is exposed even without WebRTC, independently of the user's connection method.

@Atavic I believe the information is mostly outdated, see [1][2].

1: https://github.com/diafygi/webrtc-ips
2: diafygi/webrtc-ips#25

[lulcat]

Well, exposing your public ip any browser does and has to... this was about internal local ip. This is a huge network discovery exploit.. and despite using stuff like tor, you will have e.g. 10.1.XX ranges identifying networks/users and so on. data collection is a very bad thing in this day and age, and no responsibilities upon 'corps', one needs to do it oneself unfortunately.. anyway. when it comes to the block ting from the internet, the source is by canonical 0.21, and is simply setting the media.peerconnection flag thing to disable. This should just be done in during building, so it is not enabled. with a button/option to enable it if needed. Like the extension just prebuilt imo. Apart form that ye.. as long as one can set it to not be active and not be circumvented, there is no issue with allowing it to be toggled on by a user should he or she wish to use it at some point. but local network info should absolutely be disabled by default. If it's an issue to integrate the extension, then sure, keep it as a manual extra install bit then.

[Eloston]

@Atavic @xsmile I know of that flag, but WebRTC traffic can still pass through undetected by extensions, even if all site permissions are disabled (which are only media permissions), right? I don't think that flag is a guarantee no data will go through. If so, it's still a privacy risk.

I'm thinking it might be possible to use the flag's implementation as a reference for a new command-line flag that disables WebRTC.

[lulcat]

Ye.. well, like you said.. you were chaning stance.. I guess it's your call... I haven't tested enough to know how swell only disabling the media.peerconnection is.. but I know when websockets webrtc first came out a long time ago and it oculd read my lan ip I totally lost it ,p As you said yourself, you are thinking of not disabling it entirely.. either it's ripped out.. or I thin for now, perhaps integrating the default connection value ot be false is the way to go? If over time it turns out it there are poc's showing vulernabilities , then patch then?

[xsmile]

@Eloston Are you referring to this article [1]? They say that "a user first has to grant a site permission before it can access audio and video".

Chromium extensions have access to WebRTC IP handling settings, see [2]. Google's official WebRTC extension accesses them [3] and so does uBlock Origin [4]. From a privacy point of view the safest option for webRTCIPHandlingPolicy should be disable_non_proxied_udp which exposes the public IP only.

Tests did not show my local IP address and could not even show the public one if I activated uBlock's WebRTC feature - with and without being connected to an OpenVPN server.

EDIT:

Possibly webRTCIPHandlingPolicy can be pre-set to disable_non_proxied_udp, eliminating the need for uBlock in this case. However I cannot imagine myself browsing the web without it nowadays.

1: https://nakedsecurity.sophos.com/2017/05/31/chrome-bug-that-lets-sites-secretly-record-you-not-a-flaw-insists-google/
2: https://chromium.googlesource.com/chromium/src/+/master/chrome/common/extensions/api/privacy.json#40
3: https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia
4: https://github.com/gorhill/uBlock/blob/master/platform/chromium/vapi-background.js#L199

[Atavic]

The term interfaces used here refers to network cards.

For clarification, see: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/?include_text=1

[xsmile]

@Atavic The webRTCIPHandlingPolicy setting disable_non_proxied_udp corresponds to Mode 4 as defined in draft-ietf-rtcweb-ip-handling-04 and is activated by uBlock Origin.

[Eloston]

I did some research, and this is my understanding thus far:

• Setting disable_non_proxied_udp will prevent the computer's address from being visible, and also the ISP address when a proxy or VPN is used (except with an extension-based VPN or proxy)
• Disabling site permissions for audio and video disables camera and microphone access in WebRTC

This implies the following:

• Only data channels can be established, so no more types of data can be sent than what is possible with XmlHttpRequest.
• Connections by WebRTC will not contain any more identifying information than other connections by the browser.

That means there is no privacy problem. These mean that WebRTC is no more of a privacy risk than XmlHttpRequest or other connections. (edited for clarity)

But, there is still a minor concern: WebRTC cannot be filtered by an extension like XmlHttpRequest. This is similar to @Atavic's point in #179 (comment). Thus, having a flag to disable WebRTC could still be useful to someone that wants to micro-manage their connections (until extensions can intercept WebRTC connections, or an extension wraps the WebRTC interface). However, I'm not sure if there is an actual need for this.

Any thoughts?

[Eloston]

6f20952 disables log uploading. Since there are no objections to enabling WebRTC, I'm closing this.

[csagan5]

Cross-posting for those interested in how WebRTC works with custom tabs: bromite/bromite#553