Search Mailing List Archives
[liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
brianc at smallworldnews.tv
Wed Jun 12 13:48:41 PDT 2013
+1 Jillian Anne and Paul.
On Jun 12, 2013 7:24 PM, "micah" <micah at riseup.net> wrote:
> 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
> 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:
> > 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.
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys at stanford.edu or changing your settings at
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the liberationtech