[liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain

[micah]

Eleanor Saitta <ella at dymaxion.org> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 2013.06.12 11.54, micah wrote:
>> I'm constantly hearing from people who complain about the UI in
>> things like gnupg. I feel your pain, I do not want to argue that
>> you are wrong. However, I do want to argue that complaining doesn't
>> help to solve the problem. I've asked every single person who has
>> complained about this problem to me recently, "have you filed a bug
>> about your issues?" and everyone's response is: "no".
>> 
>> I've done this, and guess what? It works! I filed bugs and had 
>> discussions on the gnupg mailing list that have made your
>> experience with that tool a little bit better. There are many ways
>> that I think it can be improved still, don't get me wrong, but the
>> gnupg developers are reasonable people who want to make the
>> software better, and probably have been hearing these complaints
>> for years and years and would welcome a way to make people stop
>> complaining.
>> 
>> It seems there are a lot of people out there who have a clear idea
>> of what is good and what is bad UI and are pretty vocal about when 
>> something is bad. How about turning that into clear bugs that
>> describe better workflow and UI? You dont have to be a crypto nerd,
>> or a C programmer to make this stuff better and easier to use.
>
> Is there any point in filing a bug that says "Please have a
> professional designer re-work all use flows in this system from
> scratch"?  (No.) 

I agree, there is not much point in that. 

> Is there any point in filing a bug that says "Please remove features
> X, Y, Z, Q, R, N, and M because they're too confusing for novice
> users"?  (No, especially when X is "the entire web of trust".)

I somewhat disagree with you on this point. There is a point to filing a
bug that says, "Please remove the choice of RSA/DSA/Elgamal from the gpg
--gen-key process and just automatically use the default unless the user
has passed --advanced. It is confusing for a user who is just learning
to use the tool to have to make this choice."

> "Filing bugs" isn't enough -- it's an entire design effort.

I do not think that it is one or the other. Don't throw out the bugs or
usability enhancements because you think that the whole thing needs to
be redesigned. 

> Individuals may see a thing and think "hey, this could be changed",
> but what's needed is a top-to-bottom redesign, and that does not
> translate into a simple set of "clear bugs".  I don't believe that the
> GPG designers have the resources available to do this design effort as
> it stands, and it's not just them, it's the entire ecosystem that
> needs to be involved and work together.

I disagree. I've been working with people who have been doing this sort
of iterative changes with the software for years and things have gotten
better. 

It is actually not that hard to make significant usability changes
without needing to make top-to-bottom changes. 

For example, here is a bug I filed which coalesces my experiences doing
gnupg trainings with different activists and the stumbling blocks that
we ran into:

https://bugs.g10code.com/gnupg/issue1506?@ok_message=msg%204634%20created%0Aissue%201506%20created&@template=item

> We'd love to see this fixed.  If it was this easy, it would have been
> done years ago.

You would be surprised the changes that you can get if you ask for
them and describe clearly why they are needed. It helps a lot if you can
also clearly describe a better alternative. If you know how to code and
have time, then providing a patch will go even further. Although patches
are always welcome, they are not required.

For a really long time, smart cryptographers have been writing this
software, their heads are focused on doing the correct technical thing
and that doesn't always translate into an easy experience. They have
been doing this so long that they cannot see how this could be any
different. It is up to us who aren't so deeply stewed in hashing
algorithms and trust metrics, we who work with people who provide us the
feedback who can synthesize it and bring that back to those people in
who know the code so that they can make it more usable.

If we do not do that, it will not happen, ever. No matter how much we
complain in places where they will never hear us.

My experience has been that software gets better when I point out the
problems to the appropriate place that the developers have asked for
those things to be put. Sometimes that takes several years, sometimes I
get lucky and the change happens in a weekend. It very rarely gets
better on its own. 

You may think that the whole crypto world needs to be thrown out and we
need to start again, and you see that as an intractably impossible
problem. I see things differently because I've seen annoying things
iteratively become usable over time, and I've seen usable things become
frustrating and unusable after a design overhaul. The only way either of
those things work is if you involve users in the feedback loop. You
can't just redesign everything and then throw it out there without doing
user testing to figure out what design assumptions you made are not
shared with others.

We are the intermediaries between those who code and those who use, if
we fail to do our job we have only ourselves to blame.

micah