Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

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

Brian Conley brianc at smallworldnews.tv
Wed Jun 12 13:48:41 PDT 2013


+1 Micah

+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
> 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
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130612/9e2f8394/attachment-0001.html>


More information about the liberationtech mailing list