[Desktop] Brave 1.13.82: WebRTC setting always gets reset.

[Peacock365]

Description

The WebRTC IP handling setting always gets reset to "Default Public Interface Only" no matter which other setting I choose, I wanted to set it to "Disable Non-Proxied UDP", impossible currently.

https://github.com/brave/brave-browser/wiki/WebRTC-Custom-Settings

Steps to Reproduce

Easily reproduced, set the WebRTC setting to anything other than "Default Public Interface Only", it will get reset.

Actual result:

It's set to "Default Public Interface Only" all the time.

Expected result:

Respect the other setting I wanted to set, not getting reset.

Reproduces how often:

Easily reproduced.

Brave version (brave://version info)

Brave 1.13.82 Chromium: 85.0.4183.83 (Offizieller Build) (64-Bit)
Revision | 94abc2237ae0c9a4cb5f035431c8adfb94324633-refs/branch-heads/4183@{#1658}
OS | macOS Version 10.15.6 (Build 19G2021)

Version/Channel Information:

I use the release channel.

Miscellaneous Information:

None.

[diracdeltas]

I could not repro this on Beta (1.14) MacOS using the following steps:

1. go to brave://settings/?search=webrtc
2. set WebRTC IP handling policy to 'Disable non-proxied UDP'
3. close tab, open again and go to settings.
4. restart browser and go to settings

No matter what I tried, the setting stayed on 'Disable non-proxied UDP' (my chosen setting) instead of getting reset to 'Default public interface only'. I will ask if anyone else is seeing this on 1.13.

do you have more specific repro steps?

[jonathansampson]

I just tested on Windows 10 with Brave 1.13.82, and cannot reproduce.

@Peacock365, do you find that other settings cannot be persisted across sessions as well, or only this one?

[fmarier]

I also cannot reproduce on 1.13 / Linux:

1. Open brave://settings/privacy
2. Set "WebRTC IP Handling Policy" to "Disable non-proxied UDP".
3. Close Brave and reopen it.
4. Open brave://settings/privacy:
   

[fmarier]

@Peacock365 Do you have Sync enabled? If so, are you syncing your browser settings?

[diracdeltas]

Another report of this here, with more specific repro steps: #11373

[Peacock365]

@jonathansampson

No, as far as I can tell only this WebRTC setting is being reset. It also happens within the same session, not only across sessions. A browser restart isn't required for the setting to be reset.

It was report here, too: #11373

[Peacock365]

@fmarier

Sync isn't enabled here. I never used Sync, either.

[jonathansampson]

@Peacock365 This setting is stored in the following file:

~/Library/Application\ Support/BraveSoftware/Brave-Browser/Default/Preferences

Note: The Default directory will be used only if you are using Brave's default profile. If you had setup a different profile, you'll need to look within a directory called Profile 1, Profile 2, etc. instead.

This is a JSON file, and the setting will be stored in this manner:

"webrtc":{"ip_handling_policy":"disable_non_proxied_udp"}

Can you confirm that the "ip_handling_policy" key exists in your Preferences file, and that no other software on your machine is manipulating this file when you close the browser?

[Peacock365]

@jonathansampson

I use the default profile, no worries.

The key exists in the preference file, and shows:

"webrtc":{"ip_handling_policy":"disable_non_proxied_udp"}

However, the setting displayed in the Brave settings menu is "Default Public Interface Only". No other software is manipulating the file, I am not using any cleaners or anything. The issue begun after updating Brave to version 1.13.82. I changed no setting (including the WebRTC setting discussed here) or extension setting before or after the update. I emphasize again that the WebRTC setting being reset doesn't require a browser restart. It gets reset intermittently, within the same session, as well.

[fmarier]

@Peacock365 Which language are you running Brave in? Are you able to reproduce if you use the English version of Brave?

[Peacock365]

German. Haven't tried enforcing the English interface yet, will try.

[Peacock365]

UPDATE: I went to the following website:

https://browserleaks.com/webrtc

My IP address didn't leak there, indicating that Brave is in fact using "Disabled Non-Proxied UDP" instead of "Default Public Interface Only". However, the latter is still shown as the active setting in the Brave settings menu. Might this be just a graphical bug? Am I missing something here?

[diracdeltas]

someone in #11585 saying that this is happening for the tracker and ads setting

[Peacock365]

Tested the English user interface - no change, the bug still persists. Also not fixed by updating to Brave 1.14.81.

[fmarier]

Thanks @Peacock365 for testing the English UI. We can rule out the possibility of a translation bug.

So far I don't think anyone at Brave has been successful reproducing this. But at least it looks like it's a cosmetic issue and that you can still set your browser to use "Disabled Non-Proxied UDP".

[Brave-Matt]

+1 from Reddit:
https://www.reddit.com/r/brave_browser/comments/izk3ym/webrtc_ip_handling_policy_keeps_resetting_to/

[diracdeltas]

@simonhong any thoughts on what this could be due to?

[simonhong]

@diracdeltas I double checked the code that related with this settings.
This option is handled by BravePrivacyHandler::SetWebRTCPolicy and BravePrivacyHandler::GetWebRTCPolicy
and I can't find any clues that can cause this issue. Value is stored and delivered with right type and JS uses it properly.
Whenever I change to any options and reload, I can see proper value of prefs(ip_handling_policy) is set at brave://prefs-internals/.

Previously, we had obvious bug for ads & tracker reset issue. however, it seems we don't have bug for webrtc option.

[Peacock365]

Hey, just wanted to let you know that two settings in the Brave setup of a relative of mine got reset (relative is using Windows 8.1, btw), as well:

• The search engine got reset from Google to DuckDuckGo.
• Upon browser restart, the tabs of the last session get loaded despite the desired setting being only loading the new tab page.

It seems to me that you, the guys and gals @brave Software, have a general problem with settings persistence. Seemingly, Brave always resets random settings to their default values. From the issue of my relative, it seems to me that WebRTC being affected in my case is just random chance. Seems to be a general settings persistence bug. Cheers.

[bsclifton]

@Peacock365 do you have Sync enabled? That will sync your default browser. Besides that, I'm not sure how it could get overwritten/reset

Just to verify: if you go to brave://settings, you have the new tab configured on open set like this, right?

[Peacock365]

The relative doesn't have Sync enabled, and never had Sync enabled. Sync is completely out of the equation here.

I had this set to "Open New Tab Page" for him, however, there is a bug that causes Brave to switch to open the tabs of the last session. The setting gets reset upon restart, but also intermittently (within the same browsing session).

As I said, you seem to have a general problem with settings persistence. The Brave profile of the relative is on another PC and completely unrelated to my own profile. The operating systems are different, too (Windows / macOS).

WebRTC being affected in my case seems to be random chance, I am convinced that there is a general bug causing random settings not to persist.

[BrendanEich]

@bridiver any ideas? thanks.

[bridiver]

The "On startup" setting is 100% chromium code that uses the internal js prefs api and the WebRTC setting is custom Brave code that calls a webui method that sets a pref (this should also use the internal js prefs api, but the current implementation should function correctly). If there is an issue, the most likely cause imo is an issue writing the prefs file. That could happen either because of a local filesystem issue or possibly because of a shutdown crash. @Peacock365 if you go to brave://crashes do you see anything that aligns with your testing?

[Peacock365]

I have had crash reports disabled and no recent crash, so I can't provide any info based on that (yes, I've looked at brave://crashes). However, I had a kernel panic some time ago, and I believe Brave was open at the time of the crash. Could this be fallout from that?

However, can that explain what happened on the PC of my relative? That was Windows 8.1, and unreltae to any crash as far as I know.

[bridiver]

@Peacock365 can you check "Diagnostic Reports" in the mac Console app to see if there are any Brave crashes there? You can also run Disk Utility First Aid to see if there are any filesystem issues. Any crashes for your relative (Brave or OS)? Does the setting persist until browser restart (open and close settings page multiple times)? Do other setting changes persist correctly? What happens if you change webrtc and some other setting? Does the other setting persist when webrtc is lost?

[Peacock365]

Hey there, it seems that the issue is resolved as of Brave 1.17.68. After the update, the WebRTC setting showed that it is controlled by an extension at the moment (uBlock Origin). The greyed-out setting shown was "Default Public Interface Only". I went to a WebRTC IP leak test and my IP address leaked despite uBlock Origin being set to prevent the leak. Very strange.

Anyway, I turned off uBlock Origin's WebRTC IP leak protection setting and upon doing so, Brave kept the intended setting "Disable Non-Proxied UDP". Upon testing the WebRTC leak again, it now shows that my IP address no longer leaks.

Consider this bug RESOLVED FIXED, it seemed to be a conflict between Brave and uBlock Origin that can be resolved by using Brave's WebRTC setting instead of the one in uBlock Origin.

[fmarier]

Thanks for the update @Peacock365 . It's good to know that the UI now highlights the interaction between extensions and our settings.