Development discussion of WireGuard
 help / color / mirror / Atom feed
From: lazerl0rd@thezest.dev
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Bruno UT1 <bandry@ut1.org>, wireguard@lists.zx2c4.com
Subject: Re: [Windows Client] Out of date Title scare my users
Date: Thu, 25 Nov 2021 14:23:12 +0000	[thread overview]
Message-ID: <ccf4971633fdd62807ff51ddf7de1299@purelymail.com> (raw)
In-Reply-To: <CAHmME9oqvV9E9cVXeF5nVpumE0fJgdASaBqG6aCPyS-NLq9rXQ@mail.gmail.com>

Dear Bruno,

Whilst I understand the frustration that having hundreds of users can 
cause, I don't believe simply reverting the change [as proposed by 
Jason] is the correct solution. I've come up with a few alternative 
solutions, but before I present them I'd just like to give a brief 
introduction into why I requested that change in the first place.

WireGuard on Windows exclusively provides a GUI to users of the 
Administrators group, as well as a limited GUI to users of the Network 
Configuration Operators group when the `LimitedOperatorUI` DWORD is set. 
The latter is helpful for users who wish to separate their personal and 
administrator accounts (to protect themselves against the plethora of 
UAC exploits, amongst other security issues) where otherwise the user 
would have to switch accounts to switch tunnels. However, the GUI shown 
to Network Configuration Operators lacked any information about updates. 
This lead to users in such setups to not be informed about any updates 
unless they switched out to the Administrator account and or kept an eye 
on the releases online. This is quite a problem as users could be 
running ancient versions of WireGuard for relatively long periods of 
time without the knowledge that they are doing so (some users may even 
assume WireGuard automatically updates). As such, I asked Jason if he 
could add the ability for non-admins to at least be informed of an 
update which lead to where we are today.

After speaking to Jason "off the mailing list", he stated he wouldn't 
like to add any more configuration options (via the Registry or within 
the GUI) nor any metadata to updates so bearing that in mind I came up 
with a few alternatives:

1) Rewording the update prompt for non-admins to appear less 
"aggressive". Currently, the prompt is "Please ask the system 
administrator to update." but this could be changed to something along 
the lines of "There is an update available. The system administrator 
will update when necessary." which should reduce most, if not all, users 
from contacting you unnecessarily. I can throw up a patch for this if 
Jason agrees.

2) Avoiding users seeing the UI at all, where unnecessary. If your users 
do not need *control* of the WireGuard configuration, then avoiding 
showing them the UI altogether could be an option. I don't know your 
system as well as you do, of course, so I can't assure that this 
solution is valid. However, having hundreds of users as Network 
Configuration Operators sounds a little "worrying" to me.

3) Showing an even more limited UI for unprivileged users. If the users 
still need some form of UI, then an even more limited UI could be 
presented to users not part of the Administrators nor the Network 
Configuration Operators groups. This would lack any form of control, and 
could still be under the same `LimitedOperatorUI` Registry DWORD, or not 
if is deemed "safe enough for the masses". If it is, you could say the 
semantics refer to "Limited [User or Network] Operator UI".

4) Updates could be hidden from the UI for N days after an update or N 
updates (preferably two in this case, so that it doesn't pile up) for 
Network Configuration Operators. This provides you [and any other 
sysadmins] with a "buffer zone" to apply the updates before users 
contact you about them. This could also be teamed up with 1) to further 
reduce the likelihood of users contacting you. I'm not a large fan of 
this "solution", however, since WireGuard for Windows lacks any metadata 
to differentiate important and optional updates which can lead to a 
security patch or critical bug-fix being ignored for some time.

5) Creating a separate group which are able to switch tunnels. For users 
who just need the GUI to switch tunnels, having a group specific to such 
behavior named something along the lines of "WireGuard Operators" could 
be helpful.

Hopefully at least one of these suffices for you so that we can meet a 
mid-point of sorts that matches both your criteria as well as my own.

Thank for your time,
Diab Neiroukh

PS: Whilst it may seem a pain, I believe that a balance should be 
achieved between the sysadmins and users where if the former forgets to 
apply an update "for too long" then the users contact them as a 
reminder. After all, we're all humans and we do forget sometimes. The 
solutions 1) - with a prompt such as "There is an update available. The 
system administrator should update soon." - and 4) match up to this 
quite nicely.

On 2021-11-24 15:42, Jason A. Donenfeld wrote:
> I agree the situation is a bit ridiculous. I'll revert the change that
> added this:
> https://git.zx2c4.com/wireguard-windows/commit/?id=82129ba288f7561c89bb80e04841ffb46bc29889
> 
> I'm CCing Diab, who originally requested the change, in case he wants
> to argue with you about it. But in the absence of that, I'll revert.

  parent reply	other threads:[~2021-11-25 14:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-24 15:21 Bruno UT1
2021-11-24 15:42 ` Jason A. Donenfeld
2021-11-25 13:34   ` Diab Neiroukh
2021-11-25 14:23   ` lazerl0rd [this message]
2021-11-25 16:07     ` Bruno UT1
2021-11-25 16:27       ` Jason A. Donenfeld
2021-11-26  8:47         ` Jason A. Donenfeld
2021-11-26  9:17           ` lazerl0rd
2021-11-30 10:12             ` Bruno UT1

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ccf4971633fdd62807ff51ddf7de1299@purelymail.com \
    --to=lazerl0rd@thezest.dev \
    --cc=Jason@zx2c4.com \
    --cc=bandry@ut1.org \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).