[Enigmail] New 1.8 toolbar on the composition window

Doug Barton dougb at dougbarton.email
Wed Mar 18 08:23:04 CET 2015


On 3/17/15 11:03 PM, Daniel Kahn Gillmor wrote:
> 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

Yes, that's the default, and I have those as well (icons and text).

> 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).

They are not necessary to have as part of the compose window itself. The 
icons for encrypt and sign already change status when those features are 
enabled. That will serve for your "status" indicator. I experimented 
with moving those two buttons up to the composition toolbar, and it 
works ... I attached an example. It would be nice if the icons were a 
little cleaner and matched the existing style better, but it's a good 
start. Users for whom this is cramped and do not use S/MIME could simply 
delete that button.

The pubkey button should be right out. There is already a menu option 
for it for one-off use, and for users that want to imitate the S/MIME 
behavior there is already a checkable option in account prefs to do that.

For the users which need this ability to post keys along with their 
messages, it was already present, and very convenient.

And FWIW another reason not to encourage this behavior occurred to me. 
This list (for example) has a 40 KB limit on messages. I ran afoul of 
this when I attached the first screenshot in a message you never saw 
because it got held for moderation.

My key (after cleaning out stale/duplicate signatures) as attached by 
enigmail to an outgoing message is 92.5 KB. I have another key that is 
older and has more signatures that is probably larger.

>>>>> 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
> sessions:

You listed some good questions, and like you I don't want to get dragged 
down into arguing them point by point. However they are all questions 
that new users need to learn the answers to. Putting a shiny button for 
attaching their public key doesn't aid in that process.

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

Sort of, sure. And as above, the ability to emulate this behavior was 
already part of enigmail.

> Opportunistic encryption *is* enabled by default

Good news. :)

>>> 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 may regret asking this question, but why? For users who have not 
explicitly enabled signing and/or encryption what good thing will come 
from hitting them over the head with the fact that their messages are 
not signed or encrypted (just like they never have been in the past)?

Doug

-- 
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Enigmail-toolbar-2.jpg
Type: image/jpeg
Size: 19561 bytes
Desc: not available
URL: <https://lists.enigmail.net/pipermail/enigmail-users_enigmail.net/attachments/20150318/4ee2f555/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.enigmail.net/pipermail/enigmail-users_enigmail.net/attachments/20150318/4ee2f555/attachment-0001.sig>


More information about the enigmail-users mailing list