Bug 369069 - [RFE] Change how a new wireless connection is configured.
Summary: [RFE] Change how a new wireless connection is configured.
Status: RESOLVED INTENTIONAL
Alias: None
Product: plasma-nm
Classification: Plasma
Component: general (show other bugs)
Version: 5.7.3
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Lukáš Tinkl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-19 18:25 UTC by kdebuac.rhn
Modified: 2016-09-21 07:52 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kdebuac.rhn 2016-09-19 18:25:02 UTC
Currently, connecting to a new WiFi network can be done in 2 ways: by clicking on it in the applet list, or by entering its SSID and details in the editor manually.

When connecting via the applet, user optoinally needs to provide passwords, and the defaults are used:
- real MAC
- autoconnect every time the network is visible

As a result, KDE will help the user disseminate their MAC address to everyone they ever connected, which is not necessary a reasonable default.

In addition, these defaults can become annoying in the public space scenario: lots of networks with captive portals (or misconfigured in other ways) and poor reception.
After the user tries several networks and can't get through the captive portals, all those useless networks are saved and will connect automatically. Eventually, the user finds a network that works. Whenever this connection gets dropped (poor connectivity), one of the broken networks will be connected to. As a result, the user gets little indication that anything changed, but there's no connectivity any longer, and the user had to manually reconnect.
Setting the default to "do not reconnect" does not inconvenience the user more than otherwise.
Perhaps a better default would be "only reconnect to the same SSID".

I assume a "trusted" network to always connect to is a home network - selecting a new one would be a rare event, and therefore a small inconvenience compared to the two above factors.

Reproducible: Always

Steps to Reproduce:
1. Connect to a network
2. Change the network settings
3. Reconnect to network

Actual Results:  
Connected with new settings

Expected Results:  
Expected workflow: First (have an option to) configure, then connect.
Comment 1 Jan Grulich 2016-09-20 13:05:16 UTC
Option such as "only reconnect to the same SSID" is probably equal to disabling autoconnect for every other wireless network and NetworkManager doesn't support anthing likke that, thus we cannot support this in our applet. Also a scenario where you need to find any working/free wireless network by trying them one by one is something I wouldn't consider as a valid use case. It's a thing you probably do occasionally when traveling or something like that and the period you would be having problems with using random unsecured wireless network is rather short then something what would bother your for a long time.
Comment 2 kdebuac.rhn 2016-09-20 14:05:06 UTC
The problem with disclosing the real MAC address at "untrusted" locations - even if visited frequently - still exists regardless of traveling. I believe NetworkManager already has something in the works here.

The traveling use case will be familiar to anyone who goes abroad. The open networks are plentiful, but a lot of them require (mobile) registration/payment, and foreign names are not always clear, therefore it's not possible to find a good network at first try. You mentioned that the period of inconvenience is short, but it is also critical, because in the traveling network use case the computer would be on battery power and internet access needed ASAP. Granted, I am not sure how many people use a computer on the go these days.

Perhaps there doesn't exist a "one size fits all" solution, but I believe that the travelling use case is still valid (if niche). Therefore, it would make everyone happy if on first connection, the password dialog was replaced with the actual connection dialog. This would solve:
- the inverted workflow (configure after connecting is bad)
- privacy issues (user can choose to randomize MAC before connecting)
- travelling use case
- custom network configuration
Comment 3 Jan Grulich 2016-09-20 14:38:26 UTC
Given that we primary target for non-technical users (at least with the applet), I don't think that displaying a configuration with stuff they know nothing about once they try to connect to a wireless network would be more or less confusing for them. For technical users like you I don't think it's a big deal opening the editor and create a connection with configuration you desire.
Comment 4 kdebuac.rhn 2016-09-20 15:21:33 UTC
I tend to agree, except for two things.
First, creating a new connection manually is (surprisingly) difficult. The nm applet provides no way to copy the SSID, and the new connection editor doesn't allow to select the visible ones either. One would have to scan networks using command line (and it's not obvious how to do it) and copy the SSID from there.
Second (this may be a separate problem), I can't see any upsides of using real MAC on hardware that supports changing it. As a consequence, the non-technical user will not know that the software gives away some identifying information about them, and that they have a choice for not disclosing the information by using random MAC.

Given that there is no convenient graphical tool for technical users, I don't think it's unreasonable to target the technical ones to some extent.
Perhaps attacking the user with a full dialog is a bad idea, but clicking the network name already shows very technical information. Perhaps that's an area that could be used to let the user indicate the need to configure network before connecting?
Comment 5 Jan Grulich 2016-09-20 15:29:09 UTC
The editor actually suggests you a list with all visible wireless networks (including signal strength and list of BSSIDs).
Comment 6 kdebuac.rhn 2016-09-20 16:50:58 UTC
I have no idea how I didn't notice that before. That solves the configuration workflow I suppose.

I still claim that the MAC default is unsuitable for a user unaware of WiFi privacy problems. As the defaults author makes decisions on behalf of non-specialists, the defaults should be safe and conservative.
Comment 7 Jan Grulich 2016-09-21 07:52:09 UTC
This is NM's default configuration and I'm not going against it. If the default configuration changes in NM then we can change it on our side as well.