wifi passwords
This commit is contained in:
parent
13737cf85d
commit
24e9541e02
@ -25,6 +25,7 @@ while [ "$(echo $1 | head -c1)" = '-' -o "$#" -gt $numargs ]; do
|
||||
"-d") td=$1; shift;;
|
||||
"-V") VERBOSE=1;;
|
||||
"-x") DRY_RUN=1;;
|
||||
"--no-editor") NO_EDITOR=1;;
|
||||
*)
|
||||
echo "Unknown option '$arg'"
|
||||
usage;;
|
||||
@ -78,3 +79,7 @@ if [ ! -z $IMG_DIR ]; then
|
||||
mkdir -p "$imgDirName"
|
||||
fi
|
||||
fi
|
||||
|
||||
if [ -z $DRY_RUN ] && [ -z $NO_EDITOR ]; then
|
||||
exec $EDITOR "$postFileName"
|
||||
fi
|
||||
|
@ -0,0 +1,89 @@
|
||||
---
|
||||
title: >-
|
||||
Why Do We Have WiFi Passwords?
|
||||
description: >-
|
||||
A possible UX improvement.
|
||||
tags: tech
|
||||
---
|
||||
|
||||
It's been longer than I'd like since the last post, and unfortunately I don't
|
||||
have a ton that I can actually show for it. A lot of time has been spent on
|
||||
cryptic-net, which is coming along great and even has a proper storage mechanism
|
||||
now! But it also still has some data specific to our own network baked into the
|
||||
code, so it can't be shown publicly yet.
|
||||
|
||||
-----
|
||||
|
||||
Since I don't have much I _can_ show, I thought I'd spend a post diving into a
|
||||
thought I had the other day: **why do we have wifi passwords?**
|
||||
|
||||
The question is a bit facetious. Really what I want to ask is the adjacent
|
||||
question: why do we use usernames _and_ passwords for wifi networks? The
|
||||
question doesn't make much sense standing alone though, so it wouldn't do as a
|
||||
title.
|
||||
|
||||
In any case, what I'm proposing is that the vast majority of people don't need a
|
||||
username/password authentication mechanism to secure their wifi network in a
|
||||
practical way. Rather, most people could get along just fine with a secret token
|
||||
mechanism.
|
||||
|
||||
In the case of wifi networks, a secret token system might be better named a
|
||||
secret _name_ mechanism. Using this mechanism a router would not broadcast its
|
||||
own name to be discovered by the user's device, but rather the user inputs the
|
||||
name into their device themselves. Existing hidden wifi networks work in this
|
||||
way already, except they also require a password.
|
||||
|
||||
I'm not going to look at this from a technical or cryptographical perspective.
|
||||
Hidden wifi networks work already, I assume that under the hood this wouldn't be
|
||||
appreciably different. Instead I'd like to highlight how this change affects the
|
||||
user experience of joining a wifi network.
|
||||
|
||||
The current experience is as follows:
|
||||
|
||||
* USER discovers the network name and password through external means.
|
||||
* USER opens "add new wifi network" page on their device.
|
||||
* USER finds network name in network list, possibly waiting or scrolling if
|
||||
there are many networks.
|
||||
* USER selects the network name.
|
||||
* USER inputs password into text box.
|
||||
* USER is connected to the wifi.
|
||||
|
||||
What could this look like if the network name was secret and there was no
|
||||
password? There'd be no network list, so the whole process is much slimmer:
|
||||
|
||||
* USER discovers the secret network name through external means.
|
||||
* USER opens "add new wifi network" page on their device.
|
||||
* USER inputs secret name into text box.
|
||||
* USER is connected to the wifi.
|
||||
|
||||
The result is a 33% reduction in number of steps, and a 50% reduction in number
|
||||
of things the user has to know. The experience is virtually the same across all
|
||||
other axis.
|
||||
|
||||
So the upside of this proposal is clear, a far better UX, but what are the
|
||||
downsides? Losing a fun avenue of self-expression in the form of wifi names is
|
||||
probably the most compelling one I've thought of. There's also corporate
|
||||
environments to consider (as one always must), where it's more practical to
|
||||
remove users from the network in a targeted way, by revoking accounts, vs
|
||||
changing the password for everyone anytime a user needs to be excluded.
|
||||
|
||||
Corporate offices can keep their usernames and passwords, I guess, and we
|
||||
should come up with some other radio-based graffiti mechanism in any case. Let's
|
||||
just get rid of these pointless extra steps!
|
||||
|
||||
-----
|
||||
|
||||
That's the post. Making this proposal into reality would require a movement far
|
||||
larger than I care to organize, so we're just going to put this whole thing in
|
||||
the "fun, pointless yak-shave" bucket and move along. If you happen to know the
|
||||
architect of the next wifi protocol maybe slip this their way? Or just copy it
|
||||
and take the credit yourself, that's fine by me.
|
||||
|
||||
What's coming next? I'm taking a break from cryptic to catch up on some house
|
||||
keeping in the self-hosted arena. I've got a brand new password manager I'd like
|
||||
to try, as well as some motivation to finish getting my own email server
|
||||
properly set up (it can currently only send mail). At some point I'd like to get
|
||||
this blog gemini-ified too. Plus there's some services running in their
|
||||
vestigial docker containers on my server still, that needs to be remedied.
|
||||
|
||||
And somewhere in there I have to move too.
|
Loading…
Reference in New Issue
Block a user