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.
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?
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.
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.
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.
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.
