[Enigmail] New 1.8 toolbar on the composition window

Ian Mann ansus at neomailbox.ch
Wed Mar 18 07:10:22 CET 2015

It just seems common sense to send your key to a new contact. I use it all the time when making a new contact.

On 18/03/15 17:03, 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
> 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
> sessions:
>  * "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) :)
>           --dkg
> _______________________________________________
> enigmail-users mailing list
> enigmail-users at enigmail.net
> To unsubscribe or make changes to your subscription click here:
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.enigmail.net/pipermail/enigmail-users_enigmail.net/attachments/20150318/b692f643/attachment-0001.html>

More information about the enigmail-users mailing list