Bringup of browser forces answering connect to wireless link

When I initially bring up Brave browser on my openSuse Leap 15.2 linux system, there is a attempt to connect to the wireless connection as 2 popup windows which occur before the browser actually comes up must be responded to. Then occasionally during the browser session, additional attempts to connect to the wireless port occur again. This has become finally intolerable after several months of just clicking with the mouse to ignore the problem. How can I turn this off?

The browser is connected just fine through a wired link, capable of downloading 99 meg/sec, so no wireless connection is necessary and superfluous.

This happens every time I bring up the browser.
OS version: openSuse Linux version Leap 15.2 (latest patches) (64-bit)
Brave version: Version 1.30.87 Chromium: 94.0.4606.71 (Official Build) (64-bit)
2 screen shots are attached.

1 Like

Hello – I think I understand your description of the problem, but I don’t understand how the screenshots relate to your Wi-Fi connection prompting. Is there another screen that ties them together or are these 2 separate problems?

1 Like

I was actually just about to ask the same thing – I’ve also pinged our Linux team to see if this is already a known issue that I am not aware of.

1 Like

I’ve never used the GPG option with the kdewallet, but the reason why this shows up with Brave is that Brave (and Chrome) use the kdewallet on KDE to safely store the encryption key used to store saved passwords, cookies, etc.

Normally, in the default configuration, the wallet is encrypted using a password derived from the user login password and is automatically unlocked at login time. If that default wallet is changed (for example, it seems to be using a GPG key instead in your setup), then the first application that accesses the wallet will trigger that prompt from KDE.

On my machine, running GNOME, the gnome-keyring wallet is not automatically unlocked so I normally get a prompt after starting either Gajim or Brave.

Ah yes, good call, that makes sense.

Reminds me of a couple other threads:

Note in the last one, the behavior was due to using biometric login; since the actual login password is not supplied, it is then not possible for it to also unlock the keyring.

Note there is also a workaround some other packages use, maybe worth considering for the Brave Linux package, although I’m not personally a fan of doing that.

Can you say more about this?

The only work-around that I can think of would be to not use the OS keyring and then store the passwords/cookies in plaintext on disk (or, more precisely, encrypted with a key that’s either hardcoded or unencrypted). That’s the behavior you get if you use the --password-store=basic command-line parameter, but I wouldn’t recommend it.

Hi @fmarier , yes, that’s exactly what I was referencing here as well as in the linked thread. I don’t like the idea for the same reasons. I feel a decision there would have to consider the balance between data protection, vs. user support/difficulties and potentially giving up on the app on Linux systems due to these struggles.

Perhaps a good balance would be an easy-to-find article on ?

I’d be willing to bet most of the users running into this issue fall into one of two camps; either they aren’t set up to auto-unlock the keyring, or, they are using some kind of non-passworded unlock (e.g., biometric) where the keyring can’t be auto-unlocked because the password was not supplied.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.