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

Tristan Slominski <[email protected]> Mon, 18 Jan 2016 11:59:29 +0000
Newsgroups gmane.comp.capabilities.general
Message-ID <CAOXxbHwBYPsEDwTLg1z-Y8dzSHp1F+GZcbD2U+fzMYu=0x+hxQ@mail.gmail.com>
--===============0861333169852505556==
Content-Type: multipart/alternative; boundary=001a11407aacd81ccf05299a7cbb

--001a11407aacd81ccf05299a7cbb
Content-Type: text/plain; charset=UTF-8

The approach you describe sounds familiar to what Apple does with iMessage:
http://techcrunch.com/2014/02/27/apple-explains-exactly-how-secure-imessage-really-is

The social problem seems to not be an issue for them. The difference
between the systems appears to be that there is no central point of control
over email clients to roll out a switch and that there is no central point
of trust for email clients to agree on.

The transition from insecure system to a secure one seems to be the crux of
the problem to me. That's what results in "why are you sending me this
junk" experiences.

On Mon, Jan 18, 2016, 03:02 Jed Donnelley <capability-iCFHVraI1K1Wk0Htik3J/[email protected]> wrote:

> 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://..." <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]> <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 [email protected]://www.eros-os.org/mailman/listinfo/cap-talk
>
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>

--001a11407aacd81ccf05299a7cbb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">The approach you describe sounds familiar to what Apple does=
 with iMessage: <a href=3D"http://techcrunch.com/2014/02/27/apple-explains-=
exactly-how-secure-imessage-really-is">http://techcrunch.com/2014/02/27/app=
le-explains-exactly-how-secure-imessage-really-is</a></p>
<p dir=3D"ltr">The social problem seems to not be an issue for them. The di=
fference between the systems appears to be that there is no central point o=
f control over email clients to roll out a switch and that there is no cent=
ral point of trust for email clients to agree on.</p>
<p dir=3D"ltr">The transition from insecure system to a secure one seems to=
 be the crux of the problem to me. That&#39;s what results in &quot;why are=
 you sending me this junk&quot; experiences.</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Jan 18, 2016, 03:02=
=C2=A0Jed Donnelley &lt;<a href=3D"mailto:capability-iCFHVraI1K1Wk0Htik3J/[email protected]">capabili=
ty-iCFHVraI1K1Wk0Htik3J/[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>On 1/17/2016 9:25 PM, David Nicol
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>As people in the comments at the ycombinator item id note, the p=
roblem
is social rather then technological.</pre>
    </blockquote>
    <br>
    Thanks for the note David,<br>
    <br>
    I&#39;d very much like to better understand any of the social aspects o=
f
    &#39;the problem&#39; - which I take to be that of getting to default
    encrypted and signed email.=C2=A0 I read through the comments on the
    ycombinator page.=C2=A0 I agree that setting up and using GPG encryptio=
n
    as implemented in current email clients (at least my experience with
    Thunderbird) is a very painful process.=C2=A0 I&#39;ve also had experie=
nces
    like:<br>
    <br>
    &quot;<i>I just stopped doing this, because the only tangible impact wa=
s
      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>&quot;<br>
    <br>
    This is why I suggested an implementation change in email clients
    that would make such encryption and signing:=C2=A0 1. happen by default
    and 2.=C2=A0 be invisible.=C2=A0 In that case there would be never be a=
ny
    &quot;weird incomprehensible junk&quot; seen in emails.=C2=A0 I hope yo=
u agree that
    if the implementation is automatic and invisible then a situation
    like this, &quot;<i>Three hours later I hadn&#39;t gotten it working an=
d gave
      up<b>.</b></i>&quot; doesn&#39;t arise.=C2=A0 With this approach ther=
e is
    nothing to get working.=C2=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 &quot;changed key&quot; message to the sendi=
ng
    client.=C2=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.=C2=A0 As noted, I personally would like to be
    notified of such a change so I can probe to figure out what&#39;s going
    on, but people could ignore such notifications if they wished.=C2=A0 In
    that case neither user would be aware of the key change.=C2=A0 Sure, in
    that case a user would be subject to a man in the middle &#39;attack&#3=
9;
    where such a middle man could pose as a previously known end user.=C2=
=A0
    That can be important in the 1% of cases where it&#39;s vital that a
    person or institution is bound to a message exchange.=C2=A0 In those fe=
w
    cases people would have to be cognizant of such key changes and go
    through another binding handshake.=C2=A0 In the other 99% of cases I
    don&#39;t really care if I&#39;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&#39;s important to hav=
e
    encrypted and signed emails that ARE bound to a person or
    institution, all the infrastructure would be in place and &#39;all&#39;=
 one
    need do is the binding.=C2=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.=C2=A0 None of the tedious aspects typicall=
y
    associated with developing a &quot;web of trust&quot; (been there, done=
 that)
    are needed for encrypted and signed email that is as good as public
    key encryption technology can support.=C2=A0 I don&#39;t believe that t=
his
    situation is any more problematic than the learning that people have
    to go through to appreciate the value of <a href=3D"https://..." target=
=3D"_blank">&quot;https://...&quot;</a> in Web URLs.=C2=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&#39;m missing.<br>
    <br>
    Sincerely,<br>
    <br>
    James E. (Jed) Donnelley=C2=A0 <a href=3D"http://www.webstart.com/jed" =
target=3D"_blank">http://www.webstart.com/jed</a><br>
    <br>
    &lt;the rest is historical&gt;<br>
    <br>
    <blockquote type=3D"cite">
      <pre>I&#39;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 href=3D"https://en.wikipedia.org/wiki/Geek_Code" target=3D"_blank">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 href=3D"mailto:capability=
@webstart.com" target=3D"_blank">&lt;capability-iCFHVraI1K1Wk0Htik3J/[email protected]&gt;</a> wrote:
</pre>
      <blockquote type=3D"cite">
        <pre>On 1/8/2016 3:23 PM, Raoul Duke wrote:

<a href=3D"https://news.ycombinator.com/item?id=3D10867647" target=3D"_blan=
k">https://news.ycombinator.com/item?id=3D10867647</a>


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

&quot;email is not authenticated with GPG: it is a usability nightmare. Eve=
n many
technically apt people find it too much of a headache.&quot;:

This seems so counter intuitive to me that I&#39;m driven toward a &quot;bi=
g brother&quot;
conspiracy model.

Here&#39;s how simple I believe it should be:
</pre>
      </blockquote>
      <pre>_______________________________________________
cap-talk mailing list
<a href=3D"mailto:[email protected]" target=3D"_blank">cap-talk@mai=
l.eros-os.org</a>
<a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" target=3D"_bla=
nk">http://www.eros-os.org/mailman/listinfo/cap-talk</a>

</pre>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>
cap-talk mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">cap-talk@mai=
l.eros-os.org</a><br>
<a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" rel=3D"norefer=
rer" target=3D"_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a>=
<br>
</blockquote></div>

--001a11407aacd81ccf05299a7cbb--

--===============0861333169852505556==
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

--===============0861333169852505556==--