#369 KDE creates by default unencrypted WiFi hotspots and does not even offer to enable encryption (technical and legal issue for users)
Closed: Deferred to upstream by siosm. Opened by py0xc3.

it seems that KDE creates by default unencrypted hotspots, when the hotspot button is used. The users are not even asked if they want to encrypt the hotspot.

On one hand, this is not a "best practice" for obvious reasons (this offers many possibilities for harm of the users; e.g., abuse of their connection for illegal stuff; costs for additional traffic if third-parties start to use the unprotected connection). On the other hand, there are countries were the use of unencrypted WiFi fulfills "gross negligence" (of the hotspot owner/provider) when such a hotspot is abused by third-parties, which can cause legal issues for our users.

I think to remember that in earlier releases, KDE created WPA2 hotspots with random passwords. I suggest to return to this practice.

Another approach is the current approach from Workstation/Gnome, which enforces encryption in a 1-step-hotspot-wizard and asks the users to choose between determining a password themselves or generate a random password.


This sounds like an upstream KDE issue, not specific to Fedora's KDE.

GNOME enforcing something sounds rather awful. Having security on by default is a great strategy though. Some users may require a passwordless hotspot for some reason.

It cannot be excluded that there are niche use cases where no encryption is necessary, but these are definitely not average use cases which we should consider default, especially as this can cause harm to users who are often not aware (which includes lots of users) while they are at the moment not given a hint about the issue / potential harm.

GNOME enforcing something sounds rather awful

I think a question like "Please enter a hotspot password or choose to create a random password" or so is something users can bear. Maybe my wording "enforce" was a little inappropriate - it's just that the GNOME wizard by default assumes that encryption with password is intended (which should include most use cases I guess), and not vice versa. But the previous approach in KDE to just generate a random password is acceptable, too. But in any case, by default neither creating encryption nor asking/telling users about it is problematic/dangerous.

But true, I have not checked if this configuration is from upstream or determined by the SIG.

Agree that this should be reported upstream. I don't think we change anything here.

Metadata Update from @siosm:
- Issue close_status updated to: Deferred to upstream
- Issue status updated to: Closed (was: Open)

Metadata