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@enigmail.net > To unsubscribe or make changes to your subscription click here: > https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net >
_______________________________________________ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
