KDE Plasma + Brave on Debian

  This is the “how do I make Brave do what I want” note --- especially when Brave profile UI is broken and KDE is strict about .desktop launchers. 1) Know what you’re running. Check where Brave comes from. which brave-browser If it returns /usr/bin/brave-browser , you’re on the APT-installed build (good, predictable). Also note that on Debian you often have both commands available. brave-browser is commonly a wrapper. brave-browser-stable is commonly the actual binary. 2) Where Brave stores its data. Default Brave user-data root (APT install). ~/.config/BraveSoftware/Brave-Browser/ If you only see Default/ , then you effectively have a single Brave “profile” in that directory. 3) Multiple isolated Brave sessions without Brave profiles. This is the clean workaround: run separate user-data directories . Create a new isolated environment. mkdir -p ~/.config/BraveSoftware/Brave-RDT Launch Brave using that directory. brave-browser-stable --user-data-dir= ...
0

Why Public Wi-Fi Doesn’t Load the Login Page Automatically & How to Fix It

The Problem

On public Wi-Fi networks (Starbucks, hotels, airports), the login/accept-terms page often doesn’t appear automatically.
You connect to the Wi-Fi, but your browser just spins.

To force it, you usually have to visit an HTTP site like:

http://example.com

Why This Happens (Technical Explanation)

Public Wi-Fi networks use a captive portal — a page you must see before the network gives you real internet.

Captive portals can only intercept HTTP, not HTTPS.

  • HTTP is unencrypted → the Wi-Fi network can intercept it and redirect you to the login page.

  • HTTPS is encrypted → interception would cause a browser certificate error.

Since almost all modern sites use HTTPS, nothing gets intercepted, so the login page never appears until you manually trigger an HTTP request.

Why Linux Often Doesn’t Detect Captive Portals Automatically

Many systems automatically check a known HTTP page in the background.
Systems using NetworkManager can do this, but the feature is often disabled.

That’s why nothing happens until you open example.com manually.

The Solution (Automatic + Most Secure Method)

1. Enable NetworkManager’s connectivity checking

Install the connectivity config (if available):

sudo apt install network-manager-config-connectivity-debian

Edit NetworkManager’s config:

Open with your text editor and under sudo:

/etc/NetworkManager/NetworkManager.conf

Add or update this block:


[connectivity]
uri=http://network-test.debian.org/nm
response=NetworkManager is online
interval=300
enabled=true

Restart NetworkManager:

sudo systemctl restart NetworkManager

What this accomplishes:

  • NetworkManager requests a small HTTP URL in the background.

  • If the hotspot intercepts it, NetworkManager knows a captive portal is present.

  • It automatically opens a sandboxed mini-browser login window (safer than your main browser).

No more manually loading example.com.

2. Most Secure Practice After Logging In

After the captive portal shows and you authenticate:

Immediately turn on a trusted VPN.

Why:

  • Encrypts all traffic

  • Prevents local attackers from sniffing your data

  • Protects against Man-in-the-Middle and DNS attacks

  • Stops tracking by the hotspot

This is the strongest, simplest security workflow on public Wi-Fi.

Optional: Manual Fallback Trigger

If the auto-detection ever fails, use:

http://neverssl.com

It always works because it never switches to HTTPS.

Final Summary

  • Public Wi-Fi login pages only trigger on HTTP, not HTTPS.

  • NetworkManager can auto-detect this, but you must enable connectivity checking.

  • Add the config → restart NetworkManager → enjoy automatic captive portal pop-ups.

  • After logging in, turn on a VPN for maximum security.

  • Manual fallback: open example.com or neverssl.com if needed.

Comments

Post a Comment