Getting to default encrypted/signed email (was: Re: [friam] and so it goes)

Jed Donnelley <capability-iCFHVraI1K1Wk0Htik3J/[email protected]> Mon, 18 Jan 2016 01:02:03 -0800
Newsgroups gmane.comp.capabilities.general
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--===============7826042374582883599==
Content-Type: multipart/alternative;
 boundary="------------040304060203050806090501"

This is a multi-part message in MIME format.
--------------040304060203050806090501
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 1/17/2016 9:25 PM, David Nicol wrote:
> As people in the comments at the ycombinator item id note, the problem
> is social rather then technological.

Thanks for the note David,

I'd very much like to better understand any of the social aspects of 
'the problem' - which I take to be that of getting to default encrypted 
and signed email.  I read through the comments on the ycombinator page.  
I agree that setting up and using GPG encryption as implemented in 
current email clients (at least my experience with Thunderbird) is a 
very painful process.  I've also had experiences like:

"/I just stopped doing this, because the only tangible impact was people 
asking why//my emails had weird incomprehensible junk in them. 
Admittedly this usually took//the form of mild derision rather than 
outright hostility./"

This is why I suggested an implementation change in email clients that 
would make such encryption and signing:  1. happen by default and 2.  be 
invisible.  In that case there would be never be any "weird 
incomprehensible junk" seen in emails.  I hope you agree that if the 
implementation is automatic and invisible then a situation like this, 
"/Three hours later I hadn't gotten it working and gave up*.*/" doesn't 
arise.  With this approach there is nothing to get working.  If there 
are other social problems that would still be there I very much want to 
learn about them before pursuing this topic further, so I appreciate any 
thoughts on the matter.

Even in the unusual case where a user changes their email client (e.g. 
with a reinstall) or otherwise changes their public/private key pair AND 
then receives an email from a contact before sending a new email to that 
contact, the email client could be coded to automatically reply with a 
"changed key" message to the sending client.  This then turns into the 
case where a contact sends a message from an email address that was 
formerly associated with a different public key.  As noted, I personally 
would like to be notified of such a change so I can probe to figure out 
what's going on, but people could ignore such notifications if they 
wished.  In that case neither user would be aware of the key change.  
Sure, in that case a user would be subject to a man in the middle 
'attack' where such a middle man could pose as a previously known end 
user. That can be important in the 1% of cases where it's vital that a 
person or institution is bound to a message exchange.  In those few 
cases people would have to be cognizant of such key changes and go 
through another binding handshake.  In the other 99% of cases I don't 
really care if I'm communicating securely to a man in the middle instead 
of some other entity /known without any binding/ at the other end of an 
email address.

When those very few situations do arise where it's important to have 
encrypted and signed emails that ARE bound to a person or institution, 
all the infrastructure would be in place and 'all' one need do is the 
binding.  As I noted, I believe this binding can be done quite easily, 
for example just by leveraging off of a secured web interface in many 
cases.  None of the tedious aspects typically associated with developing 
a "web of trust" (been there, done that) are needed for encrypted and 
signed email that is as good as public key encryption technology can 
support.  I don't believe that this situation is any more problematic 
than the learning that people have to go through to appreciate the value 
of "https://..." in Web URLs. Anybody who cares in the least could 
notice key changes and either clarify how they happened or in any case 
do a new binding with the new key.

Thanks for any time to respond with anything that might help me to 
understand other social problems that I'm missing.

Sincerely,

James E. (Jed) Donnelley  http://www.webstart.com/jed

<the rest is historical>

> I've been using e-mail long enough to remember when a
> good portion of the traffic on lists such as this one would have PGP
> signature blocks, and when
>
> https://en.wikipedia.org/wiki/Geek_Code
>
> was a brilliant parody of them, which fact is somehow absent from the
> wikipedia article on Geek Code.
>
> On Sun, Jan 17, 2016 at 2:35 PM, Jed Donnelley <capability-iCFHVraI1K1Wk0Htik3J/[email protected]> wrote:
>> On 1/8/2016 3:23 PM, Raoul Duke wrote:
>>
>> https://news.ycombinator.com/item?id=10867647
>>
>>
>> This topic of secure email is something that I feel frustrated to bursting
>> about (from the above):
>>
>> "email is not authenticated with GPG: it is a usability nightmare. Even many
>> technically apt people find it too much of a headache.":
>>
>> This seems so counter intuitive to me that I'm driven toward a "big brother"
>> conspiracy model.
>>
>> Here's how simple I believe it should be:
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>


--------------040304060203050806090501
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 1/17/2016 9:25 PM, David Nicol
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAFwScO9d-dQnDG_0k-Q7KavUv=3DG2dPn=3DSEFt1kiwBAagYMXbdw@mail.=
gmail.com"
      type=3D"cite">
      <pre wrap=3D"">As people in the comments at the ycombinator item id=
 note, the problem
is social rather then technological.</pre>
    </blockquote>
    <br>
    Thanks for the note David,<br>
    <br>
    I'd very much like to better understand any of the social aspects of
    'the problem' - which I take to be that of getting to default
    encrypted and signed email.=A0 I read through the comments on the
    ycombinator page.=A0 I agree that setting up and using GPG encryption
    as implemented in current email clients (at least my experience with
    Thunderbird) is a very painful process.=A0 I've also had experiences
    like:<br>
    <br>
    "<i>I just stopped doing this, because the only tangible impact was
      people asking why</i><i> my emails had weird incomprehensible junk
      in them. Admittedly this usually took</i><i> the form of mild
      derision rather than outright hostility.</i>"<br>
    <br>
    This is why I suggested an implementation change in email clients
    that would make such encryption and signing:=A0 1. happen by default
    and 2.=A0 be invisible.=A0 In that case there would be never be any
    "weird incomprehensible junk" seen in emails.=A0 I hope you agree tha=
t
    if the implementation is automatic and invisible then a situation
    like this, "<i>Three hours later I hadn't gotten it working and gave
      up<b>.</b></i>" doesn't arise.=A0 With this approach there is
    nothing to get working.=A0 If there are other social problems that
    would still be there I very much want to learn about them before
    pursuing this topic further, so I appreciate any thoughts on the
    matter.<br>
    <br>
    Even in the unusual case where a user changes their email client
    (e.g. with a reinstall) or otherwise changes their public/private
    key pair AND then receives an email from a contact before sending a
    new email to that contact, the email client could be coded to
    automatically reply with a "changed key" message to the sending
    client.=A0 This then turns into the case where a contact sends a
    message from an email address that was formerly associated with a
    different public key.=A0 As noted, I personally would like to be
    notified of such a change so I can probe to figure out what's going
    on, but people could ignore such notifications if they wished.=A0 In
    that case neither user would be aware of the key change.=A0 Sure, in
    that case a user would be subject to a man in the middle 'attack'
    where such a middle man could pose as a previously known end user.=A0
    That can be important in the 1% of cases where it's vital that a
    person or institution is bound to a message exchange.=A0 In those few
    cases people would have to be cognizant of such key changes and go
    through another binding handshake.=A0 In the other 99% of cases I
    don't really care if I'm communicating securely to a man in the
    middle instead of some other entity <i>known without any binding</i>
    at the other end of an email address.<br>
    <br>
    When those very few situations do arise where it's important to have
    encrypted and signed emails that ARE bound to a person or
    institution, all the infrastructure would be in place and 'all' one
    need do is the binding.=A0 As I noted, I believe this binding can be
    done quite easily, for example just by leveraging off of a secured
    web interface in many cases.=A0 None of the tedious aspects typically
    associated with developing a "web of trust" (been there, done that)
    are needed for encrypted and signed email that is as good as public
    key encryption technology can support.=A0 I don't believe that this
    situation is any more problematic than the learning that people have
    to go through to appreciate the value of <a class=3D"moz-txt-link-rfc=
2396E" href=3D"https://...">"https://..."</a> in Web URLs.=A0
    Anybody who cares in the least could notice key changes and either
    clarify how they happened or in any case do a new binding with the
    new key.<br>
    <br>
    Thanks for any time to respond with anything that might help me to
    understand other social problems that I'm missing.<br>
    <br>
    Sincerely,<br>
    <br>
    James E. (Jed) Donnelley=A0 <a class=3D"moz-txt-link-freetext" href=3D=
"http://www.webstart.com/jed">http://www.webstart.com/jed</a><br>
    <br>
    &lt;the rest is historical&gt;<br>
    <br>
    <blockquote
cite=3D"mid:CAFwScO9d-dQnDG_0k-Q7KavUv=3DG2dPn=3DSEFt1kiwBAagYMXbdw@mail.=
gmail.com"
      type=3D"cite">
      <pre wrap=3D"">I've been using e-mail long enough to remember when =
a
good portion of the traffic on lists such as this one would have PGP
signature blocks, and when

<a class=3D"moz-txt-link-freetext" href=3D"https://en.wikipedia.org/wiki/=
Geek_Code">https://en.wikipedia.org/wiki/Geek_Code</a>

was a brilliant parody of them, which fact is somehow absent from the
wikipedia article on Geek Code.

On Sun, Jan 17, 2016 at 2:35 PM, Jed Donnelley <a class=3D"moz-txt-link-r=
fc2396E" href=3D"mailto:capability-iCFHVraI1K1Wk0Htik3J/[email protected]">&lt;capability@webstart.=
com&gt;</a> wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">On 1/8/2016 3:23 PM, Raoul Duke wrote:

<a class=3D"moz-txt-link-freetext" href=3D"https://news.ycombinator.com/i=
tem?id=3D10867647">https://news.ycombinator.com/item?id=3D10867647</a>


This topic of secure email is something that I feel frustrated to burstin=
g
about (from the above):

"email is not authenticated with GPG: it is a usability nightmare. Even m=
any
technically apt people find it too much of a headache.":

This seems so counter intuitive to me that I'm driven toward a "big broth=
er"
conspiracy model.

Here's how simple I believe it should be:
</pre>
      </blockquote>
      <pre wrap=3D"">_______________________________________________
cap-talk mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email protected]=
s.org">[email protected]</a>
<a class=3D"moz-txt-link-freetext" href=3D"http://www.eros-os.org/mailman=
/listinfo/cap-talk">http://www.eros-os.org/mailman/listinfo/cap-talk</a>

</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------040304060203050806090501--

--===============7826042374582883599==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk

--===============7826042374582883599==--