[Enigmail] New 1.8 toolbar on the composition window

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Mar 18 07:03:24 CET 2015

On Wed 2015-03-18 01:39:06 -0400, Doug Barton wrote:
> I buy that argument, but it seems much more reasonable to me to make 
> sign and encrypt buttons that show up in the composition toolbar. This 
> would mean that we get the same usability improvement, but no additional 
> screen real estate would be necessary.

My composition toolbar currently already has:

 Send | Spelling | Attach | S/MIME | Save

Depending on how you select icons and text, these can take up a fair
amount of width already.  The four enigmail features
(encrypt,sign,pubkey,status) would also need to be effectively grouped
somehow conceptually (though i understand it sounds like you don't
particularly want pubkey or status at all).

>>>> The "Attach My Public Key" button is almost certainly a bad idea, as
>>>> it will cause new users to think that this is an action that should
>>>> be done frequently, rather than rarely.
>> This is one of the most common actions that new users *should* take,
> Um, since when? Hasn't the CW always been to have the user upload their 
> key to a key server? If they are corresponding with someone who isn't 
> smart enough to get the key Id from the signature, the new user can 
> simply send the fingerprint to their correspondent, and they can 
> download the key that way.

I used to think so too.  I'm not as sure any more, and attaching the
public key like this avoids a lot of uncertainty and doubt for new
users.  in particular, i've seen these questions during training

 * "What's a keyserver?"

 * "how do i tell enigmail to send my key to the public keyservers?"

 * "Wait, which keyserver should i publish to?"

 * "You mean my e-mail address will be listed up there publicly? i don't
    feel comfortable with this..."

 * "You think i should e-mail my friend with my fingerprint?  what's my
   fingerprint?  how do i get enigmail to put it in the message for me?"

 * "ok, i've uploaded my public key to the keyservers, and sent my
   friend my fingerprint; how does my friend get my key now?"

 * "hm, my friend is trying to get it, but the keyserver says it doesn't
    have it; how long do we have to wait?"  (this is often caused by
    pool propagation delay)

and so on.

I'm not saying all of these concerns are dealbreakers, or even that any
of them are unanswerable.  But the mechanism enigmail 1.8 is providing
avoids basically all of them.

S/MIME by default includes the user's certificate in each message, iirc,
perhaps to try to short-circuit this entire process as well.

I don't particularly *want* users to attach their keys willy-nilly, and
i don't want everyone to stop using the keyservers (they're quite useful
for initial contact and search), but i think ithis is a useful
complement to that approach.

>> I see this as comparable to browsers degrading the UI for http:
>>    http://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
> Um, no, that's not the same thing at all. It's quite disturbing that you 
> don't see the many ways that they are different.
> Routine *encryption* has some similarities to deprecating http vs. 
> https, but we already have the opportunistic encryption feature. That 
> feature should be enabled by default (if it isn't already).

Opportunistic encryption *is* enabled by default, and it clears the red
warning when it gets turned on.  i'm curious to hear details of why this
is so radically different from 

>> This is entirely a good thing.  The red warning will go away if you
>> encrypt, even if you don't sign.
>> If we don't want to encourage routine signing, maybe the warning could
>> stay red as long as it's unencrypted?  Or maybe it could be:
> I'm sorry, but this is total nonsense. Routine signing is a BAD idea. 
> Messages sent to mailing lists cannot be encrypted. And I use 
> thunderbird for business communication where I cannot do either, ever.

fwiw, i agree with you that associating RED with unsigned and NOTRED
with signed maybe doesn't seem important to me.  I'd prefer the warning
color/font to be used with unencrypted mail, and the non-warning
color/font to be used with encrypted mail, regardless of signing.

Unencrypted mail will be in the clear, just like the many web sites we
still use that are in the clear (for routine business communications
like http://amazon.com/, for example).  Users should know about this.

> I am conducting an experiment in the efficacy of PGP/MIME signatures. 
> This message should be signed. If it is not, or the signature does not 
> validate, please let me know how you received this message (direct, or 
> to a list) and the mail software you use. Thanks!

Message received on-list and signature validated properly (albeit with
mailman's appended footer outside the signature) :)


More information about the enigmail-users mailing list